hoophq/hoopcontrolplane, published in two flavours
that differ only in the rootfs underneath.
It is not the Gateway image with a different command. The Gateway image carries
the data plane’s dependencies — OCR for session-replay analysis, a set of
third-party database clients — and the Control Plane execs none of them. These
images are a stock rootfs plus the hoop binary, and nothing else.
Choosing a flavour
Both are multi-architecture manifests covering
linux/amd64 and linux/arm64.
Pin an explicit version in production rather than using latest.
Every version, its changelog and its release date are published on the hoophq/hoop releases page.
Image tags, chart versions and binary downloads all use the same version numbers.
How they differ
Both serve the whole API and the web app, run as uid
10001, and run tini as
PID 1. They differ in debuggability and nothing else: distroless has no package
manager and no shell, so it reports zero OS-package CVEs and cannot be opened
with kubectl exec.
Pick the default when you want to debug in place, -distroless when you want
that smaller surface. The Ubuntu flavour carries no suffix and latest points
at it, so the tag someone reaches for without thinking is the one they can get
a shell in.
What is set
Neither image needs a command or an argument to start the Control Plane.POSTGRES_DB_URI and API_URL are the only two variables the image needs. See
Environment Variables for the rest, and
Kubernetes for the Helm chart that sets
them for you.
Building your own
The Dockerfile isDockerfile.controlplane in hoophq/hoop.
It builds from the published release tarball rather than from source, so it needs no Go toolchain and no credentials:
--target produces default, the same flavour the unsuffixed
tag and latest point at — so an accidental default is never the restrictive
one.
Next
Kubernetes
The Helm chart, which picks the flavour with
image.tag.Docker Compose
Postgres and the Control Plane on a single host.