Flows

A command center for your microservices

Kubernetes is too much surface area for most developers, who mostly care about a handful of services. A Flow groups related microservices with their pipelines, pull requests, and alerts, and spins up a preview environment for every pull request.

Book a demo Read the docs

Flows · payments● 2 previews live

SERVICES

payments-apiprod-use1● degraded

ledger-workerprod-use1● healthy

checkout-webprod-use1● healthy

fraud-scorerprod-euw1● healthy

PIPELINE

dev→staging→prod

grafana alert · payments-api 5xx rate 4.2% on /v1/settle

PREVIEW ENVIRONMENTS

PR #915 · sha-c7e1f04payments-pr-915.dev.acme.io● ready

PR #918 · sha-3b9d2aapayments-pr-918.dev.acme.io● deploying

plural · commented on PR #915

Preview environment is ready at payments-pr-915.dev.acme.io. It updates on every push and is torn down when the PR closes.

4 services1 pipelinepayments-engineers: write

For application teams

The abstraction layer, without the slapdash of tools

Platform teams usually cobble together internal UIs, Backstage, and Argo CD to give developers a usable view. Flows provide it natively, on top of the same system that deploys the services.

Services, pipelines, and PRs together

Monitor service health, follow how updates move through each environment, and see the pull requests behind every deploy. Alerts from PagerDuty, Grafana, and other tools show up next to the services they affect.

Pull requests · paymentslinked automatically

#912 Add retry to settlement webhookmerged 2h ago

#915 Bump stripe-go to v79open

Aggregated logs

Search logs across every service in the Flow without hopping between clusters.

Metrics and heat maps

Spot latency and error-rate regressions with historical context.

Scoped access

Every view respects the Flow’s permission boundary.

Built-in governance

“This team owns these services,” in one binding

Set permissions once at the Flow instead of on every component. Bindings map to your identity provider groups and propagate to every service and pipeline registered with the Flow.

The same boundary covers every preview environment the Flow creates.

Create a Flow

flows/payments.yaml

apiVersion: deployments.plural.sh/v1alpha1

kind: Flow

metadata:

spec:

description: Payments team microservices

bindings:

read:

- groupName: payments-readers # mapped from your IdP

write:

- groupName: payments-engineers

Preview environments

A full environment for every pull request

For the life of a pull request, Flows run a near clone of your dev environment with that branch’s code. Reviewers click a link instead of pulling a branch, and the shared dev environment stays stable.

A stable dev environment

In-flight branches stop trampling the shared dev environment, a common failure in large organizations.

Test changes in isolation

Each preview runs only the code in its branch, so a failure points at that change and nothing else.

Safe schema migrations

Add a database fork to the preview to test migrations without corrupting shared dev data.

One custom resource, one line in the PR

A PreviewEnvironmentTemplate names the dev service to clone and what to override: the namespace, the image tag built for the commit, and a unique hostname for the PR.

Opt a pull request in by adding the Flow and template names to its description:

Plural Flow: payments Plural Preview: payments

Set up preview environments

flows/payments-preview.yaml

apiVersion: deployments.plural.sh/v1alpha1

kind: PreviewEnvironmentTemplate

metadata:

spec:

flowRef:

referenceServiceRef: # the dev service to clone

namespace: payments

template:

namespace: "payments-pr-{{ pr.number }}"

syncConfig:

deleteNamespace: true # clean up when the PR closes

helm:

values:

image:

tag: "sha-{{ commitSha | slice: 0, 7 }}"

ingress:

hosts:

- host: payments-pr-{{ pr.number }}.dev.acme.io

Feedback on the PR, guardrails on the cluster

Plural already receives pull request webhooks and holds your GitHub or GitLab credentials, so it redeploys the preview on every push and comments on the PR with its status and URL. When the PR closes, the preview and its namespace are deleted.

Previews are GitOps services like any other, with guardrails that keep them from leaving their tenant or overwriting the service they clone.

Guardrailsenforced by Plural

✓Previews only deploy to the same cluster as the service they clone.

✓Namespaces must be prefixed by the source service’s namespace, so a preview can’t jump tenants.

✓The Flow’s permission bindings apply to every preview it creates.

Questions

How is a Flow different from a developer portal?

Portals are usually a separate system stitched onto your deployment tooling. A Flow is native to Plural: the services, pipelines, alerts, and permissions it shows are the same ones Plural deploys and enforces.

How are Flows configured?

With a Kubernetes custom resource. Define the Flow with a description and permission bindings, then register services and pipelines with a flowRef.

How do I turn on preview environments?

Register a PreviewEnvironmentTemplate that points at the dev service to clone, then add the Plural Flow and Plural Preview annotations to a pull request’s description. Plural deploys the preview, updates it on every push, and deletes it when the PR closes.

Where do preview environments run?

On the same cluster as the service they clone, in a namespace prefixed by that service’s namespace. That keeps previews inside their tenant while preventing them from overwriting the original service.