A helpdesk built around conversations
Zammad is an open source helpdesk licensed under the AGPL-3.0. Agents work tickets that arrive by email, web form, chat widget, SMS, messaging channels such as Telegram and WhatsApp, and phone systems through CTI integrations. It includes a knowledge base, SLAs, triggers, reporting and a REST API for connecting other systems.
Zammad suits customer support teams and internal service desks whose main job is answering people quickly across channels. It integrates with i-doit for CMDB lookups; teams that need full asset management keep a separate tool for it. Decide that boundary early, because it shapes groups, ticket fields and integrations.
Components of a Zammad installation
Requirements from the current Zammad documentation. Recheck them before each major upgrade.
| Component | Role | Planning note |
|---|---|---|
| Rails server | Serves the web interface and REST API. | Runs behind Nginx or Apache, which terminate TLS. |
| WebSocket server | Pushes live ticket updates to agent browsers. | The proxy must pass WebSocket upgrades and allow long-lived connections. |
| Scheduler | Runs background jobs such as fetching mail, triggers and SLA checks. | If it stops, new mail stops becoming tickets. Monitor it directly. |
| PostgreSQL | The only supported database from Zammad 7 on. The documentation asks for PostgreSQL 15 or newer. | MySQL and MariaDB installations must move to PostgreSQL before upgrading to Zammad 7. PgBouncer needs session pooling. |
| Redis | Required for WebSocket communication. Redis 7 or newer. | The documentation names Valkey as a drop-in replacement on distributions that ship it. |
| Elasticsearch | Search and reporting. Zammad calls it optional but strongly recommended. | Current releases support Elasticsearch 8.15 or later, below version 10. OpenSearch is not listed as supported. |
| Memcached | Shared cache. | Required when services do not share one filesystem, as in container and multi-node deployments. |
Choose an installation method
Zammad documents four methods. Support and backup tooling differ between them.
Packages
DEB and RPM packages for supported Linux distributions. They include backup and restore scripts under /opt/zammad/contrib/backup. A good fit for a single server.
Docker Compose
The official compose stack runs the Rails server, WebSocket server, scheduler, Nginx, PostgreSQL, Redis, Memcached, Elasticsearch and a backup service. Pin image versions and keep volumes on persistent storage.
Kubernetes
A Helm chart is available. Zammad states that it supports only the application in this mode, so the team running the cluster owns Kubernetes-specific problems.
Source
Possible, but every dependency then needs your own patching and testing. Choose it only with a clear reason.
Size by agents, volume and search
Zammad's hardware guidance lists the number of agents and customers, ticket volume, channel use and installation type as drivers, and says no single figure fits everyone. Its documented starting points are a minimum of 2 CPU cores and 6 GB of RAM, and an example of 6 cores and 6 GB for up to 40 agents. Both need extra memory if Elasticsearch runs on the same server.
Beyond a small team, give Elasticsearch and PostgreSQL their own hosts, and move attachments out of the database. Zammad stores attachments in the database by default and recommends filesystem or S3-compatible storage for busy instances, which keeps the database smaller and backups faster to restore.
Secure sign-in and entry points
Zammad syncs users from LDAP or Active Directory one way and maps directory groups to roles. Organizations cannot be synced. LDAP users can also hold local passwords, because Zammad checks LDAP first and then its own database, so decide how local passwords are handled for directory users.
Both are configured as third-party login providers. By default Zammad creates an account on first login. For staff-only access, turn on the settings that block account creation and link logins to existing accounts by email address.
On self-hosted installations, the web server performs Kerberos authentication and passes the username to Zammad's /auth/sso endpoint in a header or REMOTE_USER variable. Make sure the proxy strips any client-supplied X-Forwarded-User header, since Zammad trusts it on that endpoint.
Each channel is an entry point. Give mailbox connections least-privilege credentials, add spam controls to web forms and chat, and restrict access to CTI endpoints. Require two-factor authentication for agents, keep the admin role small, and keep PostgreSQL, Redis and Elasticsearch on a private network, since the search index holds ticket content.
Migrate from another helpdesk
Zammad ships migrators for Freshdesk, Kayako, OTRS (versions 3.1 to 6.x) and Zendesk. They import tickets and articles, groups or queues, organizations, agents and customers. Limits apply to all of them: migrations run only on a new instance, from one source, and import everything or nothing. Hosted sources import over their APIs, so your plan's rate limits set the pace, and passwords do not carry over from hosted tools.
Run a test import first to learn the duration, then repeat on a fresh instance for cutover. The Zendesk, Freshdesk and Kayako migrators do not support a later differential import, so plan a short freeze on the old system. Zammad recommends the console over the browser wizard for large instances or when imports time out.
There is no built-in migrator for Jira Service Management. With Jira Service Management Data Center reaching end of life on March 28, 2029, teams moving to Zammad use the REST API or a custom import and map request types, queues, SLAs and custom fields deliberately.
Back up and upgrade in order
| Task | Practice |
|---|---|
| Backup scope | PostgreSQL, attachments wherever storage points, configuration and TLS material. The search index can be rebuilt from the database, which takes time on large instances. |
| Package scripts | Zammad ships backup and restore scripts for package installs and says to test and review them regularly. Copy and adapt them when they do not fit your setup. |
| Restore test | Restore to an isolated host, rebuild the search index, and confirm that an agent can open a ticket with attachments and find it through search. |
| Major upgrades | Do not skip major versions. Upgrade through each one in order and read the release notes for breaking changes before every step. |
| Database change | Move from MySQL or MariaDB to PostgreSQL before upgrading to Zammad 7. The migration guide requires Zammad 5.3 or later for that step. |
Zammad operating ownership
Support leads own the workflow. The platform team owns the services underneath it.
Platform
- Monitor the scheduler, WebSocket server, Elasticsearch health and mail fetch errors.
- Keep PostgreSQL, Redis and Elasticsearch on supported versions.
- Test restores and search index rebuilds.
Support operations
- Own groups, roles, triggers, SLAs and text modules.
- Review email routing when teams change.
- Keep knowledge base content current.
Channels
- Track credentials and token expiry for each mailbox and messaging channel.
- Test web forms and chat after website changes.
- Document CTI integration settings.
Security and privacy
- Review admin and agent roles on a schedule.
- Use the data privacy tasks for deletion requests.
- Audit third-party login and account-linking settings.
Zammad questions
Can we run Zammad without Elasticsearch?
Zammad works without it, but its documentation says search becomes slower and very limited. Elasticsearch also powers reports and search inside email attachments, so plan for it in any production deployment.
We run Zammad on MySQL. What now?
Migrate to PostgreSQL on your current major version first. An upgrade to Zammad 7 is not possible on a MySQL installation.
Can we merge two helpdesks during migration?
Not with the built-in migrators. They import from one source into a new instance. Combining sources needs an API-based import.
Do customers need accounts?
No. Customers can work entirely by email, or sign in to the customer portal. Decide per audience and set the third-party login options to match.
Scope and handover
DeployOpen plans the deployment, installs Zammad in your infrastructure, connects channels, integrates LDAP or SSO, sets up search, backups and monitoring, and runs migration tests with your support leads. The work changes with the number of agents and channels, ticket history, the migration source, availability needs and isolated network requirements.
Handover records versions, the installation method, database, Redis, Memcached and Elasticsearch setup, attachment storage, channel credentials and owners, authentication settings, backup and restore results, the upgrade sequence and the support route.
