Skip to content
Docs
GitHub

Deployment preparation

Applies toAlpha

This guide deploys a shared OpenRUM Instance with Kubernetes and Helm, the recommended production path. You need access to the cluster, domain and data services, but not the OpenRUM source code: the Helm chart and the application image are published. If you have one Linux server instead, follow the separate single-host Docker production guide. For an initial local experience, use Local development.

How it fits together

Section titled “How it fits together”
Monitored browser → HTTPS /ingest → Ingest → Kafka → Consumer → ClickHouse
Operator browser  → HTTPS /       → Console
Console           → HTTPS /api    → API → PostgreSQL / ClickHouse / Redis
Worker            → Background jobs, alerts, optional Source Map object storage

The Helm chart deploys five application services, a migration job and, by default, a single Redis. Prepare the databases, Kafka, TLS certificates and the runtime Secret separately; the chart does not create them. Decide now who maintains the cluster and each data service, and which public domain the Instance will use.

Requirements

Section titled “Requirements”

Check every row before you start. The ClickHouse row is the one most often missed.

What What you need Notes
Kubernetes 1.28 or later Permission to create Namespaces, Deployments, Services and Jobs
Helm and kubectl Installed locally and connected to the cluster Used for the install and the checks
Ingress and HTTPS An Ingress controller, a domain such as rum.example.com pointing at it, and a certificate that covers it Production requires HTTPS
PostgreSQL A database and an account that can run schema migrations Control-plane data
ClickHouse A cluster definition. Migrations use ON CLUSTER openrum_cluster and replicated tables, so you need Keeper or ZooKeeper and shard and replica macros A database alone is not enough; see step 2
Kafka At least three Brokers for the example topics below, with topic auto-creation not relied on You create the topics yourself in step 3
Redis Optional The chart runs a single Redis by default; use your own for high availability
Image access Nodes that can pull from ghcr.io The image is public. You only need your own registry to mirror it or run modified source
Capacity Persistent storage, backups and capacity alerts sized for the expected traffic See capacity planning

Prefer managed or highly available services your team already operates, and verify ports, authentication and protocol compatibility with the current OpenRUM configuration before choosing a provider. See the configuration reference for connection options.

  1. Check access to the cluster

    Section titled “Check access to the cluster”
    Terminal window
    kubectl version
    helm version
    kubectl get nodes
    kubectl create namespace openrum

    Skip the last command if the Namespace exists.

    Success: Nodes are visible, the Namespace exists, and the domain’s DNS and certificate are ready for the Ingress.

  2. Prepare databases

    Section titled “Prepare databases”

    Ask the database owner to create separate OpenRUM databases and accounts. PostgreSQL and ClickHouse accounts must be able to execute initial and subsequent schema migrations.

    Success: Both databases accept connections from the cluster, and the ClickHouse cluster definition works.

  3. Create the Kafka topics

    Section titled “Create the Kafka topics”

    Automatic Kafka topic creation is disabled. Create both rum-events-v1 and rum-events-v1.dlq. This example requires at least three Brokers; size partition counts for your workload:

    Terminal window
    kafka-topics.sh --bootstrap-server kafka-0:9092 --create --if-not-exists \
      --topic rum-events-v1 --partitions 12 --replication-factor 3 \
      --config min.insync.replicas=2 --config retention.ms=604800000
    kafka-topics.sh --bootstrap-server kafka-0:9092 --create --if-not-exists \
      --topic rum-events-v1.dlq --partitions 12 --replication-factor 3 \
      --config min.insync.replicas=2 --config retention.ms=604800000
    kafka-topics.sh --bootstrap-server kafka-0:9092 --topic rum-events-v1 --describe

    Run these where Kafka administration tools and Broker access are available. Replace the address and supply any required administrative authentication configuration. This example retains seven days; the later kafkaRetentionDuration must match actual retention. Check existing topics explicitly: --if-not-exists does not update their configuration.

    Success: Both Kafka topics exist and have healthy replicas, and all data services are reachable from the cluster.

Next: Install servicesCreate the credentials and HTTPS, then install the published Helm chart.

Release Alpha · commit local