Running your own Hub

Everything behind Pantacor Hub is open source, and the pantahub-base repository ships two ready-made ways to deploy the whole cluster — the API plus every backing service it needs:

• Docker Compose — docker compose up on a single machine. The fastest way to a full local Hub.
• Helm chart — the same stack translated to Kubernetes (charts/pantahub in the repo), for k3s/k3d, minikube, kind or a shared dev cluster.

Both describe the same set of services with the same names and ports, so everything you learn about one applies to the other.

Development first — real devices need a domain

Out of the box, both setups are development environments: you get the full stack and can drive it with the web UI, the API and the pvr CLI — but real Pantavisor devices cannot connect to them. Devices speak strict TLS and verify the server certificate against their built-in trust store, and a Hub reachable only on localhost, plain HTTP, or a self-signed certificate fails that check. To onboard actual hardware, deploy the Helm chart on a public domain with Let's Encrypt and build device images for it. In development, simulate devices instead with pantavisor-mocker.

What the cluster is made of

In words: base is the API everything talks to — the web UI (www), devices, and the pvr CLI. It keeps records in a MongoDB replica set, stores objects in S3 (localstack in dev), and ships logs through fluentd into elasticsearch. The kafka pipeline tails mongo with Debezium and lets phs build the device-summary views the UI's device list reads. gc and the cronjobs clean up unclaimed devices and unreferenced objects, and nginx terminates TLS — including the client certificates that TLS onboarding verifies.

Which one should I use?

	Docker Compose	Helm chart
Good for	Local development, trying the stack	Dev/test Kubernetes clusters, teams
Machine	One host, Docker, ~8 GB RAM free	Any k8s with ~6 GB free + a StorageClass
Config	.env.local on top of env.default	env: block in your values file
Source hacking	Mounts the repo, hot-reloads base	Deploys built images by tag
Real devices	No — development only	Only with a public domain + TLS

Either way, read the security note before exposing anything: both setups ship well-known development JWT/JWE keys in env.default / values.yaml, and in dev mode (no PANTAHUB_PRODUCTION) the built-in demo accounts are open with their defaults — admin/admin included. That's what makes the stack work out of the box; for any deployment other people can reach, replace the keys and switch to production mode with explicit demo-account passwords.

Simulating devices in development

Real hardware can't join a development deployment, but pantavisor-mocker can stand in for it: it simulates a Pantavisor device end to end — registration with an auto-join token, metadata sync, the full OTA update lifecycle with rollback, and log upload — against any Hub you point it at:

pantavisor-mocker init --storage dev-device-1 \
  --host localhost --port 12365 --token <auto-join token>
pantavisor-mocker start --storage dev-device-1 --auto

Run one storage directory per simulated device to fake a whole fleet. The full walkthrough is in Docker Compose § Simulating devices.

Going further

• Serve the cluster on your own domain with Let's Encrypt TLS — Kubernetes (Helm) § Going public.
• Build device images that talk to your Hub instead of api.pantahub.com — Devices for your own Hub.