Skip to main content
Service containers in GitHub Actions let you spin up Docker containers alongside your workflow jobs, providing on-demand services—such as databases, caches, or message queues—for your CI/CD pipelines. By defining services in your workflow YAML, you can run integration and end-to-end tests without managing external infrastructure.

Basic Workflow Without Service Containers

The simplest workflow runs tests immediately after code checkout and dependency installation. It’s ideal for unit tests that don’t require external services.
This workflow is perfect for fast-running unit tests that do not depend on external databases or caches. If your tests require a service, see the next section.

Adding a MongoDB Service Container

To test against a MongoDB database, add a services section. This example maps the container’s default MongoDB port to a host port on the runner:
Here’s what happens:
  1. Service Container: mongo:latest runs as mongodb-service.
  2. Port Mapping: Container port 27017 is mapped to runner port 12345.
  3. Environment Variables: Tests connect to localhost:12345.

Common Service Containers for CI Workflows

Be mindful of resource limits on GitHub-hosted runners. Running multiple heavyweight services can lead to slower startup times or timeouts.

Running Steps Inside a Job Container with Services

You can isolate your build environment by specifying a job container and still link to service containers through the Docker network:
Key points:
  • Job Container runs every step inside ghcr.io/node-and-packages:20.
  • Service Container mongodb-service is discoverable on the default Docker bridge network.
  • Networking uses the service container’s hostname (mongodb-service) without port mapping.

Watch Video