> ## 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.

# Migrating from Kubernetes

> Move from Kubernetes, Docker Swarm, or DIY cloud setups to Monk

## Why Migrate from Kubernetes?

Kubernetes is powerful but complex. If you're spending more time managing infrastructure than building features, Monk offers a better way.

### Common Kubernetes Pain Points

**Complexity overload:**

* Steep learning curve
* Endless YAML files
* Complex networking (Ingress, Services, Network Policies)
* Constant troubleshooting

**Operational burden:**

* Managing control plane
* Upgrading clusters
* Certificate management
* RBAC configuration
* Storage provisioning

**Developer friction:**

* Developers need K8s knowledge to deploy
* Long feedback loops
* Context switching between code and infrastructure
* Difficult local development

**Multi-cloud challenges:**

* Different K8s flavors per cloud (EKS, GKE, AKS)
* Complex migration between clouds
* Provider-specific configurations

### What Monk Offers Instead

* **No Kubernetes** — Monk uses its own distributed orchestrator
* **No YAML engineering** — Natural language operations
* **Autonomous management** — Monk handles operations
* **Multi-cloud native** — Deploy anywhere without reconfiguration
* **Developer-friendly** — No K8s knowledge required
* **Your infrastructure** — BYOI model, you control everything

<Note>
  Monk **doesn't use Kubernetes** under the hood. It has its own distributed orchestrator that eliminates K8s complexity while providing the same container orchestration capabilities.

  → [Does Monk use Kubernetes or Terraform?](/faq#does-monk-use-kubernetes-or-terraform-under-the-hood)
</Note>

## What Monk Reads from Your K8s Setup

Monk analyzes your Kubernetes configurations to understand your application:

### Kubernetes Artifacts Monk Understands

**Manifest files:**

* Deployments
* StatefulSets
* DaemonSets
* Services (ClusterIP, NodePort, LoadBalancer)
* Ingress rules
* ConfigMaps
* Secrets
* PersistentVolumeClaims

**Helm charts:**

* Chart definitions
* Values files
* Dependencies
* Templates

**Kustomize:**

* Base configurations
* Overlays
* Patches

**Operators:**

* Custom Resource Definitions (CRDs)
* Operator configurations

<Tip>
  Monk uses these files to **understand** your application, but doesn't require
  them. You can give Monk raw source code with no K8s configs, and it figures
  everything out.
</Tip>

## Migration Steps

<Steps>
  <Step title="Install Monk">
    Install the [Monk agent plugin](/getting-started/get-started) for Claude Code, Codex, Cursor, or Antigravity.
  </Step>

  <Step title="Open Your Application Code">
    Open your application source code (not just K8s manifests) in your IDE. Monk
    needs your actual application code to understand and deploy it.
  </Step>

  <Step title="Export Configurations">
    Extract any critical configurations from K8s: - Environment variables from
    ConfigMaps - Secrets - External service endpoints - Custom settings You'll
    provide these to Monk during deployment.
  </Step>

  <Step title="Tell Monk to Deploy">
    Tell your coding agent: `deploy this application to AWS` Monk
    doesn't need your K8s manifests — it analyzes your code directly.
  </Step>

  <Step title="Monk Analyzes Your App">
    Monk examines: - Source code and dependencies - Dockerfiles (uses or optimizes
    them) - docker-compose.yml (if present) - Kubernetes configs (for
    understanding) - Service dependencies
  </Step>

  <Step title="Answer Monk's Questions">
    Monk may ask about: - Deployment preferences (managed vs self-hosted
    databases) - Replica counts - Resource requirements - External service
    configurations
  </Step>

  <Step title="Provide Cloud Credentials">
    Give Monk credentials to provision resources. These stay on your machine. →
    [Security](/features/security)
  </Step>

  <Step title="Monk Deploys Everything">
    Monk autonomously: - [Containerizes](/features/containerization) your services
    (no K8s) - Provisions infrastructure - Deploys and orchestrates containers -
    Configures networking and load balancing - Sets up monitoring and logging -
    Wires everything together
  </Step>

  <Step title="Test New Deployment">
    Monk provides URLs to access your application. Test thoroughly while your K8s
    cluster continues running.
  </Step>

  <Step title="Migrate Data">
    For stateful workloads: - Export data from K8s PersistentVolumes - Import to
    new Monk-managed storage - Or keep databases on original infrastructure
    initially → [Working with Databases](/prompting/working-with-databases)
  </Step>

  <Step title="Switch Traffic">
    Update DNS or load balancer to point to Monk-managed deployment.
  </Step>

  <Step title="Decommission K8s Cluster">
    After confirming everything works, shut down your Kubernetes cluster. Monk never touches it — you're in control.
  </Step>
</Steps>

## Kubernetes to Monk Translation

### What Monk Replaces

| Kubernetes Concept      | Monk Equivalent                                     | How It Works                                                   |
| ----------------------- | --------------------------------------------------- | -------------------------------------------------------------- |
| Deployment              | [Containerized service](/features/containerization) | Monk orchestrates containers natively                          |
| StatefulSet             | Stateful container                                  | Monk handles persistence automatically                         |
| Service                 | Networking config                                   | [Automatic service discovery](/features/networking)            |
| Ingress                 | Load balancer                                       | [Automatic routing](/features/networking)                      |
| ConfigMap               | Environment variables                               | [Configuration management](/features/configuration-and-wiring) |
| Secret                  | Secure secrets                                      | Encrypted secret storage                                       |
| PersistentVolumeClaim   | Storage volumes                                     | Automatic volume provisioning                                  |
| HorizontalPodAutoscaler | Auto-scaling                                        | [Autonomous scaling](/features/scaling)                        |
| Namespace               | Isolated environment                                | [Multi-environment support](/features/autonomous-deployment)   |
| Helm Chart              | —                                                   | Not needed, Monk analyzes code                                 |
| kubectl                 | Monk chat                                           | Natural language operations                                    |

### Operations Translation

**Kubernetes commands:**

```bash theme={null}
kubectl apply -f deployment.yaml
kubectl scale deployment my-app --replicas=3
kubectl logs deployment/my-app -f
kubectl get pods
kubectl rollout restart deployment/my-app
kubectl port-forward svc/my-app 8080:80
```

**Monk equivalents:**

```
deploy this application
scale to 3 replicas
show me the logs
show running services
restart the application
access my-app on port 8080
```

Natural language. No memorization. Monk executes autonomously.

## Example Migration

### Your Current K8s Setup

```yaml theme={null}
# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
        - name: api
          image: myregistry/api:latest
          ports:
            - containerPort: 3000
          env:
            - name: DATABASE_URL
              valueFrom:
                secretKeyRef:
                  name: db-secret
                  key: url

---
apiVersion: v1
kind: Service
metadata:
  name: api-service
spec:
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: 3000
  selector:
    app: api
```

### With Monk

```
You: deploy this application to AWS with 3 replicas

Monk: Analyzing application...
      Found: Node.js API server on port 3000
      Detected: PostgreSQL dependency

      I'll deploy:
      - API server (3 replicas, containerized)
      - Load balancer (port 80 → 3000)
      - PostgreSQL database

      Need DATABASE_URL environment variable. Provide or use managed RDS?

You: use managed RDS

Monk: Provisioning AWS RDS PostgreSQL...
      Deploying API servers (3 replicas)...
      Configuring load balancer...

      ✓ Deployment complete
      URL: https://api.yourapp.com
```

**No YAML. No kubectl. Just conversation.**

## What Gets Better with Monk

### Simplified Operations

**With Kubernetes:**

* Write YAML manifests
* Apply with kubectl
* Debug pod failures
* Manage Ingress controllers
* Configure service meshes
* Handle certificate rotation
* Upgrade clusters

**With Monk:**

* Chat with Monk in natural language
* Monk handles everything autonomously
* No manual infrastructure management
* Automatic updates and maintenance

→ [Autonomous Operations](/getting-started/autonomous-operations)

### True Multi-Cloud

**With Kubernetes:**

* EKS for AWS (different from GKE, different from AKS)
* Rewrite ingress controllers per cloud
* Different storage classes
* Provider-specific annotations
* Complex migration process

**With Monk:**

* Same experience on any cloud
* No cloud-specific configuration
* Migrate with one command: `migrate this app to GCP`
* No rewriting required

→ [Multi-Cloud Support](/features/multi-cloud)

### Developer Friendliness

**With Kubernetes:**

* Developers need K8s knowledge
* Complex local development (minikube, kind)
* Long feedback loops
* Difficult troubleshooting

**With Monk:**

* Developers use natural language
* No K8s expertise needed
* Fast deployments
* [IDE-native](/getting-started/get-started) troubleshooting

### Cost Efficiency

**Monk advantages:**

* No control plane costs (Monk orchestrator runs on your VMs)
* Efficient resource usage
* [Real-time cost tracking](/features/cost-tracking)
* Easy provider switching for savings

## Common Kubernetes Migration Questions

### Do I need to rewrite my Dockerfiles?

**No.** Monk uses your existing Dockerfiles or generates optimized ones if you don't have them.

### What about my Helm charts?

You don't need them anymore. Monk reads them to understand your app, then deploys directly without Helm.

### Can I keep some workloads on K8s?

**Yes.** Migrate incrementally:

1. Deploy one service with Monk
2. Connect it to K8s workloads
3. Migrate more services gradually
4. Complete when confident

### What happens to my StatefulSets?

Monk handles stateful workloads automatically. Persistent storage is provisioned as needed.

### Can I use my existing container images?

**Yes.** Monk can pull from any registry (Docker Hub, ECR, GCR, ACR, private registries).

### What about service meshes (Istio, Linkerd)?

Not needed. Monk provides [automatic networking](/features/networking) and [encrypted service-to-service communication](/features/security).

### How do I handle custom Operators?

Monk may not support custom operators directly. For specialized workloads, consider:

* Keeping those on K8s
* Migrating the rest to Monk
* Connecting Monk services to K8s operators

## After Migration

### What You Get

* **No Kubernetes complexity** — Monk's orchestrator, not K8s
* **Autonomous operations** — Chat-based management
* **Multi-cloud freedom** — Deploy anywhere
* **Faster deployments** — Minutes instead of hours
* **Better developer experience** — No K8s knowledge needed
* **Cost transparency** — Real-time tracking

### Next Steps

* Set up [CI/CD pipelines](/prompting/setting-up-cicd)
* Configure [auto-scaling](/prompting/scaling-resources)
* Enable [monitoring](/prompting/monitoring-and-debugging)
* Track [costs](/prompting/managing-costs)

## Comparison Table

| Aspect             | Kubernetes                  | Monk                                            |
| ------------------ | --------------------------- | ----------------------------------------------- |
| **Learning Curve** | Steep (weeks to months)     | Minutes (natural language)                      |
| **Configuration**  | YAML manifests              | Code analysis, no config needed                 |
| **Operations**     | kubectl commands            | Chat interface                                  |
| **Multi-cloud**    | Complex, provider-specific  | Native, seamless                                |
| **Deployment**     | Manual apply                | Autonomous                                      |
| **Scaling**        | Manual or HPA               | [Autonomous](/features/scaling)                 |
| **Control Plane**  | Requires management         | Runs on your VMs                                |
| **Cost**           | Control plane + nodes       | Just your VMs                                   |
| **Networking**     | Complex (Ingress, Services) | [Automatic](/features/networking)               |
| **Storage**        | PVC + Storage Classes       | Automatic provisioning                          |
| **CI/CD**          | External tools required     | [Built-in automation](/features/build-and-cicd) |
| **Monitoring**     | Prometheus + Grafana setup  | [Built-in](/features/monitoring)                |

## Need Help?

**Ask Monk directly:**

```
how do I migrate from Kubernetes?
```

Monk understands your K8s setup and guides you through migration.

**Support:**

* [Getting Help](/getting-help) — All support channels
* [Community Forum](https://roadmap.monk.io/) — Ask the community

## Start Migrating

Ready to leave Kubernetes behind?

1. [Install the Monk agent plugin](/getting-started/get-started)
2. Open your application code
3. Tell Monk: `deploy this application`

Monk figures out the rest. No YAML required.