Tilt defines your dev environment as a list of resources.
How Tilt Brings up Resources
While a Tilt environment is running, you can use the CLI to explore the list of resources that Tilt is aware of. This command will print all the resources in the UI:
tilt get uiresources
Here’s example output of what this might look like:
$ tilt get uiresources
NAME CREATED AT
Tilt will try to start up the resources as fast as it’s safe to do so. Here’s the heuristic it uses by default:
Run the Tiltfile to create resources.
local_resourceat a time (so that they can’t step on each others’ local output).
Run up to 3 image build and deploys at a time in parallel (for both Kubernetes resources and Docker Compose resources). Make educated guesses about the correct order of resources and which can be run in parallel based on the YAML.
Continue until all resources have been built.
Sometimes the right startup order depends on application logic that Tilt can’t guess!
For example, you might have a resource
frontend that requires a running
before it starts.
This can lead to distracting errors on startup (especially, e.g., if you have 5 services all depending on the same backend!)
That’s why Tilt gives you a way to specify startup order manually.
resource_deps for Startup Order
Tilt has 3 built-in functions for configuring a resource:
local_resource(for local jobs and servers)
dc_resource(for docker compose services)
k8s_resource(for Kubernetes workloads - see Tiltfile concepts for more details about how YAML is divided into workloads)
All 3 functions have a
resource_deps argument. To specify that
frontend depends on
This has two effects:
frontendwill not be deployed until
databasehas been ready at least once since Tilt was started.
If you run
tilt up frontendto run only the
frontendresource, that also implicitly brings up all of
frontend’s transitive dependencies.
Adding Readiness Checks for Startup Waiting
Once a resource is ready, Tilt will start building the resources that depend on it.
By default, a resource is “ready” when:
k8s_resource: the pod is running and Kubernetes considers all of its containers ready. A job is considered ready when it has completed.
dc_resource: the container is started (NB: Tilt doesn’t currently observe docker-compose health checks).
local_resource: the command has succeeded at least once.
But Tilt also has ways to customize the definition of readiness. This will change both when dependent servers start building, and how the servers show up in the UI.
Kubernetes Readiness Checks
Kubernetes has a built-in notion of readiness. Tilt will use the built-in readiness probe when it’s available.
For any Kubernetes object type, including built-ins and CRDs, that creates pods, Tilt will consider it ready when the pod is running and all of its containers are ready. The exception to this rule is jobs, which are considered ready by Tilt when the job has completed.
If an object does not create pods, there isn’t a way for Tilt to determine readiness. Instead, you’ll want to configure the resource to let Tilt know that it shouldn’t try to use pods to determine readiness. Resources configured to ignore pods for readiness will appear as ready in the Tilt UI as soon as they are applied to the Kubernetes cluster.
To ignore pod readiness:
If you’re using custom Kubernetes resources, you can also specify the default readiness settings for a particular API Kind. See the Custom Resource Definition guide for more info.
Local Resource Readiness Checks
local_resource allows you to define readiness probes for servers running locally.
The API borrows liberally from the Kubernetes readiness probe API.
Read the guide to Local Resource Readiness Probes for more info.
By default, image build and deploys can run 3 at a time (for both
dc_resource). To change this setting, you can set the
max_parallel_updates option in
To allow 10 in parallel:
To force all deploys to happen in serial:
local_resource commands in parallel, you will need to manually mark the resource
local_resource(name, cmd, allow_parallel=True)
local_resource guide for more info.
Other Types of Dependencies
Resource dependencies are designed to help when different versions of services are broadly compatible with each other.
They focus on ensuring that some instance of a resource’s dependencies exist. They are not concerned with whether it’s a current version.
For this reason,
resource_deps currently only affects the first build after a
tilt up. Once any version of
database has been running at least once, its
dependencies are unblocked to build for the rest of Tilt’s lifetime.
For discussions on other types of dependencies in Tilt that could exist in the future, see these issues: