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?
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)
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?
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.
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.
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
We wrote a detailed breakdown of Floci's specs vs LocalStack — the 408/408 SDK test pass rate, 24ms vs 3.3s startup, services LocalStack community edition doesn't cover (API Gateway v2, Cognito, RDS with IAM auth): https://megaoneai.com/spotlight/floci-free-aws-emulator-alte...
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.
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
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?
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.
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?
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?
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.
95 comments
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.
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?
Great to see Localstack offset a bit thanks to ... AI driven shift left infrastructure tooling? This is a great trend.
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.
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 could encourage more development and adoption and lead to being a net-positive for the revenue.
The myopathy among us "online people" is assuming number of voices here and elsewhere correlate to revenue.
It does not.
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?
- 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.
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
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.
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
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.
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
https://news.ycombinator.com/item?id=47420619
https://github.com/robotocore/robotocore
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?
Amazon S3 lists objects in alphabetical order.
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.