Managed Zammad hosting

BusinessOn-prem or sovereign site

Helpdesk and ticketing across email, web forms, chat and messaging, run on your own hardware or in Switzerland and the EU, with every customer conversation in your own database. Pilae runs it on your own servers, or in Zurich, Switzerland, and eleven other Pilae Cloud regions.

Talk to us about Zammad

Licence: AGPL-3.0-only
Runs on: Your own hardware, or any of twelve Pilae regions — six of them in Switzerland and the EU
Upgrades: Pinned, tested against your configuration, applied in your window
Upstream: zammad.org

Running Zammad in production: what it takes

Deploy the stack, pinned
The Zammad web, websocket and scheduler containers with PostgreSQL, Elasticsearch, Redis and Memcached, each on a version we have run. Attachments go to the filesystem store from the first day, not into the database.
Connect the mailboxes and watch them
Each support address becomes a channel, with OAuth for Microsoft 365 and Google. Our 60-second probes read Zammad's health check, which reports a stalled scheduler, failed background jobs and any mailbox it cannot reach, and a failing check alerts an engineer.
Agents sign in through your IdP
Agents sign in through Keycloak or your own IdP over SAML or OpenID Connect. LDAP sync assigns Zammad roles from directory groups, so a leaver loses access with everyone else.
Back up tickets, rebuild the index
The database dump and the attachment archive go offsite daily, encrypted, labelled with the version they belong to. Once a month we restore them into a scratch instance, rebuild the search index and open a ticket with its attachments.
Upgrade in your window, one major at a time
Zammad should not skip major versions, and some releases ask for a search index rebuild. The Pilae Agent tests each step on a copy, waits for your approval, applies it in your window and keeps the previous version ready.

What Zammad is, and who runs it

Self-hosted Zammad for helpdesk and customer support

Zammad is a helpdesk. Every email, form submission, chat and message becomes a ticket owned by a group of agents, with SLAs, triggers, macros and a knowledge base around it. It fetches email over IMAP and sends it over SMTP, or connects to Microsoft 365 and Google mailboxes. It also takes web forms, chat, SMS, Telegram and WhatsApp, and call events from phone systems through CTI integrations. It covers what support and IT service teams use Zendesk, Freshdesk or OTRS for day to day. Teams whose support is mostly live chat on messaging apps, answered by whoever is online, are often better served by Chatwoot.

Tickets carry names, contracts, complaints and the attachments people send with them, so Zammad runs on machines of its own, in your datacentre or in a Pilae Cloud region: Zurich, one of five in the EU, or one of six further afield. Agents reach it on your private network. The only parts published through the gate on port 443 are the ones customers and messaging services have to reach, such as the web form, the chat and the WhatsApp and Telegram webhooks.

Zammad in production: search, mailboxes and upgrades

Zammad is several processes around one database: a web server, a websocket server that pushes changes to agents’ screens, and a scheduler whose background jobs fetch mail from every mailbox. PostgreSQL holds the tickets and Elasticsearch the search index, with Redis and Memcached beside them. When the scheduler stalls nothing looks broken. New mail stops arriving and the queue looks like a quiet day, so our probes read Zammad’s own health check instead of only checking that the login page loads.

The database and the attachment store are backed up daily, encrypted, to an offsite location in your chosen country, and restored every month into a scratch instance with the search index rebuilt. The Pilae Agent takes upgrades one major version at a time, each step tried on a copy, approved by you, applied in your window and recorded in the console.

Zammad licence and editions

Zammad is AGPL-3.0, and its source code is owned by the Zammad Foundation rather than by Zammad GmbH, the Berlin company that develops it. Keycloak or Entra ID sign-in needs no extra licence, and the optional AI features can run against Ollama or vLLM on your own hardware. Pricing for our operation is on request. Talk to us about the queues you want to bring across.

Zammad ships as one edition. Every channel and feature, SAML, OpenID Connect and LDAP sign-in included, is in the code we deploy, and the plan tiers on Zammad's pricing page apply only to its hosted service. The Zammad Foundation is responsible for the Zammad name and logo as trademarks. Its policy lets a provider use them to describe its services, but not in a product, service or company name or in a way that suggests endorsement, so we describe our work as running Zammad, never as an official Zammad offering. The optional Zammad AI provider is a paid service from Zammad GmbH. The AI features also work without it, against a model you host.

Zammad system requirements

Before anything is deployed, this is what has to exist. We size it with you in the first session, and we say so when your own hardware is already enough.

CPU and memory: 2 vCPU · 10 GBUpstream asks for two cores and 6 GB for Zammad, plus 4 GB when Elasticsearch runs on the same machine. For up to forty agents it suggests six cores.
Database: PostgreSQL 15+The only database Zammad supports. An older instance on MySQL or MariaDB has to be moved to PostgreSQL before it can take current releases, and we do that move when we take it over.
Search: Elasticsearch 8.15+Optional on paper and needed in practice. Without it search is slow and limited, reporting depends on it, and attachment contents are not searchable. The index is rebuilt from the database, not backed up.
Real-time and cache: Redis 7+ · MemcachedRedis carries the websocket traffic that updates agents' screens as tickets change. Memcached holds the cache every Zammad container shares.
Email channels: IMAP + SMTP, or Microsoft 365 / GoogleEach support address is a mailbox Zammad fetches from and sends through. Microsoft 365 and Google mailboxes connect through an OAuth app rather than a stored mailbox password.

Migrating from Zendesk to Zammad

