Try it locally
Run the control plane, console and a fake fleet on a laptop with just, and try the hgr CLI offline.
This takes you from a fresh checkout to a running control plane, the web console and three fake clusters. It does not serve a model. The fake clusters have no GPUs, and serving a real model needs a cluster with NVIDIA GPUs and the Dynamo platform. For that, start at Self-hosting.
Prerequisites
| Tool | Used for |
|---|---|
just | Task runner behind every step below |
| Docker | Postgres and the plane (API and hub) |
uv | Python environments |
pnpm | The console |
| Go | The hgr CLI and the other Go components (the modules require Go 1.26) |
| Python 3.12 | The plane and the dev scripts |
kind, kubectl and helm are only needed for the cluster recipes, which Local development covers. Run just on its own to list every recipe.
Run it
Install dependencies
just setup
Installs the console packages, Python virtualenvs and Go modules. It takes a few minutes on a fresh checkout.
Start the stack
just dev
Starts Postgres, migrations, the API and the hub in Docker Compose, then the console dev server in the foreground.
| Process | Address |
|---|---|
| API | http://localhost:8000 |
| Hub | ws://localhost:8001/v1/hub/sync |
| Console | http://localhost:5273 |
| Postgres | localhost:5442 (hangar/hangar) |
Seed tenants
In another terminal:
just seed
Creates the example tenants Acme and Globex over the API. Running it again leaves existing objects alone.
Start the fake fleet
In a third terminal:
just fleet
Starts one fake operator per cluster. Each waits for a cluster of its name to be registered, then connects to the hub and reports its hardware. Leave it running.
Open the console
Go to http://localhost:5273. Register the fake clusters from the console and they appear as reachable, with nodes and devices. Or run just seed --demo, which registers them for you and adds pools, quotas, workloads and an endpoint. It waits for the fleet to connect, so just fleet must be running.
The stack runs with HANGAR_APP_ENV=local, which turns admin authentication off. Anyone who can reach the API is an administrator. Use it on a laptop only and do not publish its ports.
The fake fleet
| Cluster | Hardware |
|---|---|
eu-west-1a | 2 nodes with 8 H100 SXM each, 1 node with 4 L40S |
us-east-2b | 2 nodes with 8 H200 SXM each |
lab-1 | 1 node with 4 A100 PCIe, 1 node with 4 RTX 6000 Ada |
The fake operators answer a declared deployment with replicas that go ready after a few seconds, so you can watch a workload move through placement. They render nothing and run no model.
Try the CLI offline
The hgr CLI has a built-in fake backend, so you can explore it with no plane running.
cd libs/cli
go build -o bin/hgr ./cmd/hgr
./bin/hgr --fake cluster ls
./bin/hgr --fake workload ls
./bin/hgr --fake deployment ls
To point it at your local plane instead:
./bin/hgr config set context.server http://localhost:8000
./bin/hgr cluster ls
Commands and output modes are in the hgr CLI reference.
Stop and reset
| Command | What it does |
|---|---|
just dev-down | Stop the stack and keep the data volume |
just reseed | Drop the database, migrate from scratch and seed |
just logs | Follow the API and hub logs |
What is not in the local stack
- The gateway. It needs a routing table from the plane, so it belongs to a real installation. See Gateway.
- A real operator and GPUs. Running the operator against a kind cluster, the test recipes and the compose internals are in Local development.