cbrm — manage BERO HOST servers from the terminal, from code, and from AI assistants

cbrm ("BERO management") operates BERO HOST KVM rootservers without clicking through the customer panel: check status, read the panel's action log, look at the VNC console, power a server on or off, type at its console. It is one package with five faces:

BERO HOST is a German provider of prepaid game, root and virtual servers. Its panel is pleasant to use by hand; cbrm exists for the moments when a script or an assistant should do the same thing. It is an independent community project, not made or endorsed by BERO HOST, and it only does what a customer can do in the panel with their own login.

What it can do

Every operation is one entry of a registry; the CLI (cbrm <feature> <vm> …), the HTTP API (POST /vms/{vm}/{feature}) and the MCP server (bero_<feature>) are generated from it, so all three offer the same features with the same rules. cbrm features lists them.

Every changing command takes --dry-run: cbrm reads the panel (it may refresh or page through lists, which changes nothing), checks everything, and shows the exact request it would send — without sending it or any other request that changes or submits something. A dry run of a secret feature reveals nothing.

Features named account-* act on the whole account (stored SSH keys, credit), not on one server. They still take <vm>: it names the account context, must belong to the account, must be on the allow-list (CBRM_VMS) and is repeated as --confirm <vm> like for every other change.

When BERO changes the panel

cbrm checks before every change that the panel still offers exactly what the feature relies on (the Livewire component and method, the form and its field names, the exact endpoint in the page's own script). If anything differs it stops with "the panel changed, so the change was not made" (HTTP 409, an MCP tool error) instead of guessing. If a change was sent but cannot be confirmed afterwards, the answer says so (verified: null and verify_error) instead of claiming nothing happened. cbrm doctor <vm> runs these checks for every feature, read-only — run it on a schedule to learn about a panel change before you need the feature.

Install

pipx install cbrm                                                 # from PyPI (or: pip install cbrm)
uvx cbrm vms                                                      # run without installing (uv)
nix run git+https://git.corbet.ch/corbet-infra/cbrm -- vms        # Nix (flake)

Python 3.11 or newer. Dependencies: httpx, selectolax, websockets, vncdotool, Pillow, FastAPI, uvicorn, mcp.

Configure

export CBRM_CREDENTIALS_CMD="pass show hosting/bero-host"
cbrm vms
cbrm logs 10002 --n 5
cbrm console 10002 --out screen.png
cbrm power 10002 --action restart --confirm 10002

MCP

For Claude Code, Claude Desktop or any MCP client (stdio):

{ "mcpServers": { "bero": { "command": "uvx", "args": ["--from", "cbrm", "cbrm-mcp"],
    "env": { "CBRM_CREDENTIALS_CMD": "pass show hosting/bero-host", "CBRM_VMS": "10001 10002" } } } }

With a shared API the assistant never sees the panel password: "env": { "CBRM_API_URL": "https://cbrm.example.internal", "CBRM_API_TOKEN": "…" }. The skill skills/bero/SKILL.md teaches an agent the safe order of work (read, confirm, act, look again); copy it into your agent's skill directory.

Recipes

Booting your own ISO (for example to install any OS)

1. cbrm iso-add <vm> --url <public https url> --title <t> --confirm <vm>. The panel confirms at once but downloads in the background (a 1.5 GB image took about 30 minutes); until it is done, inserting it reports success and inserts nothing — cbrm's verified: false tells you.
2. cbrm isos <vm> --search <t> → cbrm iso-mount <vm> --drive ide2 --iso <id> --confirm <vm>. Keep one CD drive (cbrm drive-delete <vm> --drive ide0 … if a reinstall created a second one).
3. After mounting: cbrm boot-order-set <vm> --order ide2 scsi0 net0 --confirm <vm>.
4. cbrm power <vm> --action stop …, then --action start. The console becomes reachable about 20 s after the start; if your ISO has a boot menu, cbrm console-input <vm> --keys enter --repeat 3 --interval 0.5 … right away selects its default entry. cbrm console shows what is on the screen.

Status

cbrm is young (0.x) and used in production by its authors on BERO HOST KVM rootservers. Covered today: the server lifecycle — status, action log, console (screenshot and input), power, root password, reinstall with SSH keys, own ISOs, CD drives, boot order and rescue system — and, new since 0.3.1, IP addresses and reverse DNS, network reset, backups (list, create, restore, delete, automatic-backup status), scheduled tasks, host name and product name, statistics (current and history), the account's SSH keys, and read-only renewal and credit information (runtime left, the prices the panel quotes, payment method, upgrade possible or not, balance). Planned: support tickets and — as the cost risk class — the paying actions: renewals, upgrades and credit top-ups. Restoring single files from a backup is not covered. Issues and pull requests are welcome on the primary repository.

How it works

BERO HOST does not publish an API, so cbrm uses what the panel itself uses: its login form, its server-rendered pages, one Livewire request for the action log, the JSON endpoints behind its power buttons, and the noVNC console session it hands out (a Proxmox VNC websocket, bridged to a local port and driven with vncdotool). Details in docs/architecture.md.

If the panel changes, cbrm fails with a clear error instead of guessing; see docs/operations.md.

Where the code lives

Please open issues and pull requests on the primary; changes pushed to a mirror are overwritten.

License

LGPL-3.0-only WITH LGPL-3.0-linking-exception — use cbrm from any application under any license; changes to cbrm itself stay open. Details in LICENSE.md. Contributions are welcome under the same terms; see CONTRIBUTING.md.