Skip to main content
Popsink has two levels of grouping, and the difference between them is a network boundary, not a naming convention. Getting the mapping right up front is much cheaper than moving pipelines later.

​
The two levels

Deployment

One running data plane: one Helm release, one URL, one Kubernetes cluster, one network. The connector workers that read your sources run inside it, as pods in its namespace.

Environment

A scope inside a deployment: its own broker and retention configuration, its own teams and members, its own pipelines. Not a separate runtime — it shares the deployment’s cluster, network and URL.
Everything else hangs off an environment:
The control plane sits above all of it and manages your whole fleet of deployments from a single organization, with one user and billing view. What travels between the two is documented in Control plane and data plane. How large each of those boxes gets before the design has to be split — tables per connector, subscriptions per target, connectors per deployment — is covered in Sizing and limits.

​
The rule

One deployment per isolated network.
Environments split a single reachable network into separate scopes. They do not span networks, VPCs or regions — every environment of a deployment is served by the same pods, in the same cluster, reachable at the same URL. So a fleet like “Staging London”, “Production London”, “Production Sydney” maps to three deployments, each with a single environment: The alternative — a “London” deployment holding “Staging” and “Production” environments — only works if both tiers are reachable from the same cluster. If they sit in isolated networks, a pipeline in the Sydney environment of a London deployment would have no worker in Sydney to run its connector.

​
When a second environment is the right answer

Use additional environments inside one deployment when the network is the same and only the scope differs:
  • separate teams that must not see each other’s pipelines;
  • a different broker retention policy for one class of workload;
  • a sandbox tier that shares the cluster with production but not the data.

​
Per-deployment isolation

Each deployment is registered separately in the control plane and must keep its own: Everything else — images, chart version, ingress class, IAM patterns — can and should be identical across deployments. A single values.yaml template with the per-deployment values substituted is the usual shape.

​
Upgrading a fleet

Deployments upgrade independently: helm upgrade one at a time, with the version the control plane reports as supported. Roll a staging deployment first, confirm its status flips back to Live in the control plane, then move through the production ones.

Install a deployment

The Helm chart, component by component.