Getting started

From a bare server to a live app

Sproobo runs on Linux servers you already own or rent — a Hetzner box, a bare-metal machine, whatever you have root on. Enroll it once, and every deploy after that is a git push and a health-gated blue-green swap.

Before you start

  • A Linux server you control, with root SSH access: Ubuntu 22.04/24.04/26.04, Debian 12/13 (Debian-family), or Amazon Linux 2023 (RHEL-family).
  • Outbound access on port 443 — that's it. No inbound ports need to be opened. The agent dials out to the control plane; it never listens for an inbound connection from Sproobo.
  • A domain you can point DNS at, if you want a public URL with TLS. You can also deploy first and wire up DNS afterward.

The path

01

Add a server

From the dashboard: Servers → Add server. Or from the CLI: sproobo enroll <name> -y. Either way you get back a one-liner with a single-use enroll token baked in.

02

Run the one-liner as root

Paste it into an SSH session on the server:

SPROOBO_ENROLL_TOKEN='<your-token>' bash -c "$(curl -fsSL 'https://cp.sproobo.com/dl/bootstrap.sh')"

This runs the enroll bootstrap script end to end: Docker, the agent, the firewall baseline, the shared proxy, and enrollment.

03

Wait for the bootstrap to finish

The one-liner takes a couple of minutes to run — it installs Docker CE and the agent. Once the agent connects outbound over WSS/443, the server flips from enrolling to ready in the dashboard within seconds.

04

Create your app

From the dashboard's New app flow, or the CLI:

sproobo apps create my-app --server <serverId> --repo https://github.com/you/app --domain example.com -y

This wires up apex+www ingress and a certificate, then kicks off the first deploy.

05

Watch the first deploy stream live

The image builds off-box, the new container starts, passes the health gate, and the proxy switches traffic to it — the same blue-green path every later deploy uses.

06

Point DNS at the server

Add records for both the apex domain and www pointing at the server's IP — Sproobo's proxy config always expects both.

07

The certificate issues automatically

Once DNS resolves, the built-in ACME issuance picks it up and keeps it renewed — nothing to configure by hand.

What the bootstrap script actually does

Nine idempotent steps. Every one is check-then-act, so re-running the same one-liner later is safe and self-heals a partial run:

1

Detect OS & arch

Confirms Debian-family or RHEL-family, amd64/arm64, root/sudo, and free disk space.

2

Detect port owners

Checks whether something already holds :80/:443 — used later to decide whether Sproobo starts its own proxy or steps aside for yours.

3

Install Docker

Docker CE, containerd, buildx, and the compose plugin, from each distro's official repo.

4

Configure the Docker daemon

Sets userland-proxy=false — required so the host firewall (the DOCKER-USER chain) can actually enforce rules on published container ports.

5

Set up the host

Creates the unprivileged sproobo system user (the bind-mount data owner) and the /var/lib/sproobo directory tree.

6

Install the agent

Downloads the checksum-verified agent binary for this host's architecture, installs the systemd unit, and stages the enroll token.

7

Firewall baseline

ufw (Debian-family) or firewalld (RHEL-family): allow 22/80/443, then default-deny everything else inbound. SSH is allowed before the default-deny is ever applied — it is never closed.

8

Network & proxy

Creates the internal sproobo-int Docker network and starts the shared Caddy proxy container — unless a foreign process already owns :80/:443, in which case it steps aside instead of fighting for the port.

9

Enroll

Enables and starts the agent service. It dials the control plane and completes enrollment with the staged token.

The agent only ever dials out.

The control channel is outbound WSS over 443, initiated by the agent. There's no inbound port for the platform to sit on, and it works fine behind NAT — you never open a firewall hole for Sproobo to reach in.

Next