Guide · Alternatives
A LocalStack alternative with real compute
LocalStack is the best-known way to run AWS APIs locally, and for many teams it is the right one. HomeCloud takes a different approach: every API is backed by a real engine running in Docker, IAM is always enforced, and it is built to be left running. Here is what that changes, and when you should not switch.
People look for an alternative to LocalStack for a few recurring reasons: a test passed locally but failed on AWS because the emulated service accepted something the real one would not, a feature they need is only in the paid tier, or they want something persistent that a team or a class can share. HomeCloud is a good fit for some of these and a poor fit for others. This page tries to be precise about which.
What HomeCloud does differently
Real engines behind the API
HomeCloud implements the AWS APIs itself and runs the work on the real thing, as containers on your Docker host:
| Service | What does the work |
|---|---|
| Lambda | AWS's official runtime images (public.ecr.aws/lambda/...) |
| RDS | PostgreSQL, MySQL, MariaDB |
| ElastiCache | Redis, Valkey, Memcached |
| S3 | MinIO |
| EC2 | Containers you can shell into; two images boot QEMU/KVM virtual machines |
| ELB v2, Route 53, ACM | nginx, CoreDNS, a private CA |
| Security groups | iptables rules inside each VPC network |
So an integration test that creates a database can connect to it and run migrations; traffic to an ECS service goes through a load balancer; a security group that forgets a port actually blocks it. DynamoDB, SQS, SNS, EventBridge, Step Functions, IAM, KMS, Secrets Manager and CloudWatch are implemented in HomeCloud itself.
IAM is on by default
Every request, from the CLI, an SDK, Terraform or the console, is checked against the same policy evaluator: identity and resource policies, conditions, permissions boundaries, iam:PassRole. With LocalStack Community IAM is not enforced, and with Pro enforcement is available but opt-in. If your bug was "the Lambda role was missing a permission", this is the difference that catches it before deploy.
A console and a server, not just an endpoint
The web console is built into the binary and works offline, with CloudWatch metrics and logs for every resource and a CloudTrail record of every API call. State persists on disk by default, and there are commands for users, backups, upgrades, TLS and running as a system service, because HomeCloud is meant to be left running for a team, a homelab or a classroom. LocalStack's web app is hosted and needs an account, and its state is ephemeral by default (Pro adds persistence).
No paid tier
Every feature is in the AGPL-3.0 code. If you run a modified HomeCloud as a service for others, you share your changes; using it for your own tests and infrastructure carries no obligations beyond that.
When LocalStack is the better choice
- Service coverage. LocalStack Pro covers far more services and operations. If your stack uses Kinesis, EKS, Athena, Glue, OpenSearch, REST API Gateway, WebSocket APIs or AppSync, HomeCloud does not have them.
- Multiple regions or accounts. HomeCloud serves one region (
us-east-1) and one account. - CI footprint. One container emulating services in-process starts faster and uses less memory. HomeCloud starts MinIO on first boot and real engines on demand, which takes longer.
- Maturity and ecosystem. LocalStack has years of production use, wrappers like
awslocal,tflocalandcdklocal, extensive docs and commercial support. HomeCloud's first release was in September 2026.
And for fast, isolated unit tests in Python, moto's in-process mocks are simpler than either.
Pointing an existing setup at HomeCloud
If your tests already target a local endpoint, switching is mostly configuration. HomeCloud listens on port 8080, and homecloud aws-env prints the variables the AWS CLI, boto3, the Go and JavaScript SDKs and Terraform read:
eval "$(homecloud aws-env)"
echo $AWS_ENDPOINT_URL # http://127.0.0.1:8080
aws s3 ls # plain aws, no wrapper neededThings to change:
- Credentials. Dummy keys such as
test/testwill not work: HomeCloud verifies SigV4 signatures. Use the keys fromhomecloud aws-env, or create an IAM user with only the permissions your code should have. - Hard-coded endpoints. Replace
localhost:4566withAWS_ENDPOINT_URL, which current SDKs read on their own. - S3 addressing. Use path-style addressing (
s3_use_path_style = true,addressing_style: path,UsePathStyle) when the endpoint islocalhostor an IP. - Terraform. Instead of
tflocal, use the stock provider withs3_use_path_style; the Terraform guide shows both ways to set the endpoint. - Permissions. Code that ran with no IAM checks may now get
AccessDenied. That is usually the point, but budget time for it.
In CI
A GitHub Action installs a checksum-verified release, starts it and exports the AWS_* variables; testcontainers modules for Go and Python start the ghcr.io/solinode/homecloud image from a test. One HomeCloud runs per Docker host, so do not start several in parallel on the same runner.
- uses: solinode/homecloud/integrations/github-action@main
with:
services-wait: s3
- run: pytest # boto3 reads AWS_ENDPOINT_URLDetails for each option are in the testing and CI guide.
Deciding
Try HomeCloud if your stack fits inside its services (the compatibility reference lists them per operation) and you care more about realistic behavior, IAM and persistence than about breadth or start-up time. Stay with LocalStack if you need the services or regions it has and HomeCloud lacks. Running both is reasonable too: HomeCloud for the integration tests that touch databases and functions, a lighter emulator or moto for the rest. A row-by-row table is on the HomeCloud vs LocalStack page, and Lambda specifics are in testing Lambda locally.
Other projects change quickly. This page reflects HomeCloud v0.4.0 and LocalStack as described in our comparison doc; check LocalStack's current documentation and licensing, and tell us if anything here is out of date.