Zammad Elasticsearch setup guide

How Zammad Elasticsearch setup speeds up search and reporting

Elasticsearch is optional for Zammad, but it is strongly recommended if your agents need faster search, reporting features and the ability to find text inside email attachments. Consider a team whose ticket volume has grown steadily: agents wait on searches, managers struggle to pull reports, and someone needs to locate a contract phrase buried in a PDF sent three months ago. This section explains what the Elasticsearch connection changes, what stays in PostgreSQL, and what you must plan for because the index is a separate system.

Zammad stores its content in PostgreSQL 15 or newer, and that remains the system of record for tickets, articles, users and settings. Elasticsearch holds a searchable copy of that content. When the connection is configured, agents use it for ticket and article search, and reporting features draw on it as well. Administrators should confirm with the Zammad documentation which search and reporting functions depend on the index, so they know what users will notice if the index is stale or unavailable. Attachment content search is a separate capability that reads text from files, so it should be tested on realistic documents before rollout.

Because the index is a second store, you need to plan it like any other production component. Decide where the cluster runs, who patches it, how it is monitored, and how it is backed up. Confirm the supported Elasticsearch version for your Zammad release in the software requirements before you choose one, since version compatibility is a common source of failed setups. Plan for a full index rebuild after upgrades or migrations, and estimate how long that rebuild takes on a copy of your real data. Ask your team whether a rebuild can run during a maintenance window and what agents will see while it runs.

The harder part is keeping the index in step with the application. If a ticket is updated in PostgreSQL but the index update fails, agents search and get incomplete or outdated results, and nobody notices until a customer complains. You also add an infrastructure component that needs capacity, certificates, storage growth monitoring and on-call coverage. Attachment content indexing raises data handling questions: extracted text can contain personal data or confidential material, so you must decide who can search it, how long the extracted text is retained, and whether backups of the index fall under the same policy as the database.

Before go-live, run a short test: create tickets with attachments, confirm they appear in search, change them, confirm the index reflects the change, then trigger a rebuild and time it. Record the results and the access rules you agreed. Those records feed directly into your sizing, backup and data handling decisions.

Which Zammad and infrastructure components the Elasticsearch connection touches

Elasticsearch is one of several services behind a Zammad installation, and each one has a distinct job. Knowing which component stores what, which carries realtime traffic, and where the search connection is configured helps you plan versions, sizing and failure handling before you connect anything.

Zammad application

The Zammad application runs the helpdesk logic: tickets, channels, triggers and the agent and customer interfaces. It is the only component that talks to Elasticsearch directly, so search indexing and queries originate here. Confirm which Zammad release you run before choosing an Elasticsearch version, because supported combinations change between releases.

Elasticsearch search backend

Elasticsearch provides faster search, reporting features and search across email attachment content. Zammad documents it as optional but strongly recommended, so a Zammad instance can run without it but loses that capability. Check the supported Elasticsearch versions in the Zammad software requirements for your release, and plan for a rebuild of the index after upgrades or migrations.

PostgreSQL content store

PostgreSQL 15 or newer holds Zammad's content, including tickets, users and articles. Elasticsearch is an index built from this data, not the system of record, so the database is what you must back up to recover. Confirm the PostgreSQL version against the software requirements before you provision the database host.

Redis realtime messaging

Redis 7 or newer supports realtime websocket communication, which keeps agent screens updated as tickets change. It is separate from the search path, so a Redis fault affects live updates rather than search results. Confirm the Redis version in the requirements and decide whether it runs on a dedicated host or a managed service.

Nginx or Apache reverse proxy

A reverse proxy, either Nginx or Apache, sits in front of Zammad and handles client connections, including the websocket traffic. Its configuration determines how requests reach the application and how TLS is terminated. Confirm which proxy your release supports and verify that websocket upgrade handling is configured before go-live.

Memcached or file system cache

Memcached is required for multi-instance deployments such as containers or cluster nodes, where instances must share cached data. A single installation can use the file system cache instead. Choose the cache based on how many Zammad instances you run, because moving from one instance to several later adds a shared cache dependency.

Which Elasticsearch deployment choice fits your Zammad setup

This table compares four places to run Elasticsearch for Zammad, from a single node beside the application to a self-run Kubernetes cluster. Read each row against your own team's patching, backup, monitoring and on-call capacity, because the operational load is what separates the options more than the initial install.

