Deploying Zammad on Kubernetes with Helm starts with its dependencies
The official Zammad Helm chart is the documented route for running Zammad on Kubernetes, but the application does not run on its own. Zammad stores its content in PostgreSQL 15 or newer, requires Redis 7 or newer for realtime websocket communication, and needs a reverse proxy in front of it, with Nginx or Apache as the supported options. For multi-instance runs such as several pods in a cluster, Memcached is required, and Elasticsearch is optional but strongly recommended for search, reporting and attachment content search. Before anyone writes a values file, the platform team should decide which of these components run inside the cluster, which run as managed services in the same cloud account, and which already exist as shared platform services that Zammad can reuse.
The difficulty is that most of these dependencies are stateful. PostgreSQL holds every ticket, article and user record, so its storage class, volume snapshots, backup schedule and restore test determine the recovery point for the helpdesk. Attachments and any file-based storage need persistent volumes that survive pod rescheduling and that are included in backups, because a database restore without matching attachments leaves tickets pointing at files that no longer exist. Elasticsearch indexes are derived data, but rebuilding them after an upgrade or migration can take time on a large ticket history, so the team should know whether its cluster has the disk and memory for a full reindex before go-live. Each of these choices affects the Helm values, the node pools and the runbooks, and none of them is solved by the chart alone.
Support boundaries are the second source of surprise. On Kubernetes, Zammad vendor support covers the Zammad application only, not Kubernetes-specific problems such as storage class behavior, ingress controller configuration, pod scheduling, network policies or cluster upgrades. Ask the vendor and your own platform team, in writing, who owns a failure that starts in the cluster network and surfaces as a broken websocket connection in the agent interface. Confirm which Zammad support subscription tier you hold, because the response times differ by tier, and confirm that your chart version and Zammad application version are both on the support matrix you rely on.
A practical first step is a written dependency inventory with four columns: component, version required by Zammad, where it runs, and who is responsible for its backup, patching and monitoring. Check the PostgreSQL and Redis versions against the current Zammad software requirements before you pin any image tag, and record the Memcached and Elasticsearch decisions explicitly even if the answer is to defer them. This inventory becomes the input for the storage design, the upgrade plan and the scaling decisions covered in the sections that follow.
Which components the Zammad Helm chart brings into the cluster
The Zammad Helm chart deploys the application alongside the services it depends on. Each component below has a version, role or support note from Zammad's documentation, and each can be bundled in the chart, pointed at an external service, or left out. Check the chart values for every item before you agree ownership with your platform team.
Zammad application pods
The application pods run the Zammad processes that serve the web application, websocket traffic and background jobs for tickets, email channels and scheduled tasks. Kubernetes deployments often run more than one application pod, so the replica count and the storage each pod expects affect how the rest of the stack is sized. Confirm in the chart values which Zammad version the default image tag targets, how many replicas are set, and which shared storage the pods mount. Ask the chart maintainers how upgrades roll across replicas.
PostgreSQL database
Zammad stores its content in PostgreSQL 15 or newer, so tickets, articles, users and settings all depend on this database. Confirm in the chart values whether PostgreSQL is deployed as a bundled dependency, pointed at an external instance, or replaced by a managed service. Check that the version the chart deploys meets the 15 or newer requirement. Ask who owns backups, restore testing and major version upgrades for the database.
Redis for websocket communication
Zammad requires Redis 7 or newer for websocket communication between the browser and the application. Without a working Redis, the live interaction features that agents rely on will not behave as expected, so treat it as a hard dependency. Confirm in the chart values whether Redis is bundled, external or optional, and which Redis version the chart deploys. Check its persistence settings and whether a single instance meets your availability expectations.
Memcached for multi-instance caching
Memcached is needed for multi-instance Zammad deployments such as containers or cluster nodes, while single installations can use the file system cache. Because a Kubernetes deployment usually runs several application pods, expect Memcached to sit in the cache path for this chart. Confirm in the chart values whether Memcached is bundled, external or disabled, and whether the application is configured to use it. Ask how cache consistency is handled across replicas during scaling and upgrades.
Elasticsearch for search and reporting
Zammad uses Elasticsearch for faster search, reporting and searching email attachment content. Zammad documents it as optional but strongly recommended, so decide early whether your deployment needs it. Confirm in the chart values whether Elasticsearch is deployed by the chart or connected to an existing cluster, and check the supported Elasticsearch version in Zammad's software requirements. Index storage, memory and the index rebuilds needed after upgrades or migrations are major operational considerations to plan for.
Reverse proxy and TLS termination
Zammad supports Nginx or Apache as the reverse proxy in front of the application. In Kubernetes, the ingress controller, any proxy the chart adds and certificate handling must be settled together, or traffic may be encrypted at one hop and unencrypted at another. Confirm in the chart values which proxy is used, where TLS terminates, and whether websocket connections pass through the ingress unchanged. Ask who renews certificates and how that renewal is tested.
Which dependencies to run in the cluster and which to externalize
This table compares running each Zammad dependency inside the cluster with pointing Zammad at a service you operate or buy elsewhere. Read each row against who owns backups, patching and failover, because the chart's defaults do not settle those duties for you. The main takeaway is that the PostgreSQL, Redis and Elasticsearch decisions carry the most operational weight, while Memcached and the file system cache mainly affect how you scale.
| Dependency and option | When it fits | Operational cost you take on |
|---|---|---|
| PostgreSQL in the cluster | Pilots and test environments where a platform team accepts a single database pod and the data risk that comes with it | You own backups, restore tests, minor version patching and storage resilience. Confirm the chart's PostgreSQL version meets the PostgreSQL 15 or newer requirement. |
| PostgreSQL externalized | Production when a database team already runs backups, replication and patching for PostgreSQL 15 or newer | You own the connection settings, credentials, the network path from the cluster and a restore procedure tested against Zammad data. Ask who holds failover and approves maintenance windows. |
| Redis in the cluster | Single-site installs where a short Redis outage is tolerable for live updates and Redis 7 or newer is available | Redis carries realtime websocket traffic, so a pod restart interrupts live updates. You own its persistence settings, version upgrades and access controls on the service. |
| Redis externalized | Production clusters that already run a managed or highly available Redis 7 or newer service | You own network rules so only Zammad pods can reach Redis, credential rotation and failover testing. Confirm the service accepts the websocket connections Zammad opens. |
| Elasticsearch in the cluster | Teams that want search and attachment search without a separate platform, accepting that Elasticsearch is optional but strongly recommended | You own heap and storage sizing, snapshots, version pairing with Zammad and index rebuilds after upgrades or migrations. |
| Elasticsearch externalized | Organizations that already operate a supported search cluster with snapshot and monitoring routines | You own network access from the cluster, index access rights and capacity planning shared with other workloads. Confirm the version Zammad documents before connecting. |
| Memcached in the cluster | Any installation with more than one Zammad instance, such as several pods or nodes | Memcached is required for multi-instance deployments. It holds cache only, so you monitor its availability and keep it reachable from every Zammad pod. |
| File system cache | Single installations with one replica where no second Zammad instance will run | Little extra to run, but the cache lives on one volume. Adding a second replica later means adding Memcached and reviewing the storage class. |
Where Zammad support stops on Kubernetes
Zammad documents Kubernetes deployment and publishes an official Helm chart, but its support covers the Zammad application only. Problems that originate in the cluster itself, such as pod scheduling on specific nodes, ingress controller behavior, storage class provisioning and cluster networking between Zammad and its backing services, fall outside that support. Before you deploy, decide who answers for each layer. If that split is not written down, the first outage will start with an argument about whose problem it is, and the helpdesk will be down while that argument runs.
In practice, your platform team owns the cluster. That includes node pools and scheduler constraints, the ingress controller and TLS termination in front of the Zammad web pods, the storage class and persistent volume claims used for attachments and the database, and network policies that control traffic between Zammad, PostgreSQL, Redis, Memcached and Elasticsearch. Zammad's team owns the application behavior, the chart's documented values for the Zammad release you chose, and product defects. Some items sit on the line, such as which chart values affect storage or resource requests, so list those explicitly and agree who reviews them.
A vendor subscription changes the Zammad side of that split, not the cluster side. Zammad's pricing page lists self-hosted support subscriptions named Business at 2,999 EUR per year, Enterprise at 5,999 EUR per year and Corporation at 9,999 EUR per year, with response times of 6 hours, 4 hours and 2 hours respectively. Those response times apply to the support the subscription provides, so read them as targets for application issues. Confirm in writing whether the subscription covers the Helm chart and its values, which versions are supported, how severity is defined, when the clock starts and whether any Kubernetes-specific guidance is included.
A DeployOpen engagement can take on the cluster-side work that the Zammad subscription does not cover, such as designing the ingress and storage layout, hardening network paths between services and writing runbooks for the platform team. Most engagements are fixed-scope, so the cluster tasks, deliverables and timelines are agreed in writing before work starts, and ongoing support is available as a retainer. An engagement does not change what Zammad's support covers, so keep the vendor subscription and the engagement scopes side by side in your responsibility matrix.
Start by drafting a responsibility matrix with one row per component and one column per owner, then ask Zammad for its current support terms in writing and file them with the matrix. Illustrative example: a Zammad pod stays pending because the requested storage class has no provisioner. The platform team owns the fix, and Zammad's team may still need the chart values to confirm the claim is correct. Run a tabletop exercise with that scenario before go-live so everyone knows where to open a ticket, what evidence to attach and how long each response is expected to take.
How to build a Zammad Helm deployment in order
This sequence takes a Zammad Helm deployment from an unpinned chart to a tested, documented release in your own cluster. Each step hands over a specific artifact, from pinned versions and provisioned data stores to verified mail channels and a values file under version control. Work through the steps in order, because later steps depend on the versions and backends chosen earlier.
Pin the chart and application versions
Choose one Helm chart version and one Zammad application version, and write both into the deployment record before anything is installed. Check the chart's documented Zammad version against the Zammad software requirements, and confirm the minimums of PostgreSQL 15 or newer and Redis 7 or newer. Security fixes have been published for both the 6.5 and 7.x lines, so confirm which line you are standing up and follow its security notices. Done when a single chart version and image tag are recorded in your change ticket and in a version-controlled file.
Provision PostgreSQL and Redis with persistence
Run PostgreSQL 15 or newer and Redis 7 or newer outside the Zammad pod lifecycle, either as managed services in your cloud account or as stateful workloads with persistent volumes. Zammad stores its content in PostgreSQL and uses Redis for realtime websocket communication, so losing either without a backup means lost tickets or broken live updates. Schedule volume snapshots or logical dumps, then test one restore into a scratch namespace. Done when the restored database connects to a test Zammad release without errors.
Set Memcached and Elasticsearch by topology
Decide whether this release runs one Zammad instance or several. Multiple application pods need Memcached as a shared cache, while a single installation can use the file system cache. Elasticsearch is optional but strongly recommended for faster search, reporting and attachment content search, so confirm with the business whether those features are needed before go-live. Done when the values file states the cache and search backends for the chosen topology and their endpoints are reachable from the application namespace.
Create secrets outside values files
Generate the database password, Redis credentials, application secrets and any mail or SSO credentials in your secrets manager, then reference them from the chart by name. Keep them out of values files, Helm release history and container images. Restrict who can read the namespace secrets and record who owns each rotation. Done when a dry-run render of the chart contains secret references only, and a search of the values files for passwords returns no matches.
Configure ingress and TLS termination
Expose the Zammad service through your ingress controller and terminate TLS with certificates from your certificate authority or cluster issuer. Check Zammad's documented reverse proxy requirements against your controller, including forwarded headers and websocket upgrades. Set the external hostname the application advertises so links in notification emails resolve correctly. Done when the hostname loads over HTTPS with a valid certificate chain and a browser session keeps its websocket connection open.
Deploy and run first-login and mail tests
Install the pinned chart with the reviewed values file and wait for the application pods to pass their readiness checks. Replace any initial credentials the install creates, sign in as an administrator, and confirm an agent account can open the ticket view. Send a test message into an inbound email channel and confirm it creates a ticket, then reply from Zammad to confirm outbound delivery. Done when both test messages appear in the expected ticket and channel logs.
Record chart values in version control
Commit the final values file, the pinned chart version, the image tag, and the ingress and backup configuration to a version-controlled repository, with secrets referenced but never stored. Tag the commit that matches the tested release, and file the test results and restore evidence alongside it. Document who reviews chart and Zammad upgrades, and where the support boundary sits: Zammad's support covers the application, while cluster issues stay with your platform team. Done when a clean checkout renders the same manifests as the tested release.
How to confirm the Zammad cluster works and fails safely
Confirm the deployment with a fixed set of tests before any user depends on it. The first group proves the basics: every pod reports ready, the application can reach PostgreSQL and Redis, and a ticket created in one browser session appears in a second session without a manual refresh. Websocket updates are the most common place for a misconfigured reverse proxy to fail silently, so test them through the same ingress path your users will use, not by calling the Zammad pod directly. Zammad's requirements name PostgreSQL 15 or newer and Redis 7 or newer, so check the versions your chart actually deploys against those minimums before you read any test result as meaningful.
Next, test state that must survive change. Create a ticket with an attachment, delete the Zammad application pods, let the replacements become ready, and then download the attachment and confirm its checksum matches the original. Repeat the check after a rolling restart of the deployment. If attachments are stored on a volume, verify that the storage class and reclaim policy match what you intended, because a volume that is deleted with its claim will pass a pod restart test and still lose data on a namespace cleanup. Record which storage backend the chart uses in your environment and confirm it against the chart version you run, since defaults change between releases.
Failure testing is where most teams learn the most. Stop the PostgreSQL service or scale its pod to zero for a short, defined window while watching the application. The expected behavior is a clear error to agents and no partially written tickets. Do the same for Redis, where the realistic symptom is loss of live updates while ticket data remains intact. Afterward, confirm that no ticket or article was duplicated or lost by comparing record counts with a snapshot taken beforehand. Write down the exact errors users see, because those messages become the basis of your runbook and your support escalation.
Search degradation needs its own test. Zammad uses Elasticsearch for faster search, reporting and searching email attachment content, and the requirements describe it as optional but strongly recommended. Stop Elasticsearch and confirm two things: ticket creation and viewing still work, and search returns a clear message or falls back to the behavior your Zammad version documents. Then restart Elasticsearch and confirm indexing catches up. Confirm the exact fallback behavior with the Zammad documentation for your release, because it is not a detail to assume.
Finish with a restore test from backup. Restore the PostgreSQL database and the attachment storage into a separate namespace, point a test instance at them, and check that a sample of tickets, articles, attachments and user accounts match the source. Time the restore and write down the steps, because that measured time is the figure your recovery objective should be based on. Repeat this test after every chart or Zammad upgrade. Ask your implementation partner and your own platform team to agree in writing on the pass criteria, the owner of each test, and the evidence you will keep, and confirm each test step against the chart version and Zammad release you are deploying.
What drives effort and cost in a Zammad Kubernetes deployment
This table lists the factors that change the work in a Zammad Helm deployment and what to do to keep each one manageable. Read each row as a lever: the driver on the left changes scope, and the right-hand columns show how to hold it down. The main takeaway is that stateful dependencies, values standardization and customization boundaries usually matter more to effort than the Helm install itself.
| Driver | Why it changes effort or cost | How to keep it down |
|---|---|---|
| Number of agents and channels | More agents, groups and inbound channels (email, chat, forms, phone) increase load, trigger volume and the number of integrations to test and monitor. | Confirm expected agent count and channel list before sizing. Phase channels in after go-live rather than enabling all at once. |
| Data and attachment volume | Ticket history, attachments and email content grow PostgreSQL storage and file storage, and drive backup and restore time. | Agree a retention policy early. Size persistent volumes and backup targets from measured growth, and confirm storage class performance with your platform team. |
| Number of environments | Each environment (test, staging, production) needs its own values, secrets, database and upgrade rehearsal, so work multiplies with every added environment. | Keep one base values file and apply small, environment-specific overlays. Manage them in version control so differences are reviewable. |
| In-cluster or external dependencies | Running PostgreSQL, Redis, Memcached and Elasticsearch inside the cluster means you own their storage, backups, upgrades and failure handling. | Consider externalizing stateful services to managed or dedicated instances you already operate. Confirm the chart's connection settings for each external service before committing. |
| Elasticsearch for search | Elasticsearch is optional but strongly recommended for faster search, reporting and attachment search. It adds a stateful component with its own sizing, index rebuilds and monitoring. | Decide early whether search and reporting need Elasticsearch. Plan index rebuilds into upgrade and migration runbooks rather than treating them as ad hoc tasks. |
| Integrations and SSO | SAML, OpenID Connect, Microsoft, Google, GitHub and GitLab logins, plus external systems, each need configuration, testing and ongoing credential management. | Limit the identity providers in scope to those you need. Document role mapping and test each login path in staging before production rollout. |
| Customization | Custom triggers, macros, attributes or code can break at upgrade time. Support on Kubernetes covers the Zammad application only, so custom code is your responsibility to validate. | Restrict customization to documented configuration and supported APIs where possible. Keep a register of changes and retest them on every minor and security release. |
| Air-gapped or regulated constraints | Restricted networks need mirrored container images, offline chart and dependency sources, and evidence for access control, encryption and logging reviews. | Confirm image and chart mirroring with your registry team early. Record configuration decisions as evidence in the same repository as the values files. |
| Cluster maturity | Teams without established ingress, TLS, storage class, backup and monitoring standards must build those before Zammad can run reliably, which can exceed the Zammad work itself. | Assess existing cluster standards first. Reuse your ingress, certificate, secret and backup patterns instead of creating Zammad-specific ones. |
How the Kubernetes setup changes by topology and environment
A single Zammad application pod is the simplest topology. Zammad can use the file system cache for a single installation, so Memcached is not a prerequisite. PostgreSQL and Redis usually still run as separate services, either as dependencies managed by the chart or as external endpoints, and Elasticsearch remains optional but recommended for search and attachment search.
What changes in this topology:
- Cache: the file system cache covers a single installation, so you do not need a shared cache layer.
- Persistence: attachments and any local data need a persistent volume claim that survives pod restarts and node moves.
- Upgrades: one replica means a short interruption during rollout unless you schedule a maintenance window.
- Support boundary: Zammad support covers the application only. Scheduling, volumes, ingress and node health stay with your platform team.
Confirm with the vendor the minimum PostgreSQL 15 and Redis 7 versions for your target release, and confirm with the platform team which storage class backs the volume and how it is backed up.
Running several Zammad application pods behind a load balancer requires shared state. Zammad needs Memcached for multi-instance deployments such as containers or cluster nodes, because cache data cannot stay on one node's disk. Every pod must reach the same database, Redis and cache endpoints, so the design moves those services out of individual pods.
What changes in this topology:
- Memcached: deploy a shared cache that all instances use, so cache state stays consistent across pods.
- PostgreSQL 15 or newer: use one shared database, and size connection limits for the total number of pods.
- Redis 7 or newer: share one Redis service for realtime websocket communication, and confirm that the ingress passes websocket traffic correctly.
- Elasticsearch: it stays optional, but if you use it, every pod must query the same cluster so search results match across instances.
- Persistence: attachments must sit on storage that all pods can mount. Confirm which access modes the chart and your storage class support before you commit to a design.
Ask the vendor which chart values set the external PostgreSQL, Redis and Memcached endpoints, and ask the platform team to confirm the shared access mode available in your cluster.
Managed Kubernetes services run the control plane for you, but node pools, storage classes, ingress controllers and cluster upgrades remain part of your operating model. Managed database and cache services can replace in-cluster dependencies, which moves patching and backup responsibility to the provider. The Helm chart behaves the same way on a managed cluster, but the operational boundary moves.
What changes in this topology:
- Control plane: the provider upgrades the control plane on its own schedule, so check Kubernetes version compatibility with the chart before you accept automatic upgrades.
- Storage: provider storage classes differ in access modes, snapshot support and performance, so test attachment storage before go-live.
- Dependencies: managed PostgreSQL and Redis services take on patching and backups, but you must confirm they offer the Zammad minimum versions.
- Ingress and TLS: load balancers and certificate handling come from provider add-ons, which must keep websocket connections open.
- Support boundary: Zammad support does not cover Kubernetes-specific issues, so cluster faults go to the provider or your platform team.
Confirm with the platform team which provider upgrade channel applies to your cluster, and confirm with the vendor which Kubernetes versions the chart is tested against.
In an air-gapped cluster, nodes cannot pull container images or chart archives from public registries. Every image that Zammad and its dependencies need must be mirrored into an internal registry, and the chart archive must be stored inside your network. Upgrades become a transfer and approval process as much as a configuration change, so the delivery pipeline matters as much as the chart values.
What changes in this topology:
- Images: mirror the Zammad application image and every dependency image, including PostgreSQL, Redis, Memcached and Elasticsearch if you use them, into the internal registry with pinned tags or digests.
- Chart: store the chart archive internally and record its version next to the image digests it was tested with.
- Updates: security releases must pass through your transfer and approval process before rollout, so plan for that lag when you assess exposure.
- Dependencies: dependency versions must match the requirements listed for the Zammad release you deploy.
- Support boundary: confirm with the vendor how support engagements can reach an isolated environment and how diagnostic data leaves it.
Ask the vendor for the full list of images each chart version pulls, and ask the platform team how the mirror is synchronized and how its contents are verified.
What to monitor, back up, upgrade and document after go-live
Once Zammad is live on Kubernetes, the first operational task is to watch the components the Helm chart deploys and the services they depend on. Pod health alone does not show whether agents can work. Track the Zammad pods for restarts and failed readiness checks, watch PostgreSQL 15 or newer for connection exhaustion, and watch Redis 7 or newer for websocket connection counts, because realtime updates to agent screens depend on it. Watch the background job queue for a growing backlog, since delayed email processing is often the first visible sign of trouble. If you run Elasticsearch, check cluster health and index status, because search and attachment content search can fail quietly when the index is unhealthy. Confirm with your platform team which metrics the cluster already collects and which need an exporter.
Back up PostgreSQL and attachment storage on a schedule, and prove the backups work by restoring them into a separate namespace. The database holds ticket content and configuration, while attachments live in the storage backend you configured for the chart. Both must be captured from the same point in time, or the restored tickets will not match their files. Decide who owns the snapshot tooling, how long backups are kept, and where copies are stored outside the cluster. Redis holds transient realtime state, so confirm with your implementer whether it needs backing up for your version or is rebuilt after a restore. Record the restore duration from each test, since that figure is what the business will ask about after an incident.
Pin the Helm chart version and the Zammad image tag in your deployment code so that routine cluster changes cannot move Zammad to a new release unannounced. Then track releases on the Zammad releases page. Zammad 7.2 was released on 23 September 2026, followed by security releases 7.2.1 on 6 October 2026 and 7.2.2 on 8 October 2026. Zammad also published security release 6.5.5 on 15 October 2026, so both the 6.5 and 7.x lines received security fixes in parallel. Name one owner who reads each advisory, decides the upgrade window and tests the new image in a staging namespace first. Confirm which release line your pinned chart version targets before you plan the work.
Plan the Elasticsearch index rebuild as a named step in every upgrade and migration runbook. Schedule it after the new version is running and before users return to the system, then check that ticket search, attachment search and reports return the expected results. Ask your implementer which rebuild procedure the target release expects, run it in staging, and time it there so the production window is based on a measured duration. Keep the Elasticsearch settings and cluster sizing in version control with the rest of the deployment, so the rebuild can be repeated after a restore or a migration.
Finish with a handover pack that the operations team can use without the original builders. It should include the chart version and values files under version control, a component map covering pods, PostgreSQL, Redis, Memcached and Elasticsearch with named owners, the backup and restore runbook with the date of the last successful restore test, the upgrade and rollback runbook, the index rebuild steps, the alert list with thresholds, the secrets inventory with a rotation owner, and an escalation path. Zammad support on Kubernetes covers the application, not Kubernetes-specific issues, so record which vendor or internal team handles each type of fault before go-live.
Questions teams ask before deploying Zammad on Kubernetes
Is the official Zammad Helm chart enough for a production deployment?
The chart is a starting point, not a complete production design. Zammad stores its content in PostgreSQL 15 or newer, requires Redis 7 or newer for realtime websocket communication, and needs Memcached when several Zammad instances run as containers or cluster nodes. Elasticsearch is optional but strongly recommended for search, reporting and attachment search. You also need a reverse proxy (Nginx or Apache), TLS, backups, monitoring and mail configuration. Confirm in the chart documentation which of these components it deploys and which you must supply, then decide where each one runs.
What skills does our team need to run Zammad on Kubernetes?
Your team needs working knowledge of the Kubernetes platform itself, plus the services Zammad depends on. In practice that means cluster administration, persistent storage and storage classes, ingress and TLS, and operating PostgreSQL and Redis with backups and upgrades. Teams that enable Elasticsearch also need search cluster operations, and teams that receive email through Zammad need mail server and mailbox configuration. Confirm which of these skills already exist in your platform team, and which will need an external partner or additional training.
How do agent count and data volume change the effort and cost?
Self-hosted Zammad has no license fee, so the cost is infrastructure, support and staff time. More agents raise concurrent load on the application, Redis, Memcached and PostgreSQL, which affects node sizing and database capacity. Data volume affects storage growth, backup duration, Elasticsearch index size and the size of any migration. The hosted option is priced per agent per month, with tiers of up to 5 agents at 7 EUR (annual billing), up to 35 agents at 16 EUR and unlimited agents at 25 EUR, according to Zammad's pricing page. Ask any partner to size the design from your agent count, ticket history and attachment volume.
How long does a Zammad deployment on Kubernetes take?
The duration depends on scope rather than on the chart alone. A single environment with default settings takes far less effort than a deployment that includes SSO, Elasticsearch, email channels, a helpdesk migration, multiple environments and acceptance testing. The effort for each item should be stated in the written scope, along with the milestones and the client responsibilities that can delay them. Most DeployOpen engagements are fixed-scope, so the timeline is agreed in writing before work starts. Ask any provider for a breakdown by workstream, not a single figure.
Can our internal team deploy Zammad on Kubernetes without an outside partner?
Yes, if your team already runs Kubernetes, PostgreSQL, Redis and storage well and has time to test upgrades and recovery before go-live. The main risks are underestimated dependencies, untested backups and upgrades that are delayed until a security release is urgent. A partner is most useful when the scope is fixed, the skills are missing, or the deadline is short. DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, and can also provide ongoing support as a retainer.
What does Zammad support cover on Kubernetes deployments?
Zammad support covers the Zammad application. It does not cover Kubernetes-specific issues such as node failures, cluster networking, storage class behavior or ingress controllers, so those need your platform team or another provider. Self-hosted support subscriptions are named Business at 2,999 EUR per year, Enterprise at 5,999 EUR per year and Corporation at 9,999 EUR per year, with response times of 6 hours, 4 hours and 2 hours respectively, according to Zammad's pricing page. Confirm with Zammad how it handles issues that involve both the chart and the application before you rely on it.
Which Zammad release should a new Kubernetes deployment target?
Choose the current release line when you build, then pin the chart and application versions so upgrades are deliberate. Zammad 7.2 was released on 23 September 2026 as a minor release, followed by security releases 7.2.1 on 6 October 2026 and 7.2.2 on 8 October 2026. Security fixes for the 6.5 line were published separately, with 6.5.5 on 15 October 2026. Check the Zammad releases page on the day you start, confirm which line your team will maintain, and test each security release in a non-production environment before it reaches the cluster.
Is Elasticsearch required when running Zammad on Kubernetes?
No, Elasticsearch is optional, but Zammad strongly recommends it. It provides faster search, reporting features and search across email attachment content. On Kubernetes it becomes another stateful service with its own storage, memory, sizing and index rebuild requirements after upgrades or migrations. Decide early whether your agents need attachment search and reporting, because that choice changes the infrastructure you must provision and operate. Confirm the sizing for your data volume with your Elasticsearch operations team before you commit to a design.
How DeployOpen scopes, builds and hands over a Zammad Kubernetes deployment
DeployOpen approaches Zammad on Kubernetes with Helm as a fixed-scope engagement inside your own cluster and cloud accounts. We agree the scope in writing first, then build, test, document and hand over the deployment. Zammad's own support covers the application, so the scope needs to name who owns the Kubernetes platform.
How we scope
- The written scope names the Zammad chart version, PostgreSQL, Redis and Elasticsearch choices before any work starts.
- Scope records which cluster, namespaces, storage classes and ingress controller the deployment will use.
- Ongoing support after go-live can be added as a retainer, and the boundary with Zammad support is written down.
How we build
- Deploy the official Helm chart with values files kept in version control, so every change is reviewed and repeatable.
- Provision PostgreSQL 15 or newer, Redis 7 or newer, and Memcached for multi-pod Zammad instances.
- Front Zammad with a TLS-terminating Nginx or Apache reverse proxy, tested end to end before cutover.
How we hand over
- Documentation covers the values files, secrets handling, storage layout and the upgrade runbook for your team.
- Backup and restore steps for PostgreSQL and attachment storage are tested and documented before handover.
- A written support boundary separates DeployOpen work, Zammad application support and cluster issues.
How we support
- Upgrades follow Zammad's minor and security releases, tested on a staging cluster before production rollout.
- Scaling changes, such as adding Zammad pods or adjusting Elasticsearch, are reviewed against the written scope.
- Retainer support can include testing customizations before each Helm chart upgrade, so breaking changes surface before production.
