BYOC: Overview & How It Works

Bring Your Own Compute (BYOC) lets you register a server you already own — a VPS, a dedicated box, an on-prem machine, anything that can run Docker — and deploy your Raklane apps and databases onto it. You keep the server, the bill for it, and full root access the whole time. Raklane takes care of the platform part: building your code, rolling out releases with health checks and rollbacks, routing traffic, issuing HTTPS certificates, and showing you status, logs, and metrics in the same dashboard you use for everything else.

This page explains what BYOC is and how it works under the hood. When you're ready to set one up, go to Setting Up a BYOC Server.

When to use BYOC

BYOC is a good fit when:

• You already pay for servers and want a PaaS workflow (git push → live app) on top of them instead of managing Docker, reverse proxies, and certificates by hand.
• You need control over where your app physically runs — a specific country, a specific provider, your own data center, or hardware with particular specs.
• You want predictable infrastructure cost. Your server's compute isn't billed by Raklane at all; at most, Raklane charges a small management fee (see BYOC Billing).
• You want traffic to go straight to your own machine. BYOC apps are served directly from your server, not through Raklane's shared infrastructure.

If you'd rather not run any server yourself, Raklane's managed compute (pay-as-you-go or dedicated hosting) is simpler — see Where Your App Runs for a side-by-side comparison.

The big picture

There are two sides to every BYOC setup:

• The Raklane control plane — the dashboard, API, build system, image registry, and the thing that decides what should be running where. Raklane operates this.
• Your server — runs three things Raklane installs once: Docker (runs your containers), Caddy (serves your apps over HTTPS), and the Raklane Node Agent (a small background service that takes instructions from the control plane).

Two connections matter, and they go in opposite directions:

1. Control traffic flows outbound from your server. The Node Agent dials out to Raklane and keeps one encrypted connection open. Every instruction (start this container, stop that one, update routes, fetch logs) travels down that connection. Raklane never logs into your server, never needs SSH access, and never needs an inbound port for orchestration.
2. Visitor traffic flows inbound to your server. Your app's visitors connect directly to your server's public IP on ports 80/443, where Caddy terminates HTTPS and forwards the request to your container. This traffic never passes through Raklane.

What happens when you deploy to a BYOC server

Deploying to your server looks exactly like deploying anywhere else — you click Deploy (or push to GitHub). Behind the scenes:

1. Raklane builds your image centrally. Your source is cloned and built (with Cloud Native Buildpacks) on Raklane's build system, not on your server — so a small VPS never runs out of memory compiling your app, and every server gets an identical image. The built image is pushed to Raklane's registry.
2. Raklane checks there's room. Your app's CPU/memory requests are checked against what your server has available. A deploy that can't fit is rejected up front rather than failing halfway.
3. The agent pulls and starts the container. Raklane tells your server's agent which image to pull and how to run it (ports, environment variables, resource limits). The agent pulls the image from the registry and starts the container with Docker.
4. Raklane health-checks the new release. The new container must pass its health check before it gets any traffic. If it fails, the deploy is aborted and whatever was running before keeps serving — the same zero-downtime, automatic-rollback behavior as any other deploy (see Deploying Your App).
5. Raklane updates your server's routes. Once the new release is healthy, Raklane sends your server's Caddy an updated routing table, so your app's hostnames point at the new container. The old release is retired after the safety-net bake window.

How your app is reached

Every app on a BYOC server gets a default URL that works immediately, with no DNS setup on your part. It's built from three parts:

Put together, that's https://my-app-a1b2c3.203.0.113.10.byoc.example.com.

The BYOC domain is a special kind of DNS domain: any hostname under it resolves to the IP address written inside the hostname. Because the server's IP is part of the name, the URL always points straight at your server, with no DNS record for anyone to create. Each Raklane installation chooses its own BYOC domain. It may be a public wildcard-DNS service such as sslip.io or nip.io, or a domain the installation runs itself. You don't need to know which: the app's overview page always shows the exact URL.

You can also add your own custom domain — point an A record at your server's IP (not Raklane's). See Running Apps & Databases on BYOC.

HTTPS

Caddy on your server gets certificates automatically from a public certificate authority, on demand: the first time a request arrives for a hostname, Caddy asks Raklane whether that hostname is legitimate (an app's default URL, or a custom domain that has passed DNS verification). Only if Raklane says yes does Caddy request a certificate. This stops anyone from pointing random domains at your server and making it request certificates for them.

Certificate issuance needs port 80 reachable from the internet (the certificate authority verifies over it), even though your app is served on 443.

If your server's IP is private (a LAN address, a local VM, something behind NAT), no public certificate authority can reach it, so Raklane configures that server for plain HTTP only. Everything else works; there's just no HTTPS.

Enrollment and security

The security model is built around one rule: your server only ever makes outbound connections, and it only ever holds a credential for itself.

• One-time enrollment token. When you register a server, Raklane gives you an install command containing a one-time token. Raklane stores only a hash of it. The token is consumed the moment your server enrolls; replaying it afterwards fails. If you lose it before using it, you can regenerate it, which immediately invalidates the old one.
• Your server's private key never leaves your server. During enrollment, the agent generates its own key pair locally and sends Raklane only a certificate signing request. Raklane signs it and returns a client certificate.
• The certificate identity is decided by Raklane, not your server. The certificate is tied to your cluster's ID, looked up from the token. A compromised server can't impersonate a different one.
• Mutual TLS on every connection. The agent proves who it is with its certificate on every connection, and verifies it's talking to the real Raklane control plane.
• No cloud credentials. Raklane never asks for your cloud provider's API keys, IAM roles, or SSH keys. The "provider" you pick when registering is just a label.
• No inbound ports for orchestration. The only inbound ports your server needs are 80/443 for your app's visitors (and 22 for your own SSH, which Raklane doesn't use).

What happens when something goes wrong

BYOC is designed so that a hiccup on either side never takes your running apps down by itself.

"Unreachable" deliberately isn't "failed": it means Raklane can't currently confirm the state of your app, not that your app has stopped. In most cases your app is still running and serving traffic the whole time.

Things to know before you start

• Each server you register is its own cluster. You can register as many servers as you like, but each one is a separate cluster with a single node, and you choose which one an app deploys to. Raklane doesn't (yet) spread one app's replicas across several of your servers. See Managing BYOC Servers.
• Raklane manages Caddy on that server. Raklane replaces Caddy's whole configuration each time routes change, so don't use the same Caddy instance to host unrelated sites — they'd be removed. Use a dedicated server (or a separate reverse proxy on other ports) for anything Raklane doesn't manage.
• Logs are fetched on demand. Runtime logs from a BYOC app are fetched from your server when you open the Logs page, rather than continuously streamed and stored.
• IPv4 is required for the default URL. A server whose only address is IPv6 doesn't get an IP-based default URL. A custom domain still works.
• Databases on your server are your data. Raklane doesn't back up databases that run on BYOC servers. Back up the server (or the database) yourself.

Next steps

1. Setting Up a BYOC Server — register your server and run the install command.
2. Running Apps & Databases on BYOC — deploy, add domains, and provision databases.
3. Managing BYOC Servers — status checks, renaming, decommissioning, agent updates.
4. BYOC Agent Configuration — every setting the agent on your server reads.
5. BYOC Billing — how the management fee works.
6. BYOC Troubleshooting — when something doesn't work.