Migrate from Kubernetes to osModa: 22 Concepts to SSH + NixOS
Kubernetes was built to orchestrate thousands of stateless microservices at Google scale. Running a handful of AI agents on it means learning pods, deployments, services, ingress, config maps, secrets, PVCs, and 15+ more concepts -- then writing hundreds of lines of YAML. osModa replaces all of that with SSH access to a dedicated NixOS server with built-in self-healing, audit logging, and encrypted mesh networking from $14.99/mo.
TL;DR
- • Kubernetes requires 22+ concepts and hundreds of lines of YAML for a few agents
- • osModa: SSH into a dedicated NixOS server, run your processes, done
- • k8s Deployments/Pods become processes monitored by osmoda-watch
- • k8s Services/Ingress become direct port binding or osmoda-mesh
- • Managed k8s (EKS/GKE/AKS) costs $73+/mo just for the control plane
Step-by-Step Migration from Kubernetes
Migrating from Kubernetes to osModa is less about translating config files and more about simplifying your architecture. The goal is to identify what your Kubernetes manifests actually do and map each piece to the much simpler osModa equivalent.
Step 1: Inventory Your Kubernetes Resources
Run kubectl get all --all-namespaces to see every resource in your cluster. For each Deployment, note the container image, resource requests/limits, environment variables, volume mounts, and replicas. Document your Services (which ports are exposed), Ingress rules (which domains route to which services), ConfigMaps, and Secrets. This inventory is your migration blueprint.
Step 2: Map Services to osModa Nodes
Determine how many osModa servers you need. If your k8s cluster runs 3-5 services that collectively need 4 CPUs and 8 GB RAM, a single Pro plan server ($34.99/mo, 4 CPU, 8 GB RAM) can run all of them as processes on one machine. For workloads that genuinely require multiple nodes (separate regions, isolation requirements, or resource needs exceeding a single server), spawn multiple osModa servers and connect them via osmoda-mesh.
Step 3: Spawn osModa Servers
Use the osModa dashboard or API to spawn your servers. Provisioning takes 5-10 minutes per server. You get IP addresses, SSH credentials, and WebSocket endpoints. If spawning multiple servers, osmoda-mesh automatically establishes encrypted connections between them.
Step 4: Deploy Your Applications
SSH into each server and deploy your applications. What was a Kubernetes Deployment with a container image becomes: install the runtime via NixOS packages, clone your code, set environment variables, and start the process. ConfigMaps become configuration files on the filesystem. Secrets become environment variables or files in a secure directory. PersistentVolumeClaims become directories on the server's disk (40-320 GB depending on plan).
Step 5: Configure Networking
Kubernetes Services and Ingress resources are replaced by direct port binding. Your application listens on a port, and you point DNS to the server IP. For inter-service communication that previously used Kubernetes ClusterIP services, processes on the same osModa server communicate via localhost. For cross-server communication, osmoda-mesh provides encrypted peer-to-peer networking with automatic service discovery -- no NetworkPolicy YAML required.
Step 6: Verify and Decommission
Test all services on osModa while your Kubernetes cluster continues running. Verify API endpoints, inter-service communication, database connections, and external integrations. Once confirmed, update DNS to point to osModa servers. After production traffic is stable, drain and delete your Kubernetes nodes, then destroy the cluster to stop cloud provider billing.
Before and After: Kubernetes vs osModa
| K8s Concept | Kubernetes | osModa Equivalent |
|---|---|---|
| Pod | Container group in shared namespace | Process on your server |
| Deployment | YAML manifest + rolling update | Deploy via SSH + NixOS atomic switch |
| Service | ClusterIP / LoadBalancer | Direct port binding / osmoda-mesh |
| Ingress | Ingress controller + YAML rules | DNS pointing to server IP |
| ConfigMap | YAML-encoded configuration | Config files on filesystem |
| Secret | Base64-encoded in etcd | Env vars / osmoda-keyd vault |
| PVC | Storage claim + provisioner | Filesystem directory (40-320 GB) |
| Health Check | Liveness/readiness probes | osmoda-watch automatic monitoring |
| Rollback | kubectl rollout undo (per-deployment) | Yes -- NixOS atomic rollback (whole system) |
| Networking | CNI + kube-proxy + NetworkPolicy | osmoda-mesh (post-quantum, zero config) |
Key Differences: Kubernetes vs osModa
Complexity: 22 Concepts vs SSH
Running a simple application on Kubernetes requires understanding pods, containers, deployments, replica sets, services, endpoints, ingress, ingress controllers, config maps, secrets, persistent volumes, persistent volume claims, storage classes, namespaces, RBAC, service accounts, network policies, resource quotas, limit ranges, horizontal pod autoscaler, and more. On osModa, you SSH into a server, deploy your code, and let the platform daemons handle the rest.
YAML Manifests vs Declarative Config
A typical Kubernetes deployment for a single service requires 100+ lines of YAML across Deployment, Service, Ingress, ConfigMap, and Secret manifests. Running 5 AI agents requires 500+ lines of YAML that must be kept in sync. On osModa, you manage NixOS configuration for the system and run processes directly. The NixOS configuration for an entire server with multiple services is typically shorter than the Kubernetes YAML for a single service.
What You Gain
Moving from Kubernetes to osModa eliminates k8s complexity, YAML manifests, kubectl, and the need for DevOps engineers who specialize in Kubernetes. You get dedicated servers with full root access, self-healing with crash-loop detection, SHA-256 audit logging, NixOS atomic rollbacks, osmoda-mesh for encrypted networking, and flat-rate pricing. The total cost of ownership drops dramatically because you eliminate managed k8s control plane fees, worker node costs, and the engineering time spent on k8s operations.
What Requires Manual Work
Kubernetes provides features that osModa does not replicate: horizontal pod auto-scaling, advanced traffic routing (canary, blue-green), multi-cluster federation, and the ability to run thousands of services across hundreds of nodes. If you genuinely need these capabilities, Kubernetes is the right tool. For small teams running 1-20 AI agents, the complexity cost of Kubernetes far exceeds the benefit. The migration itself requires understanding both your k8s manifests and NixOS configuration, which takes time if your team is new to NixOS.
Explore More Migration Guides
- Migrate from Docker Compose -- containers to NixOS declarative config
- Migrate from AWS -- 200+ services to one dedicated server
- osModa vs Kubernetes (full comparison) -- detailed breakdown
- Migrate from Heroku -- dynos to dedicated servers
- All migration guides -- complete list of platform migration guides
Frequently Asked Questions
Is osModa really a Kubernetes replacement?
For small-to-medium AI agent workloads (1-20 agents), yes. Kubernetes was designed for orchestrating thousands of stateless microservices across large clusters. If you are running a handful of AI agents, Kubernetes introduces massive complexity for minimal benefit. osModa provides the features that actually matter for agent workloads -- self-healing, process supervision, encrypted networking, and audit logging -- without requiring you to learn 22+ k8s concepts. For teams running 100+ microservices at enterprise scale, Kubernetes may still be the right choice.
How do I map Kubernetes services to osModa?
Each Kubernetes Deployment/Pod maps to a process running on an osModa server monitored by osmoda-watch. Kubernetes Services (ClusterIP, LoadBalancer) are replaced by direct port binding or osmoda-mesh for cross-server communication. ConfigMaps and Secrets become environment variables or configuration files on the server. PersistentVolumeClaims become directories on the server's filesystem. Ingress is replaced by direct DNS pointing to the server IP or a reverse proxy you configure.
What replaces kubectl on osModa?
SSH. Instead of 'kubectl exec -it pod -- /bin/sh', you 'ssh root@server'. Instead of 'kubectl logs pod', you check logs directly on the server or via the osModa dashboard. Instead of 'kubectl apply -f deployment.yaml', you edit the NixOS configuration and run 'nixos-rebuild switch'. The interface is simpler because you are managing a server, not an orchestration platform.
What about Kubernetes auto-scaling?
Kubernetes Horizontal Pod Autoscaler scales pods based on CPU/memory metrics. osModa servers have fixed resources per plan. For AI agent workloads, auto-scaling is rarely the right model -- agents are long-running processes, not request-response services that need more replicas during traffic spikes. If you need more capacity, spawn an additional osModa server and connect it via osmoda-mesh. For workloads that genuinely need dynamic scaling across many nodes, Kubernetes may still be more appropriate.
How does osmoda-mesh compare to Kubernetes networking?
Kubernetes networking uses kube-proxy, CNI plugins, and DNS-based service discovery to route traffic between pods. This requires understanding Services, Endpoints, NetworkPolicies, and Ingress resources. osmoda-mesh provides encrypted peer-to-peer networking between osModa servers with automatic peer discovery. There are no YAML resources to configure -- mesh networking is active on every server by default. The trade-off is that osmoda-mesh is simpler but less configurable than Kubernetes networking for complex routing rules.
Can I migrate from managed Kubernetes (EKS, GKE, AKS)?
Yes. Managed Kubernetes services add cloud provider costs on top of k8s complexity. AWS EKS charges $0.10/hour ($73/mo) just for the control plane, plus EC2 instance costs for worker nodes. GKE charges $0.10/hour for Autopilot clusters. The migration process is the same regardless of whether you run self-managed or managed Kubernetes: identify your services, translate them to osModa processes, and deploy. You may also need to replace cloud-specific integrations (AWS ALB Ingress, GCP Load Balancer) with direct networking.
Escape Kubernetes Complexity
Dedicated NixOS servers with SSH access, self-healing, audit logging, and encrypted mesh networking. No YAML, no kubectl, no DevOps hire. From $14.99/mo.
Explore More
Last updated: March 2026