Antrieb

Antrieb MCP Server

Instant disposable clusters for LLM-generated networks and infra.

Say an LLM writes a VyOS NAT config, an OpenWrt firewall rule set, or a bash script to harden a CentOS cluster. Where do you run it before it touches your environment? Antrieb gives the LLM a disposable multi-node cluster, with real VMs and real networking, to try what it generates. Break it, quickly reprovision, try again. No cleanup.

Same OS and appliances your LLM-generated code will target in production: CentOS Stream, Ubuntu, Debian, Alma, Alpine, VyOS, OPNsense, SONiC, OpenWrt. Multi-network topologies with per-NIC assignment. Not a container, not a microVM, not some unknown Linux — the same kernels and packages your real fleet runs.

Root access, private networking, passwordless SSH between nodes. Ten minutes per cluster. Clean slate every time. Instant clusters that change the economics of being wrong for LLMs.

Quick Start

Antrieb is a remote MCP server. Nothing to install. Add it to your config and start provisioning.

Claude Web / ChatGPT

With web-based AI clients, add Antrieb as a custom connector.

In claude.ai: go to Settings → Connectors, click Add custom connector. Enter:

• Name: Antrieb
• URL: https://antrieb.sh/mcp

Click Add, then Connect and sign in. Back in your chat, try something like:

*Create a 3-node Kubernetes cluster, with node1 running both as control-plane and worker, and node2/node3 as pure workers. Install nginx with 3 pods and pod anti-affinity.*

Walkthrough video: https://youtu.be/8nts8ol-yeA

MCP Clients (Claude Desktop, Claude Code, Codex, custom clients)

Get a free API key at antrieb.sh/dash, then add this to your MCP client config (e.g. .mcp.json for Claude Desktop):

Claude Code

Put this JSON in the current folder in a file called .mcp.json. Claude Code will find it automatically.

{

"mcpServers": { "antrieb": { "type": "http", "url": "https://antrieb.sh/mcp", "headers": { "Authorization": "Bearer ant_YOUR_API_KEY" } } } }

#### Codex

Put this TOML content in ./.codex/config.toml. Then set the ANTRIEB_TOKEN environment variable with your API key before launching Codex.

 [mcp_servers.antrieb]

url = "https://antrieb.sh/mcp" bearer_token_env_var = "ANTRIEB_TOKEN"

No local install, no dependencies, no Docker.

How It Works

Your LLM controls real VMs through 5 tools:

1. provision  →  Spin up a cluster (sub-second per VM, declare custom networks and NICs)

1. exec → Run commands on any node (cluster-scoped env vars auto-injected)
2. save → Snapshot a node as an image, or save a runbook
3. search → Discover images, runbooks, or active clusters
4. delete → Destroy a cluster, or decommission a saved artifact

The LLM drives the entire workflow: provision a cluster, install software command by command, verify each step, and iterate until it works. Antrieb provides the infrastructure; the LLM provides the intelligence.

Example Workflow

You: provision 3 ubuntu nodes and install nginx on all nodes

LLM: provision(cluster: ["ubuntu24.04 x3"]) → { session_id: "abc12", nodes: ["node1", "node2", "node3"], provision_time_ms: 720 }

LLM: exec(session_id: "abc12", node: "node1", command: "apt-get update && apt-get install -y nginx") → { exit_code: 0, stdout: "..." }

LLM: exec(session_id: "abc12", node: "node1", command: "systemctl start nginx && curl -s localhost") → { exit_code: 0, stdout: " Welcome to nginx... " }

LLM: save(type: "image", session_id: "abc12", node: "node1", name: "my-nginx", commands: [...]) → { ani: "antrieb:my-nginx:v1" }

LLM: delete(type: "cluster", name: "abc12") → { success: true }

Available Images

Base Images

Stack Images

Stack images are custom images created by enriching the base images with additional packages.

Use search to discover all available images with full descriptions, or just specify a distro name and Antrieb picks the right one.

Cluster Networking

Networking is a first-class input to provision, not an afterthought. Every cluster is L2-isolated from every other cluster (even ones you own), with hostname resolution, passwordless SSH between its own nodes, and cluster-scoped env vars auto-injected into every exec call. What *varies* between runs is how nodes are wired and controlled by the optional networks and nics parameters on provision.

There are two modes: the default network (flat, one-subnet, internet-reachable) and declared networks (first-class multi-subnet, multi-NIC topologies).

Every cluster (both modes)

• Hostname resolution: node1, node2, node3 in /etc/hosts on every node.
• Passwordless SSH: a per-cluster ed25519 keypair distributed to all nodes. ssh node2 hostname just works.
• L2 isolation: nodes across different clusters cannot reach each other, regardless of CIDR overlap or account.
• Env vars on every `exec`: NODE_NAME, NODE_INDEX, NODE_IP, CLUSTER_HOSTS (multiline IP NAME — drop-in for /etc/hosts), CLUSTER_SSH_PUBKEY, CLUSTER_SSH_PRIVKEY.

