Self-hosting

OpenRUM runs on infrastructure you control. Both production paths are available in Alpha, without an uptime guarantee. Choose one first; the setup and the operating responsibilities differ.

Choose a deployment path

Kubernetes / Helm · RecommendedRun the application services on a cluster you operate, with PostgreSQL, ClickHouse and Kafka that you provide.

Docker · Single hostRun the complete stack on one Linux server, with automatic HTTPS, backups and a single failure boundary.

	Kubernetes / Helm	Docker (single host)
Best for	A shared Instance for a team that already runs a cluster and managed data services	One Linux server, a small team, or real traffic on a small budget
You provide	Cluster, Ingress and HTTPS, PostgreSQL, ClickHouse (clustered), Kafka, optionally Redis	A Linux host with Docker, and a domain that points at it
Data services	Yours, outside the chart	Bundled in the stack, on the same host
Failure boundary	Your cluster and your data services	The one host and its disk: a lost host needs a restore
Image and chart	Published: pull the chart and the image, build nothing	You build the image from a checkout of a release tag
Start with	Deployment preparation	Single-host Docker production

What is released

The current release is 0.1.2. The application image ghcr.io/open-rum/openrum:0.1.2 (for linux/amd64 and linux/arm64) and the Helm chart oci://ghcr.io/open-rum/charts/openrum at version 0.1.2 are public. The Docker path builds the same release from a checkout of its tag. Release notes are on GitHub Releases.

Not for real traffic

The Compose stack used for local development includes Demo data and example credentials. Never expose it to real traffic; use one of the two production paths above.

If you want to change OpenRUM’s source code or try it from a checkout, follow Local development instead.

What you operate

Self-hosting means your team owns the domain and HTTPS, credentials, capacity, service health, upgrades, and recovery. Start with the architecture and external dependencies.

Before accepting real traffic:

• Size the Instance with capacity and retention.
• Set up backups and complete a tested restore before the first upgrade.
• Read the threat model before exposing Ingest to the internet.
• Configure Console authentication if you want Google, GitHub, OIDC or LDAP sign-in.

While it runs:

• Plan upgrades and read how to handle storage pressure.
• Keep troubleshooting at hand.

Object storage is optional. Core monitoring runs without a Bucket; Source Map Artifacts require Alibaba OSS or an S3-compatible provider.