Ververica DocsVerverica Docs
Docs Home
Viewing docs for
Self-ManagedNot available for BYOC

Ververica Platform 3.1.2

Applies toSelf-Managed v3
10 min read
On this page

Release Date: 2026-07-31

Ververica Platform 3.1.2 is a maintenance and feature release focused on declarative Helm chart configuration, private-certificate trust, and on-premises installation defaults, plus bug fixes across the Kubernetes Operator, SQL Gateway, and metrics reporting.

New Features and Improvements

Platform-Wide Deployment Defaults Through Helm Values

The deployment default blocks rendered into the AppManager configuration are now Helm values instead of hardcoded template content. Operators can set globalDeploymentDefaults, flinkConfigurationStream, flinkConfigurationBatch, systemDeploymentDefaults, and systemSessionClusterDefaults in values.yaml, and the values are applied to deployments created afterwards.

globalDeploymentDefaults accepts two top-level keys. spec applies to streaming deployments and batchSpec applies to deployments that set batchMode: true. Both keys accept flinkConfiguration and kubernetes.pods, which means a trust store volume and the corresponding JVM options can be delivered to every JobManager and TaskManager from the chart.

Because the same blocks accept kubernetes.pods.volumeMounts, a private certificate authority can be mounted into Flink pods declaratively. This removes the need for a post-install job that patches the AppManager configuration after every upgrade.

For configuration details, precedence rules, and a complete private certificate example, see Platform-Wide Deployment Defaults.

Platform-Wide Session Cluster Defaults

Ververica Platform restores platform-wide session cluster defaults, matching the capability available in Ververica Platform 2.x. Operators can set globalSessionClusterDefaults in values.yaml to apply flinkConfiguration and kubernetes.pods settings to session clusters created afterwards.

Session cluster defaults are applied when the session cluster is created. Changing the value affects session clusters created after the change, and existing session clusters keep the configuration they were created with.

For more information, see Platform-Wide Deployment Defaults.

Pod and Container Security Context

You can now configure a pod and container security context through Helm values, so Ververica Platform pods can run as non-root and meet stricter cluster security policies.

Default File System Group for Volume Permissions

Ververica Platform now ships a default file system group configuration that resolves permission errors when Flink jobs write to mounted volumes. You no longer need to set runAsGroup: 0 manually for the general case.

Published: Defaults

Independent Custom Resource Definition Installation

The custom resource definition can now be installed and upgraded independently of the platform chart. Set ververica-platform-crd.enabled: false in values.yaml to exclude the custom resource definition from the release, and apply it separately. This suits environments where cluster-scoped resources are managed by a different team or under a separate change-control process than namespaced workloads.

Published: Kubernetes Operator

AppManager API Endpoint Visibility

AppManager endpoints, including metrics and logs, are now exposed through the customer-facing public API allowlist.

ServiceAccount Configuration Across All Subcharts

Every subchart that creates a ServiceAccount now honors serviceAccount.create and serviceAccount.name. Setting serviceAccount.create: false together with serviceAccount.name makes the component use a pre-created ServiceAccount instead of creating one, and suits clusters where ServiceAccounts and their role bindings are provisioned outside the application chart. This applies to access-control, vvp-appmanager, vvp-gateway, vvp-advisor, vvp-autopilot, vvp-meta, and vvp-k8s-operator.

On-Premises Installations Render No Default Ingress

On-premises installations no longer render an Ingress resource or a default host by default. global.ingress is empty in the shipped values, and an Ingress is created only when explicitly configured through global.ingress.enabled: true together with className, host, and, where required, tls.enabled. Set path and pathType explicitly, because they have no fallback value.

Configurable Artifact Upload Size Limit

The maximum artifact upload size is now a single Helm value, global.upload.maxFileSize, applied consistently to every service that accepts a job-artifact upload. The default is 200MB.

In Ververica Platform 2.x this limit was raised by passing Spring Boot environment variables through each service's env block, which has no effect in Ververica Platform 3.x.

Published: Artifacts

Audit Logs to Standard Output

Audit events can now be written to standard output with an audit marker, so an existing cluster log pipeline becomes the durable store instead of the file-based sidecar, and the log-forwarding sidecar is not deployed in this mode. Set api-gateway.audit.output: stdout. Audit events are emitted as JSON lines carrying "audit": true. The default remains file-based output.

For more information, see Audit Logs.

Configuration Changes Roll the Affected Pods

Platform components previously read their configuration once at startup, so a Helm upgrade that changed only rendered configuration left running pods untouched until a manual restart. Platform components now carry a configuration checksum in their pod template, so a Helm upgrade that changes their rendered configuration rolls the affected pods automatically.

