Security & Architecture

This page is for anyone deciding whether to connect a server to Raklane. It describes what is built today, in plain terms, and links to the pages with the details. It makes no promises beyond that: Raklane holds no security certifications yet and offers no formal uptime guarantee (SLA).

The pieces

Caddy, the agent and your app containers all run on your server; the arrows show who connects to whom.

• The control plane is Raklane's own service: the dashboard, the API, the build pipeline, and the database of your account, apps and settings. Your account and billing data are kept on Raklane's servers in Indonesia.
• Your server runs three things the install command puts there: Docker, Caddy (the web server that serves your apps over HTTPS), and the Raklane agent.
• Builds run on the control plane, not on your server. Raklane clones your repository, builds a container image with Cloud Native Buildpacks, and your server's agent pulls the finished image. Your server never needs build tools or the extra memory a build takes.

How the agent connects

The agent dials out to Raklane and keeps one connection open, secured with mutual TLS: both sides prove who they are with certificates. Raklane sends commands (start this container, update these routes) down that connection, and the agent sends results and heartbeats back.

• No inbound port is opened for Raklane. Your server needs ports 80 and 443 open for your visitors, and 22 only for your own SSH.
• Raklane never logs into your server. It doesn't ask for your SSH keys or your cloud provider account. You run the install command once, yourself, over your own SSH session.
• Enrollment tokens work once. The token in the install command is cleared the moment the server enrolls; a copied token can't enroll a second machine.
• The server's private key never leaves it. The agent generates its own key and sends only a certificate request. Raklane decides the identity in the certificate, so a server can't claim to be a different one.
• Each server has its own certificate. A compromised server can't act for your other servers.

For the full enrollment sequence, see BYOC: Overview & How It Works.

What access the agent has

The agent runs as a system service and talks to Docker on your server. With that, it can pull your app's images, start and stop containers, read their logs and resource usage, and update Caddy's routes and certificates.

Access to Docker is effectively root-level access to that machine. That's true of any tool that deploys containers for you, and it's why the protections above exist. Treat a server you connect to Raklane as dedicated to the apps you run on it.

The agent also keeps itself up to date: about once an hour it checks for a new agent build, verifies its checksum and restarts into it, without restarting your apps. You can change the interval or turn this off; see BYOC Agent Configuration.

How secrets are handled

• Environment variables are encrypted before Raklane stores them, every value, not only the ones that look sensitive. Your app receives them when its container starts on your server. See Environment Variables.
• Secrets (a private repository's access token, a webhook signing key) are encrypted too, and never shown again after you save them. You can rotate a secret in place. See Secrets.
• Builds use your repository token only to clone the code.

Anyone with root on your server can read your app's environment inside its containers, as on any server you run yourself.

Does my traffic pass through Raklane?

No. On your own server, your app's address points straight at your server, and Caddy there terminates HTTPS. Requests and responses never pass through Raklane.

Two consequences:

• If Raklane is unreachable, your apps keep serving. You can't deploy until it's back, and a brand-new custom domain waits to get its first certificate.
• Raklane doesn't see your app's traffic. Through the agent, it does collect resource metrics (CPU, memory, network, disk) and fetches your app's logs when you open them in the dashboard.

Safer releases

Every deploy starts new replicas next to the running ones and waits for them to pass a health check (HTTP or TCP) before switching traffic. If they fail, the deploy stops and the old version keeps serving, untouched. After the switch, the previous version stays warm for a short window; if the new one fails during it, Raklane rolls back automatically. See Deploying Your App.

Disconnecting a server

1. Move the apps on it elsewhere, or pause and delete them, and delete its databases (after backing them up).
2. Choose Decommission from the server's menu. It can no longer receive deploys and stops counting toward your fee.
3. To remove the agent from the machine, run:

sudo systemctl disable --now raklane-agent
sudo rm -rf /etc/raklane-agent /etc/default/raklane-agent /var/lib/raklane-agent

Docker and Caddy stay installed; remove them with your package manager if you don't need them. If you think a server is compromised, follow Managing BYOC Servers.

Who manages what

Reporting a security problem

Email hi@raklane.com with what you found and how to reproduce it. To report abuse coming from an app hosted on Raklane, use the report form.

Where to go next

• How Raklane Works — the full journey from code to traffic.
• Setting Up a BYOC Server — requirements and the one-line install.
• Privacy Policy — what data Raklane keeps and why.