Overview
Self-hosted Zammad carries no license fee, because it is licensed under the GNU Affero General Public License version 3. A cost of ownership comparison against hosted plans therefore turns on who pays for infrastructure, operations, staff time and optional support, measured against per-agent hosted subscriptions. The license line is zero on one side, so the real work is putting every other line item into a comparable model.
Teams usually open this comparison in one of four situations: selecting a new helpdesk, moving off a hosted tool that has become expensive or restrictive, answering a data residency question, or preparing a budget review. In each case the question is the same: what does the platform cost over three to five years once the people, servers, backups and support terms are counted? Start by listing the components on each side before collecting any quotes.
Self-hosted cost components include virtual machines or hardware, PostgreSQL, Redis, and, for search, Elasticsearch, plus reverse proxy, backups, monitoring, upgrade testing and the staff hours to run them. Optional support subscriptions are sold by the vendor with stated response times, so confirm whether your model needs one. Hosted plans bill per agent per month, so the agent count and its growth become the main cost driver.
Many organizations work through this comparison internally first, using their own infrastructure rates and staff time. A partner becomes useful when you need a written, scoped total cost model, or when the model depends on an environment design you have not yet made, such as sizing, high availability or data location. Ask for the scope, assumptions and exclusions in writing so the model can be checked against the vendor pricing you collect.
What the cost of ownership work includes
A cost of ownership assessment produces a model you can change as your agent count, hosting choices and support needs evolve. It is an input to your decision, not a quote.
Self-hosted component inventory
Every component the self-hosted option needs is listed with its role: the Zammad application, PostgreSQL 15 or newer, Redis 7 or newer for realtime websocket communication, and a reverse proxy running Nginx or Apache. Elasticsearch is listed as optional but strongly recommended for search and attachment search, and Memcached is listed only if you plan multiple application instances. Each line gets an owner and a hosting location.
Hosted plan comparison by agent count
Hosted plans are billed per agent per month, with Starter, Professional and Plus tiers that cap agent counts differently. The comparison maps your current and projected agent numbers onto each tier, so you can see where the step-ups fall. Confirm the annual or monthly billing terms and what the hosted plan includes before comparing totals.
Support tier comparison
Self-hosted Zammad has no license fee, but Zammad's optional support subscriptions are priced per year across Business, Enterprise and Corporation tiers, with different response times. Compare these against the hosted plan's included support and against any internal or partner support you would otherwise need. Confirm current terms with Zammad before relying on any figure.
Staff time model for operations
The model estimates recurring staff time for minor and security releases, database and search maintenance, backup and restore tests, and monitoring. Security releases can be published on short notice across more than one release line, so plan for unscheduled work. Enter your own hours and rates, since the model should reflect your team's skills and on-call arrangements.
Assumptions register
Each figure in the model is recorded with its source, owner and the date it was confirmed, including hosting prices, support terms, staff rates and expected growth. Assumptions that drive the result most are marked so reviewers can challenge them first. The register makes the model auditable by finance, security and procurement.
Data location and sensitivity factors
The model records where ticket data, attachments and backups would live, since the hosted option runs in a data center in Germany and the self-hosted option runs wherever you choose. Data location affects transfer, backup and compliance costs that a per-agent price does not show. Confirm residency and retention requirements with your legal and compliance teams before comparing options.
What drives the total cost
This table lists the drivers that move the total cost of self-hosted Zammad and hosted plans, why each one matters, and how to keep it under control.
| Driver | Why it moves cost | How to keep it under control |
|---|---|---|
| Agent count | Hosted plans price per agent per month and change tier at 5 and 35 agents, so each added agent can move the plan. | Count named agents and peak concurrent use, then check where the tier boundaries fall before committing. |
| Instances and shared services | Multi-instance deployments need Memcached, shared PostgreSQL and Redis, which add servers, monitoring and backup scope. | Start with a single instance unless availability needs justify more, and confirm the Memcached need for your deployment method. |
| Elasticsearch size and hosting | Elasticsearch is optional but strongly recommended. Running it in-house adds hosts, patching and index rebuilds, while a bought service adds a recurring fee. | Size the cluster from attachment volume and reporting needs, and ask the quote to price the hosting model you choose. |
| Support tier | Business 2,999, Enterprise 5,999 and Corporation 9,999 EUR per year, with 6, 4 and 2 hour response times (Zammad pricing page). | Match the tier to how long the helpdesk can wait for a fix, and confirm in writing what each tier covers. |
| Release handling | Security fixes shipped on 6.5.5 (15 October 2026) and on 7.2.1 and 7.2.2 (6 and 8 October 2026), so staff may need to track two lines. | Choose one release line on purpose, keep a test environment, and plan staff time for security releases on that line. |
| Data location and residency | Hosted plans run in a data center in Germany. Self-hosting keeps data where you place it, but residency rules can require in-region backups and logs. | List every data store, including backups, search indexes and logs, and confirm where each must reside. |
| Staff skills | Running PostgreSQL 15 or newer, Redis 7 or newer and Elasticsearch needs skills in-house or paid support time, and gaps show up as outages and slow upgrades. | Inventory database, cache and search skills before choosing self-hosting, and ask partners to quote the components in scope. |
How the assessment runs
The sequence turns scattered helpdesk facts into one cost model that your infrastructure, security and finance owners have each checked against their own assumptions.
Confirm requirements and constraints
We record the number of agents and how they split across teams, the channels in use (email, chat, web forms and phone), expected ticket volume, data residency rules and retention periods. The output is a written requirements sheet that you sign off before any costing starts.
Design the self-hosted reference architecture
We map the components a self-hosted Zammad needs, including the application, PostgreSQL 15 or newer, Redis 7 or newer, the reverse proxy, and optional Elasticsearch and Memcached for multi-instance layouts. The output is a reference diagram with sizing assumptions that your infrastructure team can challenge.
Price the hosted options from published plans
We take the hosted per-agent plans from Zammad's published pricing page and map your agent count and growth against each tier and its agent limit. The output is a side-by-side table showing which tier fits and where a higher tier would start to apply, with the data location each plan states.
Build the staff-time and support model
We estimate the internal hours for administration, upgrades, backups, monitoring and on-call, then compare them with the self-hosted support options and their stated response times. The output is a staffing model that shows which costs recur and which are one-time.
Run the three-way review
We walk through the draft model with your infrastructure, security and finance owners, recording each challenge and how it changes the assumptions. The output is a reviewed model with a named owner for every assumption that remains open.
Deliver the model with assumptions and sensitivities
We deliver the cost model with its assumptions, the inputs that move the result most, and the questions to ask any vendor or partner in a quote. Timing follows the written scope agreed before work starts.
Recurring costs after go-live
This table lists the recurring cost lines for self-hosted and hosted Zammad, with list prices from the Zammad pricing page and an illustrative example, so you can see which costs are priced and which you must confirm.
| Cost line | Self-hosted | Hosted |
|---|---|---|
| Software licence | No license fee for the AGPL-3.0 licensed software | Per agent per month: 7 EUR (up to 5 agents, annual billing), 16 EUR (up to 35 agents), 25 EUR (unlimited agents) |
| Vendor support | Optional subscription: 2,999 EUR (Business), 5,999 EUR (Enterprise) or 9,999 EUR (Corporation) per year | Confirm with Zammad which support levels and response times the plan includes |
| Infrastructure | Application servers, PostgreSQL, Redis, Elasticsearch, reverse proxy and Memcached for multi-instance setups, billed by your cloud or data center | Hosted in a Zammad data center in Germany; confirm what the plan covers and what sits outside it |
| Backups and storage | Backup storage, retention and restore testing, sized to your ticket and attachment volume | Confirm backup frequency, retention, export rights and any storage limits in the service terms |
| Staff time for upgrades and patching | Your team or partner applies minor, security and major releases and rebuilds search indexes when needed | Confirm which updates the vendor applies and what your team still manages, such as configuration and integrations |
| Illustrative: 10 agents | Business support at 2,999 EUR per year, plus infrastructure and staff time, which are not priced here | Professional plan at 16 EUR per agent: 160 EUR per month, or 1,920 EUR per year at list price |
How the comparison changes by starting point
Teams leaving a hosted helpdesk usually compare a per-agent subscription with the cost of running their own platform. Self-hosting replaces that recurring line with infrastructure, staff time and, if chosen, a support subscription.
- Subscription line: hosted fees stop at cutover, but confirm the notice period and any data export terms in your current contract.
- Infrastructure: application servers, PostgreSQL, Redis and Elasticsearch become recurring costs you own.
- Migration: Zammad includes migrators for Freshdesk and Zendesk, which can reduce one-time effort. Confirm how your export covers attachments and history.
- Data location: hosted Zammad runs in a German data center. Self-hosting lets you choose the location, which affects your compliance review.
- Staff time: your administrators take on patching, backups and monitoring that the vendor handled before.
Organizations replacing an older self-managed ticketing tool already pay for servers and staff. The comparison focuses on what changes at retirement and what the new platform adds.
- License line: Zammad has no license fee for self-hosted use, so any commercial license for the old tool can end once data is moved.
- Server and maintenance: retiring old hosts removes their hardware, operating system and database upkeep, but the new stack adds Redis and search services.
- Migration path: OTRS has a built-in migrator. For other systems, the Zammad API or custom development is needed, and that effort is one-time but can be significant.
- Skills: staff familiar with the old tool may need training, which is a one-time cost. Ask whether knowledge of custom scripts can transfer.
- Support: if the old tool has no supplier, a support subscription replaces an informal dependency with a defined service level.
Running Zammad on Kubernetes with the official Helm chart moves the application into a cluster your team or partner operates. Zammad support covers the Zammad application only, so cluster operations remain your responsibility.
- Cluster costs: if you already run a cluster, Zammad adds capacity rather than a new platform. A dedicated cluster adds its own infrastructure and operations cost.
- Kubernetes operations: cluster upgrades, node maintenance, storage classes, ingress and certificates stay with your team or partner, and this effort recurs.
- Multi-instance needs: Memcached is required for multi-instance deployments such as containers, so confirm it is sized and monitored.
- Support boundary: application issues go to Zammad support under the chosen subscription tier, while Kubernetes-specific issues need your own escalation path.
- Ownership: ask a partner to confirm who is on call for the cluster, the database and the application before the cost model is final.
In an air-gapped or data-center-only environment, hosted plans do not fit because ticket data cannot leave the network. The cost model shifts toward local infrastructure, offline maintenance and internal staffing.
- Hosted line: the per-agent hosted fee is removed from the model because the hosted service is not an option in this setting.
- Hardware: servers, storage and backups must be sized in your own facilities, and this is a one-time purchase plus refresh cost.
- Offline updates: security releases must be moved into the isolated network, tested and applied. Confirm the process your team will use and how the Elasticsearch index is rebuilt after updates.
- Support delivery: ask whether the subscription support workflow works without outbound connectivity and how remote assistance is handled.
- Staff time: offline patching and testing usually take more administrator time than connected operations.
A mixed model keeps the application on your infrastructure and buys a Zammad support subscription. The license line is zero, and the subscription becomes the main vendor cost.
- Subscription tiers: the Business tier is listed at 2,999 EUR per year, Enterprise at 5,999 EUR per year and Corporation at 9,999 EUR per year, according to the Zammad pricing page. Confirm current pricing before budgeting.
- Response times: the Zammad pricing page lists 6 hours for Business, 4 hours for Enterprise and 2 hours for Corporation. Choose the tier that matches your helpdesk's tolerance for downtime.
- Recurring cost: the subscription renews each year, so include it in your annual budget alongside infrastructure and staff time.
- Internal effort: support covers vendor-side issues, not your own troubleshooting, so keep administrator capacity in the model.
- Quote request: ask for the subscription terms in writing, including what happens to support if you move to a new major version.
What the client needs to provide
A fair comparison between self-hosted Zammad and a hosted per-agent plan depends on inputs only the client can supply. Start by collecting current agent and seat counts split by role, such as agents, administrators and light agents, along with a realistic forecast for the next two to three years. Hosted pricing is quoted per agent, so the agent count and its growth path drive most of the subscription line, while self-hosted infrastructure scales with ticket volume, attachments and concurrency instead.
Next, document the channels in use (email, chat, web forms and phone) and the historical ticket and attachment volumes for the last 12 to 24 months. Attachment volume matters more than many teams expect, because it affects PostgreSQL storage, backup size and Elasticsearch indexing of attachment content. Ask your helpdesk team to export or estimate these figures from the current system, and state which ones are measured and which are estimated.
Legal and compliance owners should confirm data residency, retention periods and any deletion obligations for customer correspondence. The hosted plans run in a data center in Germany, so any requirement to keep data in a specific country, region or your own facilities must be checked against that fact before comparing options. Also confirm current infrastructure costs you could reuse, such as virtualization capacity, storage, backup tooling and monitoring, and whether your organization has a hosting option already approved for this data class.
Name the people who will run the stack. A self-hosted deployment needs staff who can operate PostgreSQL, Redis, Elasticsearch and the reverse proxy, apply security releases and restore backups. List who holds those skills today, how many hours they can realistically give, and who is on call. Finally, name one accountable owner for the decision and a second person who signs off the final figures, so the model, the quotes and the internal assumptions are reviewed by the people who will live with the outcome.
Frequently asked questions
Is self-hosted Zammad free to use, or are there license fees?
Yes, self-hosted Zammad has no license fee because it is licensed under the GNU Affero General Public License version 3. Your costs are the infrastructure to run it, including PostgreSQL 15 or newer and Redis 7 or newer, plus Elasticsearch if you use it for search, and the staff time to install, patch, back up and support the system. These costs recur and depend on your environment, so include them in the model before comparing with a hosted fee.
Is a Zammad support subscription required for self-hosted use?
No, a support subscription is optional. Zammad sells self-hosted support as Business at 2,999 EUR per year, Enterprise at 5,999 EUR per year and Corporation at 9,999 EUR per year, with response times of 6, 4 and 2 hours respectively, according to the Zammad pricing page. Choose a tier based on how quickly you need a vendor response and how much internal capacity you have to resolve issues yourself. Confirm current terms and what each tier includes before budgeting.
How do hosted Zammad per-agent plans compare once agent counts grow?
Hosted plans are billed per agent per month, so cost rises with headcount and steps up when you pass a tier cap. Starter is 7 EUR per agent per month on annual billing for up to 5 agents, Professional is 16 EUR per agent for up to 35 agents, and Plus is 25 EUR per agent with unlimited agents. As an illustrative example, six agents on Professional would cost 96 EUR per month, compared with 35 EUR for five agents on Starter. Model your headcount over your planning horizon, because moving to Plus raises the per-agent rate.
How long does a Zammad cost of ownership assessment take?
The timeline comes from the scope agreed in writing before work starts, so ask for it with your quote. The main drivers are the number of channels (email, chat, forms and phone), how many groups and roles you need, whether you migrate from Zendesk, Freshdesk, OTRS or another system, whether you need SSO, and whether Elasticsearch is in scope. Ask DeployOpen to state the environment assumptions behind the timeline so you can check them against your own infrastructure.
Can our own team build a Zammad cost model without outside help?
Yes, your team can build the model using the published Zammad prices, your agent counts and your own infrastructure and staff figures. Start with the license position, the optional support tiers and the hosted per-agent rates, then add infrastructure for PostgreSQL, Redis, Elasticsearch and any Memcached nodes, plus staff hours for upgrades, backups and monitoring. Use your own ticket volumes and headcount, since those inputs decide which option costs less for you. Outside help is available on a fixed-scope basis if you prefer it.
Where is customer data stored with hosted and self-hosted Zammad?
With hosted Zammad, the service runs in a data center in Germany, according to the Zammad pricing page. With self-hosted Zammad, data stays wherever you deploy it, whether in your cloud accounts, your data centers or an air-gapped network. Confirm the hosted provider's data processing terms, backup locations and subprocessors before signing, and check any residency rules that apply to your sector. For self-hosted deployments, you also decide where backups and Elasticsearch indexes are kept.
How DeployOpen approaches this work
DeployOpen compares self-hosted Zammad with a hosted plan using your own infrastructure, staff time and data location requirements. We then plan, build, document and support the self-hosted option in infrastructure you control.
How we scope
- We write down the self-hosted cost components: servers, PostgreSQL, Redis, Elasticsearch, backups, staff time and any support subscription.
- We compare that model with the hosted per-agent plans, using your agent count, channels and data residency requirements.
- The scope is agreed in writing as a fixed-scope engagement before work starts, so the comparison has a defined basis.
How we build
- We size the self-hosted stack, including search and cache, against your expected ticket volume and agent count.
- We build the deployment in your cloud account or data center, with backups, monitoring and upgrade steps documented.
- We set up a documented routine for applying minor and security releases, with testing before production changes.
How we hand over
- You receive a cost model with recurring and one-time line items, showing who pays for each one.
- Runbooks cover backups, restores, upgrades, Elasticsearch index rebuilds and the operating tasks your team takes on.
- We document where Zammad's support ends and which costs stay with your team, so the ownership boundary is explicit.
How we support
- Ongoing support, upgrades and testing are available as a retainer, scoped in writing to the work you need.
- Zammad's own support subscriptions are bought from Zammad, so we help you compare them with retainer coverage.
- Retainer scope is agreed in writing, so you know which operating tasks are covered and which stay in-house.
