Handling external dependencies

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:

An actual, containerized service, just like you’d use in production.
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

Ollama

Payment service mocks

Stripe-Mock

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

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.

Handling external dependencies

Approaches

Dependencies available off-the-shelf

Public Clouds

AWS

Azure

GCP

Open source dependencies

Database & storage services

Messaging, queuing & mesh services

Other cloud native services

LLM services

Payment service mocks

Internal dependencies

Docker code for including dependencies

For containerized services or mocks

Localstack

MinIO

Kubernetes manifests for dependencies

For services or mocks

Localstack

MinIO

Writing a mock yourself