Running the emulator

Once Vera is running, this is how to reach it, watch it, start it again and update it. Get started covers downloading and starting it, and Licenses and plans activating Pro.

Endpoints

The launcher, and the Free plan’s docker run command in Get started, publish each cloud at its own address on your machine:

Cloud	Address on your machine
Amazon Web Services (AWS)	`http://localhost:5003`
Google Cloud	`http://localhost:8081`
Microsoft Azure	`https://localhost:8543`

Use these from clients on the same machine as Docker. Inside another container, localhost means that container, not Vera.

VERA_ENDPOINT is a shell variable these docs’ commands read. Exporting it changes only the commands that use it, not where the emulator listens.

Other launcher ports

The launcher also publishes these ports, each on 127.0.0.1 only, for specific services. They’re the launcher’s mappings: the Free plan’s docker run command in Get started publishes only the three endpoints above.

Port	Purpose
`8544`	HTTP proxy for Azure data hostnames. It isn’t a replacement REST endpoint.
`15432`	Azure PostgreSQL over TLS. It isn’t Cloud SQL’s native database endpoint.
`10000`	Azure Redis over TLS.
`16443`–`16452`	GKE clusters’ Kubernetes API endpoints. Use the endpoint the cluster returns.

Status, logs and health

If you started the Free plan directly with Docker, skip vera status: the Docker commands work on their own.

./vera status
docker ps --filter name=vera
docker logs --tail 100 vera

./vera status
docker ps --filter name=vera
docker logs --tail 100 vera

.\vera.exe status
docker ps --filter name=vera
docker logs --tail 100 vera

vera status reports the container’s Docker state. It doesn’t show whether the emulator is ready or which plan is active. If an endpoint can’t be reached yet, the emulator is still starting: check the logs, wait, and try again. Then check access for the plan.

docker logs --follow vera keeps printing new lines; Ctrl+C stops following them, not the emulator. The image has a Docker health check every 15 seconds, with a 180-second startup grace period during which failed checks don’t count toward an unhealthy result; checks can pass before it ends. That’s how the image is set up, not a promise of how long startup takes.

A healthy container means its endpoints are answering. It doesn’t mean Pro is active, which the license status shows, or that every service works fully: each service page says what it covers and where it stops.

The launcher’s console

Without --detach, vera start follows the emulator’s console in your terminal. Ctrl+C stops following and leaves the emulator running, although the console’s banner says Ctrl+C stops Vera. vera logs (.\vera.exe logs in PowerShell) follows the console again. To stop the emulator, use vera stop, as in Stop and start again.

The commands in these docs add --detach, so start returns at once and the next command runs.

The CLI inside the container

The launcher is the vera file on your machine. The emulator’s image has a vera command of its own, which runs inside the container. Run it with docker exec, the same way in every terminal:

docker exec vera vera status
docker exec vera vera services
docker exec vera vera env gcp

env gcp prints commands that set up Google Cloud clients for the emulator. Printing them changes nothing in your shell: run the ones you want yourself, in a separate terminal kept for the emulator. For PowerShell commands, the account page’s form is docker exec vera vera env --shell powershell.

The commands env gcp prints select the emulator’s seeded project, vera-emulator. The examples in these docs set up their own project, example-project, and their own endpoint overrides, so follow each page’s setup when you run its example.

Stop and start again

Choose your system and CPU, AMD64 or ARM64 as in Get started, so start names the image you loaded:

AMD64
ARM64

./vera stop
./vera start vera:1.2.2-amd64 --detach

./vera stop
./vera start vera:1.2.2-arm64 --detach

AMD64
ARM64

./vera stop
./vera start vera:1.2.2-amd64 --detach

./vera stop
./vera start vera:1.2.2-arm64 --detach

AMD64
ARM64

.\vera.exe stop
.\vera.exe start vera:1.2.2-amd64 --detach

.\vera.exe stop
.\vera.exe start vera:1.2.2-arm64 --detach

stop removes the emulator’s container, and with it everything you created in the emulator. start, with the exact image tag, starts a fresh one, and --detach returns at once instead of following its console. The archive, the loaded image and the key the launcher installed are outside the container, so they stay. Use the launcher’s stop rather than docker stop vera, which leaves a launcher-started container in place.

Treat what you create in the emulator as disposable. Persistence varies by service, and this release has no documented way to keep or restore resources. For a fresh session, stop the emulator and start it again.

Started with docker run on the Free plan? Stop it with Docker. The --rm in Get started’s command removes the container too, so run the same command to start a new one:

docker stop vera

If you started it without --rm, stopping it keeps the container. Remove it with docker rm vera before you start again.

Update to a new release

Download the new release’s image from your Vera account, check its checksum and load it with docker load --input and its archive’s name, as in Get started. Note the tag docker load prints. On Pro or a trial, download and check the new release’s launcher too, as in Get started. Loading the image doesn’t change the emulator that’s running.
When you’re ready to lose what’s in the running emulator, stop it, then start the new release by its new tag:
- Started with the launcher (Pro or a trial): stop it with ./vera stop (.\vera.exe stop in PowerShell), then start the new tag with ./vera start (.\vera.exe start) and --detach, as in Stop and start again.
- Started with Docker (Free plan): stop it with docker stop vera, then run the Free plan’s docker run command with the new tag in place of the old one. Its --rm removes the stopped container; if you started it without --rm, remove the container with docker rm vera first.
Check access, and send a request you know works.

