Configure LocalStack by enabling only the AWS-like services your project needs, deciding whether emulator state should survive restarts, and provisioning test fixtures with initialization hooks. For example, SERVICES=s3,sqs PERSISTENCE=1 localstack start starts with S3 and SQS enabled and persistence on. The right setup depends on whether each run should begin with fresh test data or resume a previous working state.
Choose which LocalStack services to enable
Set SERVICES to a comma-delimited list of service names, such as s3,sqs. When the variable is set, LocalStack loads only the listed services; other services are disabled and cannot be used. See the LocalStack configuration reference for supported configuration and service names.
Start with the services the application or test suite actually uses. This keeps the local environment aligned with the test’s dependencies instead of assuming every service is available. To check service names and current status, consult /_localstack/health.
Decide whether LocalStack state should persist
LocalStack state is ephemeral by default: it resets when the emulator shuts down or exits unexpectedly. Enable snapshots with PERSISTENCE=1, or use the documented --persist option. Persistent state is stored beneath the LocalStack volume directory, rooted inside the container at /var/lib/localstack. Mount or otherwise retain that directory if it must survive container replacement. See the persistence documentation.
Recommended Free Tools
#1 Best Overall
Persistence is useful for resuming a development environment, but it is not the same as a clean test fixture. A resumed snapshot can contain resources from earlier runs. If tests need deterministic starting data, decide how the environment is reset and seeded rather than relying on persistence alone.
Choose when snapshots are saved and loaded
LocalStack offers snapshot strategies that trade routine overhead against how much recent state might be lost and when restore work occurs. The documented save default is SCHEDULED, which flushes every 15 seconds by default. The documented load default is ON_REQUEST. Exact behavior and configuration options are described in the persistence reference.
| Snapshot action | Strategy | Practical effect |
|---|---|---|
| Save | ON_REQUEST |
Can add latency or block state-changing requests while state is saved. |
| Save | ON_SHUTDOWN |
Low routine overhead, but recent state can be lost if shutdown does not complete. |
| Save | SCHEDULED |
Automatically flushes on a schedule; default interval is 15 seconds. |
| Save | MANUAL |
Snapshot timing is explicitly controlled through state endpoints. |
| Load | ON_REQUEST |
Loads state as requests require it; errors may appear as services are accessed. |
| Load | ON_STARTUP |
Loads state during startup, so restoration work happens before normal use. |
| Load | MANUAL |
Loading is explicitly controlled through state endpoints. |
Pick a save strategy based on the cost of losing the newest changes versus the interruption or work caused by saving. Pick a load strategy based on whether startup work or later, request-triggered restore is more suitable. Do not treat the 15-second schedule as a guarantee that all changes are durably saved at every moment.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Seed test data with initialization hooks
LocalStack provides initialization hooks under /etc/localstack/init, with hook directories for boot, start, ready, and shutdown. Mount project-owned scripts into the hook directory appropriate to when provisioning should run. A ready hook is a practical place for provisioning once services are ready to accept setup requests.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →- Keep fixtures with the project. Store setup scripts and fixture data alongside the application or test configuration so changes can be reviewed and versioned with the code.
- Mount the script into an init hook. For example, mount a ready hook under
/etc/localstack/init/ready.d/. - Provision the resources the application needs. Make the script create the required test resources and be safe to run as part of the intended startup workflow.
- Choose fresh or resumed state deliberately. If each test run requires known fixtures, define how prior state is cleared or replaced. If developers want to resume a working environment, enable persistence and account for older resources.
LocalStack’s migration example illustrates the configuration shape: it mounts a ready hook, sets SERVICES=s3,sqs and PERSISTENCE=1, then starts with lstk start. It is an example of wiring a hook and settings, not a complete S3 or SQS fixture; the project must provide its own provisioning commands and data.
Know the limits of snapshots
Persistence support and test coverage vary by service. Dynamic ports used by services such as RDS or ElastiCache may not be preserved on restore, which can leave restored resources pointing to invalid or unintended ports. The documentation suggests restoring services in their original deployment order, but notes that this is not always reliable.
Snapshots may also be incompatible across LocalStack versions. Treat snapshots as environment state rather than portable, version-independent test fixtures, and validate the relevant service and version combination when relying on restore behavior.
Use export and import for file-based state workflows
Automatic persistence is intended to pause and resume emulator state. LocalStack also documents state export and import commands for file-based workflows; those commands are marked preview, and importing state created by another version may fail. Consult the current persistence documentation before adopting them for a repeatable workflow.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
