Run a Fake S3 Server Locally

If you’ve ever built an app that talks to AWS S3 — maybe uploading images, storing backups, or handling static files — you know testing against the real thing can be a pain. You either spend money, wait on slow uploads/downloads, or juggle AWS credentials just to verify basic logic.

What if I told you there’s a simple way to run a fake S3 server locally that speaks the same API your app expects — no AWS account needed? That’s exactly what gofakes3 gives you.

What Is gofakes3?

gofakes3 is an open-source project written in Go that behaves like Amazon S3 — but locally, on your machine. Think of it as a development-friendly S3 clone you can start in seconds for tests or local builds. GitHub

This isn’t a full clone of everything AWS S3 does, but it supports the core parts you care about when writing code that uploads, downloads, and lists objects.

It’s primarily meant for:

• Local development of S3-dependent functions (like AWS Lambda or backend services).
• Integration testing without touching the real AWS infrastructure.
• Testing browser-based uploads to S3 endpoints without needing credentials or S3 buckets in AWS.

In short: gofakes3 lets you iterate faster and safer when your app depends on object storage.

Why You’d Use This (and When Not To)

The obvious question: why not just use AWS for testing? Great question.

Using real AWS buckets in development is slow, brittle, and often expensive. Worse, you can easily overwrite production data or leak credentials into your test environments. With gofakes3, none of that matters because it’s running locally and isolated.

But it’s worth being clear: gofakes3 is not production-grade storage. It’s designed for testing and local development only. It doesn’t have the performance, durability, or security guarantees that AWS S3 provides — and large parts of the S3 API aren’t implemented yet. So don’t run this in production expecting real S3 reliability.

A Quick Look at How It Works

Because this is Go-powered, integrating gofakes3 with your Go projects feels natural:

1. Start a fake S3 server backed by an in-memory or on-disk storage.
2. Point your AWS SDK client (in tests or dev environment) at the fake server’s endpoint.
3. Use the same S3 API calls as you would with the real AWS S3, create buckets, upload files, list objects.

Here’s what this pattern looks like in Go using the AWS SDK v2 (thanks to the official examples):

backend := s3mem.New()
faker := gofakes3.New(backend)
ts := httptest.NewServer(faker.Server())
defer ts.Close()

From your app’s perspective, you’re still calling S3, it’s just pointed at a local address instead of AWS. Makes writing automated tests much smoother. GitHub

This pattern is common in integration testing: you mock or fake external services, but keep the real API shape so your code doesn’t have to know it’s not hitting AWS. Reddit

How This Fits Into a Real Workflow

I want to be honest — you won’t replace AWS entirely with this. But here’s how gofakes3 has saved headaches in real development cycles:

• No AWS creds in your CI pipeline. Ever accidently uploaded test artifacts to a real bucket? With gofakes3, that risk goes away.
• Fast feedback loops. No network calls to AWS mean tests run instantly.
• Repeatable builds. Your team doesn’t need AWS access to run integration tests — every developer can spin up the fake S3 locally.

For teams doing CI/CD, microservices, or backend integrations that rely heavily on object storage, this turns what used to be a messy part of the pipeline into a predictable one.

Alternatives & When You Might Use Them

If you need more than just S3, like DynamoDB, Lambda, or SNS in addition to object storage, consider tools like LocalStack which spin up multiple AWS service mocks locally.

There are also other S3 mock servers out there — some in Node.js or Python — but if your project is Go-centric or you just want a minimal, fast tool that feels native, gofakes3 hits the sweet spot.

Final Thoughts

Gofakes3 is one of those tools that makes the developer experience noticeably better. It’s simple, it works with the real AWS SDKs, and it removes a lot of friction from local development and testing. If your workflow involves any service that reads or writes to S3, spinning up a gofakes3 server instead of poking real buckets is an easy win.

Whether you’re exploring serverless functions, testing object uploads, or just trying to avoid racking up AWS charges during development, it’s worth giving this a try. Just remember: keep it for testing and development, not production.