Fast feedback on Kubernetes: Key takeaways from “Fast Feedback Development meets Kubernetes with Tilt” (Michael Sattler, nexyo GmbH)

The developer’s dilemma: speed, complexity, and drift between environments

In “Fast Feedback Development meets Kubernetes with Tilt,” Michael Sattler of nexyo GmbH walked through a familiar challenge: how to keep rapid, high-quality development feedback when your stack grows into microservices and your infrastructure moves to Kubernetes and the cloud. From our DevJobs.at editorial vantage point, the session was a practical blueprint for aligning local dev, CI/CD, and production—without sacrificing developer experience.

Sattler framed the problem space in three parts that many engineering teams will recognize:

• Missing fast feedback for code changes in local development
• Many hard-to-manage local configurations for different developer needs
• Environment drift raising the question: “Will this really work in prod?”

Notably, these issues surfaced in spite of a modern toolchain—containerized services, CI pipelines, and later a cloud-first move to Kubernetes with Azure, Terraform, and Helm. The core pain wasn’t a lack of automation; it was the lack of coherence across dev, CI, and prod, which slowed down feedback loops.

Below, we recap the pain points, the introduction of Tilt and K3D, the architecture choices, a live demo, and the concrete lessons that teams can apply.

Before Tilt: Docker Compose plus manual steps equals slow loops

The team initially combined development scenarios using several Docker Compose files. On paper that enabled flexible local setups; in practice it left too many manual steps:

• Re-compiling Go and Java services
• Restarting Docker containers
• Waiting for CI to build an image in a private registry to test locally

At worst, waiting for the CI build took up to 20 minutes—hardly a fast feedback loop. Context evaporates during that time and iteration cadence drops.

As the codebase and number of microservices grew, pressure mounted. Local setups had to cover an increasing range of scenarios and they diverged from the evolving production environment.

Cloud-first, but not dev-first: the widening gap with production

In early 2023, the team went cloud-first: Kubernetes and multiple Azure services, all deployed via Terraform and Helm. It brought scale and automation—but local dev and CI pipelines drifted away from production reality:

• Different toolchains and orchestration flows
• Higher maintenance burden for local setups
• Onboarding became cumbersome: “too many things in too many places”

The drift had concrete consequences. Engineers repeatedly asked if things that worked locally or in CI would hold in production. One example Sattler highlighted: setting up SSL locally to access a frontend via HTTPS. In prod, certificates are automated in the cluster; locally they used self-signed certificates and a workflow that felt nothing like production.

Tilt as the missing piece: Kubernetes workflows with fast feedback

The turning point came with Tilt—an open-source microservice development environment for teams that deploy to Kubernetes. Sattler called it an elegant solution that addresses multiple pain points at once:

• Run a local Kubernetes cluster via K3D
• Declaratively describe dev infrastructure in a Tiltfile (Starlark syntax)
• Automatically synchronize file changes with running services
• One entry point: “tilt up” to start and keep everything in sync

Tilt groups setup, build, and deploy steps into “resources.” When you declare file and folder dependencies per resource, Tilt only re-executes the affected parts upon changes—rebuilding images, deploying manifests, and updating running components. This incremental approach slashes wait times and restores fast feedback inside a realistic Kubernetes environment.

Tilt’s dashboard adds visibility: resource status, activity, and grouping—helpful for team members who aren’t Kubernetes experts.

The architecture view: same artifacts, consistent processes

Sattler outlined a unified flow where local dev and CI simulate production closely, while production keeps its own orchestration control:

• Local development: K3D as the cluster, deployments controlled by Tilt
• CI test jobs: K3D also controlled by Tilt, for production-like end-to-end testing
• Production: Azure Kubernetes cluster, deployments controlled by Terraform; Helm charts are the shared artifact across all stages

The key is that the same Helm charts are used locally and in production. The difference lies in who triggers deployments: Tilt locally and in CI, Terraform in production. That way, configuration remains synchronized, and adding new services to the local stack feels like “set it up once, run it everywhere.”

One Tiltfile, many dev setups: shareable and reproducible

nexyo’s team leaned on Tilt’s Starlark-powered configuration to make custom setups easy to define and share. The Tiltfile reads a configuration and conditionally starts specific resources. Practically speaking, that led to:

• No more hours of tweaking dozens of local files
• Lower maintenance thanks to programmable configuration (loops, conditionals, functions)
• Shareable, reproducible dev variants via tilt-config.json

If someone hits an issue—say, with API tests—they can send their config file to a teammate, who can reproduce the setup and help debug. That shift from tribal knowledge to portable configuration reduces coordination cost and accelerates problem-solving.

Aligning dev, CI/CD, and prod: close simulation and reproducibility

The most powerful result Sattler emphasized: Tilt and K3D synchronize local development with production workflows. CI test jobs run K3D controlled by Tilt, mirroring developers’ local flow. The outcome:

• A close simulation of the production system in test jobs
• Reproducibility of CI environments on developer machines
• Consistent Helm charts and deployment steps across stages

In his words, all environments go through the same processes—using Terraform or Tilt to deploy Helm charts to either K3D or the Azure Kubernetes cluster. New services now truly feel like “set up once, run everywhere.”

The live demo: from a code tweak to a longer API key in 1.1 seconds

To illustrate the fast feedback in action, Sattler demoed a realistic change:

• The local setup supports up to three “Nexio Data Hub” instances; in the demo, two hubs were running.
• For “Hub 0,” the control plane backend microservice ran in dev mode.
• Tilt was configured to update only when files in the control plane service directory changed.

