Using the emulator

Endpoint and certificate

Start Vera as in Get started. Microsoft Azure’s APIs are then served over HTTPS from https://localhost:8543, with a certificate the emulator generates for itself. Fetch that certificate once from your own emulator, as in Azure over HTTPS, and give it to every later request, so each one checks TLS:

export VERA_CA_CERT="$PWD/vera-ca.pem"
curl --fail --silent --show-error --noproxy '*' --insecure \
https://localhost:8543/_vera/ca.pem --output "$VERA_CA_CERT"
curl --fail --silent --show-error --noproxy '*' \
--cacert "$VERA_CA_CERT" https://localhost:8543/_vera/health

Output

{ "cloud": "azure", "generation_status": "generated", "status": "ok" }

--insecure is only for that first download from the emulator on your own machine. Don’t keep it, turn off certificate checks in general or add the certificate to your system’s trust store. If you recreate the emulator and its certificate changes, fetch it again. It’s a public certificate, separate from your license key.

Subscription, tenant and token

The emulator has one local subscription and tenant, and accepts a dummy bearer token. Every Azure example in these docs uses these values:

Setting	Value
Subscription	00000000-0000-0000-0000-000000000001
Tenant	00000000-0000-0000-0000-0000000000a1
Bearer token	vera-local

The token is a dummy Azure credential, not your Vera license key, and no Azure account is needed. Resource IDs such as /subscriptions/…/resourceGroups/… are paths added to the emulator’s address, not hosts or links.

Plans

Azure’s plans are set per API, not per service. In Vera 1.2.2, the APIs marked Free run on the Free plan, with no license key. Pro includes them and turns on the APIs marked Pro: activate your license key and start the emulator with the Vera launcher, as in Activate Pro.

A service can include APIs on both plans. Storage, Key Vault, Microsoft Entra ID and Azure Monitor each do: they’re badged Free, and the line under each title, and each API in the page’s coverage, say which APIs need Pro. The examples were replayed on Vera 1.2.2 with full access, so not every example is a Free-plan example.

API versions

Each management request names an api-version, and there’s no single version every Azure API accepts. Each service page’s examples use the versions they were checked with on Vera 1.2.2; another version can be rejected. Without an api-version, a request answered 400 MissingApiVersionParameter; with an invalid one, 400 InvalidApiVersionParameter; and without the bearer token, 401 AuthenticationFailed.

Microsoft Graph requests (Microsoft Entra ID) use /v1.0/… paths instead, and the Storage data APIs send an x-ms-version header. The service pages show each one.

Data host names

Data APIs, such as Blob, Key Vault secrets or AI Search documents, are reached at a host name for the resource, under .localhost, on the same port. A storage account’s blob service is azdatastore.blob.core.localhost:8543, for example. curl’s --resolve sends the request to your own machine while keeping that host name for routing and for checking the certificate, so it works even where .localhost names don’t resolve:

curl --noproxy '*' --cacert "$VERA_CA_CERT" \
  --resolve 'azdatastore.blob.core.localhost:8543:127.0.0.1' \
  -H 'Authorization: Bearer vera-local' \
  -H 'x-ms-version: 2026-12-06' \
  'https://azdatastore.blob.core.localhost:8543/azdata?restype=container&comp=list'

That request lists the blobs of a container the Storage example creates. Don’t put Azure-looking URLs, connection strings or kubeconfigs from a response into a command: some point at public Azure hosts. Use the local routes each service page shows.

The Vera launcher also publishes an HTTP proxy for Azure data host names on port 8544, bound to 127.0.0.1. It isn’t a replacement for the endpoint on port 8543, and the examples don’t use it: they keep --resolve.

Request helpers

Each service page’s setup fetches the certificate and defines a small Bash helper for its commands: arm for compute and networking, data_request and data_arm for storage, databases, secrets, configuration and search, and azmsg_request for messaging, identity, monitoring and workflows. Each one sends the dummy token, checks TLS with the certificate, follows long-running operations and refuses any address other than the emulator’s on port 8543, so a returned Azure URL can’t send a request to Azure.

They need Bash, curl and Python 3, and some pages also use jq. On macOS, whose terminal starts zsh, type bash first; the Bash that comes with macOS is fine. The helpers expect the emulator on its default port, 8543.

