How kilter uses Tilt

Tilt is the engine of kilter's dev loop. Once kilter up has a cluster running, Tilt takes over: it watches your source files, decides how to get each change into the running container, and keeps every service's build/runtime status visible in one place.

Two paths into the pod

For every change, Tilt picks one of two update paths:

Live update (~1–3s). Tilt copies the changed files directly into the running container (kubectl cp under the hood) — no image rebuild, no pod restart. This is the fast path, and it applies to edits of existing files already in Tilt's sync list (.ts, .tsx, .css).

Image rebuild (~10–30s). Tilt rebuilds the container image and rolls a new pod. This happens on kilter up, on changes outside the sync list, and on Dockerfile changes.

Which path does my change take?

Change	Do	Why
Edit an existing source file	just save	live_update copies it in
New file or directory	`kilter up`	rebuild so Tilt's sync list learns it
`package.json` / dependencies	`kilter up`	needs `npm install` baked into the image
Env var / ConfigMap	`kilter restart`	pod re-reads env, same image
Helm chart values	`kilter up`	Helm release upgrade
Edit "not taking effect"	`kilter up`	module cache may be stale after a synced file

Rule of thumb: if kilter restart doesn't pick up the change, kilter up.

The silent failure: edits that never arrive

If Tilt's live_update sync rules don't cover your source directory, the pod stays healthy but your edits never reach it. Compare file timestamps on host vs pod to confirm; the fix (re-render or splice sync() rules) is in the troubleshooting docs under "Tilt not syncing changes".

kilter up / down and Tilt

kilter up starts (or restarts) Tilt against your project's cluster — and is also how you force a full rebuild.
kilter down stops Tilt but leaves the cluster and all pods running. Your app keeps serving; it just stops reacting to file changes.
kilter stop stops Tilt and pauses the cluster (see KIND).

Debugging

Start with kilter's wrappers:

kilter status            # pod states across the namespace
kilter logs              # tail everything
kilter logs postgres     # tail one service
kilter restart <svc>     # bounce a stuck pod

The Tilt UI is the richer view when a build is the problem: it shows each resource's build log, sync events, and current status, so you can see whether a change went out as a live update or triggered a rebuild — and why a rebuild failed.

Next: How kilter uses Helm — where all those service manifests come from.