In our organization, we heavily rely on AWS for our production environments, which is why my teams and I have been using LocalStack for about two and a half years to completely replicate our cloud environment locally. A great, specific example of our main use case for LocalStack is developing an API that triggers a Lambda function when an image is uploaded to an S3 bucket. Instead of deploying to AWS and waiting, we spin up LocalStack inside a Docker container. We can upload files via `awslocal`, instantly watch the Lambda trigger, verify the records update in our local DynamoDB, and step through the code with breakpoints. Our main use case is local integration testing and debugging for serverless applications. Our team continuously uses LocalStack, virtually every time a developer is writing code and wants to test a resource locally. Beyond day-to-day coding, it heavily optimizes our CI and CD pipeline workflows. Instead of spinning up temporary, expensive AWS environments for every pull request, we run LocalStack directly on our GitHub Actions to execute integration and tests.
Specialist Backend Engineer at a computer software company with 1,001-5,000 employees
Real User
Top 20
May 14, 2026
My main use case for LocalStack is to set up a configuration for my environment to configure the AWS components locally on my machine. I use it to have all the components I need to run my applications locally and simulate the use cases of my applications with AWS services. I use LocalStack to test database services like DynamoDB, test SNS services, and SQS to send messages. Another configuration that I use is Secrets Manager.
Software Engineer at a tech services company with 501-1,000 employees
Real User
Top 10
Apr 30, 2026
My main use case for LocalStack is for tests on my machine. For example, when I want to create a table in AWS, I create a LocalStack and use it in my tests before I publish the Terraform. I also create my application container and create the tables in LocalStack for running all my tests. I use not only tables, but also SQS and SNS. I only have features that I use to add about my main use case for LocalStack, to be honest.
The main use case for LocalStack was about simulation in order to have a low impact on costs for our AWS environments. An example of how I use LocalStack is to have a simulation for our Vault, where we store our secrets. The way we store it was to have an internal software that we can give to others who are non-technical.
My main use case for LocalStack is to run AWS services locally on our machines, such as running on our laptop or on our server, and for a sandbox for testing our cloud apps. A quick, specific example of how I use LocalStack for testing my cloud apps is that we use LocalStack for a sandbox or staging environment for AWS resources. We test it on LocalStack, and if everything works well, then we deploy it to AWS.
LocalStack is a cloud service emulator that enables developers to build and test cloud applications entirely on their local machines, simulating relevant AWS features to enhance efficiency.LocalStack offers an accessible environment for rapid cloud development and testing cycles, reducing the dependency on cloud-based infrastructure during the early stages of software development. It is especially useful for teams aiming to minimize costs and time delays caused by deploying to remote services...
In our organization, we heavily rely on AWS for our production environments, which is why my teams and I have been using LocalStack for about two and a half years to completely replicate our cloud environment locally. A great, specific example of our main use case for LocalStack is developing an API that triggers a Lambda function when an image is uploaded to an S3 bucket. Instead of deploying to AWS and waiting, we spin up LocalStack inside a Docker container. We can upload files via `awslocal`, instantly watch the Lambda trigger, verify the records update in our local DynamoDB, and step through the code with breakpoints. Our main use case is local integration testing and debugging for serverless applications. Our team continuously uses LocalStack, virtually every time a developer is writing code and wants to test a resource locally. Beyond day-to-day coding, it heavily optimizes our CI and CD pipeline workflows. Instead of spinning up temporary, expensive AWS environments for every pull request, we run LocalStack directly on our GitHub Actions to execute integration and tests.
My main use case for LocalStack is to set up a configuration for my environment to configure the AWS components locally on my machine. I use it to have all the components I need to run my applications locally and simulate the use cases of my applications with AWS services. I use LocalStack to test database services like DynamoDB, test SNS services, and SQS to send messages. Another configuration that I use is Secrets Manager.
My main use case for LocalStack is for tests on my machine. For example, when I want to create a table in AWS, I create a LocalStack and use it in my tests before I publish the Terraform. I also create my application container and create the tables in LocalStack for running all my tests. I use not only tables, but also SQS and SNS. I only have features that I use to add about my main use case for LocalStack, to be honest.
The main use case for LocalStack was about simulation in order to have a low impact on costs for our AWS environments. An example of how I use LocalStack is to have a simulation for our Vault, where we store our secrets. The way we store it was to have an internal software that we can give to others who are non-technical.
My main use case for LocalStack is to run AWS services locally on our machines, such as running on our laptop or on our server, and for a sandbox for testing our cloud apps. A quick, specific example of how I use LocalStack for testing my cloud apps is that we use LocalStack for a sandbox or staging environment for AWS resources. We test it on LocalStack, and if everything works well, then we deploy it to AWS.