JDK 17 Recommended Engine

JDK 17 is now labeled as the recommended VERA engine version in the deployment and session cluster creation forms. JDK 11 engine versions remain available and supported.

Published: VERA Engine Versions and Java Compatibility

Bug Fixes

Force Termination for Stuck Deployments

Deployments that got stuck indefinitely in a starting or cancelling state now have a supported way to force termination.

  • Submission-time pod-template validation: a new validation during job submission that rejects unrecognized or misplaced Kubernetes pod-template fields (for example fsGroup set at the container level instead of pod level, or volumeMounts placed directly under the pod spec instead of inside a container). Previously, these malformed specs were silently accepted and persisted, then crashed on each reconcile attempt. This feature has its own toggle to disable the checks if needed.
  • Force-stop for application-mode jobs: Ververica Platform had a POST /jobs/{jobId}:forceStop endpoint, but it worked only for session-mode deployments. The fix removes this restriction, controlled by a new toggle, vvp.appmanager.force-terminate-enabled (default false).

Helm Chart Values Silently Ignored

This release resolves several issues where Helm chart values were silently ignored, including custom image registry settings and pod template volume mounts.

Published (pod template volume mount part): Pod-Level Customization

Loading a Savepoint from a Custom Location Through YAML

Fixed an issue where a savepoint path supplied through the deployment YAML was not applied, which prevented state restoration from an external location without using the API directly. You can now load a savepoint from a custom location through YAML configuration, either through the Kubernetes Operator CR's new restoreStrategy field or the REST API.

Published: Load a Savepoint from a Custom Location

OpenShift Upgrade Issues

Several issues affecting upgrades on OpenShift deployments are resolved.

SQL Gateway Support for s3a:// Paimon and Iceberg Catalogs

The SQL Gateway now resolves s3a:// warehouse locations for catalogs that use the Hadoop file system API, including Paimon and Iceberg with catalog-type=hadoop, removing a previous ClassNotFoundException. Paimon resolves s3a:// through the Hadoop file system API, which loads from the main class loader, while flink-s3-fs-hadoop ships only in the isolated plugin class loader. The platform now places the required class on the SQL Gateway class path at startup.

This behavior is controlled by vvp-appagent.sqlService.s3aCompatibility.enabled, which defaults to true. Set it to false to keep the main class path free of the unshaded Hadoop S3 file system.

Credentials supplied in the catalog WITH clause are used for the connection, and the configuration survives SQL Gateway restarts without manual reapplication. This is scoped to s3a:///s3://; the platform's internal s3i:// blob storage scheme is not a Hadoop file system scheme and still can't be used as a catalog warehouse.

Published: Blob Storage

Kerberos JDBC Authentication on Private-CA Blob Storage

Fixes native Kerberos JDBC deployments (for example SQL Server Integrated Security) failing to start when the platform's blob storage serves its TLS certificate from a private certificate authority. The agent and JAR services now use the same CA-truststore convention already used by the SQL, AppManager, and Gateway components.

Published: Connecting to SQL Server with Integrated Security (Kerberos)

Prometheus and JMX Metrics Reporters Did Not Start

Fixed an issue where the shipped deployment defaults set metrics.reporters to a colon-separated list. Apache Flink® splits this setting on commas only, so neither the JMX nor the Prometheus reporter was registered and no metrics were served. The shipped defaults now use a comma-separated list and include the reporter factory class and port.

No documentation change is needed: the existing Monitoring and Metrics guide already describes the correct, now-restored configuration.

Kubernetes ownerReferences Missing on Platform Resources

Fixed an issue where resources created by the platform did not carry Kubernetes ownerReferences, which prevented dependent objects from being garbage collected when their owner was deleted.

NullPointerException on AppManager Endpoint Lookup

Fixed an issue where the Gateway threw a NullPointerException during an AppManager endpoint lookup.

Maximum Parallelism Setting Ignored

Fixed an issue where the maximum parallelism configured for a deployment was not respected at runtime.

Pod Template Fields Dropped on the V2 API

Fixed an issue where kubernetes and pod template fields submitted through the V2 API were accepted but not persisted.

