Running Apps & Databases on BYOC

Deploying apps to your own server, default URLs and custom domains, HTTPS, resource limits, logs, and self-hosted databases.

Fri Oct 02 2026 00:00:00 GMT+0000 (Coordinated Universal Time)

Once your server is Healthy (see Setting Up a BYOC Server), almost everything works exactly as it does on Raklane's managed compute. This page covers what's the same, and the handful of things that are different.

Deploying an app to your server

A new app

Create the app as usual (see Getting Started). On the wizard's last step, Review, choose where it runs:

PAYG cluster — Raklane's managed compute, billed per resource.
Dedicated cluster — Raklane's managed compute, using your dedicated hosting subscription.
BYOC — one of your own registered servers. Pick the server from the list; only Healthy servers can receive a deploy.

An existing app

Open the app, go to Settings → Deployment location, select BYOC, pick a server, and click Move deployment. This immediately deploys the app's current source to the new server using the normal zero-downtime process. Once it's live there, the app's old location is retired.

After that, every Deploy, Redeploy, GitHub auto-deploy, and Retry goes to the same server until you move it again.

What's the same

Everything about the deploy itself:

Builds with Cloud Native Buildpacks (on Raklane's build system, not your server).
Zero-downtime rollouts, health checks, the safety-net bake window, and automatic rollback.
Replicas, CPU/memory/storage requests and limits, and changing them without redeploying.
Environment variables and secrets.
Pausing, resuming, and deleting apps.
Build logs, runtime logs, status, metrics, and live process lists in the dashboard. Metrics are reported by the server's agent over its existing connection — see Metrics on a BYOC server.

What's different

Capacity is your server's. Raklane only places an app on your server if its resource requests fit what your server has left. If a deploy is rejected for capacity, lower the app's requests, remove something else from the server, or use a bigger server.
Your app's container runs on your hardware, so its performance, uptime, and network depend on your server and provider.
Runtime logs are fetched when you look at them, straight from your server, rather than streamed continuously.

Your app's URL

Every app on a BYOC server gets a free default URL made of the app's subdomain, your server's IP address, and your Raklane installation's BYOC domain:

https://my-app-a1b2c3.203.0.113.10.byoc.example.com

The BYOC domain (byoc.example.com here) is a wildcard-DNS domain chosen by your Raklane installation. It may be a public service like sslip.io or nip.io, or a domain the installation runs itself. Any hostname under it resolves to the IP written inside the name, so the URL works immediately — there's no DNS for you to set up. You'll find the exact URL on the app's overview page once the deploy is active. See how the default URL works.

If your server's IP ever changes (for example, you rebuild the VPS), the default URL changes with it.

Custom domains

To serve your app on your own domain (app.example.com):

Open the app's Domains page and add the hostname.
At your DNS provider, create an A record for that hostname pointing at your server's public IP — not at Raklane. (You can copy the IP from the server's card on the Clusters page.)
Wait for Raklane to verify it. Raklane periodically checks that the hostname resolves to your server's IP. Once it does, the domain changes from pending to verified. If it stays pending, the Domains page shows what the hostname currently resolves to, so you can tell a wrong record from a DNS propagation delay.
Visit https://app.example.com. The first request triggers certificate issuance, which takes a few seconds; after that, HTTPS just works and renews automatically.

A CNAME also works, as long as it ultimately resolves to your server's IP. If you use a proxying CDN (such as Cloudflare with the orange cloud enabled), DNS resolves to the CDN instead of your server, so verification fails. Use DNS-only mode, at least until the domain is verified and its certificate issued.

HTTPS, in detail

Certificates come from a public certificate authority and are obtained by Caddy on your server on demand — the first time a request for that hostname arrives.
Before requesting one, Caddy asks Raklane whether the hostname is allowed. Only your apps' default URLs and verified custom domains are allowed, so nobody can make your server request certificates for domains you don't control.
Port 80 must be reachable from the internet for issuance and renewal, even though your app is served on 443.
On a server with a private IP (LAN, local VM, behind NAT), Raklane serves apps over plain HTTP only, because no certificate authority could ever reach the server to issue one.

Reaching your app from other apps

Apps on the same BYOC server can reach each other over the server's internal container network. Apps on different servers (or on Raklane's managed compute) should talk to each other over their public URLs.

Databases on your server

You can run a Postgres or MySQL database on your BYOC server, the same way you'd run one on Raklane's infrastructure (see Databases):

From your project's Databases page, click to create a database.
Choose where it runs: BYOC, then pick your server.
Choose the engine, version, and name, and set the CPU, memory, and storage you want it to have — on BYOC you size it yourself, instead of picking a hosting plan.
Choose Network access (see below), and create it.

A BYOC database has no hosting charge. If your installation charges a BYOC management fee, each database counts toward it — see BYOC Billing.

Network access

Local (the default) — reachable only by your apps on the same server, over its internal container network. This is the right choice for an app talking to its own database: nothing is exposed to the internet.
External — additionally reachable from outside, for example from your laptop or another server. The Databases page shows the external host and port to use.

How an external database is reached depends on how your Raklane installation is set up:

Relayed through Raklane. The external address is on Raklane's own domain (it looks like db-… followed by your installation's domain). Connections go to Raklane, which forwards them to your server over the agent's existing encrypted connection. Your server doesn't need any database port open.
Direct to your server. The external address is your server's own IP (or its External host, if you set one). In this case, open the database's port in your server's firewall and your cloud provider's firewall, and make sure the address is reachable from wherever you're connecting.

If your server is behind NAT and the address shown is a private IP, set the server's External host (Clusters → the server's menu → Edit) to its real public IP or hostname.

Your data, your responsibility

A BYOC database's data lives on your server's disk (under /var/lib/raklane-agent/). This means:

Raklane doesn't back it up. Use your provider's disk snapshots, or schedule your own pg_dump/mysqldump.
It stays on that server. Moving the database to a different server means exporting and importing the data yourself.
Decommissioning the server requires deleting the database first.

The password is shown only once, when the database is created — copy it straight away.