Zammad high availability starts with shared state, not extra application nodes
When a single Zammad host fails, agents lose their queue and customers lose their channel to your support team. High availability means running several Zammad application instances against shared PostgreSQL, Redis, Memcached and Elasticsearch, with backup and recovery planned around those same components. The application nodes are the easy part. The hard part is making sure every node sees the same data, sessions and realtime events, so that losing one node does not log agents out or drop tickets in progress.
Shared state is where the effort sits. Zammad stores its content in PostgreSQL 15 or newer, so the database becomes the single source of truth and needs its own redundancy plan, such as replication with a tested failover procedure. Redis 7 or newer carries the realtime websocket communication, so a node that receives a browser connection must be able to reach the same Redis as its peers. Memcached is required for multi-instance deployments such as containers or cluster nodes, because the file system cache used by single installations is not shared between nodes. Confirm each of these with the current Zammad software requirements before you size anything.
Session handling, realtime updates and cached objects all have to behave identically on every node. If one node caches a stale user role or misses a Redis event, agents will see inconsistent ticket lists or delayed notifications, and that is hard to diagnose in production. Your reverse proxy also needs a deliberate decision on how websocket connections are routed and whether sticky sessions are used. Nginx and Apache are both supported, so write down which one you run and test websocket upgrades through it during the build.
Elasticsearch is optional, but Zammad strongly recommends it for faster search, reporting and attachment content search. In a highly available design, decide early whether search must survive a node or cluster failure, because that changes the cluster topology, the index replica settings and the backup scope. Treat the search index as rebuildable data, but plan the time it takes to rebuild it.
Most of the work after installation is configuration, testing and operations rather than installing packages. Expect to define the failover runbook, verify that a node can be removed and replaced without user impact, test restores of PostgreSQL and attachment storage, and check what happens during a Zammad minor or security release. Ask any implementation partner to show the test evidence for each failure scenario, and confirm with your own infrastructure team which parts of the stack they will run and which they expect your platform team to own.
Which components must be shared, and which can stay per node
Every Zammad node must read and write the same content, sessions and realtime messages, so the database, Redis and search layers are shared. Application processes and the proxy can usually be repeated per node, but their configuration must match. Use the cards below to confirm which items each node needs to reach and which versions your install method requires.
Zammad application instances
Each application node serves web requests and runs background work for the same helpdesk. All nodes must run the same Zammad release and point at the same database, Redis, Memcached and search settings, because mismatched versions or configurations can break sessions and background jobs. Confirm in the Zammad documentation for your install method where attachments are stored and whether every node can reach that location. A node that cannot see the same attachment store will fail on some ticket views.
PostgreSQL 15 or newer
PostgreSQL is the content store for tickets, articles, users, organizations and settings, so it is the primary shared state. Every node reads and writes the same database, which makes its availability the limit for the whole helpdesk. Confirm the minimum version against the Zammad software requirements before you build. Ask the database team to own replication, backups and a failover procedure that has been tested with Zammad running on top of it.
Redis 7 or newer
Redis carries realtime websocket communication, so agents see ticket updates made on other nodes. Zammad requires Redis 7 or newer, and all application nodes must reach the same Redis service for live updates to reach every browser session. Confirm the supported Redis deployment model with the Zammad documentation before design. Plan monitoring for Redis and decide in advance how agents will be told of degraded live updates during an outage.
Memcached for multi-instance deployments
Memcached is required for multi-instance deployments such as containers or cluster nodes. A single installation can use the file system cache, which stays on one host. With several nodes, a local file cache on each host means nodes can hold different cached data, so the cache must be shared. Confirm the Memcached sizing and connection settings in the software requirements for your version, and test node restarts to see whether cached data is rebuilt cleanly.
Elasticsearch for search and reporting
Elasticsearch is optional, but Zammad strongly recommends it for faster search, reporting and searching the content of email attachments. Every node queries the same search index, so a node with different search settings can return different results. Index rebuilds after upgrades or migrations are a planning item that affects users during the work. Ask for the supported Elasticsearch version and a sizing estimate for your ticket volume before you commit to a cluster design.
Nginx or Apache reverse proxy
The reverse proxy sits in front of the application nodes, distributes requests and usually terminates TLS. It must pass the websocket upgrade headers that Redis-backed realtime updates depend on, or agents will lose live updates without an obvious error. Confirm the proxy configuration in the Zammad documentation for your version. Decide whether requests need session affinity, and test failover of one node while agents are logged in.
Zammad high availability decisions and their operational trade-offs
This table compares the six main decisions behind a highly available Zammad deployment, from install method to backup location. Read each row as a choice with a fit condition and an operational cost in staff time, skills and failure modes. The main takeaway is that every shared service you make highly available adds components your team must run, patch and recover.
| Decision | When it fits | Operational cost and failure modes |
|---|---|---|
| Deployment method | Docker Compose or package installs suit teams with one or two nodes and existing host operations. Kubernetes with the Helm chart suits teams already running clusters and comfortable owning cluster skills. | Package installs are simplest to patch but are hard to replicate across nodes. Docker Compose needs container and volume discipline. Zammad support covers only the application on Kubernetes, so cluster faults fall to your platform team. |
| PostgreSQL placement | Self-managed PostgreSQL fits teams with strong database administration and tested failover. A managed service fits teams that already operate one and want backups and failover handled by that service. | Self-managed replication and failover need DBA time and tested runbooks. A managed service adds a provider dependency and requires confirming that its version meets Zammad's PostgreSQL 15 or newer requirement. |
| Redis and Memcached as clustered services | Dedicated clustered services fit multi-instance deployments, where Memcached is needed, and where websocket sessions must survive a node loss. Single-node setups may keep these on the host. | Each clustered service adds monitoring, memory tuning and failover testing. Redis 7 or newer is required for realtime websocket communication. Loss of these services disrupts live agent views and cached sessions. |
| Elasticsearch availability | Highly available Elasticsearch fits organizations where search, reporting and attachment search are used heavily. Treating the index as rebuildable fits teams that accept slower search during recovery. | Clustered Elasticsearch needs cluster-level skills and capacity planning. A rebuildable index reduces cluster work but lengthens search outages after failure or upgrades. Confirm rebuild procedures with Zammad's Elasticsearch documentation. |
| Reverse proxy and load balancer placement | A load balancer in front of two or more application nodes fits multi-instance designs. A proxy on each node fits simpler layouts where the balancer is provided by existing network infrastructure. | Each option adds TLS certificate handling and health-check configuration. Misconfigured session affinity or health checks can route agents to unhealthy nodes. Confirm proxy support for Nginx or Apache against Zammad's software requirements. |
| Backup storage location | Backups stored in a separate failure domain from the primary cluster fit recovery planning. Backups kept on the same storage as production limit recovery to that storage's failure modes. | Backups need encryption keys, retention rules and restore tests. Restore time depends on database and attachment volume, so ask for measured restore tests rather than estimates. Failed restores are the most common gap found in reviews. |
How to build a multi-instance Zammad in order
This sequence takes a self-hosted Zammad helpdesk from a single installation to several application nodes that share one database, cache, search index and attachment store. Each step closes with a check the team can record, so the setup is proven before live tickets depend on it. The final step is a documented failover test that must pass before go-live.
Confirm software requirements and versions
Start by reading the Zammad software requirements page for the release you plan to run, then record the supported PostgreSQL and Redis versions against your platform's support matrix. Zammad requires PostgreSQL 15 or newer and Redis 7 or newer, so check your database platform and Redis distribution against those minimums. Confirm the reverse proxy and operating system choices on the same page. The step closes when the team signs off a written version list that the build will follow.
Stand up shared PostgreSQL and test failover
Provision PostgreSQL as a shared service that every Zammad node can reach, using the high availability method your database platform supports. Create the Zammad database and application role, restrict network access to the application nodes, and confirm that database backups run. Then trigger a controlled switchover with your platform's own tooling and confirm that Zammad reconnects afterward. The step closes when the switchover completes and a test ticket saves on the new primary.
Deploy Redis and Memcached as shared services
Deploy Redis for realtime websocket communication and Memcached as the shared cache, since Zammad documents Memcached for multi-instance deployments. Place both services on addresses reachable from every application node and restrict access to them. Point each node at the same Redis and Memcached endpoints. Open two browser sessions that reach different nodes and confirm that a change to a ticket appears in the other session without a page reload. The step closes when websocket updates arrive from each node the browser can reach.
Install at least two application instances
Install at least two Zammad application instances using the method your team has chosen, such as package installation, Docker Compose or Helm, and read that method's documented support scope before you begin. Point every instance at the same PostgreSQL, Redis, Memcached and search endpoints, and keep the application version identical across nodes. Run database migrations once, following the documented procedure, then confirm each node starts and serves the login page. The step closes when every node reports the same version and handles requests against the shared database.
Configure reverse proxy and session stickiness
Place Nginx or Apache in front of the application nodes to terminate TLS and balance requests across them. Add session stickiness only if the Zammad documentation for your chosen setup requires it, and confirm that requirement against the documentation for your version before configuring it. Set forwarded headers so Zammad sees the correct protocol and client address, and check that websocket upgrades pass through the proxy. The step closes when login, ticket updates and websocket updates succeed through the proxy address.
Connect Elasticsearch and build the index
Connect Zammad to Elasticsearch so that search, reporting and attachment content search use one shared cluster, and point every node at that cluster. Zammad describes Elasticsearch as optional but strongly recommended, so confirm the supported cluster version and sizing in the Zammad search documentation against your expected data volume. Start the index build from an administrator account and let it finish before agents return to the system. The step closes when a search for a known ticket returns results from each node and the index build reports complete.
Configure shared attachments and scheduled backups
Confirm in the Zammad documentation which attachment storage option applies to your version, then move attachments to a location every node can read and write so an upload through one node is available from all of them. Enable scheduled backups of PostgreSQL, attachments and the Elasticsearch configuration, storing copies outside the cluster. Write a restore procedure for each component. The step closes when a test restore into a separate environment brings back a ticket and its attachment.
Run a documented failover test before go-live
Write the failover test before the test day, listing each component to stop, the expected behavior and the person responsible for each check. Run the test in a non-production copy of the environment first, then against production only after the team agrees on the results. Stop one application node during normal use, fail over the database, restart Redis and confirm cache and websocket behavior, and check that agents can log in and create tickets throughout. The step closes when the test record shows each expected result and the owners approve the go-live decision.
Zammad high availability by deployment environment
A single node runs the Zammad application, PostgreSQL, Redis and any search service on one host or a small set of services. High availability here means fast recovery, not automatic failover, so the design question is how quickly you can restore a working instance after a failure.
- Shared storage: not required. A single installation can use the file system cache, and attachments stay on the storage location you configure. Confirm the storage option you choose against the current documentation.
- Load balancing: no failover pool exists. The reverse proxy still terminates TLS and fronts the one instance.
- Backup scope: the PostgreSQL database, attachment storage and configuration files must be backed up together and restored as a matched set. If the Elasticsearch index is lost, plan a rebuild from source data and measure its duration in your environment.
- Upgrade sequencing: take a verified backup, apply the release, then test login, the email channel and ticket creation before reopening the queue.
Measure a full restore on hardware similar to production, because that elapsed time is the actual outage window for this model.
Several Zammad application nodes sit behind a load balancer and share one PostgreSQL database and Redis. Memcached is needed for multi-instance deployments, so it becomes part of the cluster design. Application nodes can fail over, but the database, Redis and shared storage become the components that must be designed for resilience.
- Shared storage: every node must reach the same attachment storage. Confirm which shared file system or object storage option the version you run supports, and test write consistency under load.
- Load balancing: configure the proxy for session stickiness where needed and for websocket upgrades used by realtime updates. Confirm the Nginx or Apache settings against the documentation for your release.
- Backup scope: back up the database, the shared attachment storage and the Redis configuration. Include the Memcached configuration only if your runbook depends on it. Plan the Elasticsearch index rebuild separately.
- Upgrade sequencing: upgrade one node at a time, remove it from rotation first, and confirm which node runs database migrations so they execute once.
Confirm in the release notes whether a rolling upgrade is supported for the exact version you plan to run before scheduling the change.
The official Helm chart deploys Zammad onto a Kubernetes cluster. Zammad support covers the Zammad application only. Zammad support does not cover Kubernetes-specific issues, so the cluster platform owner must own storage classes, ingress and node failure handling.
- Shared storage: the cluster provides persistent volumes through storage classes. The platform owner must select a class whose access mode supports multiple pods and test it under node failure.
- Load balancing: routing depends on the ingress controller and service configuration. Confirm that the controller supports the websocket connections Zammad uses.
- Backup scope: application-level backups do not capture cluster state. The platform team must own volume snapshots or database backups and prove them with restore tests.
- Upgrade sequencing: check the chart version, the application image and the chart values before the change. Coordinate any cluster upgrade with the Zammad release so both are not changed in the same window.
Write a responsibility matrix that names the owner of each Kubernetes-specific failure, such as a lost node, a full volume or an ingress outage, before go-live.
In an air-gapped network, the install and upgrade process cannot pull images, packages or dependencies from the public internet. Container images, operating system packages, Zammad packages and the Elasticsearch dependency must be mirrored inside the network. Treat this as a planning item to confirm for your install method, not as a step to assume.
- Shared storage: the storage backend must sit inside the enclave and meet the same sharing requirements as the chosen topology.
- Load balancing: use internal load balancing and certificates issued by your internal certificate authority. Confirm that clients trust the chain.
- Backup scope: store backups inside the enclave and include the mirror repositories, so a restore does not depend on external downloads.
- Upgrade sequencing: mirror each release and security update before the change window. Confirm that the Elasticsearch version you mirror is compatible with the Zammad release.
Ask Zammad which artifacts an offline installation requires for your chosen method and build a mirror manifest from that answer before any change window is set.
What drives the effort and cost of a Zammad high availability setup
This table lists the factors that change how much work a highly available Zammad setup takes to build, test and run, and how to keep each one manageable. Read each row as a question to answer for your environment before requesting a quote. The main takeaway is that a standard install, a production-like staging environment and documented runbooks reduce effort more than any single infrastructure choice.
| Driver | Why it changes effort or cost | How to keep it down |
|---|---|---|
| Agents and concurrent users | More concurrent agents increase load on the application instances, PostgreSQL connections and the Redis websocket layer, which affects how many nodes and how much tuning are needed. | Confirm peak concurrent agents with your team before design. Size the load test to that peak rather than to total headcount. |
| Ticket and attachment volume | Large ticket histories and attachment stores increase database size, backup duration, restore testing time and Elasticsearch indexing work. | Set retention and attachment size policies early. Confirm where attachments are stored and how they are included in backups. |
| Channels (email, chat, forms, phone) | Each inbound channel adds mail accounts, webhooks, telephony or chat connectors that must fail over cleanly and be tested after each change. | Limit channels at go-live to what agents need. Document each connector with its owner and its failover behavior. |
| Integrations and API traffic | Scripted API callers and external systems add load, credentials to rotate and endpoints to verify after each upgrade. | Inventory every API consumer and service account. Route integrations through one documented gateway or service account pattern where possible. |
| Number of environments | Test, staging and production each need their own PostgreSQL, Redis, Memcached and Elasticsearch components, so environment count multiplies build and patch work. | Keep staging close to production in topology and versions. Use infrastructure as code so environments are rebuilt the same way. |
| Customization retested after upgrades | Custom triggers, macros, object attributes and scripts may behave differently after a minor or major release and need regression testing on every cluster change. | Keep custom triggers and workflows few and well documented. Store them in version control and keep a regression checklist for each release. |
| Compliance evidence requirements | Assessors may ask for backup restore results, change records, access reviews and availability records, which take time to collect and keep current. | Agree the evidence list before build. Automate exports where the platform allows, and schedule restore tests so records accumulate over time. |
| Team skills in PostgreSQL, Redis and Kubernetes | Gaps in these skills increase time for failover design, troubleshooting and on-call coverage. Kubernetes-specific issues fall outside Zammad application support. | Confirm current skills per component. Use the standard install method for your platform and write runbooks for failover, restore and node replacement. |
| Standard install methods and runbooks | Custom deployment patterns add unique steps that must be rebuilt and understood by each new operator. | Start from a documented install method such as Docker Compose or the Helm chart where it fits your environment. Keep runbooks current with each change. |
How to verify Zammad high availability works and fails safely
Verification starts before any test runs. Write down the expected result for each check, including what a user should see, what an agent should see and how long the team expects a degraded state to last. Recording expectations first keeps the team from rationalizing an unexpected outcome after the fact. It also gives compliance reviewers a clear link between a control and its evidence. Store the written plan, the test window, the people involved and the rollback steps in the same place as the test results.
The first checks confirm that the cluster behaves as one helpdesk. Place two or more Zammad application instances behind the load balancer, then create tickets, replies and notes through different requests and confirm that every node serves the same ticket history, user records and sessions. Repeat the check for an agent who logs in, is routed to a different node and continues working without a second login. Then verify realtime behavior: an agent on each node should see a new ticket or reply appear without refreshing the page. Realtime delivery depends on Redis and the websocket path through the reverse proxy, so a failure here often points to proxy configuration rather than to Zammad itself.
Next, stop one application instance during a defined test window and confirm that users keep working. Watch the load balancer health checks, the number of failed requests, and whether agents must log in again. Then stop Redis, Memcached and Elasticsearch one at a time, not together. For each service, record what stops working, such as realtime updates, cached sessions, search results or attachment search, and what continues. Restart each service and confirm that the platform returns to its expected state. Treat any data loss or stuck queue as a failure of the design, not as an acceptable side effect of the test.
Backups need their own verification. Restore PostgreSQL and the attachment store into a separate environment, never over production data. Confirm that ticket history, article bodies, user assignments and attachments open and download correctly. Check that the restored Zammad version matches the backup's version and that Elasticsearch can be rebuilt from the restored data if search is part of the scope. Ask your implementation partner and your own database team to confirm the exact restore commands, retention settings and the recovery point each backup supports, because these depend on your storage and backup tooling.
Finally, rehearse a full recovery with timed steps. Time each action from the first decision to a usable helpdesk: declaring the incident, provisioning or selecting infrastructure, restoring the database and attachments, reconnecting search, and checking agent access. Compare the measured times against the recovery targets your organization has agreed. Note every step that needed improvisation, and update the runbook before the next rehearsal. Keep the signed results, timings and any gaps as evidence for compliance readiness. This evidence supports an independent assessment but does not replace one, and no certification is implied by completing these tests.
What to monitor, back up, upgrade and document after go-live
This table lists the operational duties that keep a multi-instance Zammad cluster recoverable after go-live, grouped by monitoring, backup, upgrade and documentation. Read each row as a question your team must answer before cutover, with the component named and the evidence to keep. The main takeaway is that backups and recovery steps for Elasticsearch, secrets and attachments matter as much as the database, because a restore that skips them can leave agents without search or files.
| Area | What to do | Confirm or keep as evidence |
|---|---|---|
| Application health | Watch the Zammad web and worker processes on every instance, plus the reverse proxy in front of them | Health checks per instance, alert routing, and a named on-call owner |
| Database connections and replication | Track PostgreSQL connection counts across all Zammad instances, and replication lag if a replica is in use | Connection limits set per instance, and the replica failover steps your DBA has tested |
| Redis and Memcached | Confirm Redis 7 or newer stays reachable for websocket traffic, and Memcached is reachable from every instance | Availability alerts for both services and a documented behavior when either one is down |
| Elasticsearch cluster health | Monitor cluster status, node availability and index health for the search backend | Cluster health dashboards and the index rebuild procedure written down before go-live |
| Queue and websocket errors | Review background job failures and websocket connection errors after each change | Log retention for worker and websocket logs, and an error threshold that triggers investigation |
| Disk for attachments | Track free space on shared attachment storage and on each database and search node | Capacity alerts with growth trends reviewed on a fixed schedule |
| PostgreSQL and attachment backups | Back up the database and the attachment storage together so tickets and their files match in time | Restore tests that open a ticket, its history and at least one attachment in a staging copy |
| Elasticsearch and secrets | Back up Elasticsearch configuration and record how the index is rebuilt from the database, plus secrets and environment files stored securely | A written rebuild procedure, an inventory of environment files, and a secrets store with access logs |
| Security and minor releases | Apply the 7.2 line with its 7.2.1 and 7.2.2 security releases, and the 6.5.5 security release on the 6.5 line, after testing | Release notes reviewed, a staging upgrade log, and the version recorded for each instance |
| Rolling upgrade sequence | Upgrade one instance at a time in a staging copy first, then roll the same order in production while the others serve traffic | Checks on each instance after its upgrade and a rollback plan for the database step |
| Architecture and runbooks | Keep a current architecture diagram, runbooks for failover and restore, and recovery time and recovery point objectives set by the business | Signed-off objectives, a dated diagram, and drills that show the runbooks work |
| Support contacts | List contacts for the Zammad support tier you chose, since response times differ by tier | Response times confirmed on the Zammad pricing page, with escalation contacts in the runbooks |
Common questions about Zammad high availability
How much more effort is Zammad high availability than a single node?
It takes noticeably more effort, mainly because every layer becomes shared and must be tested as one system. A single node runs the application, database and cache on one host. A high availability setup runs several Zammad instances against shared PostgreSQL and Redis, with Memcached for multi-instance operation, plus a reverse proxy in front and usually Elasticsearch for search. Zammad's software requirements state that Memcached is needed for multi-instance deployments, while single installations can use the file system cache. The extra work sits in shared file storage, session handling, failover testing and backup restore drills. Ask any partner to split its estimate by layer so you can see which parts your team would own.
What skills does our team need for Zammad high availability?
Your team needs working knowledge of each shared component, plus one person who owns the runbook. Key skills:
- PostgreSQL administration, including replication, backups and version 15 or newer
- Redis 7 or newer, which Zammad requires for realtime websocket communication
- Memcached and, if used, Elasticsearch operations
- Linux administration and reverse proxy configuration with Nginx or Apache
- Kubernetes or container operations if you deploy with Docker Compose or the Helm chart
The runbook owner decides how failover is tested, who responds to alerts and when backups are restored for verification. Without a named owner, a multi-node setup tends to drift from its documented state after the first upgrade or staff change. Confirm these skills in your own team before choosing a build approach.
Can our IT team set up Zammad high availability without outside help?
Often yes, if the team already runs PostgreSQL, Redis and Linux services in production and has time for testing. The harder part is usually not the first installation but proving the setup behaves correctly under failure. Plan for node loss, database failover, cache restarts, attachment storage access and a full restore from backup, then repeat these tests after each Zammad release. Teams without a recent record of operating these components often find the testing and documentation take longer than the build itself. An outside partner can take on the build, the tests or the handover, or any combination of them. DeployOpen works inside your own cloud accounts, data centers or air-gapped networks, and most engagements are fixed-scope with the scope agreed in writing first.
How long does a Zammad high availability project take?
The duration depends on scope, environment and approvals, so no fixed figure applies to every organization. The main drivers are the number of nodes, whether Elasticsearch and Kubernetes are included, how much existing infrastructure you can reuse, and whether data migration from another helpdesk runs in the same project. Access requests, change approvals and maintenance windows for testing also add elapsed time even when the technical work is small. Ask for a timeline in the written scope that lists each phase, the testing windows, the handover date and the dependencies on your team, such as database or network access. A timeline without these dependencies is hard to hold anyone to.
Which parts of Zammad high availability are one-time and which recur?
The design, build, initial failover testing and runbook are one-time costs. Ongoing costs recur because Zammad publishes minor and security releases, and each release needs testing across the cluster before rollout. Recurring work includes applying updates, renewing certificates, reviewing monitoring and capacity, running periodic backup restores, and keeping the runbook current as components change. Support is recurring too, whether it comes from an internal team or from a retainer. Ask any quote to separate these categories so you can budget the build separately from the operating model. The recurring share grows with the number of shared components you run.
What should a written scope for Zammad high availability include?
A useful written scope names each component, its version and where it runs. Include the number of Zammad instances, the PostgreSQL and Redis topology, the Memcached and Elasticsearch setup, the reverse proxy, and the hosting environment. It should also state the backup and recovery objectives you need, the failover tests to be performed, and the acceptance criteria for each test. Add handover items such as the runbook, monitoring setup and training, plus change control for later requests. Exclusions matter as much as inclusions. For example, if Kubernetes platform issues are outside the scope, say so, because Zammad's Kubernetes support covers only the Zammad application. Most DeployOpen engagements are fixed-scope, and the scope is agreed in writing before work starts.
Do Zammad support subscriptions change the high availability picture?
They change the support model, not the architecture. Self-hosted Zammad has no license fee, so a support subscription is the main vendor cost you add. Zammad's pricing page lists Business at 2,999 EUR per year, Enterprise at 5,999 EUR per year and Corporation at 9,999 EUR per year. The same page lists self-hosted support response times of 6 hours for Business, 4 hours for Enterprise and 2 hours for Corporation. Compare those times with how long your helpdesk can be unavailable before it affects customers. Confirm with Zammad what each tier covers, especially for multi-instance setups and any Kubernetes deployment. A subscription does not replace your own failover design, backups or tests.
How DeployOpen scopes, builds and supports Zammad high availability
DeployOpen plans and implements highly available Zammad inside your own infrastructure, from the multi-instance application tier through shared PostgreSQL, Redis, Memcached and Elasticsearch to backup and recovery. Engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Map which Zammad components must be redundant, including the application instances, PostgreSQL, Redis, Memcached and Elasticsearch.
- Confirm the hosting model, cloud accounts or data centers, and the reverse proxy choice between Nginx and Apache.
- Record in the written scope the availability targets, recovery objectives and the decisions the client must sign off.
How we build
- Deploy multiple Zammad instances sharing one PostgreSQL database, Redis for websockets and Memcached for the multi-instance cache.
- Configure Elasticsearch and the reverse proxy, then test failover of each component separately and together.
- Set up backups of the database and search data, and test restores against a recovery plan the client approves.
How we hand over
- Deliver architecture diagrams, configuration records, runbooks for failover and restore, and the test results gathered during the build.
- Walk the client's operations team through failover drills so they can run them without DeployOpen present.
- Document which parts are Zammad application behavior and which depend on the infrastructure platform underneath.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped in writing.
- Plan how Zammad minor and security releases are tested in a staging copy of the clustered setup before production.
- Review backup coverage and failover tests on a schedule the client agrees, and record changes for audit evidence.