Option	When it fits	Patching and upgrades	Backup and restore	Monitoring and on-call ownership
Single node on the Zammad host	Small installations with a low ticket volume and a team that accepts search downtime during maintenance	Your team patches the OS and Elasticsearch on the same host, so a search fix can require a Zammad restart window	Snapshots must be configured to a location outside the host, or the index can only be rebuilt from Zammad data	One alert set for host and search; the same person usually owns both, which raises on-call load
Dedicated node or small cluster in the same network zone	Organizations that want search isolated from the application server but still keep traffic on a private network	Your team patches separate hosts, so the upgrade order between Zammad and Elasticsearch needs a written runbook	Snapshot repository and retention are set on the cluster, with restore tested against a non-production copy	Separate host metrics and cluster health checks; confirm who receives cluster yellow or red status alerts
Managed Elasticsearch service in your own cloud account	Teams that prefer the provider to run cluster hosts while data and network policy stay in an account you control	The provider handles much of the node patching, but you still schedule version changes and confirm Zammad compatibility	Confirm the provider's snapshot options, retention and whether restores are self-service or require a support request	Provider metrics are available, but alert routing, thresholds and escalation to your team remain your responsibility
Self-run cluster on Kubernetes	Organizations already operating Kubernetes with storage, backup and monitoring tooling in place	Operators or Helm charts handle rolling changes, but your team owns node pools, storage classes and version pinning	Volume snapshots do not replace Elasticsearch snapshots; plan repository configuration and restore drills	Highest ownership load: cluster, pods and storage alerts sit with your platform team; Zammad support covers only the application

Zammad Elasticsearch setup steps in order

This sequence connects a self-hosted Zammad instance to Elasticsearch so that ticket search, reporting and attachment search run against an index the team controls. Each step ends with a check, so the team can confirm the connection, the index and the search results before go-live. The exact settings screen and index build procedure should be taken from the Zammad documentation for the installed version.

Confirm the Zammad release and Elasticsearch version
The engineer responsible for the platform records the installed Zammad version and reads the software requirements for that release to find the Elasticsearch version it supports. Confirm the version with Zammad documentation before ordering or building the cluster, because the supported version determines the cluster build. Check: a short record listing the Zammad version, the supported Elasticsearch version and the hosting platform, signed off by the service owner.
Provision the Elasticsearch cluster in your network
The platform team builds the Elasticsearch cluster in the same cloud account, data center or air-gapped network as Zammad, using the version confirmed in the previous step. Storage, memory and node count depend on ticket volume and attachment volume, so agree those figures with the vendor guidance and your own data before the build. Check: the cluster reports a healthy status from an administrative host, and the version it reports matches the record from the first step.
Restrict access and enable TLS
Configure transport encryption on the cluster and create firewall or security group rules that allow connections only from the Zammad application hosts and named administrators. Use certificates issued by your internal certificate authority, and keep the cluster credentials in your secrets manager, outside configuration files. Check: a connection from a Zammad host succeeds over TLS, and a connection attempt from any unlisted host is refused.
Configure the connection in Zammad admin settings
An administrator enters the cluster address, credentials and certificate trust details in the Zammad admin settings for search. Take the exact screen and field names from the Zammad documentation for the installed version, since they can change between releases. Check: the connection status shows as connected after saving, and the Zammad application logs show no authentication or certificate errors during the test.
Build the initial search index
Start the initial index build using the procedure in the Zammad documentation for the installed version, and let it run to completion. Schedule the build in a window agreed with the business, because ticket volume and attachment volume determine how long it takes and how much load it places on the application and the cluster. Check: the build finishes without errors, and the indexed ticket and article counts match the counts the team recorded before the build started.
Test ticket search with known tickets
Testers choose a set of test tickets with known numbers, titles, customer names and body text, then search for each one from an agent account. Each query should return its expected ticket at or near the top of the results, and results should respect the agent's group access. Check: every test query returns its known ticket, and a search from an agent without access to a group does not show that group's tickets.
Verify reporting and attachment search
Create a test ticket with an attachment that contains a unique marker phrase, such as a document with an agreed marker word, so the team can confirm that attachment content is searchable. Then run the reporting views that depend on Elasticsearch and compare the totals with the known contents of the test data set. Check: the marker phrase returns the test ticket, and the report totals match the expected counts for the test data.

What drives Elasticsearch setup effort and cost

