Docker deployment overview

Broka runs as four containers: the console you open, the two services behind it, and a PostgreSQL database. There is no message broker in this stack — Broka is a console for brokers, and you point it at your own clusters after it is running.

What runs

Service	Image	What it does	Published
ui	broka-ui:1.0.0	Serves the console and proxies /api to the orchestrator on the same origin. nginx lives inside this image — you do not run a separate one.	Yes — the only published port, 3000 → 8080
orchestrator	broka-orchestrator:1.0.0	The API: accounts, roles, environments, the connection registry, the audit trail. Applies database migrations at startup.	No
broker	broka-broker:1.0.0	Talks to your Kafka — and, in Commercial, Redis, RabbitMQ, Apache Artemis (formerly ActiveMQ Artemis) and Memcached. One container serves every platform — a commercial installation does not run five.	No
postgres	postgres:17	Stores everything Broka owns: users, connections, saved views, the audit trail.	No

Nothing but the UI is reachable from outside the Compose network. The orchestrator and the broker service talk to each other by service name, and PostgreSQL is not published at all.

Startup order, and why it matters

Compose starts these in a fixed order, each waiting for the one before it to report healthy:

postgres  →  orchestrator  →  broker
                          →  ui

The orchestrator owns the database schema and applies its migrations while it starts, so it has to be the first application service up. The broker service waits on the orchestrator, not on PostgreSQL: a healthy but empty database would let it start against tables that do not exist yet. When the orchestrator answers its health check, the migrations have already run.

One volume, one port, five secrets

• Volume — pgdata holds the PostgreSQL data directory. It is the only state; the three application containers are replaceable.
• Port — BROKA_HTTP_PORT (default 3000) is the only port Broka publishes.
• Secrets — five values you generate once, at install time. The images ship no defaults for them: an unset value stops the container at startup and names the variable, rather than booting with a publicly known key.

One of them deserves its own sentence, and gets a full warning on the install page:

BROKA_KEK encrypts every broker credential you save. Replace it on an installation that already has connections and those secrets become permanently unrecoverable — with no error at startup and no warning in the console. Back up this file as carefully as you back up the database; one without the other is useless.

BROKA_KEK, BROKA_KEK_ID and BROKA_SERVICE_TOKEN are read by both the orchestrator and the broker service and must be byte-identical in both. A single .env value feeds both spellings for exactly this reason.

Editions are in the images

All three BROKA images come in a Community and a Commercial build. The difference is inside the images, not in a setting. A Community broker build does not contain the Redis, RabbitMQ, Artemis or Memcached modules at all, which you can verify for yourself rather than take on trust:

docker run --rm --entrypoint sh <broker image> -c 'ls lib/ | grep -iE "redis|rabbit|artemis|memcached"'

Empty on Community, populated on Commercial.

Commercial is installed from the customer portal, where an organisation with a subscription finds its images, its credential and the installation guides. A commercial installation is then activated in the console — online with a code from the portal, or offline with a request the console generates, which you send to us and we answer with a licence to paste. Activation decides how long the commercial platforms keep accepting writes; it never decides what the image contains.

What this stack deliberately does not include

• No message broker. You connect Broka to the clusters you already run.
• No TLS. nginx inside the UI image listens on plain HTTP. Terminate TLS in front of it — a load balancer, an ingress, or a host-level reverse proxy holding the certificate.
• No clustering. The orchestrator runs as a single replica by design: it is request-driven and applies migrations at startup. Recovery is "restart and continue", not a hot standby.
• No Kubernetes manifests or Helm chart yet. The supported deployment today is Docker Compose. A Helm chart and a Linux package for Commercial are due at the Commercial opening; Community ships as images and Compose only.

Requirements

Docker Engine	24.0 or newer, with the Compose plugin
Architecture	linux/amd64. Apple Silicon runs it under emulation; it is not a supported architecture.
Sizing	Memory: 4 GiB for the broker service, which the compose file sets, plus well under 1 GiB for the other three containers. CPU: (pending measurement)
Outbound access	Not required by Community, which needs no activation of any kind. A Commercial installation's requirements are in its guide in the customer portal; a licence activated offline needs no outbound path at all.

Next

• Install with Docker Compose — the file, the secrets and first-run setup.
• Configuration reference — every variable, and what happens when one is missing.
• Networking and TLS — putting a reverse proxy in front.