Overview

Kubrain is a deployment platform you talk to, not click. The only interface is an MCP server plus a matching kubrain CLI — you point Claude (or any LLM agent) at it, and the agent provisions, deploys, scales, and bills your infrastructure through a small set of tools. No dashboards, ever.

It runs on vanilla, upstream Kubernetes. That matters for one reason: your app can grow from a single node to multi-service and highly available without ever moving to a different platform. You get that headroom without operating a cluster yourself.

Why it works this way

The whole product is designed around one customer: your agent. That leads to a few properties you can rely on everywhere:

• A tiny, declarative, idempotent surface. Re-running a create/set operation with the same arguments is a no-op that returns the existing resource — never a duplicate. So an agent can always “ensure” a resource exists without checking first.
• Cost is visible before you commit. Anything that spends money has a dry path: pricing and estimate quote a shape without creating anything, dry_run previews a change, and plan_blueprint diffs a whole tenant. The agent sees the € and the diff, then commits.
• Structured, natural-language errors. When something can’t happen (“capacity full for 32 GB nodes in this zone; largest available is 16 GB”), the error is written for an agent to read and self-correct.
• Instant kubectl. The moment a cluster is ready, its kubeconfig points at a stable public endpoint — the agent has working kubectl with no extra steps.

The one idea

Everything is a control-plane operation over the tools, and the tools are the source of truth. You express intent to a cloud that owns the machinery; you do not run kubectl/CAPI steps by hand. For any request, the reflex is “which tool expresses this intent?”. Reach for raw kubectl (against a fetched kubeconfig) only to observe a running workload, or when no tool covers the intent. When memory and a tool result disagree, the tool wins.

How you approach any task

The same shape works for a cluster, a DNS record, or an app:

1. Look before you leap. Start from a list_*/get_* view, not memory. Half of “create X” requests are really “reconcile the X that already exists.”
2. Preview cost and change. Run the dry path — estimate/get_quota for spend, dry_run/plan_blueprint for change — and surface the numbers.
3. Commit the intent through the one tool that owns it.
4. Expect async. Provisioning, scaling, resizing, and upgrading return when the change is requested. Poll the matching get_* view until the state is what you need before the next step.
5. Report plainly — what changed, what it costs, what is still converging.

One price, billed on RAM

Kubrain has one transparent price model. The binding, billed resource is RAM: €0.006 per GiB-hour (≈ €4.38 / GiB-month), with the control plane, bundled vCPU (~1 per 2 GiB), and egress included. Two add-on dimensions have a published rate — standard volumes (€0.05 / GiB-month, first 20 GiB free) and LoadBalancer public IPs (€3.50 / month each). Your agent can compute the bill in one multiplication, before creating anything. See Pricing and Quotas for the details.

Working discipline

A few rules that keep an agent safe on real infrastructure:

• Secrets go to files, never the transcript. get_kubeconfig and get_bucket_credentials write to a file (mode 0600) and return only a confirmation; set_secret reads its value from a file or an env var. Hand these tools a path, then use the file.
• Destructive and outward-facing actions are confirm-first. Deleting a cluster, VPC, zone, bucket, or deployment — or pruning a blueprint — cascades to real machines, data, or public DNS. Name exactly what cascades and get an explicit OK; approval for one action does not extend to the next.
• Production wants HA. For anything you care about, provision an ha tier (≥3 control planes). Reserve dev/normal for prototypes.

Next

• Quickstart — take a code directory all the way to a live URL.
• MCP tools — the full catalogue of what an agent can call.