This table lists the factors that change how much work a Zammad Elasticsearch setup takes, why each one matters, and how to keep it contained. Read each row against your own ticket history, attachment policy and operating model before asking for a quote. The main takeaway is that scoping attachment indexing and sizing from measured data usually matter more than the number of tools involved.

Driver	Why it changes effort or cost	How to keep it down
Tickets and articles to index	Initial indexing time, index size and reindex runs grow with the number of tickets and articles, and the volume determines how much cluster capacity must be provisioned.	Measure the current database size and article count before design, and size the cluster from that measured set rather than from estimates.
Attachment volume and types	Content search on email attachments requires text extraction, which adds processing load and index growth. Large files and many formats increase both build and runtime work.	Agree which attachment types need content search, exclude low-value formats, and test extraction on a representative sample before enabling it broadly.
Number of agents and reporting use	More agents means more concurrent searches, and heavier reporting use adds query load that can affect cluster sizing and tuning.	Confirm which reports depend on Elasticsearch, review query patterns with the agent team, and plan capacity for peak usage rather than average use.
Number of Zammad instances sharing the index	Multi-instance deployments need consistent index configuration, shared access and coordinated rebuilds. Each added instance adds integration testing and operating steps.	Define one index configuration as a standard, confirm which instance performs index maintenance, and document the shared settings in a single runbook.
Environments (test, staging, production)	Each environment needs its own cluster or index, data handling and verification. Drift between environments creates rework during upgrades and cutover.	Use the same build runbook and configuration templates in every environment, changing only hostnames, credentials and sizing values.
Data classification and retention for attachment text	Extracted attachment text is copied into the search index, so classification, retention and deletion rules apply to the index as well as to the database and file storage.	Confirm with your data protection and compliance owners which content may be indexed and how long it stays, then build deletion and index rebuild steps into the design.
Who operates the cluster	An in-house team carries ongoing patching, monitoring, capacity and backup work. A partner adds scope to agree in writing, and support terms determine response expectations.	Ask for the operating split in writing, including who patches the cluster, who watches capacity, who runs index rebuilds and what support covers.

How Zammad Elasticsearch setup differs by deployment model

A single-node installation runs the Zammad application, PostgreSQL, Redis and Elasticsearch on one server or in one tightly managed host group. Zammad can use the file system cache here, so Memcached is not needed for the search setup. The Elasticsearch service typically runs on the same host or a nearby host, and the connection is a single endpoint in the Zammad configuration. Because only one application node writes to the index, indexing and search results stay consistent without extra coordination.

Connection: point Zammad at one Elasticsearch endpoint, usually over a local or private network address.
Index ownership: the one Zammad instance creates and maintains the index, so rebuilds run from that host.
Memory pressure: Elasticsearch shares the host with PostgreSQL and Redis, so confirm available memory before go-live.
Backups: back up the Elasticsearch data directory or snapshots alongside the database, and note that the index can be rebuilt from PostgreSQL content.
Upgrades: check the Elasticsearch version against Zammad's software requirements for the target release before changing either side.

Before go-live, confirm the supported Elasticsearch versions for your Zammad release and test an index rebuild on a copy of production data.

Rebuilding the Zammad search index after upgrades or migrations

A search index rebuild is needed whenever the data Elasticsearch holds no longer matches what Zammad expects to find in PostgreSQL. In practice that means four situations: after a major or minor upgrade that changes indexed content, after restoring the PostgreSQL database to a new host, after migrating tickets in from another helpdesk, and after changing the Elasticsearch cluster or its version. Treat each of these as a planned change to the search backend, not a background task you hope nobody notices. Confirm in the Zammad documentation for your exact version whether a given upgrade changes indexed content, because the release notes are the reliable place to check that, not general assumptions about minor releases.

Start with a backup of both PostgreSQL and the current Elasticsearch data before you touch the index. The backup protects you if the rebuild fails partway, and it gives you a state to return to if the new cluster behaves differently. Then run the rebuild in a non-production environment that holds a recent copy of your database and attachments. Use that run to measure how long the rebuild takes, how much CPU, memory and disk I/O it consumes on your Elasticsearch nodes, and whether any errors appear in the Zammad logs. Those measurements are what you need to schedule production safely, because the duration on your data volume is the number that matters, not a figure from another installation.

