I built a free, open-source alternative to LocalStack — CloudDev
If you've been following the news, LocalStack recently ended its
free Community Edition. Developers now need an account and are
being pushed toward paid plans.
So I built CloudDev — a lightweight, 100% free, open-source
local AWS development environment. No account. No paywalls. Forever.
What is CloudDev?
CloudDev lets you run core AWS services locally on your machine
with a single command:
clouddev up
It starts local emulators for:
- 🪣 Amazon S3 — object storage
- 🗄️ Amazon DynamoDB — NoSQL database
- ⚡ AWS Lambda — serverless functions
- 📨 Amazon SQS — message queues
- 🌐 Amazon API Gateway — HTTP routing to Lambda
- 🖥️ Web Dashboard — live service status
- 🔍 IaC Detection — auto-configure from Terraform/CloudFormation
Why I built it
Developing on AWS is painful:
- You have to deploy to the cloud just to test
- Provisioning Lambda or API Gateway takes minutes
- Accidental usage generates unexpected charges
- Hard to test locally without internet
CloudDev solves all of this.
How it works
1. Initialize a project
clouddev init my-app
cd my-app
This creates:
my-app/
clouddev.yml
functions/
infrastructure/
2. Configure services (clouddev.yml)
services:
s3: true
dynamodb: true
lambda: true
sqs: false
api_gateway: true
3. Start your local cloud
clouddev up
S3 server starting on port 4566
DynamoDB server starting on port 4569
Lambda server starting on port 4574
API Gateway starting on port 4572
Dashboard running at http://localhost:4580
CloudDev is running. Press Ctrl+C to stop...
4. Use with the real AWS CLI
# S3 — create bucket and upload file
aws --endpoint-url=http://localhost:4566 s3 mb s3://my-bucket
aws --endpoint-url=http://localhost:4566 s3 cp file.txt s3://my-bucket/
# DynamoDB — create table and put item
aws --endpoint-url=http://localhost:4569 dynamodb create-table \
--table-name Users \
--attribute-definitions AttributeName=id,AttributeType=S \
--key-schema AttributeName=id,KeyType=HASH \
--billing-mode PAY_PER_REQUEST
# Lambda — create and invoke function
aws --endpoint-url=http://localhost:4574 lambda create-function \
--function-name hello \
--runtime python3.9 \
--handler hello.handler \
--role arn:aws:iam::000000000000:role/test \
--zip-file fileb://hello.zip
aws --endpoint-url=http://localhost:4574 lambda invoke \
--function-name hello \
--payload '{"key": "value"}' \
output.txt
5. Auto-detect from Terraform
Have an existing Terraform project? Just run:
clouddev detect
CloudDev scans your .tf files and automatically enables
the right services in clouddev.yml.
6. Web Dashboard
Open http://localhost:4580 to see live service status:
![CloudDev Dashboard showing all services running in green]
How it compares to LocalStack
| Feature | CloudDev | LocalStack Free |
|---|---|---|
| Requires account | ❌ No | ✅ Yes (now required) |
| Open source | ✅ Yes | ⚠️ Partial |
| S3, DynamoDB, Lambda | ✅ Yes | ✅ Yes |
| Web dashboard | ✅ Yes | ❌ No |
| IaC auto-detection | ✅ Yes | ❌ No |
| Cost | 🆓 Free forever | 💰 Paid plans |
Tech stack
CloudDev is built in Go — which means:
- Single binary, no runtime dependencies
- Fast startup
- Low memory usage
What's next
- Kubernetes integration
- Cost estimation before deployment
- Plugin system for additional AWS services
- More AWS service emulators
Try it out
👉 GitHub: github.com/Jeffrin-dev/CloudDev
If you find it useful, please ⭐ the repo and share it with
other AWS developers who are affected by the LocalStack change!
Contributions are very welcome — check out
CONTRIBUTING.md
to get started.
Built with Go, Let's Get Started !

Top comments (3)
The Terraform auto-detection via
clouddev detectis a really smart move — that's the kind of DX detail that gets people to actually switch tools rather than just bookmark the repo. Most developers already have existing IaC configs, so lowering the migration friction like that is huge.I run a static site with a Supabase backend and while I'm not deep in the AWS ecosystem, the pattern of "vendor kills free tier, community builds alternative" has been playing out everywhere lately. The fact that you built this in Go as a single binary with no runtime deps is exactly what makes these tools stick — nobody wants to install a whole stack just to emulate another stack.
Curious about the Lambda emulator specifically — how close is the runtime parity? That's usually where local emulators diverge from production the most in my experience.
Really appreciate that — the single binary goal was non-negotiable from day one for exactly that reason.
On Lambda runtime parity: honest answer is it's functional but not perfect. The current emulator handles invocation, environment variables, and hot reload well. Where it diverges from production is around execution context reuse, /tmp storage persistence between invocations, and layer support — those are on the roadmap. For most local dev and integration testing workflows it covers the common cases, but I wouldn't use it to debug cold start timing or memory limit behavior.
The good news is since it's open source and written in Go, the Lambda handler is one of the cleaner modules to contribute to if that's an itch you want to scratch!
VERSION v0.3.0 IS LIVE NOW !!!