> For the complete documentation index, see [llms.txt](https://docs.rumi.systems/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.rumi.systems/rumi-platform/concepts/civo-binding.md).

# Civo Binding

The Civo binding deploys the canonical Rumi private cloud onto [Civo](https://www.civo.com/). 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`](/rumi-cli/commands/cloud/civo.md) reference.

{% hint style="info" %}
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.
{% endhint %}

## 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-network` creates a private network; `list-networks` and `delete-network` manage 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.local` names 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 | cloudflare` plus `--dns-credentials`.

{% hint style="warning" %}
**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.
{% endhint %}

## 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**: `start` and `stop` act on every instance in an environment (with per-role `start-*` / `stop-*` variants), so a Civo environment can be parked when idle and resumed later.
* **Idempotent teardown**: `deprovision` removes the platform and network.

## High-level operations

* `deploy` copies the XAR to the bastion staging directory and hands it to the admin agent.
* `configure` adds or updates a controller config property on the admin node.

## Getting started

1. Set a Civo API token: `export CIVO_API_TOKEN=...` (or pass `--api-key`).
2. Choose a region (every command takes a required `--region`, e.g. `FRA1`).
3. Upload an SSH key to Civo and pass its name with `--keyPair`.

```bash
rumi cloud civo provision --region FRA1 --network my-cloud --keyPair rumi
rumi cloud civo deploy    --region FRA1 --network my-cloud --keyPair rumi --xar ./my-app.xar
# park it when idle, resume later
rumi cloud civo stop  --region FRA1 --network my-cloud
rumi cloud civo start --region FRA1 --network my-cloud
```

## Related documentation

* [Hetzner Binding](/rumi-platform/concepts/hetzner-binding.md) — the prebaked-snapshot binding on Hetzner Cloud.
* [AWS Binding](/rumi-platform/concepts/aws-binding.md) — the same private cloud on AWS (SOC 2 posture, SSM, NAT topology, CloudWatch).
* [`rumi cloud civo`](/rumi-cli/commands/cloud/civo.md) — command reference.