Zammad

Last reviewed Sep 13, 2026 · 850 words

Zammad needs 4 GB of RAM, a PostgreSQL database, Elasticsearch, Redis and Memcached before it serves its first ticket. That footprint is the whole decision. If you are a team of 3 or more agents who need SLAs, escalations, a knowledge base and more than one inbound channel, it is the most complete open-source helpdesk you can run and the cost is fine. If you are one person answering support email for a small product, you are about to run seven containers to do what FreeScout does in one PHP process, and you should go there instead.

What you get for the footprint

The ticketing core is mature in the way that only 10 years of production use produces. Tickets arrive from email accounts (IMAP or POP fetch, SMTP out), from a JavaScript chat widget you embed on your site, from a web form, from Telegram, and from social channels. Every ticket has a state machine, an owner, a group, tags, and a full history. Agents get macros, canned answers, and a shared view of who is looking at what in real time.

The features that separate it from lighter tools: SLA definitions with business calendars and escalation triggers, a customer-facing knowledge base with internal and public articles, time accounting per ticket, LDAP and SAML login, and reporting that answers "how long did first response take last month by agent" without exporting to a spreadsheet. The REST API is complete enough that teams wire it to their CRM or to n8n for routing rules the built-in trigger system does not cover.

Against Zendesk, honestly: Zendesk's mobile apps, AI answer suggestions and marketplace are ahead. Zammad's own hosted plan runs about €5 per agent per month at last check, which tells you the self-hosted version is not a loss leader but the product itself. The full comparison is in the Zendesk alternatives guide.

The Docker Compose stack, and the setting that stops Elasticsearch

The official zammad-docker-compose repository is the supported way in. It defines the Rails server, a websocket process, the scheduler, an nginx front end, PostgreSQL, Elasticsearch, Redis and Memcached, and exposes the app on port 8080 by default. Clone it, set the .env values, and docker compose up -d. First boot takes a few minutes while the database migrates and Elasticsearch builds its index.

The one host-level change that trips most first installs:

sudo sysctl -w vm.max_map_count=262144
echo 'vm.max_map_count=262144' | sudo tee /etc/sysctl.d/99-elasticsearch.conf

Without it Elasticsearch refuses to start, and Zammad without search is not Zammad. Give the Elasticsearch container a 1 GB heap on small deployments and 2 GB once you pass tens of thousands of tickets. Put the whole thing behind Caddy or Traefik for TLS; the chat widget and websocket process need a proper origin to behave.

Sizing is about tickets and attachments, not agents

Agent count barely moves resource use. Ticket volume and attachments do: every attachment is indexed for full-text search, so a helpdesk that receives PDFs and screenshots all day grows its Elasticsearch data faster than its Postgres data. A team of 5 agents handling 100 tickets a day sits happily on 4 GB total and 2 cores. At 1,000 a day plan on 8 GB and give Postgres its own disk. Back up PostgreSQL with pg_dump nightly and the attachment volume with whatever you already use; the Elasticsearch index can be rebuilt from Postgres with a rake task, so it does not need backing up at all.

The email channel is where care is needed

Zammad fetches from a mailbox rather than receiving SMTP directly, which is simpler to operate but means your outbound identity depends on the mail provider. Set up SPF and DKIM for the sending address before the first customer reply goes out, or replies land in spam and you learn about it from a complaint. Use a dedicated support mailbox, not someone's personal account, and turn on Zammad's "ignore bounce and auto-reply" detection so out-of-office loops do not create tickets by the hundred.

Chatwoot is the other serious option

If your support is chat-first (website widget, WhatsApp, Instagram) rather than email-first, Chatwoot is the bigger project with the better conversational UI, and it also runs on Rails and Postgres, so the operational cost is similar. Zammad is stronger on classic ticketing discipline: SLAs, escalations, groups, reporting. Most teams know within a minute which of those two sentences describes them.

What I'd do

For a team of 3 to 20 agents handling mostly email with some chat, run Zammad from the official Compose stack on a 4-core, 8 GB VM, Elasticsearch heap at 1 GB, Caddy in front, nightly pg_dump shipped off-box. Configure SLAs in week one, because retrofitting them onto existing tickets never happens. For a solo founder or a two-person team, run FreeScout on the smallest VPS you own and revisit Zammad when you hire agent number three.