Self-hosted Zendesk alternative for EU data residency

Self-hosted Zendesk alternative for EU data residency: what the constraint requires

The residency question covers where every copy of personal data is stored and who can reach it, including the database, attachments, search indexes, backups and logs. Zendesk's Data Center Location add-on keeps some service data in the EEA on Suite Professional and above, so a team that needs full control should first map which data classes it covers and which remain outside it. Under Article 44 of the GDPR, every transfer of personal data to a third country, including onward transfers, must meet Chapter V conditions. The EDPB's Guidelines 05/2021 treat remote access from a third country, even only displaying data on a screen for support, as a transfer, and so is storage in a cloud outside the EEA. Request that data map from the vendor in writing before you decide.

The short answer is that self-hosted Zammad in your own EU infrastructure and Zammad's German-hosted plans are the two options that let you control where all ticket data, attachments and search indexes live. Zammad is licensed under AGPLv3 and self-hosting carries no license fee, so the decision turns on who operates the servers and who can reach them. Self-hosting lets you set the region, the database and search tiers, and the admin access list. For a hosted plan, confirm support access from outside the EU, the sub-processor list and the contract terms. Also check who controls the hosting provider. 18 U.S.C. 2713 requires in-scope providers to preserve or disclose data in their control regardless of where it is located, and the EDPB's Recommendations 01/2020 state that no effective technical measure can address clear-text access that goes beyond what is necessary and proportionate.

DeployOpen plans and implements the self-hosted option inside your cloud account, data center or air-gapped network, and prepares the evidence an assessment will ask for: data flow maps, hosting and region records, access control configuration and backup locations. DeployOpen does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that work. Your data protection officer and counsel should decide whether the Zendesk gap requires a transfer tool, a documented assessment or a move. Plan the exit as well. The EU Data Act, applicable since 12 September 2025, gives customers the right to switch from a data processing service to on-premises ICT infrastructure, and bans switching charges from 12 January 2027 (Articles 25, 29 and 50).

What GDPR Chapter V and the transfer rules require of a help desk

A help desk holds personal data about customers and agents, so every place that data is stored, viewed or accessed counts. The cards below set out the transfer rules, the court and regulator positions behind them, and the disclosure risks that remain even when data sits in the EEA.

Article 44 and the cost of getting it wrong

Article 44 applies to every transfer of personal data to a third country, including onward transfers, and requires each one to meet the Chapter V conditions. Infringements of Articles 44 to 49 can attract fines of up to EUR 20 million or 4% of worldwide annual turnover, whichever is higher. For a help desk, map every system that touches ticket data, including backups, logs, email relays and support tooling, and record where each one runs. Confirm the fine ceiling with your data protection officer before relying on it in a board paper.

Remote access counts as a transfer

EDPB Guidelines 05/2021 state that remote access from a third country is a transfer, even when the person only views data on a screen for support or administration. Storage in a cloud outside the EEA is also a transfer. Vendor engineers in another country who troubleshoot your help desk therefore create transfer exposure, even if the data never leaves the EEA. Ask any vendor where its support staff sit and which access paths it uses.

Schrems II and the transfer tools

On 16 July 2020, the Court of Justice of the EU in Case C-311/18 (Schrems II) invalidated the EU-US Privacy Shield adequacy decision while holding that standard contractual clauses remained valid. Standard contractual clauses still require a case-by-case assessment of destination country law. Where a cloud provider must access data in the clear and foreign public authority powers go beyond what is necessary and proportionate, EDPB Recommendations 01/2020 say no effective technical supplementary measure can be envisioned. Document that assessment before choosing a processor.

Data Privacy Framework status and the pending appeal

Commission Implementing Decision (EU) 2023/1795 finds adequate protection only for US organizations on the Data Privacy Framework List. Its validity is contested: an appeal against the General Court's September 2025 judgment upholding it is pending as Case C-703/25 P. A vendor's certification today does not settle the question for a multi-year contract. Ask whether the vendor is on the list, what its fallback transfer tool is, and how the contract responds if the framework falls.

