Using the emulator

Endpoint

Start Vera as in Get started. Every AWS service in the emulator is then served from one address, http://localhost:5003; if you published another host port, use that one. Every AWS command in these docs passes it with --endpoint-url "$VERA_ENDPOINT", including commands that use a URL or ARN the emulator returned.

Some identifiers the emulator returns look like AWS addresses, such as an SQS queue URL on sqs.us-east-1.amazonaws.com. They’re names, not places to send requests, so keep sending to VERA_ENDPOINT.

Plans and license keys

Free services run without a license key. Pro services need an active Pro license or trial: without one, their requests answer AccessDenied with “Vera Ultimate is required for this service”. For Pro, activate your license key and start the emulator with the Vera launcher, as in Activate Pro. The Free and Pro badges on the service list and each service page show which plan includes each service; Pro includes every Free service. A license key is Vera’s, and separate from the dummy AWS credentials the setup below gives the CLI. See Licenses and plans.

Set up the AWS CLI

You need a running emulator, a POSIX shell such as bash or zsh, and the official AWS CLI version 2.

These pages describe Vera 1.2.2. Their examples were run against it on 8 November 2026, on Linux AMD64, with a full-access license. The examples’ checks on Vera 1.2.0-rc.3 used the official AWS CLI 2.31.35, with its bundled Python 3.13.9 and no client patch. Findings from earlier testing say so, with their build or date: Vera 1.2.0-rc.3, on 6 November 2026, Vera 1.2.0 preview, on 5 November 2026, or earlier testing, on 3 November 2026. Some service pages’ API coverage also includes a review of the Vera 1.2.0 source, which describes the implementation, not a run: see Coverage statuses.

The coverage tables separately use the botocore 1.43.105 operation inventory. Newer clients can use a different request protocol: see the note on CloudWatch. Install the CLI from AWS’s instructions, which also explain choosing a version. The build checked was the Linux x86-64 package; the macOS, Windows and ARM64 installers weren’t.

Run the setup in a terminal of its own, from an empty scratch directory. It gives the CLI dummy credentials and the us-east-1 region, stops it from finding real credentials in a profile, a credentials file, instance metadata or the environment, and gives it a config file of its own, with JSON output, cli_binary_format = base64 and path-style S3 addressing:

export VERA_ENDPOINT="http://localhost:5003"
export AWS_ACCESS_KEY_ID=test AWS_SECRET_ACCESS_KEY=test
export AWS_REGION=us-east-1 AWS_DEFAULT_REGION=us-east-1
export AWS_SHARED_CREDENTIALS_FILE=/dev/null
export AWS_EC2_METADATA_DISABLED=true
export AWS_PAGER="" AWS_CLI_AUTO_PROMPT=off
unset AWS_PROFILE AWS_DEFAULT_PROFILE
unset AWS_SESSION_TOKEN AWS_SECURITY_TOKEN
unset AWS_WEB_IDENTITY_TOKEN_FILE AWS_ROLE_ARN AWS_ROLE_SESSION_NAME
unset AWS_CONTAINER_CREDENTIALS_FULL_URI
unset AWS_CONTAINER_CREDENTIALS_RELATIVE_URI
cat > vera-aws-config <<'EOF'
[default]
region = us-east-1
output = json
cli_binary_format = base64
s3 =
    addressing_style = path
EOF
export AWS_CONFIG_FILE="$PWD/vera-aws-config"

The config fixes how binary arguments are read, and fileb:// still reads a file’s raw bytes. Path-style addressing puts a bucket’s name in the request path instead of the host name. The isolated config and dummy values keep your regular AWS profile untouched; they don’t turn off the emulator’s own validation or license checks.

Check the setup by asking STS who you are:

aws --version
aws --endpoint-url "$VERA_ENDPOINT" sts get-caller-identity

These are the identity’s fields, under the example account:

Output

{
  "UserId": "AIDACKCEVSQ6C2EXAMPLE",
  "Account": "123456789012",
  "Arn": "arn:aws:iam::123456789012:user/emulator"
}

When you’ve finished, close the terminal and remove the scratch directory, with vera-aws-config in it. Don’t remove the config while a sequence still needs it. Each service page explains its resource cleanup and any state that remains; removing client files doesn’t remove emulator resources. To start the emulator itself afresh, see Running the emulator.

Client troubleshooting

• badly formed help string before a request is sent. A distribution’s build labeled 2.31.35, on Python 3.14.4, failed this way for some commands. It’s a client problem, not the emulator’s; the official package with its bundled Python didn’t show it.
• CloudWatch metrics or alarms fail with missing-parameter errors on a newer CLI. The official 2.39.5 sends CloudWatch requests over Smithy RPC v2 CBOR, and valid PutMetricData and PutMetricAlarm requests failed that way in testing of Vera 1.2.0 preview. Other tested calls on 2.39.5 worked, and so did ListMetrics. The CloudWatch page has a tested fallback.

