[HN Gopher] Tilt: dev environment as code
___________________________________________________________________
Tilt: dev environment as code
Author : saikatsg
Score : 34 points
Date : 2025-04-26 19:14 UTC (3 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| cirego wrote:
| 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.
| kevmo314 wrote:
| 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!
| sigmonsays wrote:
| 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?
| Szpadel wrote:
| 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 wrote:
| 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.
| Noumenon72 wrote:
| 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 wrote:
| 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.
| eats_indigo wrote:
| 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.
| dharmab wrote:
| 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
| satvikpendem wrote:
| Isn't this essentially dev containers?
| Kuraj wrote:
| Yeah it would be really useful to have in the readme what kind
| of problems this solves that dev containers don't solve already
| cirego wrote:
| 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.
| p0w3n3d wrote:
| Backdays we used to have # vim: ts=2 sw=2 et
|
| And a shebang line
| senko wrote:
| Ah, the time when "ai" meant "autoindent" ...
| o11c wrote:
| To be fair, it remains the most useful AI for programming.
| When it's wrong, it's obvious _immediately_ when you look at
| it!
| pcthrowaway wrote:
| 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
| dhorthy wrote:
| 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
| siliconc0w wrote:
| 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 wrote:
| 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.
| patwoz wrote:
| How does Tilt compare to "skaffold dev"? We use skaffold exactly
| for that purpose. To develop within a the cluster.
| turtlebits wrote:
| 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 wrote:
| I've always appreciated that Tilt chose Starlark instead of
| YAML. Makes things so much cleaner!
| tomjakubowski wrote:
| 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.
| cirego wrote:
| I think Tilt Extensions highlights the combined power and
| composability that using Starlarks brings to Tilt:
| https://docs.tilt.dev/extensions.html.
|
| Want to create a Kubernetes secret? It's as simple as:
| load('ext://secret', 'secret_yaml_generic')
| k8s_yaml(secret_yaml_generic(...))
|
| Want to create that secret from Vault instead?
| load('ext://vault_client', 'vault_read_secret',
| 'vault_set_env_vars')
| vault_set_env_vars('https://localhost:8200','mytoken')
| my_foo = vault_read_secret('path/myfoo', 'value')
| my_bar = vault_read_secret('path/mybar', 'foobar')
| eats_indigo wrote:
| 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
| lima wrote:
| Much more flexible than Skaffold thanks to Starlark config vs.
| a rigid YAML structure.
| philip1209 wrote:
| 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:
|
| https://github.com/chroma-core/chroma
| cirego wrote:
| 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.
| eats_indigo wrote:
| Love tilt, have found it much more difficult to set up in a
| docker-compose environment than a cloud native / minikube context
___________________________________________________________________
(page generated 2025-04-26 23:00 UTC)