Integrations

Docker Compose

Bring your project's external dependencies - databases, queues, object storage - and agents run them in their sandboxes with Docker.

Most real projects don’t run in isolation: they need a Postgres, a Redis, a message queue, a MinIO. If your repository describes those dependencies in a docker-compose file, agent sandboxes handle the rest.

How it works

Keep your docker-compose file in the repository, exactly as you would for a human developer. When a managed agent’s sandbox initializes and we detect a compose file, we start the Docker daemon as part of setup - so by the time the agent picks up its first task, containers are ready to run.

Agents start what they need

Agents don’t blindly boot the whole stack. They bring up individual services as the work demands them - the database before running migrations, the queue before an integration test - the same way a thoughtful teammate would.

Good practice

  • Use the same compose file your team already uses. The whole point is that an agent’s sandbox behaves like a fresh developer machine - one definition of your dependencies, shared by humans and agents.
  • Keep services self-contained. Pin image versions and avoid depending on services outside the sandbox; each agent runs its own isolated copy, so there’s no shared dev database to fight over.
  • Put connection settings in environment secrets - anything your compose file or app expects as an environment variable will be in place before services start.