Which Zammad install method fits your team
If your team has standard Linux operations, the package install is the default to pick. Docker Compose suits a small single-host pilot run by someone comfortable with containers, and the Helm chart suits a team already running Kubernetes with platform staff who own the cluster. Whichever you choose, understand the support boundary first: Zammad's documentation states that it supports the application itself on Docker and on Kubernetes, but not Docker, Portainer or Kubernetes-specific problems. For a regulated helpdesk, that means your platform team carries the cluster, container runtime and networking issues, and you should write that ownership down before go-live.
The package route covers Ubuntu, Debian, OpenSUSE or SLES and CentOS or RHEL, and it keeps Zammad on the same operating system patching and service management your team already runs. Zammad's install pages point teams expecting 5 or more agents to its environment variable and database server configuration pages, so plan for that step early, since a production helpdesk will usually cross that line. The Docker Compose stack needs at least 4 GB of RAM and vm.max_map_count set to 262144 for Elasticsearch, and it uses its own backup and restore procedure, which you should test rather than assume matches your existing backup tooling.
The Helm chart fits when your organization already operates clusters, storage classes, ingress and secrets management, because Zammad adds one application to a platform you already support. It is a poor fit for a single team with no Kubernetes staff, since the operational burden lands on people who are not the Zammad owners. Before choosing, confirm with Zammad which Redis and Memcached topology your chosen method requires, since multi-instance deployments need Memcached. Ask your platform vendor or DeployOpen to document which layer owns each incident path, and decide that before the first pilot ticket arrives.
Which install method suits which team
The package path suits a team that already runs Linux servers, patches them on a schedule and manages PostgreSQL and Redis as ordinary services. Zammad documents package installation on Ubuntu, Debian, OpenSUSE or SLES, and CentOS or RHEL, so the install can follow your existing server standards. Your team owns the operating system, the database and cache servers, the reverse proxy and the upgrade window.
- Supported distributions: Ubuntu, Debian, OpenSUSE or SLES, and CentOS or RHEL, as listed in the package install guide.
- Database and cache: PostgreSQL 15 or newer and Redis 7 or newer, which you install, tune and back up yourselves.
- Reverse proxy: Nginx or Apache, configured and hardened by your team.
- Search: Elasticsearch is optional but strongly recommended, and you operate it if you add it.
- Backups: Your existing backup tooling must cover the database and application files together.
Confirm that your distribution and component versions match the current prerequisites before you commit to this path.
The Docker Compose stack suits a small team that is comfortable with containers and wants one documented, reproducible stack on a single host. It is a reasonable first step for an evaluation or a small production team, but the host, the container runtime and the data volumes remain your responsibility. Zammad supports the application itself, not Docker or Portainer problems, so your team must diagnose host and runtime issues.
- Host sizing: The deployment needs at least 4 GB of RAM, so size the host with headroom for Elasticsearch.
- Kernel setting: Set
vm.max_map_countto 262144 on the host for Elasticsearch. - Backups: Use Zammad's own backup and restore procedure, and rehearse a restore before go-live.
- Multi-instance caching: Memcached is needed for container deployments with more than one Zammad instance, while a single installation can use the file system cache.
- Upgrades: Your team pulls and applies new images and checks the release notes for each step.
Before you choose this path, confirm who will handle container runtime incidents, and whether your host and volume backups meet your recovery requirements.
The Helm chart suits a platform team that already runs clusters, ingress, persistent storage and observability as standard services. Zammad documents a Kubernetes install path through its Helm chart, but states that it does not support Kubernetes-specific issues, only the Zammad application. The platform team therefore owns the cluster and every dependency around the application, and it should decide early who answers for cluster-level incidents.
- Cluster layer: Ingress, storage classes, node capacity and network policy stay with your platform team.
- Stateful dependencies: PostgreSQL 15 or newer, Redis 7 or newer and, for multi-instance setups, Memcached must be provisioned and sized.
- Search service: Elasticsearch is optional but strongly recommended, and running it on Kubernetes adds its own storage and tuning work.
- Secrets and configuration: Your team manages secrets, environment variables and the chart values for each environment.
- Upgrades: Chart versions and application releases are tracked and rolled out by your pipeline.
Confirm which party supports cluster-level failures and whether your internal platform standards allow the chart as delivered.
Zammad's install pages recommend its cloud service as the easiest and often most cost-effective way to operate Zammad. This suits a team that wants a helpdesk running without owning the database, cache, search service, backups or patching. Self-hosting has no license fee, but the cost moves into staff time, infrastructure and support, and Zammad's pricing page states that self-hosted customers handle updates, backups and availability.
- Self-hosted costs: Infrastructure, operating time and any support subscription, which the pricing page lists at 2,999, 5,999 and 9,999 euros per year by tier.
- Hosted costs: Per-agent monthly plans, which the pricing page lists from 7 euros per agent per month.
- Recurring work: Self-hosting recurs for patching, backups, restore tests and capacity changes, while hosted plans shift that work to the vendor.
- Control: Self-hosting keeps data inside your own infrastructure, which may be a requirement in regulated environments.
- Exit path: Ask how data moves between hosted and self-hosted models before you commit.
Request a written comparison of total cost and data residency for your agent count before you decide.
What Zammad support covers on Docker and Kubernetes
Zammad's support on Docker Compose and Kubernetes covers the Zammad application, and nothing underneath it. Zammad documents a Docker Compose deployment and a Kubernetes Helm chart, but its Kubernetes page states that Zammad does not provide support for Kubernetes-specific issues. Its Docker documentation makes the same split: Zammad does not support Docker or Portainer specific problems, only the application itself. For a team that runs the stack on a container platform, a failing node, a broken ingress controller, a storage class that cannot provision volumes or a Portainer stack that will not redeploy all fall on your own engineers or your own service provider, not on Zammad.
Before you choose between the package, Docker Compose and the Helm chart, ask Zammad in writing what support your chosen method receives and whether that answer differs for a self-hosted support plan. Then write the split of responsibility into your operating model before go-live. A useful starting table lists each layer (host operating system, container runtime or Kubernetes control plane, ingress, PostgreSQL, Redis, Elasticsearch, Memcached, Zammad itself, backups and restore tests) and names the owner and the escalation path for each. The Docker Compose deployment also needs at least 4 GB of RAM and vm.max_map_count set to 262144 for Elasticsearch, so the host-level settings belong on that list too.
Self-hosted support from Zammad is a separate purchase. Zammad's pricing page lists self-hosted support plans at 2,999, 5,999 and 9,999 euros per year, and states that self-hosted customers handle updates, backups and availability themselves. Those annual fees cover Zammad's support, not your cluster administration, so budget for internal platform time or a fixed-scope implementation partner for the infrastructure layer, and confirm with Zammad whether any plan covers container or Kubernetes questions at all. DeployOpen can help plan and document that split for an engagement, but the support boundary itself is set by the vendor.
Components and what each method changes
Each Zammad install method moves a different set of components onto your team: the operating system, the container runtime, the cluster, or the cache and search services. Read the cards as a checklist of what you will own under each option before you pick one.
Package install on Linux
The package route installs Zammad on Ubuntu, Debian, OpenSUSE or SLES, and CentOS or RHEL, so your team patches the host, runs PostgreSQL and Redis, and owns the reverse proxy. Zammad's documentation points teams expecting 5 or more agents to its environment variable and database server configuration pages, so plan those settings before go-live. Confirm which operating system versions your distribution supports for the release you plan to run.
Docker Compose stack
The Compose stack bundles Zammad's services into containers, but it still needs a host with at least 4 GB of RAM and vm.max_map_count set to 262144 for Elasticsearch. Backups follow Zammad's own backup and restore procedure, so check that it fits your snapshot tooling. Zammad does not support Docker or Portainer specific problems, only the application itself, so your team must troubleshoot the container layer.
Helm chart on Kubernetes
The Helm chart moves the install into a cluster your organization operates, so storage classes, ingress, node sizing and upgrade windows become your responsibility. Zammad states that it does not provide support for Kubernetes specific problems, which means cluster incidents go to your platform team rather than the vendor. Confirm who owns cluster operations before choosing this route for a helpdesk.
Memcached or file system cache
Memcached is needed when several Zammad instances share work, such as container replicas or cluster nodes. A single installation can use the file system cache instead, which removes one service from the stack. Decide the instance count first, because adding a second node later means adding Memcached to the design.
Elasticsearch as strongly recommended
Elasticsearch is optional, but Zammad uses it for faster search, reporting and searching the content of email attachments, and the vendor strongly recommends it. Each install method treats it differently in practice, since the Compose route needs the kernel setting above. Budget for the extra memory and disk, and test search on realistic ticket volumes before you rely on it.
Reverse proxy choice
Zammad supports Nginx or Apache as the reverse proxy, and the choice shapes TLS termination, websocket handling and certificate renewal. On the package route you configure the proxy on the host, while on Kubernetes the ingress layer may take that role. Confirm which proxy your security team already maintains, and keep websocket support in the test plan because Redis serves realtime communication.
Package, Docker Compose and Helm side by side
This table compares the three Zammad install methods on the factors that decide day-two work: supported operating systems, host requirements, support scope, backups, upgrades, cache model, cluster readiness and team skills. Read each row against your own environment, and treat any item marked to confirm as a question for Zammad before you commit. The main takeaway is that Docker Compose and Helm move more operational responsibility onto your team than the package install does.
| Factor | Package (DEB or RPM) | Docker Compose | Helm chart on Kubernetes |
|---|---|---|---|
| Supported operating systems | Ubuntu, Debian, OpenSUSE or SLES, and CentOS or RHEL, per Zammad's package install page | Any Docker host that runs the Compose stack, to confirm with Zammad's Docker install page | Any cluster the Helm chart targets, to confirm the tested Kubernetes versions with the chart documentation |
| Minimum host requirements | Follow the Zammad software prerequisites for PostgreSQL 15 or newer and Redis 7 or newer | At least 4 GB of RAM, plus vm.max_map_count set to 262144 for Elasticsearch | Node sizing and pod resource limits are not in the supplied facts, so ask Zammad for the reference sizing |
| Support scope from Zammad | Zammad supports the application and its install procedure | Zammad supports the application only, not Docker or Portainer specific problems | Zammad supports the application only, not Kubernetes specific issues |
| Backup procedure | Standard Zammad backup and restore on the host, including the database and file storage | Zammad's own backup and restore procedure for the Compose stack | Confirm with Zammad how volumes, the database and Elasticsearch data are captured in the chart |
| Upgrade path | Package upgrades on the host, with 7.2.2 as the latest security release supplied for the 7.x line | Pull and restart the stack images, following Zammad's release notes | Chart version and application version are separate, so confirm the matching pairs with Zammad before each upgrade |
| Cache model | File system cache is sufficient for a single installation | Memcached is needed for multi-instance deployments such as containers | Memcached is needed for multi-instance deployments such as cluster nodes |
| Cluster readiness | Single host by default; scaling beyond one node needs a documented design | Single host unless you build a multi-host setup yourself | Built for multi-pod operation, but cluster-specific tuning is your responsibility |
| Skills the team must already have | Linux administration, PostgreSQL, Redis and a reverse proxy (Nginx or Apache) | Docker, Compose files, volume handling and Linux host hardening | Kubernetes operations, Helm, persistent storage, ingress and secrets management |
What drives the total cost of each install method
The software itself carries no license fee for self-hosted Zammad, so the cost of any install method is infrastructure, staff time to build and run it, and an optional support subscription. Zammad's pricing page lists self-hosted support plans named Business at 2,999 EUR per year, Enterprise at 5,999 EUR per year and Corporation at 9,999 EUR per year. Those subscriptions cover vendor support for the application, not your servers, your database or your cluster. Whichever method you pick, the largest recurring line is usually the people who patch, back up and restore the system, and Zammad's pricing page states that self-hosted customers handle updates, backups and availability themselves.
One-time work includes provisioning hosts, hardening, configuring the reverse proxy, setting up third-party login, and migrating data from your current helpdesk. Recurring work includes applying minor and security releases (7.2.2 and 6.5.5 both shipped security fixes in October 2026), testing upgrades, verifying backups, and on-call coverage. The Docker Compose stack needs at least 4 GB of RAM and vm.max_map_count set to 262144 for Elasticsearch, and it uses its own backup and restore procedure, so you should price a tested restore drill as recurring work. The package install is the lowest-overhead path on a single host, but you still own the Ruby, PostgreSQL 15 or newer and Redis 7 or newer components as they are upgraded.
The Helm chart adds platform overhead that does not appear in Zammad's own documentation: a Kubernetes cluster, ingress, persistent volumes, Memcached for multi-instance operation, and the cluster skills to run them. Zammad support covers only the application on Kubernetes, so cluster incidents fall to your platform team. Elasticsearch sizing is the cost driver most often underestimated across all three methods. Zammad treats Elasticsearch as optional but strongly recommended for search, reporting and attachment content, and its heap and storage grow with mailbox volume and retention. Ask any vendor or partner to size Elasticsearch from your ticket volume, attachment history and search expectations, and to state the node count, storage and backup approach in the quote. For the support subscription, ask which tier covers your agent count and whether it includes help with the install method you chose.
How to choose and validate an install method
This sequence turns the package, Docker Compose and Helm options into a written decision your team can defend, with a tested restore and a rehearsed upgrade before anything goes live.
Confirm agent count and channels
Count the agents who will work in Zammad at launch and the channels you plan to connect, such as email, web forms or chat. Zammad's install documentation points teams expecting 5 or more agents to its environment variable and database server configuration pages, so a team at or above that threshold should read those pages before choosing. Done means you have a written agent count, a channel list and a note on which configuration pages apply to you.
Map the host and cluster standards you already run
Ask the platform team which operating systems, container runtime, Kubernetes distribution, reverse proxy and database service they already patch and monitor. Zammad documents package installs on Ubuntu, Debian, OpenSUSE or SLES and CentOS or RHEL, a Docker Compose stack and a Helm chart. Compare each option with the standards you already support, and confirm that PostgreSQL 15 or newer and Redis 7 or newer can be run to those standards. Done means a single method is chosen with its named owner.
Check the support boundary in writing
Ask Zammad in writing what it supports for your chosen method. Zammad's Docker Compose documentation states it does not support Docker or Portainer specific problems, and its Kubernetes documentation states it does not support Kubernetes specific issues, so support covers the application only. Ask who handles the container platform, the cluster, the database and the search service, and whether a self-hosted support plan covers your environment. Done means you hold a written answer that names each party responsible for each layer.
Confirm the memory and search prerequisites
Check that the target hosts meet the Docker Compose requirement of at least 4 GB of RAM and that vm.max_map_count is set to 262144 for Elasticsearch where that method is used. Confirm Elasticsearch is planned, because Zammad describes it as optional but strongly recommended for faster search, reporting and attachment search. For multi-instance deployments such as containers or cluster nodes, confirm Memcached is in the design. Done means a checklist of hosts, settings and services is signed off by the operations owner.
Rehearse backup and restore on a test instance
Run the backup procedure for your chosen method against a non-production instance, then restore it to a clean host or cluster namespace. For Docker Compose, use the backup and restore procedure Zammad documents for that stack. Verify that tickets, attachments, users and settings return, and that search and websocket features work after the restore. Done means a restore log with the date, the operator and the result, stored where the on-call team can find it.
Test the upgrade on a staging copy
Build a staging copy from a production backup and apply the update path you will use in production, starting from the version you run today. Check that database migrations complete, that Redis and Elasticsearch reconnect, and that integrations and third-party sign-in still work. Zammad publishes minor and security releases on separate tracks, so note which release line you are on before testing. Done means a staging report with the versions tested, the steps that needed manual work and the rollback steps confirmed.
Record the decision and schedule production cutover
Write down the chosen install method, the support boundary, the restore and upgrade results and the owner for each layer. Agree the production cutover and rollback plan with the change board before go-live. Confirm that the team has a named person for security updates on both the current and any parallel release line. Done means a signed decision record that a future auditor or new administrator can read without asking the original team.
Questions teams ask before choosing a Zammad install method
Does Zammad support Kubernetes-specific problems?
No. Zammad's Kubernetes guidance points to the Zammad Helm chart and states that Zammad provides support for the Zammad application only, not for Kubernetes-specific issues. Problems with the cluster, ingress, storage classes, node scheduling or the Helm release tooling fall to your platform team or to whoever runs the cluster. Before you choose this route, confirm who on your side owns cluster operations, and ask your Zammad support contact how application issues are handled when a cluster fault is involved. A cluster you already run and operate well is the condition under which this method makes sense.
How much RAM and kernel configuration does Docker Compose need for Zammad?
The documented Docker Compose deployment needs at least 4 GB of RAM and requires vm.max_map_count set to 262144 on the host, because Elasticsearch depends on that kernel setting. Those are minimums, not sizing guidance for your ticket volume, so plan headroom for search indexing and attachments. The host setting applies to the machine itself, which matters if the host is shared with other containers or if your hardening baseline limits kernel parameters. Backups follow Zammad's own backup and restore procedure, so schedule and test them as part of the stack rather than assuming host snapshots cover the data.
Can our team run the Zammad package install on its own?
Yes, if your staff can run a supported Linux server and manage its services. Zammad documents package installation on Ubuntu, Debian, OpenSUSE or SLES, and CentOS or RHEL. For teams expecting 5 or more agents, Zammad points to its environment variable and database server configuration pages, so the database layout and service configuration need deliberate planning. The package route also depends on PostgreSQL 15 or newer and Redis 7 or newer, with Elasticsearch optional but strongly recommended for search. Confirm that your OS versions and patch cadence match the packages you plan to run before you commit.
How much staff effort does each install method add to ongoing operations?
The main effort driver is who owns the layer beneath Zammad. With the package install, your Linux administrators own the operating system, PostgreSQL, Redis, the reverse proxy (Nginx or Apache) and any Elasticsearch deployment. Docker Compose moves some of that into container and host management, and it still needs the kernel setting and a tested backup routine. Kubernetes adds cluster operations on top, and Zammad support does not cover that layer. Memcached becomes necessary for multi-instance deployments such as containers or cluster nodes, while single installations can use the file system cache. Ask any implementation partner to break down the effort by layer, and ask your own team which skills are already in place.
Can DeployOpen plan and implement the install method we choose?
DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, which covers a Zammad install on your servers, containers or cluster. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support and upgrades are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope. To get a useful quote, provide your agent count, channels, identity provider, expected data volume, existing database and cluster standards, and the operating model your team will run after handover.
How hard is it to switch install methods after go-live?
Switching is a migration project, so plan it as one. The data lives in PostgreSQL, so the safest path is to take a backup using Zammad's documented procedure, build the target environment, restore, and validate attachments, search and integrations before cutting over. Docker Compose uses its own backup and restore procedure, so a move from a package install should not assume a file-level copy is enough. Elasticsearch indexes can be rebuilt, which affects search availability during the move. Confirm the exact steps for your Zammad version with Zammad's documentation and test the restore in a non-production environment before you retire the old host.
Does the choice of install method change Zammad's license or paid support?
No. Zammad is licensed under the GNU Affero General Public License version 3 regardless of how you install it, and self-hosted Zammad has no license fee. Paid 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, according to Zammad's pricing page. Those subscriptions are separate from your infrastructure and staff costs, and Zammad's pricing page states that self-hosted customers handle updates, backups and availability themselves. Ask Zammad which of the three subscriptions covers the install method you pick, and whether Kubernetes application support is included.
How DeployOpen scopes a Zammad deployment
DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted platforms inside the client's own infrastructure, and a Zammad install is scoped the same way whichever method you pick. For a package install on Ubuntu, Debian, SLES or RHEL, the work usually covers the host build, the PostgreSQL and Redis dependencies, the reverse proxy, the Elasticsearch decision and the backup routine. For a Docker Compose or Helm deployment, it also covers the container host or cluster, persistent storage, Memcached for multi-instance setups and the Elasticsearch host settings. Engagements are typically fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing upgrades, support and testing can be added as optional retainers.
DeployOpen does not publish a price list. A quote follows from the written scope, so the useful input is a clear description of your agent count, channels, identity provider, hosting target and the install method you have chosen. Ask the vendor or DeployOpen to state which components are one-time (build, configuration, migration, hardening, documentation) and which recur (upgrades, backups testing, monitoring, support). Confirm in writing who owns Kubernetes-specific troubleshooting, since Zammad support covers only the application itself for that method. Also confirm who is responsible for the platform upgrades Zammad publishes, such as the 7.2 line and its security releases, and how those are tested before they reach production.
DeployOpen does not claim vendor partner status or certifications for Zammad, and it does not issue audit reports or attestations. Where your compliance program needs evidence of how Zammad was installed, configured and backed up, DeployOpen can prepare the systems, controls and documentation for an independent assessor to review. Before you sign, ask for the deliverables list, the acceptance criteria for the install, the handover process and the terms for a support retainer, so that the scope you approve matches the work you will receive.
How DeployOpen delivers and supports Zammad installs
DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted open-source platforms inside the client's own infrastructure. For Zammad, that means choosing the install method that fits the team's operating model, then delivering the installation, configuration, evidence and handover in writing.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope names the chosen method: DEB or RPM package, Docker Compose stack, or Helm chart.
- Scope records target operating systems, PostgreSQL, Redis, Elasticsearch and reverse proxy choices, plus identity provider integration.
How we build
- Installation runs in the client's cloud account, data center or air-gapped network, with the agreed install method.
- Configuration covers the environment variables, database server settings and cache choices the team's agent count requires.
- Multi-instance designs add Memcached and shared storage, and the build is tested against the client's own identity and mail flows.
How we hand over
- Deliverables include documented install steps, configuration records and a backup and restore procedure the team can run.
- Handover covers upgrade steps for both package and container paths, so the team knows which upgrade process it owns.
- Compliance evidence, where required, is prepared for the client's own assessor, since DeployOpen does not issue audit reports or certifications.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Confirm in the written scope which layers DeployOpen supports, such as the Zammad application, the host or the Kubernetes platform.
- Ask for the support boundary in writing, since Zammad's own support does not cover Docker or Kubernetes-specific problems.