Third-country disclosure orders under Article 48

Article 48 allows a third-country court judgment or administrative decision requiring disclosure of personal data to be recognized or enforced only when it rests on an international agreement in force with the Union or a Member State, such as a mutual legal assistance treaty. A vendor that receives a direct foreign order therefore faces a conflict between that order and GDPR. Ask your vendor how it handles such requests, whether it notifies customers, and how it limits what it discloses.

CLOUD Act reach under 18 U.S.C. 2713

The US CLOUD Act provision at 18 U.S.C. 2713, added on 23 March 2018, requires electronic communication and remote computing service providers to preserve or disclose data in their possession, custody or control, whether that data sits inside or outside the United States. An EU-hosted help desk run by a US-headquartered provider can therefore still fall within that reach. Ask for the provider's legal entity structure, the location of its keys, and its policy on challenging such requests.

Where Zendesk's EEA data location option meets the requirement and where it stops

The Data Center Location add-on, available on Suite Professional and above, keeps some of Zendesk's service data in the EEA. The word that matters is some. Before you treat the add-on as a residency answer, confirm in writing which data categories it covers, such as ticket content, attachments, audit logs, backups and search indexes. Ask whether any Zendesk support engineer or subprocessor can view that data from outside the EEA. The EDPB's Guidelines 05/2021 state that remote access from a third country, even only displaying data on a screen for support or administration, is a transfer under Chapter V of the GDPR, so support access paths belong in the same review as storage location.

Data location is not the same as legal control. The US CLOUD Act provision at 18 U.S.C. 2713 requires electronic communication and remote computing service providers to preserve or disclose data in their possession, custody or control, whether that data sits inside or outside the United States. A storage region inside the EEA does not by itself remove that reach from a US-headquartered provider. Put this question to your own counsel, and read Zendesk's data processing agreement and government request clauses alongside the add-on order form. The conclusion depends on the contract terms and your data classification, not on the region name alone.

Ask Zendesk for a written answer on five points: the exact data classes in scope, the regions where each class is stored, the subprocessor list with locations, the support access model, and how government requests are handled. Compare that with the self-hosted option. With Zammad on your own infrastructure, you choose where backups, logs and search indexes live and who holds administrative access. Zammad's German-hosted plans shift hosting to German data centers, but you still need written answers from Zammad GmbH on support access, subprocessors and any sub-contracted operations. Keep the answers with your records of processing, because an auditor will ask for them.

Which open-source options keep help desk data under your control

This table compares three ways to keep help desk records in a known location: Zammad on your own EU infrastructure, Zammad's German-hosted plans, and GLPI for internal IT tickets only. Read each row as a question of who controls the servers, backups and search indexes, and treat the confirmation column as the list to close before you sign.

