> ## Documentation Index > Fetch the complete documentation index at: https://docs.monk.io/llms.txt > Use this file to discover all available pages before exploring further. # Monk vs. Terraform, Kubernetes, and PaaS > Understand what Monk is by contrast — one orchestrator that manages infrastructure, workloads, networking, and APIs as a single live graph, instead of stitching together separate tools. The fastest way to understand Monk is to look at what it replaces and why. Most teams run production on a stack of specialized tools: **Terraform** (or Pulumi/OpenTofu) to provision infrastructure, **Kubernetes** to run containers, **Helm charts and operators** to extend the cluster, and a layer of human-written glue — pipelines, scripts, and runbooks — to wire it all together. Each tool is excellent at its slice. None of them owns the whole. Monk takes the opposite approach. It is a single orchestrator that manages **infrastructure, workloads, networking, and third-party APIs as one continuously-reconciled graph** — the [live application graph](/getting-started/what-is-monk#more-than-deployment). The wiring between resources is a first-class part of that graph, not an afterthought left to a human. **The one-line difference.** Terraform, Kubernetes, and a PaaS each manage part of your system. Monk manages all of it — and the connections between the parts — in one loop, on your cloud. ## The short version | Capability | Terraform | Kubernetes | PaaS | Monk | | --------------------------------------------- | :-------: | :--------: | :--: | :--: | | Provisions cloud infrastructure | ✓ | ✗ | ◐ | ✓ | | Runs and schedules containers | ✗ | ✓ | ✓ | ✓ | | Reconciles state continuously | ✗ | ✓ | ✓ | ✓ | | Knows infra **and** workloads together | ✗ | ✗ | ◐ | ✓ | | Manages networking (VPC, firewalls, DNS, TLS) | ◐ | ◐ | ◐ | ✓ | | Cross-cloud, hybrid, and on-prem | ◐ | ◐ | ✗ | ✓ | | Manages third-party SaaS/API lifecycle | ◐ | ✗ | ◐ | ✓ | | Runs on **your** cloud accounts | ✓ | ✓ | ✗ | ✓ | | Autonomous day-2 operation | ✗ | ◐ | ◐ | ✓ | ✓ designed for it · ◐ partial or within limits · ✗ out of scope The rest of this page explains each comparison in detail. ## Monk vs. Terraform (and other IaC) Infrastructure-as-Code tools are declarative templates for provisioning cloud resources. Terraform is outstanding at describing a desired infrastructure state and computing a plan to reach it. Two things define its boundaries: * **State is a plan-time snapshot.** Terraform reads its state when you run `plan`/`apply`. Between runs, reality drifts and Terraform doesn't notice until the next human-initiated run. * **It doesn't know about your workloads.** Terraform provisions the database and the network, but the containers running your application — and how they depend on that infrastructure — live in a different tool entirely. Monk keeps a **live state on its orchestrator** and reconciles it continuously, so drift is observed as it happens rather than discovered at the next apply. And because the same orchestrator manages the containers *and* the infrastructure beneath them, the dependency between a workload and its database, network, or DNS record is modeled — not left for a human to remember. Monk tracks what it created versus what it merely discovered in your account, so it never destroys resources it didn't provision. ## Monk vs. Kubernetes Kubernetes is an excellent container orchestrator. It reconciles workload state continuously and self-heals within a cluster. Monk provides the same workload guarantees — scheduling, internal load balancing, service discovery, health and readiness checks, rolling and blue/green deployments, and autoscaling — but differs in three structural ways. **Kubernetes' world ends at the cluster edge.** Its model assumes nodes and a network already exist and places workloads onto them. It has no native concept of *provision the VPC, the VM, or the managed database*. Monk treats a container as **one kind of resource on the same control plane** as the VM it runs on, the security group in front of it, and the managed database it talks to — so the whole application is one graph, not a workload layer floating above an unknown infrastructure layer. **Networking stops at the cluster, too.** In-cluster networking is well covered, but the cloud network (VPCs, security groups, cross-cloud and on-prem connectivity) is out of scope by design. Monk derives networking — routing, firewalls, an [encrypted overlay](/features/networking), load balancing, ingress, and TLS — directly from your application's connection graph, spanning clouds and regions automatically. **Isolation is subtractive.** The common pattern is one large multi-tenant cluster, with isolation carved out using namespaces, RBAC, network policies, and quotas. Monk gives each [environment its own cluster](/features/environments), isolated by construction, which is what makes cheap [per-branch preview environments](/features/capsules) practical. How Monk's built-in orchestrator runs your workloads — without Kubernetes underneath. ### "Why not just build Monk on Kubernetes?" Because the unified graph can't exist inside it. Kubernetes deliberately decentralizes state across many independent controllers, each reconciling its own slice. Adding infrastructure (via Cluster API or Crossplane) makes infra into more controllers in the same cluster — coexisting reconcilers, not one dependency model spanning infrastructure, networking, workloads, and SaaS. To get a single authoritative graph with one reconciliation loop, the graph has to be the foundation, not an integration layer bolted on top. That is why Monk's orchestrator is built from the ground up rather than wrapping Kubernetes. ## Monk vs. PaaS (Heroku, Vercel, Railway, Render) A Platform-as-a-Service is a fast path to production for applications that fit its mold. Monk gives you that same simplicity for *any* application — and simple apps stay just as frictionless. For a static site, Monk can even drive a PaaS like Vercel or Netlify for you, managing it as one more resource in your application graph. The difference shows the moment you outgrow the box. A PaaS owns the underlying infrastructure and supports only the architectures it anticipated. When you need multiple services, a specific cloud provider, GPU workloads, a custom database, or a topology the platform didn't plan for, you hit a wall. Monk has no such ceiling. Monk offers the convenience of a platform — one prompt to production, no manual configuration — with the openness of owning your own infrastructure: * **Bring your own cloud.** Everything runs on your AWS, GCP, Azure, DigitalOcean, or Hetzner accounts. You own the infrastructure; Monk orchestrates it. * **No fixed application shape.** Any language, any framework, any combination of services and providers. * **Swap and move.** Change a self-hosted database for a managed one by swapping a package; move between clouds by extending the cluster and migrating — same application, same configuration, different infrastructure. ## Monk vs. an AI agent with scripts or MCP tools As coding agents gain shell access and tool integrations, a natural question is whether deployment is just another thing an agent can script. The difference is **where the state lives**. An agent with a shell *is* the control plane during a session: its plan, the resources it discovered, and its credentials all live in the context window — and they evaporate when the session ends. The next session starts from zero and has to rediscover what exists. Monk inverts this. The agent is a **client of a deterministic control plane that holds the state**. That state survives sessions, restarts, and failures, so operations pick up exactly where they left off. The orchestrator computes a deterministic plan from desired versus observed state; the AI provides intent, not improvisation. This is the difference between "deploy once if nothing goes wrong" and operating a system on day two hundred. What Monk does for you after the first deployment. ## Summary | | Mainstream stack | Monk | | ----------------------------- | ------------------------------------------ | --------------------------------- | | **Model** | Separate tools per layer | One orchestrator, one graph | | **State** | Fragmented (state file + etcd + operators) | Single live application graph | | **Reconciliation** | Per-tool, mostly human-triggered | Continuous, across all layers | | **The wiring between layers** | Human glue and runbooks | First-class edges in the graph | | **Infrastructure** | Yours (Terraform) / theirs (PaaS) | Yours (bring-your-own-cloud) | | **Operation** | Deploy, then operate by hand | Deploy *and* operate autonomously | Install Monk, connect your coding agent, and deploy your first app — step by step.