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
- Aerospike
- Cassandra
- Clickhouse
- Cockroach
- CouchDB
- ElasticSearch
- Grafana-loki
- Grafana-mimir
- InfluxDB
- Jaeger
- MariaDB
- Memcached
- MongoDB
- MySQL
- Neo4j
- PostGRES
- Prometheus
- Redis
- Zookeeper
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 orchestration docs.
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.