Schedule the production rebuild for a quiet window agreed with the support team, managers and anyone who depends on helpdesk search for reporting. Expect search to be slower or incomplete until the rebuild finishes, and make sure agents know that a missing result during this period does not mean a ticket has been lost. Confirm with the Zammad documentation for your version the rebuild command, its options, and any index-specific steps, such as which indexes to delete or recreate before the run. Do not improvise these commands from memory or from older guides, because the correct sequence can change between versions.

After the rebuild completes, verify search results rather than assuming success because the process exited cleanly. Run a set of known searches covering recent tickets, older archived tickets, customer names, and text inside email attachments, and compare the results with what the same queries return in the non-production test. Check that reporting screens that depend on search return the expected counts. Record the test queries and outcomes so that the next upgrade or migration can repeat the same checks. Plan this verification as part of the change, with a named owner who can sign off or escalate, because an incomplete index is easy to miss once users are back in the system.

Securing the Elasticsearch connection and indexed attachment content

Once Zammad sends ticket content and attachment text to Elasticsearch, the search cluster becomes a second place where customer data lives. The controls below cover who can reach the cluster, how it authenticates, where credentials are kept, and how indexed content is retained and removed.

Limit network access to Zammad hosts

Only the Zammad application nodes should be able to open connections to the Elasticsearch HTTP port. Restrict this with firewall rules, security groups or network policies, and block access from user networks, other applications and administrator workstations unless they have a documented need. Check the rules from both sides: confirm Zammad connects and confirm that a test host outside the allowed list cannot.

Enable authentication and TLS

Turn on authentication for the cluster and encrypt the connection between Zammad and Elasticsearch, including transport between cluster nodes if the topology uses more than one. Confirm which Elasticsearch version and security features your edition supports before you configure them, and check the Zammad connection settings against the version you deploy. An unauthenticated or plaintext cluster reachable from the application network exposes every indexed ticket.

Keep credentials out of plain configuration

Store the Elasticsearch username and password, and any certificate passphrases, in the same secrets mechanism the rest of the deployment uses, such as a secrets manager, sealed secrets or the orchestrator's secret store. Do not place them in environment files committed to version control or in the Zammad configuration in readable form. Confirm how rotation works, since changing a credential must not require editing files by hand on every node.

Apply least-privilege roles for Zammad

Create a dedicated Elasticsearch user for Zammad with only the index, read, write and cluster privileges that its search, reporting and attachment indexing need. Do not reuse administrator accounts or the credentials of other applications. Review the role whenever Zammad moves to a new minor or major release, because required privileges can change and an overly broad role remains in place until someone removes it.

Align retention with attachment classification

Before indexing attachments, classify the material Zammad receives, such as payment records, health information, identity documents or contracts. Set index retention and deletion so the search copy follows the same rules as the source ticket, and confirm that closing, merging or purging tickets in Zammad also removes the matching indexed content. Document who may search attachment text and whether that access matches their access to the original attachments.

Cover the search copy in backup and deletion

Indexed attachment text can carry sensitive data into a second store, so Elasticsearch needs the same backup, restore, deletion and access controls as PostgreSQL and the file storage behind Zammad. Confirm whether your backup tooling captures the cluster, how long snapshots are kept, and how a deletion request for a customer is carried through to snapshots. Restoring an old snapshot can bring back content that was already deleted from the source, so plan for that case.

How to verify Zammad Elasticsearch setup and its failure behavior

Verification has two goals: prove that search returns correct results from every Zammad node, and prove that the helpdesk behaves predictably when Elasticsearch is unavailable. Before testing starts, write down the acceptance criteria with the support lead, the operations owner and a business representative. The document should name the expected search results, the maximum time a new ticket may take to become searchable, and the agent behavior that counts as acceptable during an outage. Without written criteria, a test run produces observations but no decision. Start with the connection. Confirm that each Zammad application node can reach the Elasticsearch endpoint and that the index exists with the expected name. Then run searches for a ticket number, a customer name and a word that appears only inside an email attachment. Attachment content search depends on the attachment handling in the search backend, so confirm the required ingest configuration with the Zammad documentation for your release before you treat a failed attachment search as a Zammad defect. Compare every result against a known count from a controlled test data set, and record the expected and actual numbers side by side. Next, measure indexing latency. Create a new ticket with an attachment, note the time, and search for a unique term from the attachment until it appears. Repeat the test at normal load and during a busy period, because a delay that is acceptable on a quiet afternoon may not be acceptable at peak. Also run a few reports and confirm that their totals match the same test data. A report that disagrees with a manual count usually points to an index that is incomplete or stale. Failure tests belong in staging, never in production. Stop the Elasticsearch cluster and observe what happens: whether ticket creation, replies and attachments still work, what agents see when they search, and whether the reports show an error or stale numbers. Record each observation with a timestamp, because these findings become the agent guidance. Then restart the cluster and confirm recovery by creating test tickets during the outage, checking that they appear in search once the index catches up, and confirming that the reports return to the known counts. Document what agents should expect during an outage, including the fallback they can use for ticket lookups, and who they should contact if the outage lasts longer than the agreed window.

