English
Zammad Hosting
Run a full helpdesk with ticketing, SLAs, a knowledge base, and shared team inboxes.
No setup fees-
One click deploy -
8 GB RAM Memory needed -
100 GB Disk Space Needed -
From 20 € Price
Official links
Zammad’s official links and original website
Zammad Website
More
Tech
- Docker image
- zammad/zammad:latest
- Default port
- 8080
- Database
- postgres
How Zammad works
Zammad records a customer request as a ticket and keeps messages, notes, assignments, status changes, tags, and related activity in one history. Groups route work to the appropriate team, roles control access, and agents can use macros or text modules for repeatable actions. A knowledge base can publish reusable answers and internal guidance.
Triggers, schedulers, and other automation can respond to conditions without requiring every change to be performed manually. The catalogue stack includes PostgreSQL, Redis, Memcached, a Rails service, scheduler, WebSocket service, and web front end. Elasticsearch is explicitly disabled in the supplied configuration, so the page does not promise an Elasticsearch-backed search deployment.
Key Zammad features
Ticket histories give agents the context needed to continue another person's work. Groups, owners, priorities, states, tags, and roles make responsibility visible, while internal notes let teams collaborate without exposing every discussion to the requester. Macros and automation reduce repetitive updates when the rules are defined carefully.
Reporting, knowledge articles, APIs, and integrations can extend the service. Channel availability still depends on configuration and external providers. In the supplied template, application email is disabled, which materially limits a help desk that would otherwise receive and send many tickets through email.
Zammad vs Zendesk
Zammad is a self-hosted service desk with ticketing, roles, groups, automation, knowledge, and integration options controlled by the operator. Zendesk is a managed customer-service platform that combines ticketing with messaging, voice, knowledge, analytics, workforce tools, administration, and a large marketplace.
Zendesk may suit organisations that want a provider-operated omnichannel suite and commercial support around a broad ecosystem. Zammad is appealing when infrastructure control and a self-hosted ticket history matter, provided the organisation can operate the application and accepts the channel limitations of its chosen deployment.
Who uses Zammad
Support teams use Zammad to assign customer cases, preserve conversation history, and coordinate work across groups. Internal service desks can track employee requests, while technical organisations connect web forms or approved integrations to a common queue.
A ticket system needs defined ownership, service categories, escalation rules, statuses, and retention. Automation should be tested against real cases before it changes large numbers of tickets. Without application email, the hosted setup is best evaluated for web-based, API-driven, or internal workflows rather than a conventional email-first help desk.
Self-hosting Zammad: requirements and cost
Capacity is driven by agents, tickets, articles, attachments, events, concurrent sessions, reports, automation, integrations, and retained history. PostgreSQL stores the primary records; Redis and Memcached support the service. AvaHost includes PostgreSQL but leaves it unmanaged, and the base requirement already maps to the highest public app plan.
Zammad therefore remains on Plan 4 at €20 after applying the database rule and capping app pages at Plan 4. Zammad hosting includes one-click provisioning, a support-domain certificate, automatic application updates, and scheduled backups. Application email is disabled, so inbound email tickets, outbound replies, emailed notifications, invitations, and password recovery are unavailable. Elasticsearch also remains disabled in the supplied stack.
F.A.Q
Zammad is assigned to Plan 4 at €20 because its 6144 MB application minimum already reaches the highest public app-page tier and PostgreSQL still requires additional capacity. Agents, tickets, attachments, reports, automation, integrations, knowledge articles, concurrent sessions, and retained history should be monitored closely when the service becomes operational.
The catalogue provisions PostgreSQL, Redis, Memcached, Rails, scheduler, WebSocket, and web services. PostgreSQL is included but unmanaged, and the components should be recovered as a coordinated stack. Elasticsearch is disabled in the supplied configuration, so administrators should test the available search behaviour rather than assuming a separate Elasticsearch index exists.
A support hostname can serve Zammad with automated HTTPS after DNS points to AvaHost. Use the final address for web forms, agent bookmarks, API clients, and integrations. If the hostname changes, verify sign-in, ticket links, WebSocket activity, callbacks, knowledge pages, and external systems that may still store the previous base URL.
Application email is disabled, so Zammad cannot collect inbound email, send agent replies by email, deliver ticket notifications, invite users through email, or issue password-recovery messages. Web, API, and internal ticket workflows may still be evaluated. Teams needing an email-first help desk should treat this limitation as a deployment blocker rather than a minor missing feature.