K3s in Action

For teams shipping MVPs or managing early-stage products, the infrastructure question is no longer “Should we use Kubernetes?”—it’s “How do we use Kubernetes without slowing ourselves down or overspending?”

When building infrastructure for fast-moving teams or early-stage products, you want something simple, reliable, and doesn't create more work than it solves. For us, K3s has been that middle ground—allowing production-level stability without demanding complex architecture or heavy engineering overhead from day one.

While it's marketed as a lightweight Kubernetes distribution, K3s isn’t just a tool for dev or test workloads. We've found it capable enough to run production-facing services, power developer self-service needs, and accelerate our MVP delivery pipeline.

This article shares our experience using K3s in real-world conditions, some technical steps on how we use it, and how we’ve planned for a future migration to EKS or more robust environments if scale demands it.

K3s, developed by Rancher Labs (now part of SUSE), is a certified Kubernetes distribution built for resource-constrained environments. It’s known for:

We adopted K3s primarily because it allowed:

K3s is Kubernetes minus the friction—perfect for devs focusing on application logic, not cluster bootstrapping.

Here’s a glimpse into our setup and tooling around K3s:

We typically bootstrap single-node clusters for environments like feature testing or developer sandboxing. For production-facing workloads, we use HA (High Availability) multi-node clusters with embedded etcd.

For TLS, load balancing, and DNS:

In production and staging environments, we deploy containerized applications using GitLab CI and GitHub Actions and ArgoCD, tied tightly with K3s.

Here’s how it works:

GitHub/GitLab pipelines build and push Docker images to our container registry (GitHub Packages or GitLab Registry).

Pipelines invoke helm upgrade --install or apply raw manifests for service, deployment, ingress, etc., to K3s clusters running in staging or production.

Each app has a Helm chart template for values-based configuration overrides.

Post-deploy, we trigger synthetic health checks.

If a deployment fails readiness/liveness checks, GitHub/GitLab pipeline reverts using Helm’s rollback capabilities.

We intentionally avoid complexity like dynamic ephemeral clusters or DNS rewriting per branch—because our goal is stability, not show-off automation.

Here are some highlights from our experience:

One of the best wins: our developers now work on the same orchestrator locally as we use for production workloads. No surprises. They can boot up an app with full Ingress, logs, and services

This dramatically reduced the “works on my machine” problem.

We have seen environments spin up in under 30 seconds, whether it’s a fresh cluster or an internal testing setup. This allows faster iterations and full autonomy for internal teams—without DevOps bottlenecks.

K3s works well now—but we’ve planned for eventual scaling, especially if:

Our plan looks like this:

We often see K3s dismissed as a dev-only tool, but we’re using it for actual product workloads:

This ensures that the dev-test-prod journey stays consistent, which helps debug earlier and reduces incident turnaround times.

This helps us making the solution cloud agnostic.

We’re not suggesting K3s as the ultimate Kubernetes replacement, but it’s proven to be a strategic choice for where we are. It gives us the agility of local-first development, the power of Kubernetes, and the focus to build important pieces like:

The point isn’t just about saving cost—it’s about saving complexity early, focusing engineering effort where it matters most, and keeping our path to scale open.

If you’re in the early or mid-stage of a project, or you’re looking to empower your developers without overwhelming your infrastructure team, K3s might just be the right fit.