Where Your App Runs

Choosing between a PAYG cluster, a Dedicated cluster, and your own server (BYOC) — and moving an app between them.

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

Every app runs in one of three places, called its deployment location. You choose it on the last step of creating an app, and you can change it at any time.

The three options

PAYG cluster (the default)

Your app runs on Raklane's managed servers, and you pay for the resources it uses, deducted from your wallet as you go.

Best for: getting started, side projects, apps with variable or low usage.
You manage: nothing but your app.
Billing: per resource (CPU, memory, storage), at the rates on the Pricing page.

Your app runs on Raklane's managed servers, using resources reserved for you by a dedicated hosting subscription — for example, "2 Cores / 4 GB" billed hourly or monthly. Each app you put there takes its configured CPU, memory, and storage out of the subscription's pool.

Best for: steady production workloads where you want a predictable, flat price.
You manage: nothing but your app.
Billing: a flat hourly or monthly subscription, charged up front from your wallet. Requires an active subscription (Billing → Dedicated hosting).

BYOC (Bring Your Own Compute)

Your app runs on a server you own and have registered with Raklane — any Ubuntu or Debian machine with a public IP.

Best for: using servers you already pay for, specific regions or hardware, keeping traffic on your own infrastructure, or large workloads where your own servers are cheaper.
You manage: the server itself (uptime, OS updates, disk, backups of any databases on it).
Billing: you pay your provider for the server; Raklane charges at most a small management fee. See BYOC Billing.

Side-by-side

	PAYG cluster	Dedicated cluster	BYOC
Servers owned by	Raklane	Raklane	You
Setup needed	None	Subscribe to a plan	Register a server (guide)
Price model	Per resource used	Flat subscription	Your server bill, plus a management fee if any
Default URL	Under your Raklane installation's domain	Under your Raklane installation's domain	Your server's IP under your installation's BYOC domain
Custom domain DNS points at	Raklane	Raklane	Your server's IP
Visitor traffic goes through	Raklane's ingress	Raklane's ingress	Straight to your server
Capacity	Raklane's managed capacity	Your subscription's pool	Your server's CPU/memory
Server maintenance	Raklane	Raklane	You
Builds	On Raklane	On Raklane	On Raklane
Rollouts, health checks, rollback, logs, metrics	✓	✓	✓

Choosing for a new app

On the create-app wizard's Review step, pick PAYG cluster, Dedicated cluster, or BYOC:

Dedicated cluster is only selectable with an active dedicated hosting subscription. The page shows how much of the subscription's pool the app will take.
BYOC lists your registered servers. Pick a Healthy one. If you haven't registered any, there's a link to Clusters to add one.

Moving an existing app

Open the app and go to Settings → Deployment location. The current location is shown at the top.
Choose the new location (and, for BYOC, the server).
Click Move deployment.

Moving performs a real deploy to the new location right away, using the normal zero-downtime process. The app keeps serving from its old location until the new one passes its health checks. After that, every Deploy, Redeploy, and auto-deploy goes to the new location.

Things to update when you move:

Custom domains — if you move between managed compute and BYOC, update your DNS. Managed apps' domains point at Raklane; BYOC apps' domains point at your server's IP.
Default URL — a BYOC app's default URL is based on its server's IP, so it changes when you move to or from BYOC, or between servers.
Databases — databases don't move with an app. If the app used a local database on a BYOC server, it can only reach it from that same server.

Waiting for a server

On managed compute, Raklane may start servers only when they're needed. If none is running when you deploy, the deploy shows waiting for server for a few minutes while one starts. Your build runs in parallel, so the extra wait is often short. Nothing is wrong — the deploy continues by itself once the server is ready.