arm prints the response once its operation has finished. When the response has no body, as with a virtual machine’s RunCommand, it prints the finished operation’s response instead. A finished operation isn’t a successful action: arm succeeds once the operation ends, so read the result it prints.

Long-running operations

A create, update or delete can answer HTTP 200, 201 or 202 while the change is still running. The response’s Azure-AsyncOperation or Location header names an operation to poll until it succeeds or fails; a finished operation can also answer 200 or 204 with an empty body. Then read the resource for its final state. In testing of Vera 1.2.0 preview, creating a child resource before its parent had finished gave 404 and 409 answers. Waiting a fixed time isn’t a substitute for polling: the helpers poll for you.

Azure CLI

The Azure CLI 2.92.0 was checked on Vera 1.2.2 too. It registered the emulator as a cloud of its own, signed in with a local service principal, found the local subscription, and created, read and updated a resource group. Run it with a configuration folder of its own, so your own Azure CLI profile isn’t touched, after fetching the certificate as above:

export SUB='00000000-0000-0000-0000-000000000001'
export TENANT='00000000-0000-0000-0000-0000000000a1'
export VERA_AZ_CONFIG_DIR="$(mktemp -d)"
export AZURE_CONFIG_DIR="$VERA_AZ_CONFIG_DIR"
export REQUESTS_CA_BUNDLE="$VERA_CA_CERT"
export NO_PROXY='localhost,127.0.0.1'

az cloud register --name VeraLocal \
  --endpoint-resource-manager https://localhost:8543/
az cloud set --name VeraLocal
az config set core.instance_discovery=false core.collect_telemetry=false
az login --service-principal \
  --username vera-local-client --password vera-local \
  --tenant "$TENANT" --allow-no-subscriptions
az account set --subscription "$SUB"
az rest --method get \
  --url 'https://localhost:8543/subscriptions?api-version=2022-12-01'

az group create --name vera-cli-example --location eastus --tags purpose=docs
az group show --name vera-cli-example
az group update --name vera-cli-example --set tags.phase=updated

The emulator accepts the dummy service principal. Instance discovery is off only in this configuration folder, so signing in stays local, and TLS is still checked. Don’t run an ordinary az login to a real tenant for these examples.

Only these commands were checked: others choose their own API versions or call data hosts, and may not work. Don’t use az group delete: it failed in Vera 1.2.0 preview, and on Vera 1.2.2 deleting a group through the REST API still fails, as deleting resource groups explains. The CLI’s deletion wasn’t rerun. When you’ve finished, rm -rf "$VERA_AZ_CONFIG_DIR" removes the CLI’s configuration folder; it doesn’t remove anything from the emulator.

Python SDK

On Vera 1.2.2, azure-mgmt-resource 24.0.0 created a resource group, read it and checked that it exists. Use a virtual environment of its own, and a credential that returns the dummy token: DefaultAzureCredential could pick up real Azure credentials.

python3 -m venv vera-sdk
. vera-sdk/bin/activate
pip install azure-mgmt-resource==24.0.0
cat > vera_sdk.py <<'PY'
import os
import time
from azure.core.credentials import AccessToken
from azure.mgmt.resource import ResourceManagementClient

class LocalCredential:
    def get_token(self, *scopes, **kwargs):
        return AccessToken("vera-local", int(time.time()) + 3600)

with ResourceManagementClient(
    LocalCredential(),
    "00000000-0000-0000-0000-000000000001",
    base_url="https://localhost:8543",
    connection_verify=os.environ["VERA_CA_CERT"],
    retry_total=0,
    polling_interval=1,
) as client:
    group = client.resource_groups.create_or_update(
        "vera-sdk-example", {"location": "eastus", "tags": {"purpose": "docs"}}
    )
    print(group.name, group.location)
    print(client.resource_groups.get("vera-sdk-example").name)
    print(client.resource_groups.check_existence("vera-sdk-example"))
PY
python vera_sdk.py

Output

vera-sdk-example eastus
vera-sdk-example
True

That checks those resource group calls, not every SDK. Deleting the group with the SDK failed in Vera 1.2.0 preview too, and wasn’t rerun on Vera 1.2.2, where deleting a group through the REST API still fails.

