Tilt

Working on several services can mean repeatedly starting dependencies, rebuilding images and finding the right logs after each code change. Tilt coordinates that development environment from a Tiltfile and watches for changes that require a build, deployment or configured live update. It helps shorten the feedback loop while keeping the workflow visible to the team. An in-place update can change a running container without changing its image, so verify the final application through a clean, reproducible build too.

Current guidance

Live Update checks fallback rules before synchronizing files, then executes run steps. With docker_build or custom_build, the initial build is a full build; k8s_custom_deploy can instead use a pre-built image, with optional initial_sync to synchronize local files when a container is first observed or restarts. Subsequent configured file changes can take a faster in-place path. This improves iteration but creates a distinction between the running development filesystem and a clean built image.

Define fallback rules for changes that cannot be safely synchronized, such as base-image or dependency changes. Ensure run triggers match the files that require regeneration or process restart. Tiltfiles and their commands execute with developer capabilities, so review repository configuration and restrict the Kubernetes contexts available to development workflows.

For adoption, test source edits, dependency updates, container restart and a full rebuild in a dedicated namespace. Confirm that ignored files and local secrets are not copied unintentionally and that generated assets remain reproducible. Before promoting a change, exercise the application from the image built by the normal delivery pipeline rather than a long-lived Live Update container. Keep cluster cleanup and shared dependency ownership explicit so stopping one developer’s environment does not delete another team’s state.