3 Tips and Tricks for Using LocalStack with AWS

Hopefully, you’re already aware that LocalStack can dramatically increase the speed of your AWS development by allowing you to build and test your code locally, on your own laptop. You may also already know that, beyond speeding up your development, LocalStack offers a range of developer experience improvements—for example, hot reloading, breakpoints, and step debugging for Lambdas.

At this point, I hope you’re saying, “You had me at test locally!”

Still, there are some tips and tricks you can use to make your experience developing with LocalStack even better. In this post, I’ll share a few tips from folks inside LocalStack on how they like to use it.

Tip 1: Easier Restarts

The first tip comes from our Senior Developer Relations Engineer, Harsh Mishra, and it’s one that I use every day: use the localstack restart command in the LocalStack CLI to restart your LocalStack container.

Here’s a common scenario: you’re working on some Terraform, CDK, or CloudFormation code that you want to deploy and test in LocalStack. First, you start LocalStack:

localstack start

Next, you push your resources using one of our lightweight CLI wrappers. For instance, I tend to use the AWS CDK, so I rely on cdklocal:

cdklocal bootstrap
cdklocal deploy

Now I’m ready to test, but it turns out I missed or messed up some configuration in my CDK code. A common solution might be to kill the current LocalStack instance and, once it’s done shutting down, run localstack start again to get a fresh instance.

However, a faster shortcut is to open a new Terminal tab/window and enter:

localstack restart

This accomplishes the same result with a single command, making for a smoother and quicker development experience.

Not only does this save keystrokes, but—at least to me—it feels much faster.

For additional usage information, check the LocalStack CLI documentation.

Tip 2: CLI Profiles

The second tip comes from our Staff Software Engineer, Alex Rashed, and it also aims to simplify your command line usage. Alex is a fan of using CLI profiles for the AWS CLI.

The AWS CLI provides an option for defining named profiles, which let you store different sets of credentials and configuration settings. You can switch between them easily, either by specifying the profile per command:

aws lambda invoke --function-name myfunction output.json --profile myprofile

…or by exporting an environment variable within your shell so it applies to all AWS CLI commands:

export AWS_PROFILE=myprofile

This means you can also set up a localstack profile with the correct configurations and run AWS CLI commands directly against your local instance. While our lightweight wrapper awslocal serves a similar purpose, there are a couple of advantages to using profiles:

1. You don’t have to swap between command-line tools. The same AWS CLI commands work for both AWS and LocalStack.
2. It bypasses some current limitations of awslocal.

Setting Up a Profile

To set up a LocalStack profile, you need to modify both the config and credentials files in your AWS CLI directory. You can use any text editor to do this. For example, in Visual Studio Code:

code ~/.aws/config

If you haven’t edited this file before, you may only see a default configuration. Add a localstack profile with the following details:

[profile localstack]
region = us-east-1
endpoint_url = https://localhost.localstack.cloud:4566
aws_access_key_id = test
aws_secret_access_key = test

Next, open the credentials file:

code ~/.aws/credentials

And add the following:

[localstack]
aws_access_key_id = test
aws_secret_access_key = test

Now you can quickly switch between AWS profiles using:

export AWS_PROFILE=localstack

Or by appending --profile localstack to any AWS command. For more details, check our AWS CLI documentation.

Tip 3: Delete the Volume Folder

Our final tip for the day comes from one of our Technical Support Engineers, Eduardo Delgado. As you might imagine, Eduardo encounters a lot of edge cases that can be difficult to debug, and his tip is great for solving rare issues.

The .volume folder is a cache that LocalStack mounts on your container. If you’re using the LocalStack CLI, it gets mounted in these locations:

• Mac: ~/Library/Caches/localstack/volume
• Linux: ~/.cache/localstack/volume
• Windows: %LOCALAPPDATA%\cache\localstack\volume

If you’re using Docker Compose instead of the CLI, the location is defined in your docker-compose.yml file:

volumes:
  - "${LOCALSTACK_VOLUME_DIR:-./volume}:/var/lib/localstack"

LocalStack stores cached certificates, state data, and temporary files in .volume. Occasionally, deleting this folder can help resolve issues where LocalStack won’t start or runs into unusual certificate problems.

When to Delete .volume

For example, you might see a ModuleNotFoundError like this:

while finding module specification for 'localstack.pro.core.bootstrap.extensions.autoinstall' (ModuleNotFoundError: No module named 'localstack.pro')

Or you may encounter a certificate error that persists despite troubleshooting. Deleting .volume forces LocalStack to download fresh certificate copies, which can resolve these issues.

What Are Your Tips?

If you’re a LocalStack user and have additional tips, we’d love to hear them!

You can share your insights with us and the community on BlueSky, LinkedIn, or our Community Slack.