After the first run

Audience: operator · Profile: both · Read this when: the dashboard is running and you need to scale the worker, change credentials, or protect the JWT key.

Part of the Onboarding Guide. The things you do once the dashboard is up and serving.

Scaling the job worker

Long jobs — Kubernetes and cloud-database provisions, Packer image builds, and image export/promote — run in the dedicated worker container, not the web app. Each worker runs one such job at a time, so if quick jobs pile up behind a long one (e.g. an export waiting on a 25-minute cluster provision), run more workers. The job queue claims each job atomically, so extra workers never double-run a job.

The stack starts 3 workers by default (the onboard scripts migrate installs still pinned at the old default of 1). Change the count in .env, then bring the stack up as usual:

WORKER_REPLICAS=5          # in .env — number of long jobs that can run at once
./scripts/onboard.sh       # (keep --hub if you used it)

Or scale ad-hoc without editing .env:

docker compose up -d --scale worker=5          # add -f docker-compose.hub.yml if you used --hub

WORKER_CPU_LIMIT / WORKER_MEM_LIMIT (also in .env) cap each worker's CPU and memory so several concurrent heavy jobs can't exhaust the host — tune them to your machine. Defaults: 3 workers, 2 CPUs and 2 GB each (3 busy workers can use up to ~3× those limits, so lower WORKER_REPLICAS on small hosts).

Reconfiguring credentials after first run

To update credentials or toggle feature flags after setup, navigate to /setup in your browser while logged in as admin. The wizard reopens in reconfigure mode: existing values are pre-filled, and leaving a secret field blank keeps the stored value unchanged.

Every page is reached from the navigation menu, the ☰ button at the right of the top bar. Dashboard (and, on a POV instance, POV and Templates) sit at the top; everything else is in collapsible groups that follow the tabs of Settings → Integrations:

Group	Pages
Hypervisors	Workstation, Proxmox, vSphere, Hyper-V, Nutanix, XCP-ng, Connections
Clouds	AWS, Azure, GCP, OCI
Cloud services	Containers, Databases, Kubernetes, Functions
Preview	Desktops, Directories, Workload Lab
Operations	Images, Storage, Costs, Configuration, Use cases, Inventory, Jobs, Schedules
Admin	Agents, Health, Audit, Notifications, Secrets, RBAC, Request access

A page appears only when its integration is switched on and you hold the permission it needs, and a group with nothing in it for you is not shown at all. Groups start collapsed; the group holding the page you are on opens by itself, and your browser remembers which other groups you left open. A focus chosen on the Dashboard still pins its shortlist of pages above the groups.

Which version am I running?

Open the navigation menu and choose About, at the bottom under Settings and Logout. It shows the release (for example 26.10.42, the image tag without its v), the commit it was built from, when it was built, and the API version. Signed-in API clients can read the same thing from GET /api/about; unlike /api/health it needs a token, so an anonymous caller cannot learn the exact release.

An image built by hand without --build-arg APP_VERSION=… shows dev. Run from a git checkout, it shows the nearest release tag in git describe form — 26.10.42-3-g9e6f7f4 is three commits past 26.10.42, and -dirty means uncommitted changes.

Protect and back up the JWT key

.jwt_secret_key is the root of trust for the entire application — every integration credential stored in the database is encrypted with a key derived from it. The onboard script protects it with owner-only filesystem permissions and mounts it into the container as a Docker secret.

In the community edition this key cannot be migrated to a cloud vault. It's the bootstrap key that decrypts the encrypted database — including the credentials the dashboard would need to reach any vault — so there's no startup ordering that lets it live in a vault (see Why the JWT root key cannot be migrated). At startup the dashboard reads it from JWT_SECRET_KEY_FILE → the /run/secrets/jwt_key Docker secret → the JWT_SECRET_KEY env var, in that order.

So, for the community edition:

Back it up somewhere safe (password manager, encrypted drive). Lose it and every stored credential is unrecoverable and the app won't start — see JWT key file: backup and loss recovery below.
Don't commit it — it's gitignored and excluded from the image build context.
On shared or long-lived hosts, restrict OS access to the file; the host's filesystem permissions (or the Docker secret mount) are the security boundary.

Integration credentials (your AWS/Azure/GCP keys) can be moved into an external vault — AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, or BeyondTrust Secrets Safe — from Settings → Secrets Backend (/secrets). That's a separate feature from the root key; see docs/admin/secrets-management.md. Removing the on-disk root key entirely (fetched at boot via cloud workload identity) is on the SaaS-edition roadmap — see docs/editions/comparison.md. That roadmap item is the root key only: the cloud keys themselves can already go, replaced by the dashboard's own workload identity, which is the recommended setup — see Workload identity.

Platform notes