[staticassertion]

I really don't see how any clone is going to manage to do what localstack couldn't - maintain compatibility with tons of AWS services while not getting paid for it. If this were viable, why would it not have worked before?

The only things I can think of are that perhaps LocalStack was just a mess of a codebase that couldn't maintain velocity or attract contributors, or it just failed to steward new contributors or some such thing.

[nnucera]

Hello! We won't have the broad coverage that Localstack has... we're not aiming to be the "next Localstack"... just want to keep the core services that were available for free in the LS community up to date. If you’re looking for larger services like MWAA, sorry, but we won't be supporting them.... Most core AWS services don't receive many updates anyway (their APIs don’t change drastically or frequently)

[evil-olive]

> We won't have the broad coverage that Localstack has... we're not aiming to be the "next Localstack"

you should tell that to the LLM that writes your website:

> MiniStack is your free, MIT-licensed drop-in replacement.

is it a drop-in replacement, or not?

[nnucera]

If you’re looking for a Localstack alternative, it’s often because you were using the community tier... In that case, Ministack can serve as a drop-in replacement... otherwise, the price reduction in LS might already address your needs

[mikeocool]

Personally, I would get value out of really solid compatibility of the base features of a few core services (sqs, s3, kms, and maybe dynamo are the main ones that come to mind) with a light weight gui interface and persistence.

If I’m getting into esoteric features or some “big” features that don’t make sense locally, then I just spin up a real dev account of aws, so I know I’m getting the real experience.

[petcat]

> getting into esoteric features

The problem is that everybody needs different "core" features

> > compatibility of the base features of a few core services (sqs, s3, kms, and maybe dynamo are the main ones that come to mind)

For instance, I don't care about any of those features at all. But I would care a lot about EC2, RDS, and ElastiCache Redis

[mikeocool]

Interesting — those are the ones that depending on the case, approximating them with local redis/postgres/vms without the AWS specific APIs on top is often good enough — because my app is just talking to them over native protocols anyway.

Or I am doing something so specific, that a local emulation of the aws api isn’t ever going to be good enough, so there’s not a lot of point in trying. For example, writing code that handles automatically spinning up RDS instances from an RDS snapshot — a local emulation of that process is going to be so far off from what would actually happen no matter what they do.

[drzaiusx11]

I'd put ALL the ones listed above: SQS, S3, KMS, DynamoDB, EC2, RDS, Redis in the required "core" services column, and also throw in IAM, SNS, and SecretsManager as well. Those are all table stakes imho.

I'm using all of the above in LocalStack today. Frankly, I don't believe this is as "impossible" a task as several in this thread are insinuating. It's the type of rote work you can delegate to AI to build these days, as observed in this OP.

Building a test suite to validate the state-transient mocks in question against the real deal is not difficult. Only annoyingly expensive (in time and money) if run often, which is exactly the problem they're solving.

[lucas_vieira]

This is exactly the approach fakecloud takes — depth over breadth. 13 services right now, but each one is conformance tested against the AWS Smithy API models (34,856 test variants). The bet is that fewer services with correct behavior is more useful for integration testing than broad coverage that surprises you in production.

[onion2k]

If this were viable, why would it not have worked before?

Because something wasn't in place to make it work. There are millions of examples where the second mover won, often because the first mover was too early, or the tech wasn't there to make it work, or the market didn't understand the value, etc.

In this case I imagine there are three massive benefits that you'd have over being the first mover:

- AWS is more mature and therefore moving slower, so it's easier to keep up.

- AI is useful for building 80% working code, so there's a lot less to do to keep up.

- There's a lot of devs looking for ways to move off Localstack due to the price change, which gives you (potentially) a pool of willing volunteers to contribute to an OSS alternative.

You can also learn from Localstack's open source version about what's needed, what works, what doesn't work, etc.

[switchbak]

"LocalStack was just a mess of a codebase" - very true.

I do think there's potential to semi-automatically create a compatible suite of services, but it'll require some very talented use of LLMs and some novel testing approaches. Not something I want to sign up for.

I evaluated Floci, but that has the typical issues you'd expected with freshly minted vibe code.

[mastercomputer]

What are the typical problems you mentioned with Floci? I just went into their repo, and the community is very active; I see a lot of contributions. I'm not sure what you mean by typical problems.

[sysguest]

idk maybe AWS should create one?

I mean, if we can use "virtual-AWS", it would dramatically lower entry-barrier for devs/companies who are scared of "tales of huge aws bills" and such

[switchbak]

I wouldn’t hold my breath. They do have a dynamo db fake, but they don’t even release the code for it! Perhaps they’re concerned about making it really easy to clone their stuff.

But we can still do that ourselves, dynamically interrogating the real thing and comparing it to the fake.

[justincormack]

It hasnt really been a barrier to entry though has it, cloud adoption is doing just fine.

[4m1rk]

I suppose (among many other things) LLMs are changing this. We no longer need that many contributors when we can use AWS docs, intercept AWS API calls and give it to AI agent to mimic. Of course, contributors are still needed for maintaining tests and validations.

[yieldcrv]

and then the maintainer goes on a rant about accurate but agentically coded pull requests and doesn’t merge it

[jillesvangurp]

That's true if you assume making these things is manual work. But of course with well documented API service and AI coding tools, making a functional local equivalent of any given service is not all that hard.