Skip to main content
This page is intended for integrators who install Popsink in their own Kubernetes cluster. The chart deploys a self-hosted Popsink data plane — the runtime that moves data from your sources to your targets. It connects to a control plane (managed by Popsink at control-plane.popsink.com, or your own) which orchestrates and monitors the deployment.

Architecture overview

The chart deploys the following components: You can disable any sub-component and bring your own:
  • External Kafkatansu.enabled=false, configure defaultKafka.*
  • External Schema Registrykarapace.enabled=false, configure schemaRegistry.*
  • External PostgreSQLpostgresql.enabled=false, configure externalDatabase.*
The chart does not manage ingress. You must set up your own ingress controller (Traefik, NGINX, Istio…) and point a DNS record to it. See Ingress below.

Prerequisites

Cluster

Access to Popsink images

All images are published to a private GAR registry:
Popsink will provide you with a service-account JSON token to pull these images.
Let the chart create the imagePullSecret for you:

Onboarding flow (control plane)

Before installing the chart, you need a deployment ID and a deployment JWT token issued by the control plane.
1

Open the control plane

Log into https://control-plane.popsink.com (or your own control plane).
2

Create a self-hosted deployment

Open Deployments → New deployment and pick Self-hosted.
3

Fill the wizard

  • Optional pre-fill of PostgreSQL credentials (not stored).
  • Retention strategy — pick S3-compatible storage (recommended) or PostgreSQL.
  • FQDN — the public URL where the data plane will be reachable (e.g. https://popsink.your-company.com).
4

Copy the values snippet

The wizard outputs a values-control-plane.yaml snippet containing controlPlaneUrl, deploymentId and deploymentJwtToken. Use these values verbatim — they identify and authenticate your data plane against the control plane.
5

Wait for connection

Keep the wizard open. After helm install, the control plane will switch from Awaiting connection… to Connected once the data plane registers.

Required secrets to generate yourself

Beyond the values handed by the control plane, you must generate four secrets locally:
These four secrets encrypt connector credentials, sign user sessions and protect the admin login. Lose them and you lose access to your stored connector configs. Back them up in your secret manager.
If you prefer to manage secrets out of band (Vault, Sealed Secrets, External Secrets Operator…), set the corresponding existingSecret field instead.

Tansu storage (S3)

Tansu is a stateless Kafka broker that stores log segments in S3. You must provide an S3-compatible bucket and a way to authenticate.
The bucket must exist, be writable by the configured identity, and ideally have object versioning enabled.
If you don’t want Tansu, set tansu.enabled=false and karapace.enabled=false, then point the data plane at your existing Kafka:

Ingress

The chart’s built-in ingress.enabled flag is off by default and we recommend leaving it that way: ingress in production usually needs company-specific annotations (cert-manager, WAF, allow-lists). Provide your own Ingress resource that exposes:
  • the data-plane HTTP service (<release>-data-plane, port 80),
  • on the FQDN you declared in the control plane (ingressUrl).
Example with NGINX + cert-manager:
If you want the chart to render an Ingress for you, set ingress.enabled=true and configure ingress.hostname, ingress.ingressClassName, ingress.tls.
The value of ingressUrl in the chart must match the public URL the control plane redirects users to (it is also used for OAuth-style callbacks):

Putting it together — minimal values.yaml

values.yaml

Install

Use helm search repo or check the chart’s Chart.yaml (version:) to pin the chart version. Pinning avoids surprise upgrades.
Watch the rollout:
When all pods are Ready, head back to the control-plane deployment page — the status should flip from Awaiting connection… to Connected within a minute. Open ingressUrl and log in with the adminCredentials you set.

Production checklist

  • Pin the chart version (--version) and the application image (image.tag) — never deploy latest.
  • Use external PostgreSQL (postgresql.enabled=false, externalDatabase.*) backed by managed snapshots, not the in-cluster Bitnami chart.
  • Use external S3 with versioning + lifecycle policy for Tansu.
  • Set explicit resources.requests/limits on every component (defaults target small-medium clusters; tune for your workload).
  • Configure replicaCount ≥ 2 on data-plane (default), keep tansu.replicaCount=3 (default).
  • Enable pdb.create: true (default) — at least 1 pod stays during node drains.
  • Provide imagePullSecrets via a sealed secret / external secrets controller, not plain values.
  • Back up the four secrets (admin credentials, JWT secret, Fernet key, DB password) in your secret manager.
  • Keep allowDesignLogin: false (default) and pipelineMode: false unless explicitly told otherwise — these are dev-only switches.
  • Ingress: TLS-only, cert-manager (or equivalent), restrict source ranges if your data plane is internet-exposed only for known IPs.

Upgrade

The data plane runs DB migrations on startup. Watch a pod’s logs:

Uninstall

By default the PostgreSQL PVC and Tansu/S3 data are kept (postgresql.primary.persistentVolumeClaimRetentionPolicy.whenDeleted=Retain, S3 buckets are external). Delete them manually if you want a clean slate:

Troubleshooting

For deeper logs:

Reference — most useful values

A full list lives in values.yaml (annotated with @param blocks). The most common knobs are:

Further reading

Installation prerequisites

Hardware, ingress and storage requirements for a Popsink-ready cluster.

Self-hosted onboarding

The control-plane wizard that issues your deploymentId and JWT token.