Zammad has a built-in Zendesk migrator that reads through the Zendesk API. Groups, organisations, users, custom fields and tickets with their comments, attachments and tags come across. Triggers, automations, macros, views, SLA policies and Help Center articles do not, and rebuilding them is the bulk of the project. Passwords do not move either, so people sign in through your identity provider instead. The migrator runs once, into a fresh instance, all or nothing, with no delta pass afterwards. Its speed depends on your Zendesk plan's API rate limit, so we time a test import first and plan the cutover around that figure.

Run a test import and time it
Zammad's Zendesk migrator runs against a scratch instance with a full administrator's API token. The run tells us how long the real import will take on your plan's rate limit, and which objects need renaming first, since the migrator cannot take names in Cyrillic.
Rebuild the rules
Triggers, automations, macros, views and SLA policies become Zammad triggers, schedulers, macros, overviews and SLAs, and Help Center articles become knowledge base answers. Team leads sign them off in staging.
Import once, into a fresh instance
The real import runs into a clean instance, in a window sized by the test run. With no delta pass to follow it, tickets that reach Zendesk during the import are finished there.
Move the mailboxes, then the widgets
Support addresses switch when the import finishes. By default Zammad deletes the mail it fetches and sends an auto-reply for each old message it imports as a new ticket. We keep messages on the server instead and bring any backlog in with archive mode, closed and without auto-replies. The web form and chat follow.

What a Zammad restore needs

backup/2026-09-23offsite, encrypted, taken 03:00
- 20260923030001_zammad_db.psql.gztickets, users, settings, 2.7 GB
- 20260923030001_zammad_files.tar.gz/opt/zammad/storage, 46 GB
- zammad-version.txtthe pinned release this dump belongs to
acme/zammad-opsyour repository
- compose.yamlservices and pinned images
- .envhostnames and service URLs, not in the backup
- runbook.mdrestore, reindex, mailbox checks
elasticsearch-datanot backed up, rebuilt from PostgreSQL
redis-data, memcachedsessions and cache, not in the backup

An example restore set. Zammad's own backup is a PostgreSQL dump and an archive of the attachment store, and it is restored onto the Zammad version it was taken from. The environment is not in it and the search index is rebuilt rather than restored, so the monthly drill times the reindex as well.

What Pilae is responsible for

A pinned version

A version we have run, not whatever latest resolves to that day.

A runbook

What it depends on, how it fails, what to do about it. In your repository.

A restore drill

Backups restored on a schedule. A backup nobody has restored is a file.

A patch window

Security updates in a window you agreed, with a rollback ready.

Someone watching

Every endpoint probed on the minute. An alert reaches a person, not a dashboard nobody opens.

Where it runs: zur1, fra1, fal1, gra1, ams1, hel1, lon1, ash1, hil1, sin1, tok1, syd1, on-premZurich, Frankfurt, Falkenstein, Gravelines, Amsterdam, Helsinki, London, Ashburn, Hillsboro, Singapore, Tokyo, Sydney, Your own hardware
Who holds the credentials: You do. Ours are separate, named, logged and revocable with one command. We ask before anything changes outside an agreed window.
If you leave: The machine, the data, the compose files and the runbook are already yours. Nothing stops when our access does.

What drives the price of running Zammad

Pricing is on request: a fixed price for onboarding, then a monthly price for Zammad, quoted in writing within five business days. The plans set what every deployment includes; these are the inputs the quote is built from.

Instance size: The CPU, memory and, where a model runs, the GPUs the app needs for your users and your data.
High availability: One machine with tested restores, or a replicated setup that keeps serving when a node fails.
Storage and backups: How much data it holds, how long backups are kept, and point-in-time recovery for its database.
Plan and support: Essential, Business or Enterprise: support hours, response times in the contract and how often we review the service with you.
Region: Your own hardware, where the infrastructure is already yours, or a Pilae Cloud region, where it is passed through at cost plus a fixed margin.
Sign-on and integrations: Single sign-on, directory sync, mail relays and the other systems the app has to reach.

Zammad: common questions

Is Zammad open source?

Yes. Zammad is AGPL-3.0, and the source code is owned by the Zammad Foundation, independent of Zammad GmbH, which develops it with the community. There is no paid edition of the self-hosted software. Zammad GmbH sells hosting, support contracts, project services and a hosted AI provider, and you need none of them for us to run it.

Where do our tickets and attachments live?

In PostgreSQL and the attachment store beside it, on machines that run only your helpdesk: yours, or dedicated machines in a Pilae region such as Zurich or Gravelines, in ISO 27001-certified datacentres. The search index sits on the same machines.

Can Zammad replace Zendesk?

Yes, for email, web form, chat and messaging support with SLAs, triggers, macros and a knowledge base. Marketplace apps and Zendesk Talk do not carry over. Zammad takes call events from your existing phone system through CTI integrations, showing who is calling and logging the call, but it is not a phone system itself.

Can we use its AI features without sending tickets to a third party?

Yes. Zammad's AI features, such as ticket summaries and the writing assistant, are optional and enabled one by one. They can point at a model you host through Ollama or an OpenAI-compatible server such as vLLM, so ticket text stays on your network.

Can we move from OTRS or Freshdesk instead?

Yes. Zammad has migrators for OTRS 3.1 to 6, Freshdesk and Kayako as well as Zendesk. The OTRS migrator needs a plugin installed on the OTRS side and can bring passwords across from OTRS 3.3 onwards. Every migrator imports into a fresh instance, from one source.

Back to apps

Bring us your Zammad. We will tell you what it takes.

Thirty minutes on the deployment you already have, or the one you are about to start.

Start with one workload Book a 30-minute briefing