What to monitor, back up, upgrade and document after go-live

After go-live, Zammad search needs the same operating attention as the helpdesk itself. The six items below cover the cluster, the data it holds, the upgrade path and the records a new administrator will need. Read them together, because a heap alert, a patch or a restore each changes what search returns.

Monitor cluster health and index status

Check cluster health and the status of each Zammad index on a schedule, and alert when either drops below the baseline you recorded at go-live. A degraded state after a restart, a failed reindex or a node loss can mean search results are missing or stale. Confirm with your Elasticsearch distribution's documentation which health signals and API endpoints your monitoring tool can read, and record the expected baseline for your cluster.

Watch heap and disk pressure

Track JVM heap use, garbage collection pauses and free disk on every data node. Elasticsearch slows down or stops accepting writes as either fills, which can leave new tickets unsearchable. Compare disk growth with the rate seen in the first weeks of live traffic, including attachment content indexed from email. Agree thresholds with your team, and name who responds at each level.

Correlate Zammad application logs

Keep Zammad application logs and Elasticsearch logs together so a search failure can be traced from the user request to the cluster response. Watch for errors when tickets are created or updated, since indexing failures can appear there before users notice missing results. Confirm where your installation writes logs and how long your retention policy keeps them, because both depend on how you deployed Zammad.

Back up PostgreSQL and document the index role

Treat PostgreSQL as the source of truth for tickets, users and settings, and include it in your standard backup schedule and restore tests. Decide whether the Elasticsearch index is backed up or treated as rebuildable from PostgreSQL, and write the decision down. A snapshot restores faster, while a rebuild depends on time and cluster capacity you must plan for, so confirm the rebuild duration in your own environment before relying on it.

Test each upgrade as its own change

Plan Elasticsearch upgrades as separate changes from Zammad releases, and test each one in an environment that matches production. Zammad security releases such as 7.2.1, 7.2.2 and 6.5.5 may require a re-test of search after patching, so run the search checks again after each one. Check every Zammad release against the Elasticsearch version in use before applying it, and confirm compatibility in the Zammad release notes and documentation.

Document settings, runbook, owners and tests

Keep a current record of the connection settings, including host names, ports, the index names Zammad uses and where credentials are stored. Write a rebuild runbook that lists the steps, their order and who can approve a rebuild. Name an owner for the cluster and another for Zammad search, and keep the test plan with them so the queries for ticket search, attachment search and reporting can be repeated after each change.

Questions buyers ask about Zammad Elasticsearch setup

How much does it cost to set up Elasticsearch for Zammad?

The cost has two parts: a one-time build and recurring operations. The build covers designing the cluster, connecting Zammad, sizing storage and memory, testing search and attachment search, and documenting the result. Recurring work covers patching the cluster, watching disk and heap usage, taking and testing snapshots, and rebuilding the index after Zammad upgrades or migrations. Costs go up with the number of tickets and attachments, the number of environments (production, staging, recovery), how many systems feed the cluster, and whether the cluster must run in an air-gapped network. DeployOpen does not publish a price list, so a quote follows from a written scope. Ask for the build and the recurring operations to be priced separately, and ask who holds the cluster license or hosting account. Zammad itself has no license fee when self-hosted.

How long does a Zammad Elasticsearch setup take?

The timeline depends on cluster ownership, environment access and how much testing the data needs. The schedule is set by the time it takes to provision the cluster in your infrastructure, approve network and firewall rules, load representative data, and confirm search results with your agents. Index rebuilds also take time in proportion to the data volume, so large attachment stores lengthen both the first build and later migrations. Most engagements are fixed-scope, so the agreed timeline is written into the scope before work starts. Ask for a list of the milestones, the dependencies on your team and the environments that must be ready before the search test begins.

