Layer 5 · self-hosting reality check
What it actually takes to self-host Zammad
The docs say 6 GB, plus 4 GB more if Elasticsearch runs on the same server. The Docker Compose guide asks for at least 4 GB just to start the containers.. In practice you want 16 GB for a single-server install. The vendor's floor is 6 GB for Zammad plus 4 GB for Elasticsearch, and the usual VPS size above that is 16 GB. You can fit it on 8 GB by capping the Elasticsearch heap, which Zammad itself calls a less-than-ideal fix.. Here is the honest version — real requirements, real monthly cost, what you will be maintaining, and the one thing that catches people out.
Usually reached from Freshdesk alternatives, where Zammad is one of the picks.
Wondering whether you need to at all? Is Freshdesk free? — what the free tier actually allows, and where the wall is.
| RAM — documented minimum | 6 GB, plus 4 GB more if Elasticsearch runs on the same server. The Docker Compose guide asks for at least 4 GB just to start the containers. |
|---|---|
| RAM — what it really needs | 16 GB for a single-server install. The vendor's floor is 6 GB for Zammad plus 4 GB for Elasticsearch, and the usual VPS size above that is 16 GB. You can fit it on 8 GB by capping the Elasticsearch heap, which Zammad itself calls a less-than-ideal fix. |
| CPU | 2 cores minimum; the vendor's 40-agent example uses 6 |
| Disk | Attachments are stored inside PostgreSQL by default, so the database is what grows. Zammad deduplicates identical attachments, and the Elasticsearch index takes its own space on top. Zammad says it cannot recommend a disk size because it depends too much on how you work. |
| Monthly cost | $48–96/mo for a 10-agent instance on a 16 GB VPS with Elasticsearch on the same box; $24–48/mo on 8 GB with a capped Elasticsearch heap |
| Setup time | 2–3 hours with Docker Compose, including the Elasticsearch host setting; email channels and triggers take longer |
| How you install it | docker compose from zammad-docker-compose, which bundles the Rails app, scheduler, websocket, nginx, PostgreSQL, Redis, Memcached, Elasticsearch and a backup service. There are also official DEB/RPM packages, and a Helm chart for Kubernetes. |
| Ongoing maintenance | Regular Zammad releases pulled with git pull and docker compose, PostgreSQL major-version bumps (15 or newer is now required), Elasticsearch upgrades followed by a search-index rebuild, and backups that follow the Docker-specific procedure. Zammad does not support problems that are specific to Docker. |
| Where it stops scaling | The vendor sizes up to 40 agents at 6 cores and 12 GB with Elasticsearch on the same box. Past that, move Elasticsearch and PostgreSQL to their own hosts and tune Zammad's worker settings, or move to the Helm chart. |
The thing that catches people out
Elasticsearch is technically optional, but without it Zammad's search is 'very limited', so everyone runs it, and it is the part that fails. It sizes its Java heap from the memory it can see. In a container or small VM it can see more than it really has, so the kernel kills it and ticket search quietly stops updating. Open Food Facts hit exactly this and called it 'a recurring one'. Set vm.max_map_count=262144 on the host, fix the heap size (-Xms/-Xmx) well below the box's free RAM, and rebuild the search index after every Elasticsearch or major Zammad upgrade.
When not to self-host Zammad
You are two or three people answering one shared inbox. A 10 GB floor with Elasticsearch is overkill for that, and FreeScout runs on a $5 box. Also skip it if nobody will look after a Java search cluster: use Zammad's hosted plan or stay on Freshdesk.
Every guide here carries this section. A site that only ever tells you to self-host is selling something — the useful answer is sometimes no.
Other Layer 5 self-hosting guides
- Self-hosting LibreOffice2 GB with a large spreadsheet open
- Self-hosting ONLYOFFICE6 GB for the Document Server with a handful of concurrent editors
- Self-hosting Collabora Online4 GB, and roughly 1 GB per 20 concurrent documents
- Self-hosting CryptPad2 GB for a small instance
- Self-hosting Mattermost4 GB for a team of 50 with PostgreSQL on the same box
- Self-hosting Rocket.Chat6 GB with MongoDB on the same machine
Common questions
- How much RAM does Zammad actually need?
- 16 GB for a single-server install. The vendor's floor is 6 GB for Zammad plus 4 GB for Elasticsearch, and the usual VPS size above that is 16 GB. You can fit it on 8 GB by capping the Elasticsearch heap, which Zammad itself calls a less-than-ideal fix. in practice. The documented minimum is 6 GB, plus 4 GB more if Elasticsearch runs on the same server. The Docker Compose guide asks for at least 4 GB just to start the containers., which is the figure at which the process starts rather than the figure at which it works under real use. 2 cores minimum; the vendor's 40-agent example uses 6 alongside it.
- What does self-hosting Zammad cost per month?
- $48–96/mo for a 10-agent instance on a 16 GB VPS with Elasticsearch on the same box; $24–48/mo on 8 GB with a capped Elasticsearch heap This is commodity VPS pricing and excludes your time, which is the larger cost for most people — budget for regular Zammad releases pulled with git pull and docker compose, PostgreSQL major-version bumps (15 or newer is now required), Elasticsearch upgrades followed by a search-index rebuild, and backups that follow the Docker-specific procedure. Zammad does not support problems that are specific to Docker.
- How long does it take to set up Zammad?
- 2–3 hours with Docker Compose, including the Elasticsearch host setting; email channels and triggers take longer, via docker compose from zammad-docker-compose, which bundles the Rails app, scheduler, websocket, nginx, PostgreSQL, Redis, Memcached, Elasticsearch and a backup service. There are also official DEB/RPM packages, and a Helm chart for Kubernetes..
- When should I NOT self-host Zammad?
- You are two or three people answering one shared inbox. A 10 GB floor with Elasticsearch is overkill for that, and FreeScout runs on a $5 box. Also skip it if nobody will look after a Java search cluster: use Zammad's hosted plan or stay on Freshdesk.
- What is the most common mistake when self-hosting Zammad?
- Elasticsearch is technically optional, but without it Zammad's search is 'very limited', so everyone runs it, and it is the part that fails. It sizes its Java heap from the memory it can see. In a container or small VM it can see more than it really has, so the kernel kills it and ticket search quietly stops updating. Open Food Facts hit exactly this and called it 'a recurring one'. Set vm.max_map_count=262144 on the host, fix the heap size (-Xms/-Xmx) well below the box's free RAM, and rebuild the search index after every Elasticsearch or major Zammad upgrade.