Helm Chart Values Reference

This is the complete configuration reference for the Zend Enterprise Web Platform Helm chart. The chart is an umbrella chart, so values are organized under a top-level key per subchart, plus a global key for cross-cutting configuration.

The reference is organized into four chapters:

1. Global and shared values - cross-cutting global configuration and the shared behaviors (health checks, resources) common to most pods.
2. PHP Application and web server values - your applications: the web pool, Job Queue workers, nginx customization, and ZendHQ.
3. Integrated service values - the gateway, MySQL, Redis, OpenSearch, OpenSearch Dashboards, the OpenTelemetry stack, and FluentBit.
4. Common autoscaling factors - the autoscaling block shared by the platform's scalable services.

Always supply these as values override files passed with -f. Never edit the chart's own values.yaml. See Basics of platform configuration.

Global and shared values

Global values

The global key holds configuration with cross-cutting concerns - gateway exposure, the list of PHP applications, MySQL and Redis connection details, the OpenTelemetry collector endpoint, OpenSearch hostname, and registry settings.

Key points:

• Gateway. httpPort is the port exposed on the cloud LoadBalancer. For TLS, terminate at a cloud L7 load balancer in front of the gateway and forward plain HTTP to this port. Use extraListeners to add listeners for your own services, then bind an HTTPRoute to them by sectionName (see Gateway).
• phpApplications. This is where you map each application to a hostname so the gateway can route to it - see PHP Applications.
• Auto-generated values. Empty strings for serviceHost, mysql.host, redis.host, mysql.secretName, and otel.collectorEndpoint are auto-derived from the release name and namespace. Set them explicitly only to point at external services.
• tracingRatio. Controls trace sampling globally; lower it to reduce telemetry volume in high-traffic deployments.
• Registry. imageRegistry and imagePullSecrets drive pulling from a private registry - see Configuring a Private Image Registry.

Shared behaviors

The chart defines several behaviors shared by multiple pod definitions. You can set them at a shared/default level, and most can be overridden per service or per application.

Health checks

Liveness and readiness probes can be defined for most containers:

There are additional nginx-specific checks that apply to all zendphp-web nginx containers. These add a path to probe on the host:

Resources

Resource requests and limits follow the standard Kubernetes resource requests and limits format and can be set for each deployment:

There are also nginx-specific resource settings affecting all zendphp-web nginx containers:

These nginx resources can be overridden per application via zendphp-web.applications.<app>.nginx.resources.

PHP Application and web server values

PHP applications are the reason the platform exists, and have the largest amount of available configuration. Three subcharts form the basis of an application:

• zendphp-web: The main PHP-FPM application pool and the nginx web server in front of it. Also governs horizontal autoscaling and shared volumes.
• zendphp-job-queue: The PHP-FPM Job Queue worker pools.
• zendphp-zendhq: The ZendHQ instances. ZEWP deploys one ZendHQ instance per application, segregating them within MySQL using table prefixes.

Every application includes a ZendHQ instance (for per-application monitoring rules and job queues). Applications do not require a Job Queue pool, define one only if you use that feature. Job Queue pools may use a completely different image from the web pool if you want to separate their functionality.

PHP web application

Minimal configuration

To expose the application through the gateway, add a matching entry under global.phpApplications:

Application names must match. The identifier under zendphp-web.applications and the one under global.phpApplications must be identical, or the gateway cannot route requests to the application. The name is also normalized and used as the ZendHQ table prefix, which segregates monitoring data per application.

Use a unique tag per change and pullPolicy: IfNotPresent so Kubernetes pulls only when the tag actually changes.

Additional general configuration

Other than env / envFrom, you generally won't need to change these.

Shared filesystems

Kubernetes best practice favors stateless containers, but PHP applications often need to serve user-uploaded or generated files directly from the web server (CMS uploads, generated invoices, feeds, and so on). For these cases you can add a persistent volume shared across the PHP-FPM, nginx, ZendHQ, and Job Queue containers of a pod:

Common storage classes by environment:

Cloud	StorageClass	AccessMode	Notes
Azure	azurefile-csi	ReadWriteMany	Standard
Azure	azurefile-csi-premium	ReadWriteMany	Premium SSD
AWS	efs-sc	ReadWriteMany	Requires EFS
AWS	gp3	ReadWriteOnce / ReadWriteOncePod	Single pod
GCP	filestore-csi	ReadWriteMany	Filestore
Local	local-path	ReadWriteOnce / ReadWriteOncePod	Single-node cluster
Rancher/k3s/k3d	Longhorn	ReadWriteMany	Emulated NFS

If autoscaling is enabled or replicaCount > 1, you must use ReadWriteMany. Use ReadWriteOnce/ReadWriteOncePod only on a single-node cluster or single replica, and usually only when no RWX StorageClass is available.

Common mount paths by framework:

Framework / Application	Mount Path
Laravel	/var/www/html/storage/app/public
WordPress	/var/www/html/wp-content/uploads
Drupal	/var/www/html/sites/default/files
Magento	/var/www/html/pub/media
Symfony	/var/www/html/var/uploads
Laminas / Mezzio	/var/www/data or /var/www/public/uploads

Init containers

Init containers run before the application containers in a pod, in sequence, each completing successfully before the next starts. Use them to wait for a dependency or run setup tasks (migrations, cache seeding) you don't want in the app image.

Wait for a database to become reachable:

Run database migrations (with their own, higher resource limits):

nit operations must be idempotent. Init containers run on every pod restart, so they must never duplicate work or be destructive. Most migration tools store a schema version and become no-ops when already applied.

PHP JQ workers

