Deploying Your App

Connecting a Git repo or archive, triggering a deploy, replicas, resource limits, rolling deploys, and rollbacks.

Mon Aug 10 2026 00:00:00 GMT+0000 (Coordinated Universal Time)

This covers everything involved in getting your code running on Raklane, from first deploy onward.

Choosing a source

Every App gets its code from exactly one place at a time, configured on the App's Source tab:

Git repository — a repository URL and a ref (branch, tag, or commit) to build from. Works with GitHub, GitLab, and Bitbucket URLs. Public repos need nothing extra; private repos need an access token — see Secrets → Private repositories.
Archive upload — no Git repo? Zip or tar your project and upload it directly instead.

Changing the source (a new branch, a different repo, a fresh archive) doesn't redeploy anything by itself — it just changes what the next deploy will build from.

Each App runs on a PAYG cluster, a Dedicated cluster, or your own BYOC server. You pick this when creating the App, and can change it from Settings → Deployment location — see Where Your App Runs. Every deploy goes to the App's current location.

Triggering a deploy

Click Deploy on your App's dashboard. This:

Records a new Release and returns immediately — deploying is asynchronous, so the dashboard shows the Release's status changing over time rather than making you wait.
Builds a container image from your current source (via Cloud Native Buildpacks — no Dockerfile needed for most common languages/frameworks).
Starts new container replica(s) from that image and waits for them to pass a health check.
Once every new replica is healthy, cuts traffic over to them.

Watch this happen on the App's Status page — see Logs & Status.

If you click Deploy again while a deploy is already in progress, it doesn't queue up a second one — it's folded into the release that's already being built/health-checked.

Zero-downtime by default

Deploying doesn't stop your currently-running app first. New replicas start up and get health-checked alongside the old ones, which keep serving traffic the whole time. Only once every new replica is confirmed healthy does traffic cut over — so a bad deploy never takes your app offline. If a new replica fails its health check, the deploy is aborted before cutover: the old release is left running untouched, and the new Release is marked failed.

The safety-net bake window

Even after cutover, Raklane keeps the previous Release warm for a short window rather than stopping it immediately (you'll see the new Release's status as baking during this time). If something goes wrong that the initial health check didn't catch, Raklane automatically rolls back to the previous Release with no action needed from you — the failed Release is marked rolled_back. If nothing goes wrong, the window elapses on its own, the Release moves to active, and the old one is finally stopped.

If you want to force that rollback immediately instead of waiting out the window, cancel the deploy (see below).

Canceling a deploy

While a deploy is still building or waiting on its health check, you can cancel it — this genuinely interrupts the in-progress build/health-check wait, not just hides it in the dashboard, and leaves whatever was running before completely untouched.

If you cancel during the bake window described above, it forces an immediate rollback to the previous Release instead of waiting for the window to elapse.

Replicas

By default, an App runs a single replica (one container instance). To run more — for redundancy, or to handle more traffic — set the replica count when deploying. If you don't specify one on a redeploy, Raklane keeps whatever count your previous Release was running.

Resource limits

You can set a CPU, memory, and storage request and limit per replica:

The request is what Raklane reserves for your app when deciding whether a deploy fits on available compute. If you don't set one, a small system default is used.
The limit is a hard ceiling: CPU usage beyond it is throttled, memory usage beyond it gets your container stopped (out-of-memory), and storage is enforced by the container runtime. Leave it unset for no ceiling.

Not sure what to set? Deploy with a generous limit, then check the app's Metrics tab: it shows real usage against your limits and suggests when to size up or down.

If a request would exceed what's currently available, the deploy is rejected up front (before any build even starts) rather than left to fail partway through. On Raklane's managed compute, Raklane may instead start an extra server for you — the deploy then shows waiting_for_server until it's ready. On a BYOC server, capacity is whatever your server has.

Changing replicas or resources without redeploying

You don't need to trigger a full deploy just to scale up or resize your app — from your App's Resources page you can change the replica count and/or CPU/memory directly. Raklane applies this in the background (usually within seconds) without building anything or restarting your running containers: a replica increase only starts the missing ones, a decrease only stops the newest excess ones, and a resources-only change updates each kept replica in place. Changing the storage limit is the one exception — it always requires replacing the replica, since it can't be adjusted on a running container.

Health checks

Raklane checks that your new replicas are actually ready before cutting traffic over. By default this is an HTTP check against your app's port, with a short delay before the first check and a timeout for each attempt — you can switch it to a plain TCP check instead if your app doesn't expose an HTTP endpoint, or tune the timeout and initial delay if your app needs longer to start.

Redeploying

Deploying again — after a code change, a config change, or just to restart — works exactly the same way: click Deploy. Raklane builds fresh from whatever source is currently configured and rolls out a new Release using the same zero-downtime process above.

Static sites

If your App's type is Static (chosen at creation time and not changeable afterward), deploys skip the build step entirely — your source directory is served as-is. Container port and health check settings don't apply; a static site is always served the same way.