Limits

The emulator stands in for Azure’s APIs, but it isn’t a copy of Azure. Each service page lists the limits that most affect what you can test, and its API coverage notes the rest, operation by operation. A few apply across services:

• Responses aren’t execution. A virtual machine, container app, database server or gateway is a record of its settings: a create or a healthy status doesn’t mean a guest OS, container, SQL engine, Kubernetes API, gateway, DNS server or network traffic ran. Each page says what was actually seen working, such as Blob bytes read back, Event Grid deliveries, Log Analytics queries, or SQL and Redis commands on the local PostgreSQL and Redis engines.
• Deleting resource groups fails in Vera 1.2.2. It fails for an empty group too. The DELETE returns HTTP 202, but its operation returns HTTP 500 InternalServerError, and the group remains in Deleting. Each service page deletes its own resources individually and leaves their resource group; recreating the emulator clears its local state, as in Stop and start again. See deleting resource groups.
• Returned URLs aren’t always local. Some fields, such as an API Management gateway URL or an Event Grid namespace host name, keep public Azure host names. Don’t follow them.
• Some data APIs aren’t served. On Vera 1.2.0-rc.3, the data requests tested on App Service, Functions, Cosmos DB, Service Bus and Event Hubs answered HTTP 501 DataPlaneNotEmulated: those resources are managed through Resource Manager only. Each page says which requests were tested.
• Messaging and most database protocols weren’t checked. AMQP, Kafka and database wire protocols weren’t tested on Vera 1.2.0 preview or Vera 1.2.0-rc.3. On Vera 1.2.2, psql ran SQL on the local PostgreSQL engine and redis-cli ran commands on the local Redis engine, both over TLS: see Database for PostgreSQL and Managed Redis. The pages say what was tested.
• Nothing was compared with Azure. The examples ran against the emulator only, in one subscription and tenant, mostly in eastus. Behavior that matches Azure, persistence after a restart, quotas, scaling and timing weren’t established.
• A license doesn’t fix a defect. Pro turns on the Pro APIs. It doesn’t repair a failing operation or add a missing engine.

Coverage statuses

Each service page lists every operation of the API surfaces it covers, from Microsoft’s pinned public API definitions, and marks each one. Only the APIs in this release are listed, each operation once. The counts under the page’s title cover all its APIs together, and the list shows each API with its version and plan.

The coverage comes from four checks, and each note names its evidence:

• Vera 1.2.0 preview, 5 November 2026. A few operations were checked with local requests. A Local observation without a build or date is from this testing.
• A source review, 6 November 2026. The remaining operations were assessed by a review of the Vera 1.2.0 source, which found whether the release implements each one locally, and its known limits. Its notes are marked Source inspection, sometimes with a test request against the reviewed source. A source review doesn’t mean every operation or API version was tested with a request.
• Vera 1.2.0-rc.3, 6 November 2026. Every service page’s example was replayed on this build, and a few operations were checked again. Those observations are marked Local observation: Vera 1.2.0-rc.3, 6 November 2026. An example that passed doesn’t mean the rest of its page’s coverage was run.
• Vera 1.2.2, 8 November 2026. Every service page’s example, Resource Manager’s example, the first request, and the Azure CLI and Python SDK examples were replayed on this build. A few behaviors were also checked: SQL on the local PostgreSQL engine, commands on the local Redis engine, and resource group deletion. Those observations are marked Local observation: Vera 1.2.2, 8 November 2026. As before, an example that passed doesn’t mean the rest of its page’s coverage was run.

No response was compared with Azure’s.

• Implemented Vera 1.2.0 implements this operation locally: a local request succeeded, or a review of the release's source found an implementation, as its note says. It doesn't mean every request variant or API version works, or that the response matches Azure's.
• Known difference The operation works locally, with the restriction or difference its note describes. These operations count as implemented.
• Not implemented Vera 1.2.0 has no working path for this operation: every request to it is refused, as its note says. It isn't counted as implemented, and a license key doesn't change it.
• Failed in testing A request to this operation failed in testing, for the reason its note gives. It isn't counted as implemented, and a license key doesn't change it.

Try a first requestList the emulator's subscription over local HTTPS, step by step.