Vulnerability Fixes (Inside Apache Flink®)

  • Removed binutils, binutils-common, binutils-x86-64-linux-gnu, libbinutils, libctf-nobfd0, libctf0, libgprofng0, libsframe1 to address CVE-2017-13716, CVE-2025-1152, CVE-2025-69644, CVE-2025-69645, CVE-2025-69646, CVE-2025-69647, CVE-2025-69648, CVE-2025-69651, CVE-2025-69652
  • Removed bsdutils, libblkid1, libfdisk1, libmount1, libsmartcols1, libuuid1, mount, util-linux to address CVE-2026-27456
  • Removed ch.qos.logback:logback-core to address CVE-2024-12798, CVE-2024-12801, CVE-2025-11226, CVE-2026-10532, CVE-2026-1225, CVE-2026-9828
  • Removed curl, libcurl3t64-gnutls, libcurl4t64 to address CVE-2026-10536, CVE-2026-4873, CVE-2026-5545, CVE-2026-5773, CVE-2026-6253, CVE-2026-6276, CVE-2026-6429, CVE-2026-7168, CVE-2026-8286, CVE-2026-8458, CVE-2026-8924, CVE-2026-8925, CVE-2026-8927, CVE-2026-9547
  • Removed dpkg, dpkg-dev, libdpkg-perl to address CVE-2026-2219
  • Removed gir1.2-packagekitglib-1.0, libpackagekit-glib2-18, packagekit, packagekit-tools to address CVE-2022-0987, CVE-2024-0217
  • Removed gzip to address CVE-2026-41991, CVE-2026-41992
  • Removed io.netty:netty-codec to address CVE-2025-58057, CVE-2026-42583
  • Removed io.netty:netty-codec-http to address CVE-2025-58056, CVE-2025-67735, CVE-2026-33870, CVE-2026-41417, CVE-2026-42580, CVE-2026-42581, CVE-2026-42584, CVE-2026-42585, CVE-2026-42587, CVE-2026-50020
  • Removed io.netty:netty-common to address CVE-2024-47535, CVE-2025-25193
  • Removed io.netty:netty-handler to address CVE-2025-24970, CVE-2026-44249, CVE-2026-45416, CVE-2026-50010
  • Removed libc-bin, libc-dev-bin, libc6, libc6-dev, locales to address CVE-2026-4046, CVE-2026-4437, CVE-2026-4438, CVE-2026-5435, CVE-2026-6238
  • Removed libduktape207 to address CVE-2026-12216
  • Removed libdw1t64, libelf1t64 to address CVE-2025-1352, CVE-2025-1376
  • Removed libexpat1, libexpat1-dev to address CVE-2025-66382
  • Removed libgcrypt20 to address CVE-2024-2236, CVE-2026-41989
  • Removed libgnutls30t64 to address CVE-2026-33845, CVE-2026-33846, CVE-2026-3832, CVE-2026-3833, CVE-2026-42009, CVE-2026-42010, CVE-2026-42011, CVE-2026-42012, CVE-2026-42013, CVE-2026-42014, CVE-2026-42015, CVE-2026-5260, CVE-2026-5419
  • Removed libicu74 to address CVE-2025-5222
  • Removed liblzma5, xz-utils to address CVE-2026-34743
  • Removed libncursesw6, libtinfo6, ncurses-base, ncurses-bin to address CVE-2025-69720
  • Removed libnghttp2-14 to address CVE-2026-27135, CVE-2026-58055
  • Removed libnss-systemd, libpam-systemd, libsystemd-shared, libsystemd0, libudev1, systemd, systemd-dev, systemd-resolved, … (+2 more) to address CVE-2026-40226, CVE-2026-40228
  • Removed libp11-kit0, p11-kit, p11-kit-modules to address CVE-2026-13757
  • Removed libperl5.38t64, perl, perl-base, perl-modules-5.38 to address CVE-2026-42496, CVE-2026-8376
  • Removed libpng16-16t64 to address CVE-2026-33416, CVE-2026-33636, CVE-2026-34757
  • Removed libpolkit-agent-1-0, libpolkit-gobject-1-0, polkitd to address CVE-2016-2568
  • Removed libpython3.12-minimal, libpython3.12-stdlib, python3.12, python3.12-minimal to address CVE-2025-13462, CVE-2025-69534, CVE-2026-1299, CVE-2026-1502, CVE-2026-2297, CVE-2026-3276, CVE-2026-3644, CVE-2026-4224, CVE-2026-4519, CVE-2026-4786, CVE-2026-6019, CVE-2026-6100, CVE-2026-7774, CVE-2026-8328, CVE-2026-9669
  • Removed libsqlite3-0 to address CVE-2026-11822, CVE-2026-11824
  • Removed libssl3t64, openssl to address CVE-2026-34180, CVE-2026-34182, CVE-2026-42766, CVE-2026-42767, CVE-2026-42770, CVE-2026-45445, CVE-2026-45446, CVE-2026-45447, CVE-2026-7383, CVE-2026-9076
  • Removed libxml2 to address CVE-2026-6653
  • Removed linux-libc-dev to address CVE-2013-7445, CVE-2015-7837, CVE-2015-8553, CVE-2016-8660, CVE-2017-0537, CVE-2017-13165, CVE-2017-13693, CVE-2018-1121, CVE-2018-12928, CVE-2018-12929, CVE-2018-12930, CVE-2018-12931, CVE-2018-17977, CVE-2019-14899, CVE-2019-15213, CVE-2019-15794, CVE-2019-19378, CVE-2019-19814, CVE-2019-20426, CVE-2020-14304, CVE-2020-14356, CVE-2020-35501, CVE-2021-26934, CVE-2021-3714, CVE-2021-3864, CVE-2022-0400, CVE-2022-0480, CVE-2022-1247, CVE-2022-25836, CVE-2022-2961, CVE-2022-3238, CVE-2022-41848, CVE-2022-44034, CVE-2022-4543, CVE-2022-45885, CVE-2022-48846, CVE-2022-48929, CVE-2022-49940, CVE-2022-50090, CVE-2022-50230, CVE-2022-50232, CVE-2022-50240, CVE-2022-50332, CVE-2022-50380, CVE-2022-50551, CVE-2023-0030, CVE-2023-0160, CVE-2023-1193, CVE-2023-20585, CVE-2023-26242, … (+2024 more)
  • Removed login, passwd to address CVE-2024-56433
  • Removed patch to address CVE-2018-6952, CVE-2021-45261
  • Removed pytest to address CVE-2025-71176
  • Removed sed to address CVE-2026-5958
  • Removed tar to address CVE-2025-45582, CVE-2026-5704
  • Removed wget to address CVE-2021-31879, CVE-2026-58469, CVE-2026-58470, CVE-2026-58471, CVE-2026-58472
  • Removed zlib1g to address CVE-2026-27171
  • Updated idna to 3.18 to address CVE-2026-45409
  • Updated requests to 2.34.2 to address CVE-2026-25645
  • Updated urllib3 to 2.7.0 to address CVE-2025-50181, CVE-2025-50182, CVE-2025-66418, CVE-2025-66471, CVE-2026-21441, CVE-2026-44431