Option	How data location is controlled	Trade-offs	What the reader must confirm
Self-hosted Zammad in your EU infrastructure	You choose the region, cloud account or data center, and you hold the database, attachments and backups	Full control of location and access, but your team or partner runs upgrades, patching, backups and monitoring. Zammad is licensed under AGPLv3 and its source is owned by the Zammad Foundation, so no license fee applies to the software itself.	Where PostgreSQL, Redis, Elasticsearch, Memcached, backups and log files sit, and that every copy stays in the EEA, including replicas and support access
Zammad German-hosted plans run by Zammad GmbH	Zammad GmbH runs the hosted instance in German data centers, so the primary location is set by the vendor contract	Less operational work for your team, but you rely on the vendor's hosting, subprocessors and support staff for access to your data	Named data centers, subprocessors, remote access from outside the EEA, backup locations, and how exit and export are handled under the contract
Zammad support contract for a self-hosted install	Location stays with your own infrastructure, while Zammad GmbH provides support under a paid subscription	Subscription tiers (Business, Enterprise, Corporation) add vendor support, but support engineers may need temporary access, which can count as a transfer if from a third country	Whether support access is remote, from where, and under which controls it is granted and logged
GLPI for internal IT tickets only	You host GLPI on your own servers under GPL-3.0, so location follows your deployment, and it is not built for customer-facing support	Covers ITIL incident, problem and change workflows and asset inventory, but it is not a substitute for a customer support inbox	Whether internal IT data is the only data stored, and that customer tickets are not routed into GLPI
Elasticsearch and search indexes	Zammad uses Elasticsearch for search and attachment content, so indexes hold copies of ticket data	Optional but strongly recommended, and index copies can outlive deleted tickets unless retention is set	Index host location, replication, snapshot targets and index deletion when tickets are purged
Backups and disaster recovery sites	You decide the backup target, which can be object storage or a second site	Backups often sit in a different region or provider from production, which can move data outside the EEA without notice	Backup region, encryption keys, retention periods and whether restores would occur in a third country
Third-country access and legal exposure	Your provider choice determines whether a non-EU parent company or cloud can be compelled to disclose data	Self-hosting on EU infrastructure reduces exposure only if the operator and hosting provider are also EU based and free of non-EU control	Operator ownership, hosting provider jurisdiction, and a documented assessment of foreign authority requests before you engage any processor
Data export and exit	Zammad keeps data in your database, so moving it out depends on your own schema and backups	Migration tooling and API access help, but you still need tested restore and export procedures	Tested export of tickets, attachments and users, and the migration path if you later change hosting

Choosing between self-hosting and German-hosted Zammad

A security team that must show where personal data is stored and processed usually wants the strongest answer: Zammad runs in infrastructure the organization already controls, in a data center or cloud region it selects, under its own identity and key management. Zammad is licensed under the GNU Affero General Public License version 3, so the organization can inspect the source code, and the stack is run by its own staff or a partner it appoints. Every component, from PostgreSQL 15 or newer to Redis 7 or newer and the reverse proxy, sits inside the boundary the security team defines.

Operations: Your team or a contracted partner patches the operating system, database, Redis, search and reverse proxy, and owns backups and restores.
Keys: Disk encryption, database encryption and TLS certificates are managed by your key management process, with no third party holding them.
Access: Administrator access, logging and network segmentation follow your own controls, and third-party login can run through your SAML or OpenID Connect provider.
Remote access: Confirm that no vendor support session can display or export ticket data without your approval, because remote viewing from outside the EEA can count as a transfer.
Cost: Self-hosted Zammad has no license fee, so the recurring cost is infrastructure and staff time.

Before committing, ask who holds administrative access to the hosts and whether any support path reaches production data.

How to deploy Zammad so data stays in the EU

This sequence moves Zendesk data into a Zammad instance whose hosting region, database tiers, sign-in path and backups are all chosen and checked by your team before any ticket is imported.

