Skip to main content
This is a detailed discussion of how to handle your system’s dependencies for testing in Antithesis. Remember, testing happens in a hermetic testing environment with no internet access, because your software’s always wanted its own little Faraday cage. For an overview of this topic, please read the Docker Setup guide or the Kubernetes Setup guide.

​
Approaches

Each of your software’s dependencies can be provided either as:
  1. An actual, containerized service, just like you’d use in production.
  2. A mock of the service, which could be pre-built (e.g., Localstack), or something you write yourself. You’ll use this approach for external dependencies that can’t be containerized (e.g. AWS S3), or when the service provider hasn’t made docker images available.

​
Dependencies available off-the-shelf

This directory lists containerized open-source services and prebuilt mocks. You can include them in a Docker Compose file, or add the Kubernetes manifests for them. If you’d like something added to this directory please let us know at support@antithesis.com.

​
Public Clouds

​
AWS

Antithesis has been extensively tested with both Localstack and MinIO. As of June 2025, we recommend using MinIO in place of S3 when you test in Antithesis, and mocking all other AWS services with Localstack, mostly because the free version of Localstack does not persist data to disk, which many customers require. We provide sample docker-compose.yaml blocks for both of these below. Localstack supports many services, including:
  • DynamoDB
  • S3
  • Lambda
  • CloudWatch
  • SSM
  • IAM
  • SQS
Other pre-built mocks for AWS include:

​
Azure

​
GCP

​
Open source dependencies

Any open source dependencies available on Docker Hub or any public registry can simply be uploaded to Antithesis along with your software. Here are some commonly used ones, If you’d like something added to this directory please let us know at support@antithesis.com.

​
Database & storage services

​
Messaging, queuing & mesh services

​
Other cloud native services

​
LLM services

​
Payment service mocks

​
Internal dependencies

If you own the dependency (for example a private container image), upload it to Antithesis with your software, then define it as a service in your Docker Compose file, or include a Kubernetes manifest for it.

​
Docker code for including dependencies

​
For containerized services or mocks

If you’ve uploaded your dependency or mock as a Docker image, just define it as a service in your Docker Compose file: 
version: '3.8'

services:
  service.mysoftware:
    image: mysoftware:latest
    container_name: mysoftware
    hostname: mysoftware
    depends_on: 
      - infra.postgres

  infra.postgres: 
    image: docker.io/postgres:16
    container_name: postgres
    hostname: postgres
    environment:
      - POSTGRES_DB=postgres
      - POSTGRES_USER=user
      - POSTGRES_PASSWORD=password
    volumes:
      - postgres_data:/var/lib/postgresql/data
    ports:
      - "5432:5432"
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U user -d postgres"]
      interval: 5s
      timeout: 5s
      retries: 5
      start_period: 10s

volumes:
  postgres_data:

​
Localstack

Add Localstack to docker-compose.yaml: 
infra.localstack:
  image: localstack/localstack:3.5.0
  container_name: localstack
  hostname: localstack
  environment:
    SERVICES: s3
    DEBUG: 0
    LS_LOG: warn
    SKIP_SSL_CERT_DOWNLOAD: 1
    DISABLE_EVENTS: 1
    LOCALSTACK_HOST: localstack
    DEFAULT_REGION: us-east-1
  volumes:
    - /var/lib/localstack:/var/lib/localstack
    - /var/run/docker.sock:/var/run/docker.sock

​
MinIO

MinIO is S3-compatible blob storage (not a mock). To add MinIO to docker-compose.yaml: 
infra.minio:
  container_name: minio
  hostname: minio
  image: quay.io/minio/minio
  command: server /data --console-address ":9001"
  post_start:
    - user: "root"
      command: "mkdir -p /data/primary"
  ports:
    - "9000:9000"
    - "9001:9001"
  volumes:
    - minio_data:/data
  environment:
    - MINIO_ROOT_USER=minio
    - MINIO_ROOT_PASSWORD=minio-secret
    - MINIO_DEFAULT_BUCKETS=primary

​
Kubernetes manifests for dependencies

​
For services or mocks

After you’ve uploaded the docker image your dependency or mock, just add a manifest for it in the manifests/ folder as discussed in the setup guide. Below, you can find some example manifests for common dependencies.

​
Localstack

LocalStack provides a Helm chart you can use to template and run your dependencies in Kubernetes. Just add the helm chart: 
helm repo add localstack https://localstack.github.io/helm-charts
helm repo update
Create a values.yaml file to enable your dependencies. Here is an example one for S3: 
fullnameOverride: localstack
image:
  tag: "3.5.0"
startServices: "s3"
persistence:
  enabled: true
  size: 5Gi
tests:
  enabled: false
extraEnvVars:
  - { name: LS_LOG, value: "warn" }
  - { name: SKIP_SSL_CERT_DOWNLOAD, value: "1" }
  - { name: DISABLE_EVENTS, value: "1" }
Render to manifests/: 
helm template localstack localstack/localstack \
  -f values.yaml \
  > manifests/localstack.yaml

​
MinIO

MinIO is S3-compatible storage (not a mock). Use the Bitnami Helm chart to render a manifest. Add the bitnami Helm repo: 
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
Example values.yaml file: 
fullnameOverride: minio
image:
  tag: "2025"
auth:
  rootUser: "minio"
  rootPassword: "minio-secret"
defaultBuckets: "primary"
persistence:
  enabled: true
  size: 5Gi
Render to manifests/: 
helm template minio bitnami/minio \
  -f values.yaml \
  > manifests/minio.yaml

​
Writing a mock yourself

Several tools are available to assist with writing your own mocks, if nothing in the provider’s ecosystem meets your needs. This is a partial list: If you’d like to explore this approach, we suggest emailing us at support@antithesis.com or reaching out on Discord.