Vulnerability Fixes (Outside Apache Flink®)

Base images for the platform tool containers were rebuilt, and the kubectl, nginx, and postgresql images used by init containers and sidecars report no known vulnerabilities.

Upgrade

To upgrade Ververica Platform to version 3.1.2, run the following Helm command:

BASH
1helm upgrade --install <RELEASE_NAME> \
2  oci://registry.ververica.cloud/platform-charts/ververica-platform \
3  --version 3.1.2 \
4  --namespace vvp-system \
5  --values values.yaml

Check the Placement of upgradeStrategy in Deployment Defaults

Ververica Platform 3.1.2 validates the globalDeploymentDefaults value at startup. If upgradeStrategy is nested under spec.template.spec instead of spec, AppManager does not start and reports the following:

TEXT
1Failed to deserialize vvp.globalDeploymentDefaults to a GlobalDeploymentDefaults resource.
2Action: Please verify that the provided value for
3vvp.globalDeploymentDefaults.spec.template.spec.upgradeStrategy has the expected type.

Move upgradeStrategy to the spec level, as a sibling of template:

YAML
1vvp-appmanager:
2  globalDeploymentDefaults: |-
3    spec:
4      template:
5        spec:
6          resources:
7            jobmanager:
8              cpu: 1
9              memory: 1Gi
10      upgradeStrategy:
11        kind: STATELESS

The AppManager readiness probe has a long initial delay. A pod that fails this validation stays in the Running state without becoming ready, rather than entering CrashLoopBackOff. Check the AppManager log for APPLICATION FAILED TO START before concluding that the pod is still starting.

Add batchSpec for Batch Deployment Defaults

globalDeploymentDefaults applies spec to streaming deployments and batchSpec to batch deployments. The shipped default does not include batchSpec, so batch deployments inherit nothing from this block until it is added. If batch deployments require the same resources, Flink configuration, or volume mounts as streaming deployments, add a batchSpec key alongside spec. The spec key is required and must be present even when only batch defaults are needed.

Retire Post-Install Configuration Jobs

Installations that patch the AppManager configuration after installation, for example with a job that writes namespace deployment defaults, can move that content into the globalDeploymentDefaults, flinkConfigurationStream, and flinkConfigurationBatch values and remove the job.

Minimum MariaDB Version

MariaDB 11.4.5 or later is required. Earlier 11.4.x releases don't provide the utf8mb4_0900_ai_ci collation used by the advisor schema migration, and the migration fails on those versions.

Was this helpful?