Guides
Deploy to your own server
Run your app on a server you rent, for a few euros a month and no lock-in, with previews per pull request.
Most apps on Launchpad run on Vercel, which is the fastest way to get live and free to start. The other option is a server you rent yourself — a €4/month box at Hetzner, a $6 droplet, a machine in your own office — with Launchpad deploying onto it exactly as it deploys to Vercel.
You might want this if you'd rather pay a flat few euros a month than per-seat pricing, if your data has to stay in a particular country, or if you simply don't want your app's home to be a company that can change its terms.
What you should know first
A single server is not a content delivery network, and being honest about that matters more than selling you the idea:
- One machine, one place. Visitors far from it wait longer than they would on Vercel's edge. You can put Cloudflare's free plan in front to cache static files, which closes much of the gap.
- No failover. If the box goes down, your app is down until it comes back. Vercel and Render run redundant infrastructure; one server doesn't.
- Backups are yours. A database Launchpad puts on the server is backed up daily, but to the server's own disk: if the disk dies, so do the copies. Add S3 storage in Coolify to keep them somewhere else.
- Updates are yours. The operating system and Coolify both need occasional patching.
For a side project, an internal tool, a demo, or an app with users in one region, this is a good trade. For something people depend on around the clock, stay on Vercel until you have someone to carry a pager.
How it works
Launchpad doesn't install anything on your server and never asks for SSH access or a root password. Instead you run Coolify on the box — an open-source, Apache-2.0 licensed deployment platform — and give Launchpad its address and an API token. From then on Launchpad talks to Coolify's HTTP API the same way it talks to Vercel's or Render's.
That boundary is deliberate. The worst secret a service can hold is root on someone else's machine, so Launchpad holds a token you can revoke in one click instead, and your server's keys never leave your hands.
Set it up
1. Get a server. Any provider works. Ubuntu 22.04 or 24.04, at least 2 CPUs and 4 GB of RAM — 8 GB if you'll also run a database on it. Builds are the hungry part.
2. Install Coolify. One command from their install guide, run on the server. It takes a few minutes and ends with a web interface on port 8000.
3. Give Coolify a domain and a certificate. Point something like coolify.example.com at the
server's IP and set it in Coolify's settings, so its own interface is on HTTPS. Launchpad will not
send your token over plain HTTP.
4. Turn the API on. In Coolify: Settings → Advanced → API access. Self-hosted installs ship with it off.
5. Make a token. Keys & Tokens → API Tokens, with write access. It's shown once.
6. Tell Launchpad. On the Connections screen, add:
| Setting | What it is |
|---|---|
COOLIFY_URL | Your Coolify's address, e.g. https://coolify.example.com |
COOLIFY_API_TOKEN | The token from step 5 |
COOLIFY_SERVER_UUID | Only if Coolify manages more than one server |
COOLIFY_GITHUB_APP_UUID | Only for a private repo — see below |
7. Point the app at it. When you import a repository, choose Your own server under
"Hosted on". Or, in launchpad.json:
{
"name": "shop",
"repo": "acme/shop",
"framework": "nextjs",
"hosting": { "provider": "coolify" }
}
Use "coolify" for anything that runs a server — Next.js, Nuxt, Remix, an Express API. Use
"coolify-static" for a site that builds to files, and say where they land:
{ "hosting": { "provider": "coolify-static", "outputDir": "dist" } }
Then deploy as usual. Launchpad creates the project and the application, puts every service's keys on it as environment variables, and starts the build.
Private repositories
Cloning over https only works for a public repo. For a private one, connect a GitHub App inside
Coolify (Sources → GitHub), then set COOLIFY_GITHUB_APP_UUID to its uuid. Launchpad will use
it for the clone. Without it the deploy still runs, and the log tells you this is why a private repo
would fail.
What you get
- A deploy on every push. If you connected a GitHub App in Coolify, Coolify builds each push
itself. If not, Coolify never hears about pushes, so Launchpad starts the deploy instead: it sees
every push through its own GitHub App. (Using only the command line, run
launchpad up, or add the webhook Coolify shows under the app's Webhooks.) - A deployment per pull request. Coolify serves each open pull request on its own address, so a reviewer can click a link instead of pulling the branch. Launchpad turns this on when it creates the app.
- HTTPS automatically. Set
domaininlaunchpad.jsonand add an A record to the server's IP; Coolify's proxy gets the certificate from Let's Encrypt and renews it. - Health checks, alerts and the status page work unchanged — they probe the app's address, and don't care what's behind it.
What stays where it is
Choosing your own server for hosting doesn't move anything else. Your database is still on Neon or Supabase, email still on Resend, storage still on R2, unless you move those too. That's usually what you want: a server going down shouldn't take your data with it.
Or put the database on the server too
For the cheapest setup, or data that must stay on your machine, Postgres can run on the same server:
{
"hosting": { "provider": "coolify" },
"services": { "database": { "provider": "coolify" } }
}
In the import wizard, pick Your own server for hosting, then On my server for the database.
- Nothing on the internet can reach it. It has an address only on the server's private network,
which your app uses through
DATABASE_URL. That's also why it needs the app on the same server: an app on Vercel, or a worker on Render, couldn't connect, and Launchpad refuses that setup rather than open the database to the internet. - Backed up daily, keeping the last 7, from the first deploy. The copies are on the server's own disk, so add S3 storage in Coolify (Storages) and turn it on for the backup to keep copies off the machine.
- Previews don't get a copy. On Neon, each pull request's preview gets its own database; on your own server, previews have none.
- Deleting the project deletes the database and its data, as it does on Neon or Supabase.
Launchpad sets the database's password itself and keeps it with your other secrets, so it can always rebuild the connection string, even if Coolify's token can't read passwords back.
Leaving
Nothing here locks you in, in either direction. launchpad down removes the application from your
server and leaves the server alone. To go back to Vercel, change hosting.provider to "vercel" and
deploy; to leave Launchpad entirely, your apps keep running in Coolify, which you own and can drive
yourself.
Something missing or wrong? Edit this page on GitHub or email hello@axonscape.com.