Cloud providers like AWS, GCP, and Azure should offer local emulators for development. This would encourage developers to utilize their services more.
I currently work with several AWS serverless stacks that are challenging or even impossible to integration test locally. While Localstack provide a decent solution, it seems like a service that AWS should offer to enhance the developer experience. They’d also be in the best position to keep it current.
Ilove the emulation, but it will never come from the hyper scalers.
One issue is that local emulation runs into some big political rocks as soon as it gets good. To start with, the emulator is good enough and covers a tiny surface of what people want, eg k8s and s3. Resistance here is about customers experiencing issues caused by gaps in fidelity vs the real environment and subsequent pain for the emulator product team. ok, fine.
But then you get customers who take your emulator and use it in places where AWS cant go, eg, airgapped environments. They start asking for more serious features. But wait! another team in the hyperscaler was already trying to solve this, for far more than zero dollars. Azure Stack. Azure Local. AWS Snowball. Now there are VPs shooting at you because you are, in their view, cannibalizing their revenue.
You might try to avoid this war by emphasizing the dev sandbox aspect, selling to developers only and making sure that you only talk about APIs and stuff. Problem is, the API surface is 90% of why the cloud is useful (the other ten percent being the assertion that you don't have to think about it, which is an increasingly untrue proposition, as the reams of SREs will tell you). So now you have an emulator for the most valuable part of Cloud, in the hands of people who know how to use it and are strongly incentivized and capable of making it better, all running locally. It's a very small step to making that commercial and wiping huge chunks of revenue out, as your VP will tell you as they sign your pink slip.
Talking to devs, the most common thing I hear re emulation is a desire to be able to let rip on any service and not fear a giant bill. Since all clouds have budget tools I wonder why this isnt possible today? Maybe theres a weakness in the planning tools rather thanthe post-use budgeting ones?
An official local emulator sounds nice until AWS has to explain why S3, IAM, or Kinesis behave a little differntly on your laptop, because the minute it's blessed people will treat every mismatch as an AWS bug, not a dev-time compromise.
Except that it's true, they can't. How else are they going to race to the bottom of the minimum number of employees and maximum amount of management bonuses?
Microsoft used to with their Azure Service Dev Kit. the ASDK was a single-node "sandbox" meant to emulate the entire Azure cloud locally. They may have something similar now but paired back
You should build your software around abstractions and interfaces which are portable enough to work locally and in AWS or any other cloud and not just AWS specific APIs.
I agree that this is what everyone should strive to do but this quickly hits a limit.
For example, IAM/S3/SQS policy evaluations can have profound impact on an application running but an abstraction wouldn’t help much here (assuming the developer is putting any thought into securing things). There just isn’t an alternative to these. If you’re rolling out an application using AWS-proprietary services, you have to get into vendor-specific functionality.
it's a trade off, a risk. (sure, for many people it doesn't make sense, because they don't have scale or growth anywhere near the numbers where generic/abstracted is not efficient enough)
Totally agree that AI coding makes this even more important. We are working on a coding agent-first cloud and a large part of that is ensuring everything runs locally so folks can let their coding agents define the infra and test it all
It's a fair point but iff you neglect that the overwhelming revenue drivers for these services are large corps who are already locked-in.
Devx doesn't matter at all once you're there.
The myopathy among us "online people" is assuming number of voices here and elsewhere correlate to revenue.
Just fyi, myopathy is a general term for diseases that affect some types of muscles, while myopia is short-sightedness -- assuming the latter is what you were going for!
Without the infrastructure behind it to make it make sense, cloud platforms just seem like convoluted ways of storing data and launching applications/VMs to me.
The only functional use of a tool like this to me would be to learn how to use AWS so that I can work for people who want me to use AWS. Would that not be to Amazon's benefit?
A few notes about "local AWS" (or "local cloud") based on other comments and my own XP:
- I'm not sure this kind of product is really a foot in the door to create new customers. Someone not willing to create an actual account because they have no money or they just don't want to put their card details is not someone who's going to become a 6 figures per year customer, which is the level to be noticed by those providers.
- The free tier of AWS is actually quite generous. For my own needs I spend less than $10/year total spread around dozens of accounts.
- If one wants to learn AWS, they MUST learn that there are no hard spend limits, and the only way to actually learn it, is to be bitten by it as early as possible. It's better to overspend $5 at the beginning of the journey than to overspend $5k when going to prod.
- The main interest of local cloud is actually to make things easier and iterating faster, because you don't focus on all the security layer. Since everything is local, focus on using the services, period. Meanwhile, if you wanted to rely on actual dev accounts, you need to first make sure that everything is secure. With local cloud you can skip all this. But then, if you decide to go live, you have to fix this security debt and it most often than not break things that "work on my computer".
- Localstack has the actual support of AWS, that's why they have so much features and are able to follow the releases of the services. I doubt this FOSS alternative will have it.
Security is the entire reason I want tools like this. Specifically for emulating IAM: if you've got a hard organisational "least privilege" mandate then you start with virtually nothing allowed and have to enable permissions for the explicit set of API calls you're using. You're not doing `Allow :` but you're also not using AWS-managed roles. That combined with the fact that - certainly with terraform - there's no mapping between "I need to manage this resource" and "these are the permissions needed to do so" means that every time you do something new in your infrastructure you're going into a game of permissions whack-a-mole where the deploy/fix/deploy cycle can easily take a multiple of the time it took to develop the feature you want to deploy, because one trip round the loop is a full attempted deployment. Whereas if there's an accurate local emulator not just of the feature but of the permissions attached to it, you can shortcut the slow bit.
Localstack does have IAM emulation as part of the paid product. I'm intrigued to see how well this does at the same thing.
When you're running hundreds of integration test suites per day in CI pipelines, the free tier is irrelevant. You need fast, deterministic, isolated environments that spin up and tear down in seconds, not real AWS calls that introduce network latency, eventual consistency flakiness, rate limits, and costs that compound with every merge request.
It'd be great to just use AWS but in practice it doesn't happen. Even if billing doesn't, limits + no notion of namespacing will hit you very quickly in CI. It's also not practical to give every dev AWS account, I did it with 200 people it was OK but always caused management pain. Free tier also don't cover organizations.
> they MUST learn that there are no hard spend limits, and the only way to actually learn it, is to be bitten by it as early as possible
This is a bizarre take. "The best way to learn fire safety is to get burned." You can understand AWS billing without treating surprise charges as a rite of passage.
The main use case for local emulators is unit testing. Maybe even some integration testing, especially for stuff like VPC setup that often can't be done without global side effects.
Security for dev accounts is not a big deal, just give each developer an individual account and set up billing alerts.
How's this compare to moto? I understand folks are upset about licensing changes for LocalStack (which I happily use at my day job with an enterprise license), but there are already several good alternatives.
The aws endpoint coverage is impressive for moto [1], which my team almost migrated to, but we liked our support contract with LocalStack.
If you want to use that for unit testing, then I think it would be better to mock the calls to AWS services. That way you test only your implementation, in an environment you control.
If you want to use that for local development, then I think it would be better to provision a test environment (using Terraform or any other IaC tool). That way you don't run the risk of a bug slipping into prod because the emulator has a different behaviour than the real service.
> LocalStack's community edition sunset in March 2026 — requiring auth tokens, dropping CI support, and freezing security updates. Floci is the no-strings-attached alternative.
Unfortunate that they're closing up after all these years. That said, I have their enterprise license at work and it has been fantastic, saving thousands of dev hours by giving our team tighter feedback loops without having to wait for ages on cloudformation deployments. LocalStack allows me to test my changes on the train without even an internet connection (the keys are baked into our dev containers)
This project would be comical if it takes off. In Romanian this name means "a small pile of hair", but informally it's only used as a synonym for pubic hair.
Although I love localstack and am grateful for what they have done, I always thought that an open community-driven solution would be much more suitable and opens a lot of doors for AWS engineers to contribute back. I’m certain that it’s on their best interest to do so (specially as many of their popular products have local versions)
It’s a no-brainer to me as AI adoption continues to increase: local-first integration testing is a must and teams that are equipped to do so will be ahead of everyone else
How is it in AWS' best interest to provide support or changes for a FOSS clone (albeit with ephemeral storage)? I believe that providing locked down local-first containers themselves for various services (which they do for services like ddb) would make more sense. I'm sure no one at AWS would take a bug report seriously saying random FOSS thing doesn't work with their official client sdks...
I think it's too early to even say if Floci will become something that people use so time will tell, but at AWS, they already had some "informal" support for localstack[1] and it's always been a "commercial product" (so you can imagine how controversial it must be internally to support a third-party clone). I'm only saying that a FOSS version is somewhat less controversial for them to support and although I would love for AWS to have something of their own they clearly have other priorities.
100% this. especially with agentic workflows actually mutating state now. local testing is the only safe way to see what happens when a model hallucinates a table drop without burning an actual staging database.
Cool, I've tried localstack before and cant wait to give it a try
Anyway, do anyone know if there're similar stuff but for gcp? So far https://github.com/goccy/bigquery-emulator helped me a lot in emulating bigquery behaviour, but I cant find emulator for the whole gcp environment.
Local AWS emulators are one of those tools where the value is inversely proportional to how much you trust your staging environment. If your staging account perfectly mirrors prod, you don't need a local emulator. But nobody's staging perfectly mirrors prod, so you end up needing something like this for the fast feedback loop on IAM policies, Step Functions state machines, and anything involving SQS/SNS fanout where the iteration cycle against real AWS is measured in minutes per attempt. The question is always parity — how closely does the emulation match real AWS behavior at the edges? LocalStack has been chasing that for years and still hits gaps. Curious how Floci handles the services where AWS's own behavior is underdocumented.
The point of tools like this is for development, not staging. By “development” I don’t just mean developers writing code, but any unit tests that require behavioural testing that cannot easily be mocked too.
So by the time you’re ready to push to staging you should be past the point of wanting to emulate AWS and instead pushing to UAT/test/staging (whatever your naming convention) AWS accounts.
Ideally you would have multiple non-production environments in AWS and if your teams are well staffed then your dedicated Cloud Platform / DevOps team should be locking these non-prod environments from developers in the same way as they do to production too.
Bonus points if you can spin up ephemeral environments automatically for feature branches via CI/CD. But that’s often impractical / not pragmatic for your average cloud-based project.
100% this. I've used AWS emulation layers for local-first development going on the better part of a decade. I cannot stress how much time it saves me from pushing code that would have failed in staging. When the cost of deployment pipelines via cloudformation is so high, it's a no brainer.
DIY mocks alone can get you somewhat there, but that relies on the developer having intimate knowledge of the aws sdk under test and it's very easy to mock the inputs and outputs wrong. I'd rather defer that to an emulation layer that does that mimicry better than my guess and check with 30m between attempts when my cloudformation deployments ultimately fail...
Isn’t a “local emulator of cloud services” kind of the perfect project to be vibe coded? Extremely well documented surface to implement, very easy to test automatically and prove it matches the spec, and if you make some things sub optimal performance wise, that is totally fine because by project will not be used in a tight loop anyway - e.g. it will just need to be faster than over the network hop plus the time it takes for the cloud to actually persist things. This can just need to do this in ram and doesn’t need to scale.
So I’m shocked cloud providers haven’t just done this themselves, given how feasible it is with the right harness
AWS _does_ officially provide local-first dev containers for services like DynamoDB but sadly not every AWS service comes with those. Why? I have no idea, like you said it's clearly feasible and they already do it for some services today...
Not necessarily. Would you respond the same if the previous person said, "Was this built using an IDE" or "What qualifications do you have to write this software"?
Shit code can be written with AI. Good code can also be written with AI. The question was only really asked to confirm biases.
As someone who has worked in projects with hundreds of seemingly trivial dependencies which still manage to produce a steady stream of security notices, "What qualifications do you have to write this software" seems like an entirely reasonable, far too seldom asked question to me.
I dont automatically dismiss ai slop but when its obvious this was barely reviewed and sloppily committed with broken links 404ing or files missing from git, then it is slop.
Using llm as a tool is different from guiding it with care vs tossing a one sentence prompt to copy localstack and expecting the bot to rewrite it for you, then pushing a thousand file in one go with typos in half the commit message.
Longevity of products comes from the effort and care put into them if you barely invest any of it to even look at the output, look at the graveyard of "show hn" slop. Just a temporary project that fades away quickly
There are no code commits. The commits are all trying to fix ci.
The release page (changelog) is all invalid/wrong/useless or otherwise unrelated code changes linked.
Not clearly stating that it was AI written, and trying to hide the claude.md file.
The feature table is clearly not reviewed, like "Native binary" = "Yes" while Localstack is no. There is no "native" binary, it is a packed JVM app. Localstack is just as "native" then. "Security updates Yes" .. entirely unproven.
I'll have a much harder time convincing my company to try out such a tool if it's AI slop than when there's a group of people behind it.
I'll happily use it for personal development stuff if I ever decide to try cloud stuff in my free time, but it's hardly an alternative to established projects like LocalStack for serious business needs.
Not that any of it should matter to the people behind this project of course, they can run and make it in whatever way they want. They stand to lose nothing if I can't convince my boss and they probably shouldn't care.
At that speed you can treat it as disposable: fresh instance per test run, no shared state, no flaky tests from leftover S3 objects. that was never practical with LocalStack cold start
This is why I use LocalStack today. I can stand up all my infra for my teams 14 microservices in under 30s and test my in flight changes, all without an internet connection. Deploying to our real staging environments take 30m (literally) for a single CDK / cloudformation stack change. The fact I have an immediate feedback loop saves my team inordinate amounts of time. Cloudformation deployments are criminally slow.
I recently discussed this with an adjacent org that didn't use a local environment at all outside of junit mocks for unit testing, and their deployment pipelines take over 45m per commit. Ridiculous.
Side note: this local-first strategy works well but requires some beefy hardware with gobs of ram, at least in my line of work with java and rails microservices. My laptop is an M4 with 64gb ram. I honestly wish I had the 128GB model...
Looking at the features this seems to be an awesome project, but the commit history (even on the develop branch) shows almost nothing.
No pull-requests, no real issues, it smells like it was auto-generated which is disappointing. Makes it harder to trust if you're going to test with "real data", how do we know it won't be sent elsewhere?
I don't understand why you'd be making this comment when the commit history shows this whole project is a week old.
>how do we know it won't be sent elsewhere?how do we know it won't be sent elsewhere?
I the past open source meant that you trusted in theory that someone else would notice and report these things. These days though just load up your LLM of choice and ask it to do a security audit. There are some unreliable ways to cheat this and they aren't magical, but it would be pretty hard to subvert this kind of audit.
It is usual for a new project to start small, and slowly add new features. Instead this project seems to arrive "fully formed".
There is no "this is the core, then we add S3, then we add RDS, then we add ..." history to view and that seems both unnatural and surprising. Over half the commits are messing around with github actions and documentations.
Definitely this. I like seeing issues reasonably populated with OSS projects. Otherwise, how am I supposed to contribute back to it? Granted it's a newer project so I will be keeping track in the future.
This seems useful for testing. I was wanting to create some ansible roles for things like packaging a lambda. One of the things it does is check s3 for an existing zip package. It would be nice to mock that in testing.
It's not clear from README, does it have persistence?
I.e. if I create an s3 bucket and upload files in it, would the bucket/files be there after I restart the emulator?
I run several Docker services on EC2 and testing locally before deploying has always been painful. This looks promising for catching config issues before they hit production. Does it support EC2 + RDS together in local mode?
Also localhost and presumably this are good for validating your logic before you throw in roles, network and everything else that can be an issue on AWS.
Confirm it runs in this, and 99% of the time the issue when you deploy is something in the AWS config, not your logic.
Exactly, especially when people are starting out, don't have a clear understanding of the inner workings of the system for whatever reason. Jobs are getting harder to find nowadays and if during learning, you make one mistake, you either pay or the learning stops.
IDK, I never fancied using local emulators for stuff like the cloud, as others have pointed out, for UT you can mock cloud services, and for localdevelopment you should intercat with the cloud.
Hiding bad system design behind another docker container will not push you to the right direction, but the opposite.
In addition this is def vide-coded (50k loc in one week) so I don't see how can one trust this even.
Tools like this one are for local-first development, obviously you still need "real" staging environments. Deploying changes to staging takes significant time due to cloudformation being horribly slow. This is to move faster so you have tighter feedback loops for infra changes.
Getting Java to run is a base requirement for running most software written in Java.
However, there is a dedicated Dockerfile for creating a native image (Java words for "binary") that shouldn't require a JVM. I haven't tested running the binary myself so it's possible there are dependencies I'm not aware of, but I'm pretty sure you can just grab the binary out of the container image and run there locally if you want to.
It'll produce a Linux image of course, if you're on macOS or Windows you'd have to create a native image for those platforms manually.
Isn't a docker image basically a universal binary at this point? It's a way to ship a reproducible environment with little more config than setting an ENV var or two. All my local stuff runs under a docker compose stack so I have a container for the db, a container for redis, LocalStack, etc
I'm not saying it's ideal, just saying that's what we've shifted to for repeatable programs. Your Linux "universal" binary certainly won't work on your Mac directly either...
Cloud providers like AWS, GCP, and Azure should offer local emulators for development. This would encourage developers to utilize their services more.
I currently work with several AWS serverless stacks that are challenging or even impossible to integration test locally. While Localstack provide a decent solution, it seems like a service that AWS should offer to enhance the developer experience. They’d also be in the best position to keep it current.
Ilove the emulation, but it will never come from the hyper scalers.
One issue is that local emulation runs into some big political rocks as soon as it gets good. To start with, the emulator is good enough and covers a tiny surface of what people want, eg k8s and s3. Resistance here is about customers experiencing issues caused by gaps in fidelity vs the real environment and subsequent pain for the emulator product team. ok, fine.
But then you get customers who take your emulator and use it in places where AWS cant go, eg, airgapped environments. They start asking for more serious features. But wait! another team in the hyperscaler was already trying to solve this, for far more than zero dollars. Azure Stack. Azure Local. AWS Snowball. Now there are VPs shooting at you because you are, in their view, cannibalizing their revenue.
You might try to avoid this war by emphasizing the dev sandbox aspect, selling to developers only and making sure that you only talk about APIs and stuff. Problem is, the API surface is 90% of why the cloud is useful (the other ten percent being the assertion that you don't have to think about it, which is an increasingly untrue proposition, as the reams of SREs will tell you). So now you have an emulator for the most valuable part of Cloud, in the hands of people who know how to use it and are strongly incentivized and capable of making it better, all running locally. It's a very small step to making that commercial and wiping huge chunks of revenue out, as your VP will tell you as they sign your pink slip.
Talking to devs, the most common thing I hear re emulation is a desire to be able to let rip on any service and not fear a giant bill. Since all clouds have budget tools I wonder why this isnt possible today? Maybe theres a weakness in the planning tools rather thanthe post-use budgeting ones?
An official local emulator sounds nice until AWS has to explain why S3, IAM, or Kinesis behave a little differntly on your laptop, because the minute it's blessed people will treat every mismatch as an AWS bug, not a dev-time compromise.
AWS don't want that support nightmare.
“A trillion dollar company cannot afford bug triage” is a weird argument tbh.
Except that it's true, they can't. How else are they going to race to the bottom of the minimum number of employees and maximum amount of management bonuses?
what makes you think AWS would look at any of the bugs filed by people using local emulators
Because, in this hypothetical situation, AWS provides the emulators that people are filing bugs on.
I noticed an AWS engineer publish a local AWS suite https://github.com/local-web-services/local-web-services which seems comparable.
Great to see Localstack offset a bit thanks to ... AI driven shift left infrastructure tooling? This is a great trend.
Microsoft used to with their Azure Service Dev Kit. the ASDK was a single-node "sandbox" meant to emulate the entire Azure cloud locally. They may have something similar now but paired back
CloudFlare for their serverless offering did it, and it works decent.
I disagree with this entirely.
You should build your software around abstractions and interfaces which are portable enough to work locally and in AWS or any other cloud and not just AWS specific APIs.
I agree that this is what everyone should strive to do but this quickly hits a limit.
For example, IAM/S3/SQS policy evaluations can have profound impact on an application running but an abstraction wouldn’t help much here (assuming the developer is putting any thought into securing things). There just isn’t an alternative to these. If you’re rolling out an application using AWS-proprietary services, you have to get into vendor-specific functionality.
My point is you should not build on top of their native services if it incurs this problem.
it's a trade off, a risk. (sure, for many people it doesn't make sense, because they don't have scale or growth anywhere near the numbers where generic/abstracted is not efficient enough)
Azure does this and has amazing tooling for bringing it all together locally (Aspire)
[dead]
They should... put work into sacrificing revenue?
If you have a local “digital twin” of the service, it makes it much easier to develop against using AI. This would likely drive adoption.
It's even easier for their revenue if you have to provision dev AWS environments for everyone.
Totally agree that AI coding makes this even more important. We are working on a coding agent-first cloud and a large part of that is ensuring everything runs locally so folks can let their coding agents define the infra and test it all
It's not clear that it would be a net-negative on the revenue.
It could encourage more development and adoption and lead to being a net-positive for the revenue.
It's a fair point but iff you neglect that the overwhelming revenue drivers for these services are large corps who are already locked-in. Devx doesn't matter at all once you're there.
The myopathy among us "online people" is assuming number of voices here and elsewhere correlate to revenue.
It does not.
Just fyi, myopathy is a general term for diseases that affect some types of muscles, while myopia is short-sightedness -- assuming the latter is what you were going for!
Thanks!
If it's irrelevant whether or not individual developers are on board, why are Amazon offering a free plan?
Without the infrastructure behind it to make it make sense, cloud platforms just seem like convoluted ways of storing data and launching applications/VMs to me.
The only functional use of a tool like this to me would be to learn how to use AWS so that I can work for people who want me to use AWS. Would that not be to Amazon's benefit?
Why would an emulator sacrifice revenue? It's like saying minecraft destroys construction businesses
A few notes about "local AWS" (or "local cloud") based on other comments and my own XP:
- I'm not sure this kind of product is really a foot in the door to create new customers. Someone not willing to create an actual account because they have no money or they just don't want to put their card details is not someone who's going to become a 6 figures per year customer, which is the level to be noticed by those providers.
- The free tier of AWS is actually quite generous. For my own needs I spend less than $10/year total spread around dozens of accounts.
- If one wants to learn AWS, they MUST learn that there are no hard spend limits, and the only way to actually learn it, is to be bitten by it as early as possible. It's better to overspend $5 at the beginning of the journey than to overspend $5k when going to prod.
- The main interest of local cloud is actually to make things easier and iterating faster, because you don't focus on all the security layer. Since everything is local, focus on using the services, period. Meanwhile, if you wanted to rely on actual dev accounts, you need to first make sure that everything is secure. With local cloud you can skip all this. But then, if you decide to go live, you have to fix this security debt and it most often than not break things that "work on my computer".
- Localstack has the actual support of AWS, that's why they have so much features and are able to follow the releases of the services. I doubt this FOSS alternative will have it.
Security is the entire reason I want tools like this. Specifically for emulating IAM: if you've got a hard organisational "least privilege" mandate then you start with virtually nothing allowed and have to enable permissions for the explicit set of API calls you're using. You're not doing `Allow :` but you're also not using AWS-managed roles. That combined with the fact that - certainly with terraform - there's no mapping between "I need to manage this resource" and "these are the permissions needed to do so" means that every time you do something new in your infrastructure you're going into a game of permissions whack-a-mole where the deploy/fix/deploy cycle can easily take a multiple of the time it took to develop the feature you want to deploy, because one trip round the loop is a full attempted deployment. Whereas if there's an accurate local emulator not just of the feature but of the permissions attached to it, you can shortcut the slow bit.
Localstack does have IAM emulation as part of the paid product. I'm intrigued to see how well this does at the same thing.
A major use case for LocalStack is CI/CD.
When you're running hundreds of integration test suites per day in CI pipelines, the free tier is irrelevant. You need fast, deterministic, isolated environments that spin up and tear down in seconds, not real AWS calls that introduce network latency, eventual consistency flakiness, rate limits, and costs that compound with every merge request.
It'd be great to just use AWS but in practice it doesn't happen. Even if billing doesn't, limits + no notion of namespacing will hit you very quickly in CI. It's also not practical to give every dev AWS account, I did it with 200 people it was OK but always caused management pain. Free tier also don't cover organizations.
> they MUST learn that there are no hard spend limits, and the only way to actually learn it, is to be bitten by it as early as possible
This is a bizarre take. "The best way to learn fire safety is to get burned." You can understand AWS billing without treating surprise charges as a rite of passage.
The main use case for local emulators is unit testing. Maybe even some integration testing, especially for stuff like VPC setup that often can't be done without global side effects.
Security for dev accounts is not a big deal, just give each developer an individual account and set up billing alerts.
> Security for dev accounts is not a big deal, just give each developer an individual account and set up billing alerts.
If your only focus is spending, yes.
Otherwise, a "not a big deal" dev account can quickly become the door to your whole org for hackers
It really depends on the way you set it up and use it. Raw EC2 instances are obviously the most dangerous items.
RDS databases, DynamoDB, and S3? Much less so.
> you set it up and use it
That's my point: I'm not the one setting it up and using it, it's the devs using it
And I'm not expecting them to know how to navigate a cloud provider securely.
So it's either setting the dev account with all the required guardrails in place, or using "local cloud" on their computer
How's this compare to moto? I understand folks are upset about licensing changes for LocalStack (which I happily use at my day job with an enterprise license), but there are already several good alternatives.
The aws endpoint coverage is impressive for moto [1], which my team almost migrated to, but we liked our support contract with LocalStack.
http://docs.getmoto.org/en/latest/docs/services/index.html
Those kind of tools are futile endeavors to me.
If you want to use that for unit testing, then I think it would be better to mock the calls to AWS services. That way you test only your implementation, in an environment you control.
If you want to use that for local development, then I think it would be better to provision a test environment (using Terraform or any other IaC tool). That way you don't run the risk of a bug slipping into prod because the emulator has a different behaviour than the real service.
Also would like to add, that you might experiance bugs on "local env" while it will work on AWS.
[dead]
> LocalStack's community edition sunset in March 2026 — requiring auth tokens, dropping CI support, and freezing security updates. Floci is the no-strings-attached alternative.
Unfortunate that they're closing up after all these years. That said, I have their enterprise license at work and it has been fantastic, saving thousands of dev hours by giving our team tighter feedback loops without having to wait for ages on cloudformation deployments. LocalStack allows me to test my changes on the train without even an internet connection (the keys are baked into our dev containers)
This project would be comical if it takes off. In Romanian this name means "a small pile of hair", but informally it's only used as a synonym for pubic hair.
In Latin it's a tuft of wool, best known for expressions of valuelessness like "flocci non facio," meaning 'I don't consider it worth a tuft of wool.'
This is exactly what I was waiting for.
Although I love localstack and am grateful for what they have done, I always thought that an open community-driven solution would be much more suitable and opens a lot of doors for AWS engineers to contribute back. I’m certain that it’s on their best interest to do so (specially as many of their popular products have local versions)
It’s a no-brainer to me as AI adoption continues to increase: local-first integration testing is a must and teams that are equipped to do so will be ahead of everyone else
How is it in AWS' best interest to provide support or changes for a FOSS clone (albeit with ephemeral storage)? I believe that providing locked down local-first containers themselves for various services (which they do for services like ddb) would make more sense. I'm sure no one at AWS would take a bug report seriously saying random FOSS thing doesn't work with their official client sdks...
I think it's too early to even say if Floci will become something that people use so time will tell, but at AWS, they already had some "informal" support for localstack[1] and it's always been a "commercial product" (so you can imagine how controversial it must be internally to support a third-party clone). I'm only saying that a FOSS version is somewhat less controversial for them to support and although I would love for AWS to have something of their own they clearly have other priorities.
[1] https://docs.aws.amazon.com/prescriptive-guidance/latest/pat...
100% this. especially with agentic workflows actually mutating state now. local testing is the only safe way to see what happens when a model hallucinates a table drop without burning an actual staging database.
Cool, I've tried localstack before and cant wait to give it a try
Anyway, do anyone know if there're similar stuff but for gcp? So far https://github.com/goccy/bigquery-emulator helped me a lot in emulating bigquery behaviour, but I cant find emulator for the whole gcp environment.
Local AWS emulators are one of those tools where the value is inversely proportional to how much you trust your staging environment. If your staging account perfectly mirrors prod, you don't need a local emulator. But nobody's staging perfectly mirrors prod, so you end up needing something like this for the fast feedback loop on IAM policies, Step Functions state machines, and anything involving SQS/SNS fanout where the iteration cycle against real AWS is measured in minutes per attempt. The question is always parity — how closely does the emulation match real AWS behavior at the edges? LocalStack has been chasing that for years and still hits gaps. Curious how Floci handles the services where AWS's own behavior is underdocumented.
The point of tools like this is for development, not staging. By “development” I don’t just mean developers writing code, but any unit tests that require behavioural testing that cannot easily be mocked too.
So by the time you’re ready to push to staging you should be past the point of wanting to emulate AWS and instead pushing to UAT/test/staging (whatever your naming convention) AWS accounts.
Ideally you would have multiple non-production environments in AWS and if your teams are well staffed then your dedicated Cloud Platform / DevOps team should be locking these non-prod environments from developers in the same way as they do to production too.
Bonus points if you can spin up ephemeral environments automatically for feature branches via CI/CD. But that’s often impractical / not pragmatic for your average cloud-based project.
Ultimately you need staging, yes.
But you can’t have every dev tweaking staging at the same time as they work. How can you debug things when the ground is shifting beneath you?
Ideally every dev has their own AWS account to play with, but that can be cost prohibitive.
A good middle ground is where 95% of work is done locally using emulators and staging is used for the remaining 5%.
One of the first things I do when building a new component is create a docker compose environment for it.
Relying on staging means no offline development and also leads to toe-stepping. Cheap local implementations are great for consistent tests.
100% this. I've used AWS emulation layers for local-first development going on the better part of a decade. I cannot stress how much time it saves me from pushing code that would have failed in staging. When the cost of deployment pipelines via cloudformation is so high, it's a no brainer.
DIY mocks alone can get you somewhat there, but that relies on the developer having intimate knowledge of the aws sdk under test and it's very easy to mock the inputs and outputs wrong. I'd rather defer that to an emulation layer that does that mimicry better than my guess and check with 30m between attempts when my cloudformation deployments ultimately fail...
is all of this is vibe coded?
Can't say for sure but the first commit was only four days ago and has a gitignore mentioning to Claude so probably yes. https://github.com/hectorvent/floci/blob/main/.gitignore
Isn’t a “local emulator of cloud services” kind of the perfect project to be vibe coded? Extremely well documented surface to implement, very easy to test automatically and prove it matches the spec, and if you make some things sub optimal performance wise, that is totally fine because by project will not be used in a tight loop anyway - e.g. it will just need to be faster than over the network hop plus the time it takes for the cloud to actually persist things. This can just need to do this in ram and doesn’t need to scale.
So I’m shocked cloud providers haven’t just done this themselves, given how feasible it is with the right harness
AWS _does_ officially provide local-first dev containers for services like DynamoDB but sadly not every AWS service comes with those. Why? I have no idea, like you said it's clearly feasible and they already do it for some services today...
https://github.com/hectorvent/floci/blob/main/CONTRIBUTING.m...
Mentions CLAUDE.md and didn't even bother deleting it.
What matters more is if there is good QA.
Does it matter?
It does to the person who asked the question.
Whether their concerns are driven by curiosity, ethics, philosophy, or something else entirely is really immaterial to the question itself.
Not necessarily. Would you respond the same if the previous person said, "Was this built using an IDE" or "What qualifications do you have to write this software"?
Shit code can be written with AI. Good code can also be written with AI. The question was only really asked to confirm biases.
As someone who has worked in projects with hundreds of seemingly trivial dependencies which still manage to produce a steady stream of security notices, "What qualifications do you have to write this software" seems like an entirely reasonable, far too seldom asked question to me.
Sure, but that seems like quite a high gatekeeping bar for a test suite.
What test suite?
I dont automatically dismiss ai slop but when its obvious this was barely reviewed and sloppily committed with broken links 404ing or files missing from git, then it is slop.
Using llm as a tool is different from guiding it with care vs tossing a one sentence prompt to copy localstack and expecting the bot to rewrite it for you, then pushing a thousand file in one go with typos in half the commit message.
Longevity of products comes from the effort and care put into them if you barely invest any of it to even look at the output, look at the graveyard of "show hn" slop. Just a temporary project that fades away quickly
The commits are sloppy and careless and the commit messages are worthless and zero-effort (and often wrong): https://github.com/hectorvent/floci/commit/1ebaa6205c2e1aa9f...
There are no code commits. The commits are all trying to fix ci.
The release page (changelog) is all invalid/wrong/useless or otherwise unrelated code changes linked.
Not clearly stating that it was AI written, and trying to hide the claude.md file.
The feature table is clearly not reviewed, like "Native binary" = "Yes" while Localstack is no. There is no "native" binary, it is a packed JVM app. Localstack is just as "native" then. "Security updates Yes" .. entirely unproven.
I'll have a much harder time convincing my company to try out such a tool if it's AI slop than when there's a group of people behind it.
I'll happily use it for personal development stuff if I ever decide to try cloud stuff in my free time, but it's hardly an alternative to established projects like LocalStack for serious business needs.
Not that any of it should matter to the people behind this project of course, they can run and make it in whatever way they want. They stand to lose nothing if I can't convince my boss and they probably shouldn't care.
24ms startup is the real story
At that speed you can treat it as disposable: fresh instance per test run, no shared state, no flaky tests from leftover S3 objects. that was never practical with LocalStack cold start
This is why I use LocalStack today. I can stand up all my infra for my teams 14 microservices in under 30s and test my in flight changes, all without an internet connection. Deploying to our real staging environments take 30m (literally) for a single CDK / cloudformation stack change. The fact I have an immediate feedback loop saves my team inordinate amounts of time. Cloudformation deployments are criminally slow.
I recently discussed this with an adjacent org that didn't use a local environment at all outside of junit mocks for unit testing, and their deployment pipelines take over 45m per commit. Ridiculous.
Side note: this local-first strategy works well but requires some beefy hardware with gobs of ram, at least in my line of work with java and rails microservices. My laptop is an M4 with 64gb ram. I honestly wish I had the 128GB model...
Looking at the features this seems to be an awesome project, but the commit history (even on the develop branch) shows almost nothing.
No pull-requests, no real issues, it smells like it was auto-generated which is disappointing. Makes it harder to trust if you're going to test with "real data", how do we know it won't be sent elsewhere?
I don't understand why you'd be making this comment when the commit history shows this whole project is a week old.
>how do we know it won't be sent elsewhere?how do we know it won't be sent elsewhere?
I the past open source meant that you trusted in theory that someone else would notice and report these things. These days though just load up your LLM of choice and ask it to do a security audit. There are some unreliable ways to cheat this and they aren't magical, but it would be pretty hard to subvert this kind of audit.
It is usual for a new project to start small, and slowly add new features. Instead this project seems to arrive "fully formed".
There is no "this is the core, then we add S3, then we add RDS, then we add ..." history to view and that seems both unnatural and surprising. Over half the commits are messing around with github actions and documentations.
Definitely this. I like seeing issues reasonably populated with OSS projects. Otherwise, how am I supposed to contribute back to it? Granted it's a newer project so I will be keeping track in the future.
Could also be a vibe coded project.
Seems pretty similar to this from a few days ago (but with lower coverage from what i can tell):
https://news.ycombinator.com/item?id=47420619
https://github.com/robotocore/robotocore
This seems useful for testing. I was wanting to create some ansible roles for things like packaging a lambda. One of the things it does is check s3 for an existing zip package. It would be nice to mock that in testing.
It's not clear from README, does it have persistence? I.e. if I create an s3 bucket and upload files in it, would the bucket/files be there after I restart the emulator?
I run several Docker services on EC2 and testing locally before deploying has always been painful. This looks promising for catching config issues before they hit production. Does it support EC2 + RDS together in local mode?
If I wanted to follow a tutorial or book but could not afford AWS, could this tool be used as a substitute for AWS functionality?
Aws has lots of free. What would you need to pay for?
Its pretty easy to step over those limits.
Also localhost and presumably this are good for validating your logic before you throw in roles, network and everything else that can be an issue on AWS.
Confirm it runs in this, and 99% of the time the issue when you deploy is something in the AWS config, not your logic.
>> "It's pretty easy to step over those limits."
Exactly, especially when people are starting out, don't have a clear understanding of the inner workings of the system for whatever reason. Jobs are getting harder to find nowadays and if during learning, you make one mistake, you either pay or the learning stops.
A credit card on file is required to use free tier and it is still a barrier for many.
The real barrier for me is that I can’t set a hard spending limit.
That's true.
IDK, I never fancied using local emulators for stuff like the cloud, as others have pointed out, for UT you can mock cloud services, and for localdevelopment you should intercat with the cloud.
Hiding bad system design behind another docker container will not push you to the right direction, but the opposite.
In addition this is def vide-coded (50k loc in one week) so I don't see how can one trust this even.
Tools like this one are for local-first development, obviously you still need "real" staging environments. Deploying changes to staging takes significant time due to cloudformation being horribly slow. This is to move faster so you have tighter feedback loops for infra changes.
I’d be happier if this could run as one binary without Docker. Java is so much harder to setup.
Getting Java to run is a base requirement for running most software written in Java.
However, there is a dedicated Dockerfile for creating a native image (Java words for "binary") that shouldn't require a JVM. I haven't tested running the binary myself so it's possible there are dependencies I'm not aware of, but I'm pretty sure you can just grab the binary out of the container image and run there locally if you want to.
It'll produce a Linux image of course, if you're on macOS or Windows you'd have to create a native image for those platforms manually.
Yeah, compare this with downloading single binary approach.
Downloading JDK, setting up the correct env variables, or running Docker, all this is just pain, compared to single binary approach.
Isn't a docker image basically a universal binary at this point? It's a way to ship a reproducible environment with little more config than setting an ENV var or two. All my local stuff runs under a docker compose stack so I have a container for the db, a container for redis, LocalStack, etc
Is it though?
On my Mac Docker runs Linux virtualized. It’s a resource hog.
Compare that with simple native binary.
I'm not saying it's ideal, just saying that's what we've shifted to for repeatable programs. Your Linux "universal" binary certainly won't work on your Mac directly either...
Are you considering a php / laravel sdk too?
I really need to find a way to have appsync local
Is Eucalyptus still a thing?
[dead]
[dead]
[dead]
[flagged]
[dead]