Running Services

Start all services defined in your workspace:

dagger up

Services run in ephemeral containers. Their ports are tunneled to your local machine. Stop with Ctrl+C.

Listing and filtering services

dagger up -l                    # list available services
dagger up web                   # start only the 'web' service
dagger up web api redis         # start multiple services

Use cases

• Running a database for local development or testing
• Running end-to-end integration tests against a service
• Running sidecars (proxies, caches, queues)

How services work

Service containers have three key properties:

• Content-addressed hostnames. Each service gets a canonical hostname derived from its definition. Same definition, same hostname — no port conflicts.
• Just-in-time lifecycle. Services start when first needed, are de-duplicated if multiple clients request the same service, and stop when no longer referenced.
• Health checks. Services are health-checked before clients can connect. No race conditions between service startup and test execution.

Container-to-host networking

A service defined in a module can be exposed to your local machine:

# Start an HTTP service and access it locally
dagger up web
curl http://localhost:80

Host-to-container networking

Containers running in Dagger can also connect to services on your host machine. This is useful for testing against a locally running database or API.

A function exposes a host service by accepting it as an argument, using the tcp:// or udp:// provider to point at a host port:

# Make a database running on the host reachable from the function
dagger call integration-test --db=tcp://localhost:5432

Inside the function the argument is an ordinary Service, so the same code works whether the upstream runs on your host or in another container.