Servers Overview

Servers are the deployment targets in Reoclo. Any Linux host with Docker, git, and curl installed can be onboarded as a deployment target. Reoclo is provider-agnostic: it works with AWS EC2, Hetzner Cloud, DigitalOcean Droplets, Vultr, Linode, bare metal servers, home lab machines, or anything else running Linux.

You can bring your own infrastructure (BYOS), or connect cloud credentials for managed provisioning and power operations.

How Servers Connect

Reoclo uses a lightweight Runner agent installed on your server. The agent makes an outbound WebSocket connection to Reoclo. Commands are relayed through this connection, so no inbound ports are required. The agent runs as a systemd service and handles reconnection automatically.

Feature	Detail
Connection direction	Outbound (your server connects to Reoclo)
Setup	Install an agent via one-line command
Firewall requirements	Outbound HTTPS only (no inbound ports needed)
Works with	Cloud VMs, bare metal, firewalled servers, NAT, private networks
Key management	Token-based registration (no keys to manage)
Health monitoring	WebSocket heartbeat, immediate status updates

See the Runner setup guide for installation instructions.

Server Lifecycle

Every server moves through a defined lifecycle. Reoclo updates the status automatically based on health checks and connection telemetry.

PROVISIONING -> ACTIVE -> UNREACHABLE -> DECOMMISSIONED
                  ^          |
                  +----------+
                  (auto-recovery)

PROVISIONING

Initial state after you add a server. Reoclo runs a health check to verify connectivity and required tools (Docker, git, curl). Once the check passes, the server transitions to ACTIVE.

If the health check fails, the server stays in PROVISIONING. Check the server logs for details.

ACTIVE

The server is healthy and accepting deployments. This is the normal operational state.

UNREACHABLE

After the runner agent disconnects or consecutive health check failures, the server is marked UNREACHABLE. Deployments are blocked until connectivity is restored.

Auto-recovery: When the runner agent reconnects, the server automatically transitions back to ACTIVE. No manual intervention is needed.

DECOMMISSIONED

The server has been retired. It cannot be modified or deployed to. This is a soft delete: the server record is retained for audit purposes, but it’s excluded from all operational workflows.

To reactivate a decommissioned server, you must remove it and add it again.

Health Monitoring

The runner agent maintains a WebSocket heartbeat with Reoclo. If the connection drops, the server is immediately marked UNREACHABLE. When the agent reconnects, the server returns to ACTIVE.

Health checks also verify:

Docker is installed and running
git and curl are available
The server has sufficient disk space

Prerequisites

Before adding a server, ensure it meets these requirements:

Operating system: Linux (any distribution with systemd)
Docker: Installed and running. The runner agent user must be able to run Docker commands without sudo. Add the user to the docker group if needed.
git: Installed and available in PATH
curl: Installed and available in PATH
Network access: Outbound HTTPS connectivity to Reoclo

To verify Docker access, run:

docker ps

If you see “permission denied”, add your user to the docker group:

sudo usermod -aG docker $USER

Log out and back in for the change to take effect.

Adding a Server

Navigate to Servers in the Reoclo dashboard
Click Add Server
Follow the Runner setup guide to install the agent

After adding the server, Reoclo runs a health check. If successful, the server transitions to ACTIVE and is ready for deployments.