What Vaicoa is

Alpha

For testing only; it does not yet meet the Cyber Resilience Act’s requirements. Named testers only, with an alpha key that ends on a fixed date. Status and limits of the alpha →

Vaicoa is a small platform you run in your own cloud project. It has three parts:

• The hub: one Go binary with one SQLite file, on a small server in your project. It holds the desired state of every server (its release, its settings, its environment), creates servers with your own cloud token, makes twins and recovery tests, issues short-lived access, and keeps an audit of every request.
• The agent on each server: a small program, not an AI model. It connects out to the hub, fetches the desired state, applies it and reports back. No server listens for the hub.
• The vai command: the client on your machine, for macOS, Linux and Windows. It creates the hub, pairs your device with it, and runs it from the terminal. Coding agents use it too, with a key of their own.

The architecture page draws how the parts talk to each other; scenarios shows concrete set-ups with their servers and costs.

What it does

• Production on servers you own. The hub, its database and your cloud tokens stay in your project. If the hub is down, production keeps running; only management pauses: twins, upgrades, access requests, new servers.
• Twins. A twin is a short-lived copy of an environment in a second project, with seed data from your repository by default. People and coding agents work on it without touching production. See twins.
• Agents with limits. A coding agent gets its own key and a ceiling the hub enforces: it may read, and it may work on twins. What touches production waits for a person’s approval. See agents and approvals.
• Signed releases and staged updates. The hub follows a signed release channel; security releases reach twins and staging first, production later. See releases and updates.
• Backups and recovery tests. The hub replicates its own database continuously to your bucket and can run a recovery test of a production server on request. See backups and recovery tests.

Where it runs

• Hetzner Cloud today, in your own project. Built
• Your Mac, in ownpaas, whose lab answers the Hetzner Cloud API with real virtual machines. Built
• Other platforms through providers behind a Hetzner-compatible API (vaicoa-iaas): the KubeVirt provider is built; the Hetzner passthrough and an OpenStack provider are Planned.

What runs on the servers

In the alpha, Podman hosts only: each production or staging server runs your environment, a set of Kubernetes-style YAML files from a Git repository, under Podman. k3s clusters are built in the agent but refused by the hub’s alpha. See status and limits.

Next

Start with what you need.