LLM: exec(node: "node1", command: "ssh node2 hostname")

→ { stdout: "node2" }

Default network (when networks / nics are omitted)

LLM: provision(cluster: ["ubuntu24.04 x3"])

You get:

• One auto-allocated /24 network named default, one NIC per node, DHCP-assigned IPs.
• Egress to the internet via a curated port allowlist (HTTP, HTTPS, DNS, SSH, package managers). Arbitrary outbound is blocked.
• No router VM, no firewall zones, no topology to configure. Nodes talk to each other and to the outside world.

Use this whenever the *network* isn't what you're testing — application-level work, distro-specific configuration, Ansible playbooks, CI pipelines, Kubernetes-on-three-ubuntus.

Declared networks (multi-network, multi-NIC)

Pass networks and nics when the topology itself is the thing under test: routers, firewalls, DMZs, isolated back-end subnets, dual-homed nodes, BGP meshes.

LLM: provision(

cluster: ["vyos", "ubuntu24.04", "ubuntu24.04"], networks: [ { name: "wan", egress: true }, { name: "lan", cidr: "10.10.1.0/24", egress: false } ], nics: { node1: [{ net: "wan" }, { net: "lan" }], // vyos: dual-homed router node2: [{ net: "lan" }], // ubuntu backend node3: [{ net: "lan" }] // ubuntu backend } )

Contract:

• Each declared network is its own L2 segment with its own DHCP server and its own /24. CIDRs are auto-allocated when omitted; only /24 is supported.
• `egress: true` — internet-reachable on the default port allowlist. `egress: false` — traffic stays inside the network; no default route out.
• `dhcp: true` (default) — the platform assigns IPs. `dhcp: false` — you assign IPs (use this when a router VM owns addressing or you need precise /31 links).
• NIC order matters. Each entry in nics. becomes eth0, eth1, ... in the listed order.
• `.1` of every DHCP-enabled network is reserved for the platform bridge gateway. Router VMs should claim .254 (or DHCP-client) — assigning .1 to a VM causes ARP flip-flop.

This unlocks serious networking work: VyOS / OPNsense firewalls with WAN/LAN zones, SONiC as an L2 switch or L3 router, OpenWrt with its fw3 zone model, nginx behind a reverse-proxy LAN, BGP peering over /31 transit links, hairpin NAT, DNAT port-forwards. Full walkthroughs for each pattern live in the @antrieb/* runbook library.

Reusable topologies should be captured in runbooks. Networks are declared inline during provision; if the same topology matters across scenarios, save the topology, commands, and verification steps together as a runbook.

Example Network Labs

The default antrieb/* runbook library includes verified scenarios such as:

• VyOS: zone-based DMZ firewall, DNAT port forwarding, DHCP/DNS forwarding, DHCP relay, dual-WAN failover, policy-based routing, eBGP, OSPF, VRRP, WireGuard, IPsec, VLAN trunking, QoS shaping.
• SONiC: L2 bridging, L3 routing, VLAN segmentation, inter-VLAN routing with policy, BGP with FRR, OSPF, DHCP relay, LAG, SPAN mirroring, VXLAN L2 stretch.
• OPNsense: DNAT port forwarding, three-zone DMZ, WireGuard road warrior, HTTPS load balancing with HAProxy.
• OpenWrt: home-router NAT, guest-zone isolation, port forwarding, dnsmasq static DHCP and local DNS overrides.
• Service topologies: nginx reverse proxy, Ansible-managed nginx backends with HAProxy load balancing and failover drills.

Runbooks are written as executable proofs: topology, commands, expected packet behavior, and verification steps using tools like tcpdump, route tables, conntrack, BGP/OSPF state, DHCP traces, VPN handshakes, and failover tests.

Runbooks

Runbooks are the way to preserve non-trivial multi-node scenarios, capturing even little gotchas that may be too small to blog about. They're markdown documents with structure the LLM can execute:

• ## Topology required — cluster shape this applies to (images, networks, NICs)
• ## Variables — placeholders like callers substitute at apply time
• ## Steps — numbered; prose explains *why*, fenced shell blocks are the actual commands, each annotated with the node it targets
• ## Verify — how to confirm success

Save one with save(type: "runbook", session_id: "...", name: "...", body: "...markdown..."). The session_id must point to a session whose exec history demonstrates the runbook. Fetch the body with search(type: "runbook", fq_name: "namespace/name").

Runbooks complement images: an image captures installed state (packages, configs baked into a qcow2). A runbook captures a workflow (the ordered, multi-node actions that produce a working system). Prefer runbooks for anything with more than one node, because a single image can't express coordination between VMs.

Everything you save lives in your org's namespace; the antrieb/* namespace is read-only defaults.

Custom Images

Save any configured node as a reusable image:

1. Provision a base image
2. Install and configure software via exec
3. Call save(type: "image", ...) with the list of successful commands
4. Antrieb generates build-image.sh, startup.sh, and a description
5. The image is immediately available for future provision calls

Try It N