# next to your tools

If your team runs one environment per developer, you may already have what you need. antil is for the point where one developer has several workers in separate git worktrees, and those workers need separate apps and data at the same time.

Its three parts are **tunnels: apps & urls**, **chambers: shared resources**, and **seals: proof & cache**. Tunnels and Postgres chambers work locally today. Seals are coming.

## tilt

[Tilt](https://docs.tilt.dev/) gives a developer a complete development environment, with live updates and a UI for services and logs, mostly around Kubernetes and Docker Compose. It can run local processes too. That is a good fit when your team wants a fast edit-and-refresh loop for its environment.

antil's unit of work is a worker in a git worktree: many isolated stacks on one machine, sharing heavy resources, with output an agent can act on. For the shop, two agents get separate Vite/API pairs and separate databases inside one Postgres server.

You can build multiple environments with Tilt. antil makes per-worktree identity, resource sharing, and agent handoff its starting point. Reusable test proof is a planned difference, not a feature to switch on today.

## docker compose

[Compose](https://docs.docker.com/compose/) defines and runs container services, networks, and volumes. Separate Compose project names can isolate several stacks; dynamic ports and health checks can be configured too.

If one Compose project per worktree works for your team, keep it. You maintain the naming, port discovery, per-worker data, and any deliberate sharing. antil coordinates those worker boundaries and gives agents one status contract. It still uses Docker for Postgres; the shop even uses Compose for its manually shared Redis while recipes are coming.

## devcontainers

[Development containers](https://containers.dev/) define the containerized development environment and tools a contributor uses. They help teammates start with the same toolchain. antil manages the apps and resource access of parallel workers. These solve different problems; a standardized toolchain does not by itself separate two workers' database writes.

## turborepo and nx

[Turborepo](https://turborepo.com/docs/crafting-your-repository/caching) and [Nx](https://nx.dev/docs/features/cache-task-results) cache task results from declared inputs. Keep them for builds, lint, and suitable tests. Correct cache inputs matter for either tool.

A shop integration test also depends on a running API and database state. Seals will include the environment a test actually used, and run again when that environment changes or cannot be established. Today antil can launch your existing runner but adds no test cache.

## agent harnesses

Keep Codex, Claude Code, T3 Code, or the harness you use to edit code, delegate work, and open a browser. antil supplies the environment beneath each worker. An agent reads a ready URL and opens it with its existing browser tool. There is no special browser integration to install.

## when antil earns its place

Use it when parallel agents collide on app ports, invalidate each other's data, or cannot tell what a previous worker left running. For a single app with no shared state, a package script may be enough.

The local tool is free and open source. Sharing proof, trust, or resources across people and machines will use **antil cloud, paid and in early access**. Neither cloud coordination nor local seals is available yet. [What works now and what comes next](/docs/roadmap/).