Map the data and fix the hosting region
Your data protection lead and the Zendesk administrator list every data class in scope: tickets, comments, attachments, users, organizations, and any logs or exports. For each class, record where it is stored today and who can access it from outside the EEA, including support staff and vendors who view screens remotely. Choose an EU data center or a German-hosted plan and write down the region. The step is done when the data map and the chosen region are signed off in writing by the data protection lead.
Choose the deployment method
The platform team picks Docker Compose for a single host or the Kubernetes Helm chart for a cluster, based on the team's existing skills and the number of nodes they expect to run. Zammad documents both methods. If you choose Kubernetes, confirm in writing with your cluster team that you own Kubernetes-specific troubleshooting, because Zammad support covers only the Zammad application on that platform. The step is done when the method is recorded in the architecture decision file with the named owner.
Build the supporting services inside the EU
The infrastructure team provisions PostgreSQL 15 or newer for content, Redis 7 or newer for realtime websocket traffic, and Elasticsearch for search, reporting and attachment content, which Zammad describes as optional but strongly recommended. Add Memcached if you run several Zammad instances or cluster nodes; a single installation can use the file system cache. Place every component, including logs and object storage used for attachments, in the same EU region. Put Nginx or Apache in front as the reverse proxy. The step is done when each service is reachable only from the Zammad application network and a location check confirms all storage sits in the EU.
Configure single sign-on
The identity team connects Zammad to your existing identity provider through SAML or OpenID Connect, which Zammad supports alongside providers such as Microsoft, Google, GitHub and GitLab. Confirm that the identity provider itself keeps user records in the EEA or in a location your transfer assessment covers, since sign-in data is personal data. Test with a small group of agents and at least one administrator account, and disable local password login only after the test passes. The step is done when test logins succeed and the identity team confirms the redirect and certificate settings in writing.
Migrate with the Zendesk migrator
A Zendesk full administrator creates an API token, which Zammad's Zendesk migrator needs, and the migration runs on a new Zammad instance only. Expect all-or-nothing behavior, no user passwords, no differential re-runs and rate limits that depend on your Zendesk plan, so schedule the run with that in mind. Before starting, take a complete export from Zendesk as a fallback copy. The step is done when the import log shows no errors and a sample of tickets, users and attachments matches the source record by record.
Lock down remote access
The security team limits administrative access to named accounts reached through approved networks, and records every vendor or support session that could display ticket content. Under EDPB Guidelines 05/2021, even viewing data on a screen from a third country counts as a transfer, so any remote support must come from EEA locations or be covered by a documented transfer assessment. Enable audit logging for administrator actions and review who holds the admin role. The step is done when the access list is approved and each vendor's remote session path is documented.
Set the backup location and test a restore
The operations team configures backups for the database, attachments and search index to storage in the same EU region, with the same access controls as production. Confirm the backup provider does not replicate copies outside the EEA, and ask for that commitment in writing. Run a restore into a separate EU environment and check that tickets, attachments and logins work. The step is done when a restore test passes and the recovery procedure is filed with the data map from the first step.

Questions buyers ask before choosing an EU-hosted help desk

What does self-hosting Zammad cost compared with a Zendesk subscription?

Self-hosted Zammad has no license fee, so the cost is the infrastructure, the internal admin time and any support contract you choose to buy. Zammad GmbH sells self-hosted support subscriptions named Business at 2,999 EUR per year, Enterprise at 5,999 EUR per year and Corporation at 9,999 EUR per year, according to its pricing page. The main cost drivers are:

Servers for the application, PostgreSQL 15 or newer, Redis 7 or newer and, for larger installs, Elasticsearch and Memcached
Backups, monitoring, patching and certificate management
Staff time to administer the system, which recurs every month
Optional support or implementation services, which are quoted from written scope

Ask any provider for a quote that lists each component separately so you can compare it with your current Zendesk spend.

How long does a Zendesk to Zammad migration take?

Duration depends on ticket volume, the number of custom fields, attachments, integrations and how many people must test the result, so no single timeline applies to every team. Zammad's migrator works only on a new instance and runs as an all or nothing import, so plan for a full test run before cutover. Your internal team needs to provide an API token created by a full administrator, a staging environment, someone who owns the mapping of groups, roles and macros, and people who can verify tickets after import. Ask your provider to confirm the steps and the effort in writing before work starts.

Can our team run the migration and hosting without outside help?

Yes, if you have people who can operate a Linux server, a database, a reverse proxy such as Nginx or Apache, and a container or Kubernetes platform if you use one. Zammad documents package installation, Docker Compose and a Kubernetes Helm chart, but its support on Kubernetes covers only the Zammad application, not Kubernetes-specific issues. Teams without that skill set usually buy outside help for the first build, hardening, backup testing and the cutover, then run the system themselves. DeployOpen plans, implements, hardens, backs up and documents self-hosted platforms in your own infrastructure under a fixed scope agreed in writing, and offers retainers for ongoing support.

