Demo Environment

The demo is maintained in hegemony-demo-data. Its setup and operations guide covers installation, accounts, lifecycle commands, and troubleshooting.

The demo repository owns its Compose overlays, environment defaults, Keycloak identities, NetBox and external Vault seeders, plugin wheel pins, and E2E workflow. It reuses this repository's shared application services and container images. The task compose:demo:* commands, the compose:*:demo admin consoles and the task vault:up, task vault:down, task vault:logs, task vault:status and task vault:reset commands for the demo's secondary external Vault all forward to the sibling demo checkout: each runs the same-named task there and passes any -- arguments through. The checkout is expected at ../hegemony-demo-data, beside this repository; set HEGEMONY_DEMO_DATA_DIR to use one elsewhere. A forward whose checkout is missing stops with the clone command instead of running anything. The platform registry console, task compose:registry:ui:dev and task compose:registry:ui:prod, has no :demo form: the demo repository owns the demo stack's overlays, and this repository's deploy/compose/docker-compose.registry.yml is not among them.

The demo was the first stack to run flow containers in the Docker-in-Docker sandbox (deploy/compose/docker-compose.dind.yml); every dev and prod stack now does too, because the compose tasks apply that file to every stack. A demo and a dev or prod stack on the same host therefore each run their own sandbox on their own network, and the subnets must not overlap: by convention 172.28.102.0/24 for the demo, 172.28.100.0/24 for dev and 172.28.101.0/24 for prod. SERVICES=...,dind is still accepted, as a deprecated name that changes nothing.

Production authentication imports only application clients and roles, with no sample users or organization groups. Provision production users and assign their roles through your identity provider. See production hardening.