Nothing you created moves to the new release, and a new release can change the image tag, ports and services. These docs are written for Vera 1.2.2.

Docker options for the Free plan

When you start the Free plan with Docker, as in Get started, you can change its ports or start Google Cloud alone. The launcher has no options for ports or clouds, and Pro always starts with the launcher. These commands are for bash or zsh.

Use another host port

If a port is busy, change the host side of its mapping. For Google Cloud on port 18081, use this in place of its usual --publish line:

--publish 127.0.0.1:18081:8081

Then point your client there, and export any endpoint override again, since an override keeps the address it was exported with:

export VERA_ENDPOINT="http://localhost:18081"
export CLOUDSDK_API_ENDPOINT_OVERRIDES_COMPUTE="$VERA_ENDPOINT/"

Run Google Cloud alone

By default the emulator starts every cloud. To start only Google Cloud, add --cloud gcp after the image tag, and point Docker’s health check at Google Cloud’s endpoint, since the image’s own check also expects the other clouds:

AMD64
ARM64

docker run --detach --rm --name vera \
  --publish 127.0.0.1:8081:8081 \
  --health-cmd 'python -I -S -c "import urllib.request; urllib.request.urlopen(\"http://127.0.0.1:8081/health\", timeout=3).close()"' \
  vera:1.2.2-amd64 --cloud gcp

docker run --detach --rm --name vera \
  --publish 127.0.0.1:8081:8081 \
  --health-cmd 'python -I -S -c "import urllib.request; urllib.request.urlopen(\"http://127.0.0.1:8081/health\", timeout=3).close()"' \
  vera:1.2.2-arm64 --cloud gcp

Azure over HTTPS

Microsoft Azure’s endpoint, https://localhost:8543, uses a certificate the emulator generates. Fetch its certificate bundle from the emulator you just started, then use it for later requests:

curl --fail --silent --show-error --insecure \
  https://localhost:8543/_vera/ca.pem \
  --output vera-ca.pem

curl --fail --silent --show-error \
  --cacert vera-ca.pem \
  https://localhost:8543/_vera/health

curl --fail --silent --show-error --insecure \
  https://localhost:8543/_vera/ca.pem \
  --output vera-ca.pem

curl --fail --silent --show-error \
  --cacert vera-ca.pem \
  https://localhost:8543/_vera/health

curl.exe --fail --silent --show-error --insecure `
  https://localhost:8543/_vera/ca.pem `
  --output vera-ca.pem

curl.exe --fail --silent --show-error `
  --cacert vera-ca.pem `
  https://localhost:8543/_vera/health

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

--insecure is only for fetching the bundle from the emulator on your own machine; later requests check the certificate with --cacert. Don’t turn off certificate checks in general, or fetch a bundle this way from a server you don’t control. If checks start failing after you start a new emulator, fetch the bundle again, since the certificate may have changed.

Troubleshooting

Symptom	What to try
Docker can’t be reached	Start Docker, and check that `docker version` reaches it. On Windows, use Docker Desktop in Linux-container mode.
Docker can’t find the image, or tries to pull it	Load the archive, and use the exact tag `docker load` printed.
The launcher won’t run	Check that it’s the launcher for your system and CPU, that its checksum matches, and on Linux and macOS that you ran `chmod +x ./vera`.
macOS blocks the launcher as an unsigned download	Once its checksum matches and you’ve run `chmod +x ./vera`, remove the quarantine flag from that file only, with `xattr -d com.apple.quarantine ./vera`, then run it again. It’s a recovery step, needed only if macOS blocks the file. macOS wasn’t tested for these docs.
The terminal stays on the emulator’s console after `start`	`start` without `--detach` follows the console. Ctrl+C stops following and leaves the emulator running; `vera logs` follows it again.
A port is already allocated	Stop what’s using it. On the Free plan with Docker, you can also use another host port and point your client there.
The name `vera` is already in use	Look at that container first. If it’s a disposable emulator, stop it before starting a new one.
curl can’t connect while the emulator starts	Check `docker logs --tail 100 vera`, wait for the endpoint, and try again. `vera status` shows only the container’s Docker state, not whether the endpoints are ready.
`access` isn’t `full`, or a Pro service is denied	See Licenses and plans.
Azure answers with an HTTP or certificate error	Use its HTTPS endpoint and its certificate bundle. AWS and Google Cloud use HTTP.
Your client tries to sign in to the real cloud	Set up its dummy or disabled credentials and endpoint overrides again, in a terminal of their own.
A response names a real cloud’s hostname	It’s how the record is named. Keep sending requests to the emulator.
Resources are gone after a restart	Expected: see Stop and start again.

Get help

Your license key and its bound host are on your Vera account, where you can download the key again or replace it. For anything else, ask in Vera’s community Slack or use the contact page. Include:

the image tag, and your launcher’s platform, such as Linux AMD64
the output of docker ps --filter name=vera, which shows the container’s health
the error text, with anything private removed

Never send your license key or its contents, in a message or a screenshot.