How to migrate from Kubernetes to Nomad and cut costs

Why consider moving away from Kubernetes

Kubernetes has become the industry standard for container orchestration (tools that automate container creation and lifecycle management), but its architectural complexity comes at a high price. For many companies and engineering teams, managing multiple control plane components, certificates, virtual networks, and custom CRDs consumes precious development time. In practice, this means engineers spend more hours maintaining infrastructure than delivering business value to end users. When looking for alternatives, many organizations find Nomad to be a much leaner approach, focused exclusively on scheduling and running workloads without the classic operational overhead of traditional cloud-native ecosystems.

Understanding Nomad's operational philosophy

Created by HashiCorp, Nomad was designed from the ground up to be a simple, reliable, and application-agnostic tool. Unlike Kubernetes, which requires dozens of auxiliary services to function fully, Nomad is distributed as a single compiled binary file. In practice, it acts as both client and server by simply toggling a startup flag. This simplicity eliminates single points of failure and dramatically reduces the attack surface for security vulnerabilities. To better understand infrastructure impacts, it is worth exploring complementary observability strategies, such as how to monitor Docker containers with Prometheus alerts, which keep telemetry clean and straightforward.

Practical architecture and resource comparison

When putting Kubernetes and Nomad side by side, the difference in resource consumption is staggering. The Kubernetes control plane requires gigabytes of memory just to maintain cluster state in etcd and process controller reconciliation loops. Nomad, on the other hand, consumes only a few megabytes to manage thousands of tasks with high availability. In the table below, we break down the main operational trade-offs between both platforms to facilitate technical decision-making during workload migration scenarios.

Translating YAML files into HCL jobs

Migrating an application from Kubernetes to Nomad involves rewriting the deployment specification. In Kubernetes, we use long YAML files with multiple objects like Deployments, Services, and Ingress. In Nomad, we use HCL (HashiCorp Configuration Language), which groups all application logic into a single cohesive job file. In practice, this means defining a task group, network constraints, and restart policies becomes far more readable and less prone to indentation errors or API version mismatches. It is a paradigm shift that brings infrastructure closer to human-readable code clarity.

Step-by-step guide to deploying your first Nomad job

To get hands-on and test Nomad's simplicity, let's run a simple container using the official CLI tool. Make sure you have the Nomad binary installed in your development environment or test server before proceeding with the commands below.

1. Initialize the Nomad agent in development mode on your machine for quick validation tests:

   nomad agent -dev

2. Create a configuration file named web.hcl with the job definition to run a lightweight web server:
   

   job "web-server" {
     datacenters = ["dc1"]
     group "frontend" {
       count = 1
       task "server" {
         driver = "docker"
         config {
           image = "nginx:alpine"
           ports = ["http"]
         }
         resources {
           cpu    = 100
           memory = 128
         }
       }
     }
   }

3. Submit the job to the Nomad server and verify its immediate execution in the dashboard or terminal:

   nomad job run web.hcl

Common pitfalls and transition cautions

While the transition brings expressive efficiency gains, there are critical warning points every engineer should weigh. The Kubernetes ecosystem has established native solutions for advanced service discovery and complex service meshes like Istio. In Nomad, we rely on complementary tools like Consul for service discovery or simpler approaches based on internal DNS and reverse proxy routing. Carefully evaluating these dependencies prevents surprises when deploying legacy systems or highly distributed microservices into production. To complement this implementation in production environments, see our related technical analyses on How to Build Local Autonomous AI Agents with Rust and Ollama and Why does rate limiting fail in microservices?.

Final thoughts on simplicity and efficiency

Adopting Nomad to replace Kubernetes is not a technological step backward, but rather a pragmatic engineering decision based on real resource constraints and operational agility needs. When orchestrator complexity exceeds application complexity, it is time to reevaluate chosen tools. By simplifying the infrastructure lifecycle, teams gain delivery speed and significantly reduce cloud computing costs.