██╗  ██╗██████╗  █████╗ ███╗   ██╗██╗██╗  ██╗
██║ ██╔╝██╔══██╗██╔══██╗████╗  ██║██║╚██╗██╔╝
█████╔╝ ██████╔╝███████║██╔██╗ ██║██║ ╚███╔╝
██╔═██╗ ██╔══██╗██╔══██║██║╚██╗██║██║ ██╔██╗
██║  ██╗██║  ██║██║  ██║██║ ╚████║██║██╔╝ ██╗
╚═╝  ╚═╝╚═╝  ╚═╝╚═╝  ╚═╝╚═╝  ╚═══╝╚═╝╚═╝  ╚═╝

AI-native control plane for Docker & Kubernetes

Deploy. Orchestrate. Operate — for humans and AI agents alike.

Documentation · Getting Started · Roadmap · Discussions

Kranix is an open-source, AI-native control plane for Docker and Kubernetes. It gives you a single, consistent interface to deploy, manage, debug, and heal container infrastructure — whether you're running a local Docker container, a kind cluster, or a production multi-node Kubernetes environment.

The core idea is simple: infrastructure operations should be accessible to both humans and AI agents through the same interface. Every action you can do from the CLI, you can also do via the API. Every action available via the API is also exposed as an MCP tool — so AI agents like Claude or GPT can operate your infrastructure safely, with full audit logging, within boundaries you define.

Developer / AI Agent
        │
   CLI or MCP
        │
   Kranix API
        │
  Kranix Core
        │
   ┌────┼────┐
   ▼    ▼    ▼
Docker  K8s  Remote Nodes

Most infrastructure tooling was built for humans typing commands. Kranix is built for a world where AI agents are part of the ops team.

AI-operable out of the box. Kranix ships with a first-class MCP server. Connect any MCP-compatible AI agent and it can deploy workloads, stream logs, analyze failures, generate manifests, and heal degraded services — all within safe, audited boundaries. No custom integrations, no prompt engineering tricks.

One interface, any backend. The same kranix deploy command works against Docker locally, a Kubernetes cluster, or a remote bare-metal node. You don't need different tools for different environments. The runtime abstraction layer handles the backend difference transparently.

GitOps-native reconciliation. Commit a KranixApp manifest to Git — the operator picks it up and reconciles it. No manual kubectl apply. No out-of-band state. Git is always the source of truth.

AI-powered debugging, not just logging. kranix analyze <workload> doesn't wrap kubectl describe. It reasons over the full runtime state — crash reason, probable fix, resource bottleneck, failing dependency — and where possible generates a patch you can apply directly.

Composable by design. Use only the parts you need. The MCP server works standalone. The runtime drivers work without Kubernetes. Nothing forces you into the full stack.

• Continuous reconciliation — desired state always converges to actual state
• Multi-backend scheduling — Docker, Kubernetes, Podman, remote nodes
• Canary, blue-green, and rolling rollout strategies
• Health gate engine — block rollouts until readiness checks pass
• Auto-rollback — revert automatically on error rate or latency spike
• Dependency ordering — services deploy in the correct sequence
• Drift detection — alerts when runtime diverges from declared spec
• Full event log — every state transition recorded and queryable

• Deploy, restart, and delete workloads via natural language
• Stream live logs from any pod
• Analyze failures and get a probable fix with generated patch
• Generate KranixApp manifests from plain-text descriptions
• Cluster-wide health summary in one tool call
• Agent permission scopes — read-only, write, or admin per agent
• Dry-run mode — preview what an agent would do before it acts
• Per-agent audit log — every action recorded with identity and outcome
• Autonomous healing — agent watches and self-fixes without being prompted

• Single CLI for all operations — kranix deploy, logs, analyze, diff, rollback
• TUI live dashboard — real-time cluster state in the terminal
• kranix ai — inline AI assistant that diagnoses and fixes issues from the terminal
• Multi-context profiles — switch between dev, staging, and prod in one command
• Shell completion for bash, zsh, and fish

• KranixApp CRD — declare workloads as Kubernetes resources
• KranixPolicy CRD — enforce resource limits and network rules per namespace
• KranixSecret CRD — sync secrets from Vault and AWS Secrets Manager
• Progressive delivery via CRD flags — canary and blue-green without extra tools
• Multi-cluster federation — one operator managing multiple clusters

• Resource usage metrics per workload — CPU, memory, GPU
• Streaming events via SSE — live state changes pushed to any client
• OpenTelemetry traces and metrics built in
• Webhook system — push deploy/fail/scale events to Slack, PagerDuty, CI

• Docker or a running Kubernetes cluster (kind works for local)
• Go 1.22+ (if building from source)
• Helm 3.12+ (for cluster install)

# Install the CLI
curl -fsSL https://get.kranix.io | sh

# Point it at a local Kranix API
kranix login --server http://localhost:8080 --api-key your_key

# Deploy your first workload
kranix deploy --name my-app --image nginx:latest --namespace default

# Check status
kranix status my-app

# Stream logs
kranix logs my-app --follow

# Add the Helm repo
helm repo add kranix https://charts.kranix.io
helm repo update

# Install the full platform
helm install kranix kranix/kranix \
  --namespace kranix-system \
  --create-namespace

# Verify everything is running
kubectl get pods -n kranix-system

# Install the CLI and connect
curl -fsSL https://get.kranix.io | sh
kranix login --server http://kranix-api.kranix-system.svc:8080

# Start the MCP server
KRANIX_API_URL=http://localhost:8080 \
KRANIX_API_KEY=your_key \
kranix-mcp start

Add to Claude Desktop (claude_desktop_config.json):

{
  "mcpServers": {
    "kranix": {
      "command": "kranix-mcp",
      "args": ["start"],
      "env": {
        "KRANIX_API_URL": "http://localhost:8080",
        "KRANIX_API_KEY": "your_key"
      }
    }
  }
}

Once connected, your AI agent can:

You → "Deploy nginx to staging with 3 replicas"
You → "Why is my api-server pod crashing?"
You → "Show me the logs from the last 10 minutes"
You → "Roll back api-server to the previous version"

Kranix is in active early development — alpha-v1. The best time to shape the direction is now.

Good first areas:

• Core engine — reconciler design, state store backends, event bus
• Runtime drivers — Docker, Podman, remote node support
• MCP tooling — new tools, safety policy, agent testing
• Documentation — guides, architecture docs, examples

Open a Discussion to share ideas, or pick up an issue in any repo.

Apache 2.0 — see LICENSE.