Deployment paths: architecture and design

Ververica Unified Streaming Data Platform is available through two product families. Ververica Cloud: Bring Your Own Cloud runs in your own cloud account with Ververica operating the control plane. Ververica Platform is self-managed, and you run it yourself in either of its supported versions, 3.x and 2.x. That gives you three deployment paths.

What separates them is where the platform runs, which parts of it you operate, and which stream processing engine you get.

This page compares the three paths on the same axes and explains the reasoning behind the split, so you can pick one deliberately. For installation steps, each path has its own Getting Started.

One boundary, drawn in three places

Every deployment path splits the platform into a part that decides what should run and a part that runs it. Ververica Cloud: Bring Your Own Cloud makes that split explicit and puts the two halves in different places. The control plane is hosted in Ververica Cloud and provides the interface for managing deployments, monitoring, and configuration. The data plane is your own Kubernetes cluster, where Flink workloads execute. The control plane stores only metadata. A one way agent running in your cloud connects out to the control plane, so you keep control of connectivity, security policy, and observability.

Self-Managed draws the same boundary but keeps both halves inside your infrastructure. You run the platform on your own Kubernetes cluster, on premise or in a private cloud, and you own the software lifecycle end to end. Nothing needs to reach outward for the platform to function.

That single decision, whether the control plane sits with Ververica or with you, determines almost everything else: how you install, who handles upgrades, what network access is required, and which compliance arguments you are able to make.

Comparison

Who operates what

On both Self-Managed paths the answer is short: you do. You own the infrastructure, the platform stack, the security model, and the update schedule. The platform gives you complete control over data, operational processes, and the software lifecycle, and that control is the point of the path.

Bring Your Own Cloud uses a shared responsibility model, so the split is worth stating precisely. Ververica manages and distributes the agent, platform, and engine containers as Helm charts, maintains metadata in the control plane, and handles lifecycle updates to its own services. You manage the cloud infrastructure such as EKS or AKS, compute instances, VPC or VNet, storage, networking, metrics, and logging, along with service integrations and your zero trust security policies, including agent configuration. All data processing happens inside your cloud account.

For the full breakdown, including the responsibility matrix, see BYOC.

Security posture

Bring Your Own Cloud is built on zero trust principles. It assumes no implicit trust, verifies every access request, and treats Ververica as a third party, in line with NIST 800-207. Your data is processed in the data plane, in your own cloud. For the full architecture and the questions to review before deploying, see BYOC Security: Zero Trust by Design.

Self-Managed addresses the same concerns by removing the third party instead of constraining it. It secures isolated, air gapped environments and supports deployments where low latency and proximity are critical, and it keeps both data and metadata entirely under your control.

How Ververica Platform 3.x differs from 2.x

Both versions install on your own Kubernetes cluster, so the choice between them is not about where they run. It is about the engine and the operator.

Ververica Platform 3.x runs the VERA engine, an enterprise-ready stream processing engine built on Apache Flink. You select a VERA engine version when you create a deployment, and each version corresponds to a specific Apache Flink version and a supported set of Java versions. Ververica Platform 2.x is documented around Apache Flink itself, in its Spring and Stream editions. VERA is also the runtime on Bring Your Own Cloud, so on this axis 3.x has more in common with Bring Your Own Cloud than with 2.x.

The rest of the published differences are in the Kubernetes Operator.

The custom resource kind, VvpDeployment, is unchanged. As of Ververica Platform 3.1.1 the API version changed from ververica.platform/v1 to v3.ververica.platform/v1, which allows Ververica Platform 3.x and 2.x to be co-installed on the same cluster. The custom resource structure, operator behavior, and Helm configuration have all changed, and Ververica Platform 2.x custom resources need updating before you enable the 3.x operator.

Behavior that changed in the 3.x operator:

• Operator managed deployments are write protected. In 2.x you could edit them in the interface or the API, and the operator silently reverted the change at the next reconciliation. In 3.x those edits are blocked and all changes go through the custom resource.
• Multiple operators can share a namespace. The 2.x operator allowed one instance per watched namespace. In 3.x each instance filters by its instanceId, so namespaces used as a workaround can be consolidated.
• Status uses Kubernetes conditions. The 2.x status model mirrored platform deployment fields onto the custom resource. 3.x replaces it with standard conditions and simplified status fields.
• A validating admission webhook rejects invalid custom resources. The 2.x operator had none, so invalid resources were accepted and failed silently at reconciliation. In 3.x you get the error at kubectl apply time.
• Autopilot is respected. The 2.x operator overwrote Autopilot's scaling decisions on every reconcile cycle. The 3.x operator understands that Autopilot acts at the Flink job runtime level and exposes the ParallelismAligned condition for visibility.

Ververica Platform 2.x additionally offers two Flink editions, Spring and Stream, described under Supported Versions and Compatibility. Ververica Platform 3.x provides quickstarts for SQL, JAR, and Python deployments.

If you are moving an existing installation, see Migration from Ververica Platform 2, which covers the custom resource structure changes and the migration steps.

Choosing a path

Choose Ververica Platform, self-managed when any of these apply:

• Your environment is air gapped, or outbound connections to a vendor are not permitted.
• You need control over the entire software lifecycle, including when and how updates are applied.
• You run on premise, in a private cloud, at the edge, or on a Kubernetes distribution other than EKS or AKS.
• Your compliance position requires that neither data nor metadata leaves your control.

Between the two versions, Ververica Platform 3.x is where the VERA engine and the current operator capabilities live, including admission validation, conditions based status, and Autopilot awareness. Because 3.1.1 onward can be co-installed alongside 2.x on the same cluster, you are able to migrate incrementally rather than in one move.

Choose Bring Your Own Cloud when any of these apply:

• You want Ververica to operate the control plane while your data stays in your own cloud account.
• You are adopting a zero trust security strategy and want Ververica treated as a third party by design.
• You hold preferential pricing, spend commitments, or marketplace billing with AWS or Azure and want to use them.
• You run multi cloud or hybrid cloud architectures and want to avoid vendor or regional lock in.
• You want full observability of your data while still getting a managed Flink experience.

Where to go next

• BYOC for the architecture, security model, and responsibility matrix.
• Self-Managed for the core capabilities and strategic benefits.
• How to choose your deployment option for a short summary of each path.