How to Connect to DynamoDB Local and LocalStack

You have a local DynamoDB running and your code talks to it fine — but you want to see the tables, not write a scan script every time. Connecting a client to a local endpoint is two changes: point at the right URL, and hand it throwaway credentials. The details below are where people get stuck — region namespacing, the alphanumeric-key rule, and the 8000 vs 4566 port split.

DynamoDB Local vs LocalStack: what you're connecting to

Both give you a DynamoDB API on localhost with no AWS account, but they're different things:

DynamoDB Local is the downloadable DynamoDB engine in a single process — AWS ships it as a JAR and a Docker image (amazon/dynamodb-local). It's DynamoDB and nothing else. Default port 8000 (AWS docs). See running DynamoDB Local with Docker.
LocalStack emulates a stack of AWS services behind one endpoint. Its DynamoDB is itself powered by DynamoDB Local, but everything goes through LocalStack's single edge port 4566.

So the only practical difference for connecting is the endpoint URL: :8000 for standalone DynamoDB Local, :4566 for DynamoDB-via-LocalStack. Everything else — the API, the credentials trick, the GUI config — is identical.

The endpoint + dummy-credentials setup that trips everyone up

The AWS SDKs and CLI require an access key and a region even when talking to a local endpoint — but those values don't have to be real. AWS's own docs say these values "don't have to be valid AWS values to run locally" (AWS docs).

Two gotchas that aren't obvious:

The region/access-key silently namespaces your data. Without the -sharedDb flag, DynamoDB Local writes a separate myaccesskeyid_region.db file per access-key-ID + region combination — AWS's exact naming. Connect with a different key or region than your app used and your tables look like they've vanished; they're just in another file. Run with -sharedDb (one shared-local-instance.db for every client) or match the exact key + region your app uses.
The access key ID must be alphanumeric on DynamoDB Local — no symbols. AWS docs state AWS_ACCESS_KEY_ID can contain only A–Z, a–z, and 0–9; AWS introduced this in DynamoDB Local 2.0.0 (and 1.23.0+), so a key with special characters that worked on an earlier image now fails (AWS re:Post). See the error below.

For LocalStack the safe default is test / test: it ignores the secret key entirely and never validates the secret value. Real-looking AKIA…/ASIA… keys are rejected as a safeguard and fall back to the dummy account 000000000000 — the same account an arbitrary key like test resolves to. Stick with test.

Connecting with the AWS CLI (sanity check)

Before pointing a GUI at it, confirm the endpoint is alive from the CLI. The CLI can't default to a local endpoint, so you pass --endpoint-url on every command.

DynamoDB Local:

aws dynamodb list-tables --endpoint-url http://localhost:8000

LocalStack (same command, different port):

aws dynamodb list-tables --endpoint-url http://localhost:4566

If you have credentials configured at all (even fake ones in ~/.aws/credentials or via AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY), this returns your table list. An empty list with no error means the endpoint works but you're looking at a different key/region namespace — see the gotcha above.

Pass dummy creds inline for a one-off check without touching your profile:

AWS_ACCESS_KEY_ID=test AWS_SECRET_ACCESS_KEY=test AWS_REGION=us-east-1 \
  aws dynamodb list-tables --endpoint-url http://localhost:8000

DynamoDB Local GUI: browsing and querying local tables in DynoTable

Once the CLI works, a GUI needs the same three values: endpoint, region, and any dummy credentials. The CLI returns DynamoDB-JSON you read by eye; a GUI renders the same data as a table you can sort, filter, and edit.

In DynoTable, add a connection and set a custom endpoint:

Endpoint: http://localhost:8000 (DynamoDB Local) or http://localhost:4566 (LocalStack)
Region: whatever your app uses — e.g. us-east-1. It's a label here, not a real AWS region, but it must match so you land in the same data namespace.
Access key / secret: anything (test / test is conventional). Alphanumeric only for the access key on DynamoDB Local.

From there you browse items, run a Query or Scan, and edit rows visually instead of JSON by hand on the CLI. When you load fixtures, the DynamoDB-JSON converter turns plain JSON into the wire format, and Query vs Scan covers which read to reach for. Same drill for a LocalStack DynamoDB viewer — only the port changes to 4566.

DynoTable is local-only desktop software, so pointing it at localhost keeps your fixtures on your machine. For a broader look at the GUI landscape, see the DynamoDB GUI comparison.

Common errors (region mismatch, port, credentials)

Connection refused. Wrong port — 8000 is DynamoDB Local, 4566 is LocalStack. Also confirm the container actually published the port (docker run -p 8000:8000 amazon/dynamodb-local). For LocalStack, check the service is up at http://localhost:4566/_localstack/health.
The Access Key ID or Security Token is Invalid on DynamoDB Local. Since the 2.0.0 (and 1.23.0+) image, the access key ID must be alphanumeric only. A key with symbols that worked on an earlier image now fails — replace it with letters/numbers (e.g. test) and update every tool to match.
The security token included in the request is invalid against LocalStack. This is almost always an endpoint problem, not a credentials one — your SDK client dropped the --endpoint-url / endpoint_url and hit the real AWS endpoint, which rejects your dummy key. Confirm the client is actually pointed at http://localhost:4566.
Credential errors from the SDK/CLI. Even local endpoints need some credentials present. Set AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY (or a fake profile) so the SDK's credential chain resolves.
http vs https. Local endpoints are plain http. An https:// URL will fail the TLS handshake.

Is DynamoDB Local the same data as my real AWS tables?

No — local and cloud are completely separate stores. DynamoDB Local (and LocalStack's DynamoDB) keeps data in a local file or in memory; it never touches your AWS account, and AWS Regions/accounts aren't supported at the client level locally. That's the point: it's for development and testing. If you want the same fixtures in the cloud later, AWS suggests valid-looking key/region values locally so you only swap the endpoint when you move. To model that schema before you ship it, single-table design and GSI vs LSI cover the decisions that don't change between local and prod.

FAQ

Do I need real AWS credentials? No. Both DynamoDB Local and LocalStack accept dummy values. They just have to be present, alphanumeric (for DynamoDB Local), and consistent across your tools.

Why do my tables disappear when I switch tools? Without -sharedDb, DynamoDB Local partitions data by access-key + region into separate myaccesskeyid_region.db files. Use -sharedDb or keep those values identical everywhere.

What's the difference between port 8000 and 4566? 8000 is standalone DynamoDB Local's default; 4566 is LocalStack's single edge port that fronts all its emulated services, DynamoDB included.

Can one GUI connect to both? Yes — they speak the same DynamoDB API. Only the endpoint URL changes (:8000 vs :4566).

Is DynamoDB Local free? Yes. AWS distributes DynamoDB Local at no cost as a JAR and a Docker image — there are "no provisioned throughput, data storage, or data transfer costs"; it's intended for development and testing only, not production.

Can I run SQL against my local tables? Local DynamoDB speaks the same API as the cloud, so the same access-pattern rules apply — and the same limits: DynamoDB's PartiQL SELECT grammar is SELECT … FROM … WHERE … ORDER BY only — no JOIN, no GROUP BY, and no grouping aggregate functions like COUNT/SUM/AVG (see PartiQL vs SQL). DynoTable's runs those analytical queries over any connection, local included.

Try DynoTable to connect straight to localhost:8000 or localhost:4566 and browse, query, and edit your local tables with a GUI.