What does a German-hosted Zammad plan change for EU data residency?

A German-hosted plan keeps the service in data centers in Germany, which addresses where your data is stored. It does not change who operates the platform, which is Zammad GmbH, so you should confirm with the vendor where backups, logs, support access and subprocessors are located. Remote access from a third country, even only displaying data for support, counts as a transfer under EDPB Guidelines 05/2021. Ask for the processing agreement, the list of subprocessors and the support access procedure before you sign. If you want full control over where the data lives and who can access it, self-hosting in your own EU infrastructure is the option that keeps those decisions with you.

What does Zendesk's migrator leave behind?

The migrator does not move user passwords, so every imported user needs to sign in through a password reset or a configured single sign-on provider such as SAML, OpenID Connect, Microsoft or Google. It also does not support differential migrations, so changes made in Zendesk after the import are not synced and you need a planned cutover window. Rate limits depend on your Zendesk plan, which affects how long the import takes. Plan to keep Zendesk's JSON export as a backup copy, since the CSV export omits ticket comments and descriptions. Confirm each object type you rely on, such as macros, views, triggers and attachments, against the migration documentation before you decommission Zendesk.

How do the Data Act switching rules affect exit planning from Zendesk?

The EU Data Act, applicable since 12 September 2025, gives customers the right to switch from a data processing service to another provider or to on-premises ICT infrastructure. Under Articles 25, 29 and 50, the switch carries a maximum two-month notice period and a 30-day transition, and switching charges are banned from 12 January 2027. For exit planning, this means you can require a structured data export and transition from your current provider, but you still need to test the export, keep a copy of your records and confirm the terms in your contract. Ask your provider how the export formats and transition support line up with these periods, and do not assume that the statutory rights remove every practical effort.

Evidence regulators and auditors ask for under this constraint

A data residency decision is only as credible as the records behind it. The cards below cover the processing, transfer, access and patching evidence that a data protection authority, internal audit or certification body is likely to ask for. DeployOpen can prepare much of this evidence for a self-hosted Zammad deployment, but the conclusions belong to the regulator, the auditor or the certification body.

Record of processing locations

Under GDPR Article 30, a controller keeps a record of processing activities, and for a help desk that record should name every place ticket content, attachments, user profiles and logs are stored or viewed. For a self-hosted Zammad instance, list the database, Elasticsearch index, Redis, backup targets, mail relays and the hosting provider's regions, along with who can open each one from outside the EEA. Check that the record matches the actual deployment, not the plan.

Transfer impact assessments

Where any support staff, hosting operator or subprocessor sits outside the EEA, or where a third-country authority could compel access, the controller needs a documented transfer assessment. The EDPB guidance treats remote viewing of data from a third country as a transfer, so support engineers working from abroad count too. Record the assessment for each third-country link, the supplementary measures chosen and the reason they were judged sufficient.

DPA and standard contractual clauses

A data processing agreement with each processor, and standard contractual clauses under Commission Implementing Decision (EU) 2021/914 for any transfer outside the EEA, form the contractual base of the evidence file. Collect the signed versions for the hosting provider, Zammad GmbH if a support contract is bought, and any backup or email vendor. Confirm which clause module applies to each relationship and that the signatures match the entities actually operating the systems.

Administrator and remote session logs

Auditors ask who could reach ticket data, from where and when. Keep authentication logs for administrator accounts, Zammad's own audit and activity records, SSH and jump host sessions into the database and application tiers, and any remote-access tool used by a vendor. Each log should show the source location, since a session opened from outside the EEA is a transfer even when no file is downloaded. Confirm retention periods with your DPO before you set them.

Backup location records

