Civo Binding
The Civo binding deploys the canonical Rumi private cloud onto Civo. The same Rumi application, described once in DDL, runs unchanged across a developer laptop, local Docker, AWS, Hetzner, and Civo; the Civo binding is the component that turns that model into real networks, firewalls, instances, and DNS.
Where the AWS and Hetzner bindings boot nodes from a prebaked image, the Civo binding uses an install-at-boot model — a good fit for Civo's simpler image catalogue.
This page is a feature catalogue. For the commands that drive each feature, see the rumi cloud civo reference.
Civo is a supported provider at command and HTTPS parity with the Hetzner binding (pluggable DNS-01, bastion terminology, the same lifecycle surface). The one remaining validation item is live end-to-end certificate issuance; treat HTTPS on Civo as preview until it is proven live.
Deployment model
Civo uses an install-at-boot model: every node boots from a barebones Rocky image and installs its role's software via cloud-init on first boot, rather than booting from a prebaked image or snapshot as on AWS and Hetzner. This keeps the image catalogue simple, at the cost of a slower first boot while software installs — the launch commands wait for the node to finish coming up.
The role set mirrors the other bindings: a bastion, an admin node (agent + admin server + discovery broker), a monitor node (Grafana), a messaging broker (Solace, Kafka, or ActiveMQ), and application service (worker) instances.
Network topology
The topology is public-only, the same shape as the Hetzner binding: every node has a public IP and joins a private network, and only the bastion is the public entry point.
create-networkcreates a private network;list-networksanddelete-networkmanage its lifecycle.Per-role firewalls secure the fleet, including dedicated broker firewalls (Solace, Kafka, and ActiveMQ) wired into network creation.
Bastion model
DNS server: the bastion runs internal DNS for the fleet's
rumi.localnames and points each node's resolver at itself.Public entry point and reverse proxy: only the bastion is reachable from the internet; it fronts the fleet's nginx reverse proxies and is the SSH entry point. It must be launched before any other role.
The bastion has full start / stop / terminate lifecycle commands (
launch-bastion,start-bastion,stop-bastion,terminate-bastion).
HTTPS
Let's Encrypt wildcard certificates via certbot's DNS-01 challenge, terminated on the bastion's nginx. The certbot client and all three DNS plugins are installed at bastion boot, along with the renewal timer.
Provider-pluggable DNS-01, identical to the Hetzner binding:
--dns-provider route53 | hetzner | cloudflareplus--dns-credentials.
Rumi does not manage public DNS. Pointing the public name at the bastion is the operator's job, in whatever DNS hosts the domain. enable-https only proves control of the domain (the DNS-01 challenge) to issue the certificate.
Lifecycle and idempotency
Granular commands launch and manage the bastion, admin, monitor, brokers, and workers individually; convenience commands (
provision,launch-platform) stand up a whole deployment in one step.Start / stop to save cost:
startandstopact on every instance in an environment (with per-rolestart-*/stop-*variants), so a Civo environment can be parked when idle and resumed later.Idempotent teardown:
deprovisionremoves the platform and network.
High-level operations
deploycopies the XAR to the bastion staging directory and hands it to the admin agent.configureadds or updates a controller config property on the admin node.
Getting started
Set a Civo API token:
export CIVO_API_TOKEN=...(or pass--api-key).Choose a region (every command takes a required
--region, e.g.FRA1).Upload an SSH key to Civo and pass its name with
--keyPair.
Related documentation
Hetzner Binding — the prebaked-snapshot binding on Hetzner Cloud.
AWS Binding — the same private cloud on AWS (SOC 2 posture, SSM, NAT topology, CloudWatch).
rumi cloud civo— command reference.
Last updated