Managing BYOC Servers

Everything about your registered servers lives on the Clusters page. Each server appears as a card showing its name, a BYOC badge, its status, and its IP address (with a copy button). The … menu on each card has the actions described below.

Server statuses

Use the status filter at the top of the Clusters page to show only servers in a given state.

Checking a server's connection

Choose Check connection from a server's menu to run the same checks Raklane uses before trusting a server with a deploy:

• Registration — enrollment has completed.
• Heartbeat — the agent has checked in recently.
• Docker Connectivity — Raklane can reach Docker on the server through the agent, right now.

This is useful right after you've fixed something (a firewall rule, a stopped Docker service) and want confirmation without waiting.

Viewing the server's nodes

View nodes shows the machine behind this cluster: its status, capacity (CPU, memory, disk), and last heartbeat. For a BYOC server this is always one node — the server itself.

Editing a server

Choose Edit from a server's menu to change:

• Server name — the display name in the dashboard. Renaming doesn't affect anything running on the server.
• External host — see below.

External host

The External host is the public IP or hostname people outside your server's network should use to reach it. You only need it when your server is behind NAT or a private network, so the address Raklane sees it connecting from isn't its real public address. Raklane uses it for external databases on that server. When set, it appears on the server's card as External:.

Regenerating the enrollment token

While a server is still Pending, Regenerate token issues a fresh install command and immediately invalidates the old token. Use it if you lost the command, or if you think the token was exposed before you used it.

Once a server has enrolled, there's no token to regenerate. If you need to reinstall a server from scratch, decommission it and register it again.

Running more than one server

You can register as many servers as you like. Each one you register becomes its own cluster with one node, and you choose per app (and per database) which server it runs on.

Things to keep in mind:

• One app runs on one server. All of an app's replicas run on the server you chose. Raklane doesn't automatically spread replicas across several of your servers or fail over between them.
• Apps don't move by themselves. A new server doesn't take load until you move apps to it (Settings → Deployment location).
• Cross-server traffic uses public URLs. Apps and databases on different servers can't reach each other over the internal container network.

A typical multi-server layout is one server per environment (staging, production) or per group of related apps that need to talk to each other privately.

Keeping the agent up to date

The Node Agent keeps itself in step with your Raklane installation. About once an hour, it checks whether the control plane is serving a different agent build. If so, it downloads the new build, verifies its checksum, and restarts into it in place. Your app containers aren't restarted when this happens. The previous build is kept beside the new one.

To change how often it checks, or turn automatic updates off, set RAKLANE_AGENT_UPDATE_INTERVAL in the agent's settings. See BYOC Agent Configuration for this and every other agent setting.

Keep your server's operating system and Docker patched as you normally would. Raklane doesn't manage OS updates. If an update reboots the server, the agent comes back on its own.

Doing maintenance on the server

For a planned reboot or maintenance window:

1. Expect the server to show Offline and its apps unreachable while it's down. Visitors can't reach your apps while the server is off.
2. Reboot or do your maintenance as usual.
3. When the server comes back, Docker restarts your containers, the agent reconnects, and the dashboard returns to Healthy / active on its own.

If you want an app to stay up during maintenance, move it to another server (or to Raklane's managed compute) first.

Decommissioning a server

Decommission removes a server from Raklane permanently. Before you can do it, nothing may still be running on it:

1. Move every app on it elsewhere (Settings → Deployment location), or pause and delete those apps.
2. Delete any databases on it (back up their data first).
3. Choose Decommission from the server's menu.

Decommissioning is permanent: the server can no longer receive deploys, and it stops counting toward your BYOC management fee. To use the same machine again later, register it as a new server.

Decommissioning doesn't uninstall anything from the machine. To clean it up, SSH in and run:

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

Docker and Caddy are left installed, since you may use them for other things. Remove them with your package manager if you don't need them.

If you think a server is compromised

1. Move your apps to another server (or Raklane's managed compute) and redeploy.
2. Rotate any secrets and database passwords that apps on that server used.
3. Decommission the server in Raklane. Each server's certificate is tied to that server alone, so a compromised one can't act for your other servers, and enrollment tokens can't be reused.
4. Rebuild the machine before registering it again.