Backups copy the whole help desk, including ticket content and attachments, so they need their own location record. Document where each backup set is written, the region of the storage bucket or tape site, the encryption keys and who holds them, and how long copies persist after a ticket is deleted. Also record where Zendesk's own export copies are held if you keep one as a fallback, because those copies are personal data too.

Zammad security release history

Auditors and security reviewers look for a dated patch record. Zammad 7.2 was released on 23 September 2026, followed by security releases 7.2.1 on 6 October 2026 and 7.2.2 on 8 October 2026, and security release 6.5.5 on 15 October 2026 covered the 6.5 line in parallel. Keep the release notes, the date each instance was upgraded and the test evidence for each step, so you can show the time between a published fix and its deployment.

How the Data Act supports moving off a cloud help desk later

The EU Data Act gives customers of cloud data processing services a legal right to switch to another provider or to on-premises ICT infrastructure, which matters if your help desk data later moves to self-hosted Zammad. The Data Act has applied since 12 September 2025. It sets a maximum two-month notice period and a 30-day transition, and it bans switching charges from 12 January 2027. Those are statutory limits, not a guaranteed timeline. Ask Zendesk, in writing, how its contract applies notice, transition and any data return obligations to your account, and record the answer before you plan a migration window.

A switching right only helps if the data can leave the service in a usable form. Zendesk offers JSON, CSV and XML exports on Suite Growth and higher and Support Professional and higher, not on Team plans, and the account owner must ask Zendesk support to turn exports on because they are not enabled by default. The CSV export omits ticket comments and descriptions, so it cannot serve as your only copy of a support conversation. XML is capped at 500 MB and is unavailable above 200,000 tickets, while Zendesk recommends JSON for accounts of that size. Check the Zendesk export guide for the current options on your plan.

Given those limits, keep an independent JSON export in storage that your organization controls, preferably inside the EEA, and schedule it on a regular basis. Open a sample and confirm that comments, attachments metadata and timestamps are present, because a file that opens but lacks conversation history will not support a later move. Treat this copy as a backup and an audit record, not as the migration path: Zammad's Zendesk migrator does not move passwords and does not support differential runs, so a fresh export is still needed at cutover. Record who owns the export schedule, where files are kept and how long they are retained.

How DeployOpen deploys Zammad under EU data residency rules

DeployOpen plans, implements, hardens and documents self-hosted Zammad inside the client's own infrastructure, so ticket data, attachments and logs stay where the organization's data residency rules require. We prepare the system and evidence that supports a compliance assessment, while independent auditors make any formal determination.

How we scope

Engagements start with a written scope that names the data categories, hosting location and transfer paths to review.
We map every component that stores or processes tickets, including Elasticsearch, Redis, PostgreSQL and backups.
Scope also records who holds administrative and remote support access, from which countries, and under which contracts.
Scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that scope.

How we build

We deploy Zammad on your EU cloud account, data center or private network using the package, Docker Compose or Helm options.
We configure PostgreSQL 15 or newer, Redis 7 or newer, Memcached for multi-instance setups, and a reverse proxy such as Nginx or Apache.
We set up SAML or OpenID Connect sign-in against your identity provider and test access controls and logging.
Where a Zendesk export or migration is in scope, we run it on a new instance and record what was and was not transferred.

How we hand over

Handover includes architecture diagrams, data flow records and a register of every location where personal data is stored.
We document backup, restore and upgrade procedures, including how security releases for the Zammad 6.5 and 7.x lines are applied.
Runbooks cover administrator roles, access reviews and the evidence a compliance team needs for its own assessment.
Your team receives training on day-to-day administration before the engagement closes.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Upgrades are planned against Zammad's release notes and tested in a staging copy before production changes.
Security testing of the deployed application and its APIs can be scoped separately to confirm the controls work as documented.
Confirm with your legal team whether Zammad GmbH support or its German-hosted plans fit your transfer analysis, since those are separate vendor contracts.

Self-hosted Zendesk alternative for EU data residency