Limits

The emulator stands in for AWS’s APIs, but it isn’t a perfect copy. Each service page lists the limits that most affect what you can test, and its API coverage notes smaller differences, operation by operation. These examples ran the image’s own startup, without optional engine settings, so they say nothing about configurations that weren’t run. A few limits apply across services:

• Responses aren’t execution. Vera serves AWS API requests locally, with limits each service page names. A successful create or status response doesn’t mean a VM, container, build, deployment, SQL query, encryption or network traffic ran.
• Some execution engines aren’t included. In Vera 1.2.2, creating or updating CloudFormation stacks and executing change sets, starting CodeBuild builds, starting Glue job runs and ECS RunTask return HTTP 501 NotIncluded, because the engine each needs isn’t in this release. In Vera 1.2.0-rc.3, running Athena queries and submitting Batch jobs returned the same. Not every operation that starts something is affected: DataSync task executions and CloudWatch Logs queries still answer as their pages describe.
• Some data behavior is real. S3 objects, DynamoDB items and streams, SQS messages, SNS and EventBridge delivery, Kinesis records, CloudWatch Logs events and Systems Manager parameters behaved as data in the examples run on Vera 1.2.2.
• IAM identities work, but authorization isn’t established. In Vera 1.2.2, IAM users, groups, roles and group memberships were created, read and deleted, and roles created this way worked with STS and in other services’ role settings. In the reviewed source, identity-based policy enforcement is off by default, and resource-policy checks, sessions and validation can behave separately. Full permission compatibility wasn’t established. The IAM page lists IAM’s own limits, such as reports that can’t be read back.
• One account and region. Most examples use one account and us-east-1, and only the regional checks their pages describe have evidence. Cross-account isolation, durability, quotas, scaling, timing and concurrency weren’t established. Resources don’t survive stopping and starting the emulator: in Vera 1.2.2, a resource created before a restart was gone after it (see Stop and start again).
• A license doesn’t fix a defect. A Pro license turns on the Pro services. It doesn’t add a missing engine, fix a runtime error or change a request protocol. No AWS account is needed, but activating a key can need a network connection.

Coverage statuses

Each service page lists every operation of its AWS API, A to Z, from AWS’s SDK model of it, and marks whether this release implements it. The counts under the page’s title are its counts, using the botocore 1.43.105 operation inventory. Known differences are counted once per operation, even when one operation has several notes. Availability combines the earlier implementation inventory with dated observations: checking a page’s example doesn’t verify every operation.

Each Known difference’s note names its evidence first: Recorded comparison, Local observation or Source inspection. A note that starts Unverified inference is a caution, not a confirmed difference, and its operation stays Implemented. Not verified means an operation’s current availability is unknown, and Failed in testing means it failed in the tested build its note names; neither counts as implemented. Operations that answered HTTP 501 NotIncluded, because their engine isn’t included, are marked Failed in testing, with the build their note names.

• Recorded comparison: an executed local request compared with a preserved AWS response. A comparison on an error covers only that error case, not a successful lifecycle.
• Local observation: behavior seen in a local request, with no paired AWS comparison. A note names its build and date: “Vera 1.2.2, 8 November 2026” for the current release, “Vera 1.2.0-rc.3, 6 November 2026” for the release candidate before it, or “Vera 1.2.0 preview, 5 November 2026” for the preview these docs were first written from. A note without a build or date, or one that names earlier testing, comes from earlier testing, on 3 November 2026.
• Source inspection: a limit found in the release’s source, not newly executed or compared with AWS. IAM’s operations that hadn’t been checked were assessed this way, from a review of the Vera 1.2.0 source on 6 November 2026; those notes say “Vera 1.2.0 source, 6 November 2026”. A run of a release build is a separate Local observation that names that build. Source inspection doesn’t mean an operation ran successfully in a release build.

• Implemented This release provides an API handler for the operation. Read the service limitations for its behavior and execution scope. This label describes API availability; it is not a claim that every request variant has been tested against AWS.
• Known difference The operation is available, with a documented behavioral limitation or difference. Its note identifies whether the finding comes from a recorded AWS-response comparison, local observation or source inspection. These operations count as implemented in the headline total.
• Not implemented No usable implementation of this operation was found: it's absent from this release's served-operation inventory, or, as its note says, it answers with a constant or a success without doing what it advertises.
• Failed in testing This operation failed in the tested build its note names, for the reason it gives; the source may still implement it. It isn't counted as implemented, and a license key doesn't change it.

Try a first requestSend a message to SQS and receive it back, step by step, with this setup.