In the Tilt dashboard, all resources showed green and were grouped per hub. The task: review API key generation used by technical users for scripting and similar purposes. Observing the key length, Sattler switched to the Go backend code and opened the function generating the key. A helper function produced a random string with a current length of 32 characters. He doubled the length to 64 and saved the file.

Tilt immediately detected the change and updated the pod in the Kubernetes cluster. Returning to the frontend to generate a new API key, the result was now twice as long. Critically, the update took 1.1 seconds.

This is practically meaningful: it’s not a simple hot reload in a local JS server, but a compiled language running inside a Kubernetes pod being incrementally updated without a full rebuild or container restart.

What stood out technically: targeted, incremental speedups

From an editorial perspective, several technical choices explain the improved developer experience:

• Resource-driven updates instead of global rebuilds: Tilt scopes changes and updates only what’s affected.
• Production-near local environments: K3D plus shared Helm charts reduce the drift to production.
• Declarative infrastructure with a programmable configuration language: Starlark in the Tiltfile scales with the system while avoiding ad-hoc scripting sprawl.
• Visibility for the whole team: The Tilt dashboard lowers the Kubernetes barrier and surfaces operational state.
• Shareability and reproducibility: tilt-config.json turns complex setups into portable artifacts.

Together, these choices accelerate iteration speed without trading away realism.

Lessons for engineering teams

Sattler’s session distilled a set of actionable lessons:

1. Fast feedback is a system property. You need incremental build-and-deploy mechanics to achieve it. Tilt provides the resource-triggered updates; you model the dependencies carefully.
2. Favor production parity over local special cases. Using the same Helm charts locally and in prod reduces maintenance overhead and surprises.
3. Make setups shareable. A single Tiltfile plus tilt-config.json enables reproducible scenarios and collaborative debugging.
4. Invest in visibility. The Tilt dashboard amplifies learning and speeds up onboarding and incident resolution.
5. Keep process cohesion. In prod, Terraform orchestrates; locally and in CI, Tilt does. The processes remain similar; only the control points differ.

From “works on my machine” to realistic dev clusters

The gap between local hacks (e.g., self-signed certs) and automated production processes creates doubt and drags down iteration speed. Sattler’s story shows that the harder part isn’t Kubernetes per se—it’s the friction between different lifecycle stages. Tilt and K3D act as translators between these worlds, bringing production logic into daily development loops without compromising speed.

The net effect is shorter cycles, less maintenance, and a more enjoyable developer experience—all of which contribute to shipping value faster.

Practical entry points (derived directly from the talk)

Based on Sattler’s walkthrough, here are practical first steps to replicate the approach:

• Make local Kubernetes realistic: run a K3D cluster and deploy services onto it.
• Describe dev infrastructure declaratively: create a Tiltfile, define services and processes, and model build-and-deploy steps as resources.
• Maintain explicit file/folder dependencies: ensure only affected resources rebuild and redeploy.
• Use the same Helm charts locally and in production: minimize configuration drift and increase predictability.
• Introduce a tilt-config.json: toggle specific services or stacks and share configurations across the team.
• Embrace the Tilt dashboard: use it to visualize resource status, logs, and groupings.

These are straight from the session’s content and map closely to common microservice-Kubernetes dev setups.

Why the 1.1 seconds matter

The demo’s change—doubling an API key length in a Go-based control plane—is intentionally mundane. It represents the countless day-to-day edits engineers make. The significance lies in the turnaround: Tilt scoping the change to a new binary, syncing it into a running pod, and reflecting it end-to-end in the UI within seconds. No full image rebuild, no CI round-trip, no container restart.

That result collapses the supposed trade-off between Kubernetes realism and local iteration speed. You get both: a production-like cluster and fast feedback.

Conclusion: Tilt and K3D as the bridge between developer speed and production reality

“Fast Feedback Development meets Kubernetes with Tilt” showed how nexyo GmbH resolved a core tension in modern development: iterative work inside a production-like environment without long waits or brittle local hacks. Tilt serves as the enabler—coordinating resource-scoped builds and deploys, syncing only what’s necessary, and giving teams a clear view of system state.

• One shareable, declarative dev infrastructure (Tiltfile + tilt-config.json)
• Shared artifacts across environments (Helm charts)
• Cohesive processes (Tilt locally and in CI, Terraform in prod)
• Team-wide visibility (Tilt dashboard)
• Noticeably shorter feedback loops (down to seconds)

Sattler pointed to the documentation at tilt.dev as a good starting point. For teams living in Kubernetes and serious about fast feedback, Tilt plus K3D offers a pragmatic blueprint.

As Sattler noted, he’s open to questions via email or LinkedIn. Our main takeaway: fast feedback and Kubernetes don’t have to be at odds. With the right building blocks—Tilt, K3D, Helm, Terraform—the question “will it work in prod?” increasingly becomes “it already does.”

• 

  

  Go and DDD := Building the Right Thing

  Andreas Krimbacher von nexyo spricht in seinem devjobs.at TechTalk über die Entscheidungen, welche hinter der im Unternehmen angewandten Technologie Go und der Wahl der Architektur stehen.

  Watch now

• 

  

  Andreas Krimbacher, CTO von nexyo

  Der CTO von nexyo Andreas Krimbacher gibt im Interview Einblicke über das Team, wie der Recruiting Prozess abläuft und wie das Unternehmen die technologischen Herausforderungen meistert.

  Watch now

• 

  

  Michael Sattler, Software Engineer bei nexyo

  Software Engineer bei nexyo Michael Sattler gibt im Interview Einblicke in seinen Background zum Software Engineering, was seine aktuelle Arbeit beinhaltet und gibt Tipps für Neueinsteiger.

  Watch now