What does my team need to provide for an Elasticsearch setup?

Your team provides access, ownership and acceptance. Expect to provide network access between the Zammad application servers and the search cluster, including firewall and DNS changes. Your team should own the cluster account or hosting environment, so that backups, credentials and keys stay under your control. You also need a test dataset that reflects real tickets, customers and attachments, because search quality cannot be judged on an empty system. Finally, name a person who signs off on search results, reporting views and attachment search before go-live. Confirm these items in the scope document before work starts.

Can our internal team set up Zammad Elasticsearch without outside help?

Yes, a team with Linux, networking and search cluster experience can do it alone. Zammad documents Elasticsearch as optional but strongly recommended for faster search, reporting and searching email attachment content, so the integration itself is not the hard part. The risks lie in the surrounding work: sizing memory and disk for your ticket volume, securing the cluster, handling index rebuilds after upgrades, and writing a recovery procedure. Check whether your team has run search clusters in production before and whether anyone will own the cluster after go-live. If the answer is no, a fixed-scope build with a documented handover is a practical middle path.

What happens to Zammad if the Elasticsearch cluster is unavailable?

Zammad keeps running as a helpdesk, but search features and attachment search depend on the cluster. Elasticsearch is used for faster search, reporting and searching email attachment content, so an outage degrades those features and does not replace the ticket database, which is PostgreSQL. Confirm the exact behavior of your Zammad version during testing, including what users see and whether reporting and search results are stale or missing. Plan for monitoring that alerts on cluster health, a documented procedure for restarting or restoring the cluster, and a rebuild of the index once service returns. Ask the implementation partner to test this failure path before go-live.

Does a Zammad support subscription cover running Elasticsearch for us?

No. Zammad support subscriptions and their response times are separate from running an Elasticsearch cluster in your own infrastructure. Zammad sells self-hosted support subscriptions with response times tied to each tier, but the cluster, its hosting, its patching and its capacity are your responsibility or that of the partner you engage. Read the subscription terms to confirm what Zammad support covers for the application, and ask your search cluster provider or internal team to cover the cluster. Keeping these two responsibilities separate avoids gaps when an incident crosses both.

How is the Elasticsearch index rebuilt after an upgrade or migration?

The index is rebuilt as part of the upgrade or migration plan, then tested against search results before cutover. Upgrades and migrations can change what is indexed or how records are stored, so the safe approach is to plan a full rebuild in a non-production copy first. The rebuild runs longer as ticket and attachment volume grows, so schedule it inside the change window and measure it during rehearsal. Verify search results, attachment search and reporting after the rebuild, and keep the previous snapshot until the new index is accepted. Confirm the exact rebuild steps for your Zammad version with the release notes before scheduling the work.

How DeployOpen scopes, builds, hands over and supports Zammad search work

DeployOpen treats Zammad Elasticsearch setup as part of a self-hosted helpdesk build inside your own infrastructure. Each engagement starts with a written scope that names the Elasticsearch version, cluster layout, and search features in use, then moves through build, testing and handover. Ongoing support can be arranged as a retainer.

How we scope

The written scope names which Zammad search features use Elasticsearch: ticket search, reporting and attachment search.
Cluster sizing covers node count, memory, storage and the expected ticket and attachment volume, agreed before build.
Engagements are fixed-scope, so deliverables, environments and acceptance criteria are written down before work starts.

How we build

Install Elasticsearch in your cloud account, data center or air-gapped network, then confirm the supported version in Zammad's software requirements.
Connect Zammad to the cluster, then rebuild the search index and verify ticket, attachment and report results.
Keep Zammad's PostgreSQL, Redis and Memcached settings in the same review, since multi-instance deployments depend on them.

How we hand over

Documentation covers the cluster layout, index rebuild steps, access controls and the checks used to confirm search works.
Your team receives a rebuild runbook for upgrades and migrations, so the index is reindexed as a planned step.
Knowledge transfer walks administrators through monitoring, backups of the search data and what to check after each release.

How we support

Ongoing support can be arranged as a retainer covering Elasticsearch upgrades, index rebuilds and Zammad release testing.
Zammad security releases are tested against your Elasticsearch setup before they reach production.
Support boundaries are written into the scope, so Elasticsearch issues and Zammad application issues are clearly separated.