Tilt: dev environment as code
47 comments
·April 26, 2025cirego
simultsop
As far as I understand, this might be is the best tool for the guy who acquires a SaaS and have no clue how to develop/tweak stuff. Again still have no clue how you enable this or do you still have tilt in production. Marketing is not a big deal for tilt as far as I understand.
AYBABTME
Same, being able to depend on CRDs between resources would be very useful, since a lot of my Tilt usage is about making operators or working with operators.
Happy to see new releases of Tilt even if the pace has slowed down. It's a very useful tool.
kevmo314
The pitch is kinda funny to me:
> Modern apps are made of too many services. They're everywhere and in constant communication.
So we made tooling to make it easier for you to make more of them!
rotbart
Great talk about this... https://www.youtube.com/watch?v=j2AQ9eTZ3-0
mhh__
We need a complexity tariff
altbdoor
Feels like standards xkcd https://xkcd.com/927/
siliconc0w
You're always trading off speed with fidelity. Usually, trying to maintain a local integration environment is going to become too slow and expensive. The problem isn't even necessarily Kubernetes, but as dependencies increase it just gets slower and slower to try and run a copy of the world locally.
I like a fast svelte dev environment with something like docker-compose which might require some mocked out dependencies to keep things fast and then using Kubernetes for other environments once I have local tests passing.
cirego
I think that's a fair point -- you're making a tradeoff. And the best part is that you don't need to choose one or the other.
In my case, I find that I prefer having higher fidelity and simpler service code by using Tilt to avoid mocks. It's also nice for frontend development because, using a Kubernetes ingress, you can avoid the need for things like frontend proxies, CORS and other development-only setup.
ivanjermakov
Can't not mention nix-shell: https://nix.dev/manual/nix/2.18/command-ref/nix-shell
hamandcheese
I still think "dev environments" really ought to be running tests directly with your languages native tool. e.g. `cargo test`, `bundle exec rspec`, etc. If you make me run a VM that runs Kubernetes that runs a docker container that runs the tests, I will be very, very upset. Doing this properly and reliably can still be a lot of work, possibly more work if not relying on Docker is a design goal (which must be if you want to run natively on macOS).
There seem to be a lot of tools in this space. I wish they wouldn't call themselves tools for "dev environments" when they are really more like tools for "deploying an app to your local machine", which is rather different.
brumar
True. I learned this the hard way.
OptionOfT
Not to mention the developer experience is usually sub-par.
I firmly believe that the primary way of interacting with my tests should be the ability to run them one by one from the IDE, and running the code should be run / attach with breakpoints.
michaelmior
It takes some work, but it's entirely possible to both use Docker and run individual tests with breakpoints (in a Docker container) in your IDE. For example, you can attach VS Code to a running container.
philip1209
If you want to see Tilt in action, our Chroma open-source repo uses it to run the distributed version of the database for development and ci. It's pretty cool - just clone then run `tilt up` and it's working:
cirego
Thank you for sharing this! I think your Tiltfile just showed me how to solve something that's been bugging me for a while!
I see that you also have docker-compose files -- are those for different tasks or for developer preference?
I'm also curious to understand why you have different build scripts for CI (`buildx`) vs local (regular docker build)? In our team, we use the same build processes for both.
patwoz
How does Tilt compare to “skaffold dev“? We use skaffold exactly for that purpose. To develop within a the cluster.
eats_indigo
Migrated from Skaffold to Tilt at my last co, found it was much more easier to configure granular rebuild rules, which lead to faster dev loop cycles
3abiton
Any catch?
turtlebits
Skaffold works but its DX is pretty poor. Too many knobs via yaml- tilt has just enough magic that it doesn't feel like a chore to setup local dev.
cirego
I've always appreciated that Tilt chose Starlark instead of YAML. Makes things so much cleaner!
tomjakubowski
Well, now you've really got me interested. Almost every case of a YAML eDSL would be better served by Starlark instead, in my Bazel-brained opinion.
lima
Much more flexible than Skaffold thanks to Starlark config vs. a rigid YAML structure.
ajayvk
Starlark does allow for much more concise and powerful config specification. I am building https://github.com/claceio/clace, which is an application server for teams to deploy internal tools.
Clace uses Starlark for defining apps, instead of something like YAML. https://github.com/claceio/clace/blob/main/examples/utils.st... is a config file which defines around seven apps (apps are downloaded and deployed directly from git).
Clace uses Starlark for defining app level routing rules also. This avoids the need to use a nginx like DSL for routing.
satvikpendem
Isn't this essentially dev containers?
cirego
My understanding is that dev containers are more about configuring your development environment with the right toolchains to build and run services.
Tilt is a monitor process that builds and starts your services, with a hot-reload loop that rebuilds and restarts your services when the underlying code changes. The hot reload loop even works for statically compiled languages.
Kuraj
Yeah it would be really useful to have in the readme what kind of problems this solves that dev containers don't solve already
awsanswers
I hadn't heard of Tilt until this year. I inherited an environment with it integrated. It's a great reliable tool
pcthrowaway
I'm showing my age here, but I legitimately think this classic 2004 progressive anthem from Tilt (Andy Moor project) would have been bang-on perfect for the demo video compared to... whatever stock music that was: https://www.youtube.com/watch?v=0Cm-nrm8H78
sigmonsays
i don't get the value of a tool like this.
Do we really struggle bringing up services as containers and applying kube configs?
For my development of services that run in kube, I don't dev with kube, you shouldn't have to. I also use docker-compose for most dev env services.
Perhaps i'm not developing the right kind of software. Whoever finds this type of tool useful, when would you use it?
dharmab
Our team switched from Docker Compose (without Kubernetes) to Tilt for a distributed systems development environment. (Think platform engineering work on a system that scales from zero to several hundred thousand instances). Our time to go from code change to testable, running code on our laptops went from about a minute to a couple of seconds, using some Tiltfile recipes to do automatic incremental recompilation on our host laptops as we edit source files, and live-reload the new artifacts into running Kubernetes containers. The reload happens so fast that we configured our environment to compile+deploy+run on save, and the new code is already running by the time you reach for the "run tests" button.
I think if you told our team to go back to Docker Compose they'd revolt on the spot haha
eats_indigo
I think if you ever have highly dynamic infrastructure requirements -- think along the lines of a control plane that's spinning up additional workers -- it's really helpful to be able to run your infra provisioning logic locally. There's nothing worse than having to wait on cloud builds to test your iterations.
Noumenon72
If you have sidecar containers that feed your regular containers, or you need to test a Dask KubeCluster, or deploy Helm charts, this kind of lets you work with the real lifecycle. Tilt is kinda better at watching for code changes in all your containers than docker-compose too, and has a nice UI to watch logs and see what succeeded or failed.
cirego
Tilt can also help validate things like:
- Service discovery
- Volume mounts
- Ingress and Certificates
- Metrics scraping and configuration
- Dashboards
It’s really quite powerful and replaces the need to mock things out with docker compose. If you’re deploying to Kubernetes, Tilt gives you the option to avoid “development-only” setups like docker compose.
Szpadel
I never used tilt, but it looks very useful for anything that needs kube API to work, like some operator or something that needs to discover configuration from config maps.
otherwise I think it's meant for systems where system that you need for testing is to big to work on your local machine.
cirego
Yes, Tilt really shines when you’re testing interactions with Kubernetes, such a APIs. But also things like your services’ ingress configuration and metrics scraping.
By default, Tilt is actually intended for local development using kind, minikube or other similar tooling. It supports developing against a multi-node cluster but it requires extra configuration and slows down iteration time.
dhorthy
Been using tilt as a make alternative for years. Great tooling, even as just file watch + pythonic syntax for running tests, etc.
Obvs the real magic is the live syncing patches into remote containers though
Interesting to see this pop up here! I’ve been using Tilt for multiple years now but the pace of development seems to have slowed down after the Docker acquisition.
I love how Tilt enables creating a local development environment that lets my services run the same in production , test and development. Greatly simplifies my service code and improved my quality.
In particular, I’d love to see Tilt be better around handling things like CRDs (there’s no way to mark a k8s_yaml as depending on a CRD being available, a frequent source of broken tilt up invocations).
Having said that, the first thing I do, when working on any new project, is to get “tilt up” working.
Things I’ve used for testing include: eBPF-based collectors for security and observability, data pipelines, helm chart development, and Kubernetes controllers. It’s very flexible and powerful for a wide range of development.