By default, no Job Queue worker pool is created for an application. To enable one, add a zendphp-job-queue.applications.<app_name> section whose name matches your zendphp-web application:

When a Job Queue is configured, ZEWP injects a JQ_WORKER_URL environment variable into the PHP application container, the nginx container, and the Job Queue container:

• JQ_WORKER_URL: The base URL (including scheme) for reaching the Job Queue workers, typically http://<release_name>-zendphp-job-queue-<app_name>.svc.cluster.local.

Your application uses this to route jobs to the internal workers:

A benefit of routing jobs this way is that the calls are traced by OpenTelemetry, so you can follow a trace from the initial request through to the jobs it spawned.

Nginx customization

ZEWP provides standard nginx server and virtual-host configuration that works for most applications out of the box: JSON-format logging, application and Job Queue upstream FastCGI proxies, and secure routing defaults. You can override the image, environment, and health checks per application:

Four snippet settings let you inject custom nginx configuration without disturbing the platform-managed parts:

ZendHQ

The same ZendHQ settings apply to every PHP application. They cover the ZendHQ image, default admin credentials, MySQL connection, and the service ports it exposes.

The websocketPort (10091) is what the ZendHQ GUI runs on; ZendHQ is not exposed through the gateway, so you reach it via port-forward (see Accessing platform services). Provide the admin credentials and license through the secret named in secretName - see Required Platform Secrets - ZendHQ.

Integrated service values

These subcharts provide the platform's supporting services. Each can be enabled or disabled, and most need little change beyond storage size and resource limits.

Gateway

ZEWP uses the Kubernetes Gateway API, implemented with NGINX Gateway Fabric. This provides OpenTelemetry integration from the gateway and lets you extend the platform with your own HTTPRoute resources. The gateway exposes PHP web applications externally, Job Queue servers internally, and optionally the OpenSearch Dashboards.

Because the gateway is composed via a third-party Helm chart, some configuration can't be templated and must be set explicitly in particular, the OpenTelemetry exporter endpoint:

In cloud deployments, set nginx.service.type: LoadBalancer so the gateway is reachable via the cloud load balancer. For TLS, terminate at a cloud L7 LB in front and forward plain HTTP to global.gateway.httpPort.

MySQL

zendphp-mysql provides a high-availability MySQL cluster for ZendHQ. Disable it if you run MySQL/PostgreSQL elsewhere and point ZendHQ at that instead. The main things you'll configure are volume size, credentials, and resource limits.

Prefer Option B (pre-existing secrets) for production - see Required Platform Secrets - MySQL. The MySQL deployment depends on the MySQL Operator being installed (see Getting Started).

Redis

A high-availability Redis service for session clustering and data caching. Typically you'll only adjust the persistent-volume size and resource limits.

OpenSearch

OpenSearch aggregates all telemetry and logs. The main customizations are storage size, resource limits, and OpenSearch configuration.

OpenSearch Dashboards

OpenSearch Dashboards visualizes metrics, logs, and traces, and ships pre-configured dashboards. By default it's exposed via global.opensearch.hostname. See OpenSearch Dashboards Included with the Platform.

OpenTelemetry, Data Prepper, and exporters

OpenTelemetry collector

The zendphp-otel chart deploys an OpenTelemetry collector that scrapes metrics from the platform's services and accepts tracing data, then pushes everything to Data Prepper for OpenSearch ingestion. Customize it mainly to push to an alternative destination (e.g. a third-party APM/SaaS) or to change resource limits.

Data Prepper

By default, all collector data is forwarded to Data Prepper, which formats it correctly and pushes it to OpenSearch. The defaults are usually sufficient.

Metrics exporters

zendphp-exporters sets up Prometheus-style exporters for each service, scraped by the OpenTelemetry collector. You may need to provide additional configuration so values stored in secrets are available to an exporter.

FluentBit

FluentBit performs log aggregation and is installed as a DaemonSet (one instance per node). Customize it only in rare cases - for example, to push logs to a third-party aggregator.

---

Common autoscaling factors

Most scalable services in the platform - PHP web applications, the OpenTelemetry collector, Data Prepper, and OpenSearch Dashboards - share the same Kubernetes Horizontal Pod Autoscaler (HPA) configuration shape.

Autoscaling a PHP application

Field reference

Field	Meaning
enabled	Turn autoscaling on or off for the target.
minReplicas / maxReplicas	The lower and upper bounds the HPA will scale between.
targetCPUUtilizationPercentage	Scale to keep average CPU utilization near this percentage.
targetMemoryUtilizationPercentage	Scale to keep average memory utilization near this percentage.
behavior.scaleUp / behavior.scaleDown	Fine-grained control over how quickly scaling reacts.
policies	Scaling policies - see the Kubernetes scaling policies docs.
stabilizationWindowSeconds	Window over which recommendations are considered, to damp flapping.
tolerance	How far utilization may drift from target before scaling (0.0-1.0).
selectPolicy	Min, Max, or Disabled - which policy to pick when several apply.

A default autoscaling policy for all applications

Instead of (or in addition to) per-application autoscaling, you can place a default autoscaling policy at the top-level configuration. It then applies to all PHP applications and likely all other HPA-capable services in the chart unless overridden per application.

Autoscaling requires ReadWriteMany storage. Whenever autoscaling is enabled (or replicaCount > 1), any shared volumes for the application must use a ReadWriteMany access mode so multiple replicas can mount them simultaneously. See Shared filesystems.

The OpenTelemetry collector, Data Prepper, and OpenSearch Dashboards expose the same autoscaling block (without the per-application list) in their respective sections above - enable and tune them the same way if those services become a bottleneck.