What Graylog upgrade and support work involves
Graylog upgrade work moves a running deployment from one 7.x minor release to another while keeping three layers in step: the Graylog server nodes, MongoDB holding configuration and metadata, and the search backend holding log data, either Graylog Data Node or self-managed OpenSearch. Each layer has to fit the compatibility matrix for the target release. For Graylog 7.0 to 7.2, the matrix lists MongoDB 7.x up to 8.2.x and OpenSearch 1.1.x up to 3.7.x, and Graylog Security needs OpenSearch 2.0 or later. Confirm the row for your target version before you change anything.
OpenSearch 1.x is deprecated since Graylog 7.0 and will be removed in Graylog 8.0. Any cluster still on 1.x needs a move to Data Node or a supported OpenSearch line before the 8.0 upgrade, which usually means a new cluster, index migration and re-pointing Graylog. Ask Graylog for the 8.0 release date and requirements, since they are not settled in this plan. On multi-node clusters, upgrade one node at a time, keep follower nodes set to is_leader false, and check the message journal and indexing before moving to the next node.
Teams usually trigger this work for one of five reasons: a minor release that fits their plan, a security fix, a compatibility gap that appears after a MongoDB or OpenSearch change, the 8.0 deadline, or staff turnover that leaves nobody who has done an upgrade before. Keeping the work in-house is reasonable for a small single-node deployment changed rarely. For larger clusters or frequent changes, a partner can run the matrix check, staging test and rolling sequence each time. The answer depends mainly on cluster size and how often the platform changes.
Ongoing support covers more than the upgrade itself: tracking release notes and security fixes, testing each target version in staging, taking backups of MongoDB and index data before the change, and documenting rollback steps. Graylog Enterprise includes 24/7 support, while Graylog Open relies on community support, so ask which support path your edition gives you. Ask any partner to state in the written scope which upgrades, environments and response expectations a retainer covers.
What the work includes
The work runs in six packages, from the current-state inventory through ongoing support. Each package ends with a document your team keeps, so later upgrades can be repeated without depending on us.
Current-state assessment
We inventory the Graylog server version, the MongoDB and search backend versions, and how each node was installed, whether from Debian or RPM packages or Docker Compose. We also record inputs, pipelines, index sets, plugins and any node still running OpenSearch 1.x. The deliverable is a current-state inventory that becomes the baseline for every later decision.
Compatibility and upgrade path plan
We check the target Graylog 7.x release against the compatibility matrix for MongoDB and OpenSearch, including the note that Graylog Security requires OpenSearch 2.0 or later. We set the order of MongoDB, search and Graylog steps and the path off OpenSearch 1.x before Graylog 8.0 removes support. The deliverable is a written upgrade plan with go or no-go criteria.
Staging rehearsal
We build a staging copy that matches production topology, including the Graylog and MongoDB nodes, the Data Node or OpenSearch cluster and the load balancer. We run the full upgrade sequence there, log errors and timings, and test the rollback before production. The deliverable is a rehearsal report and a runbook with rollback steps the team can repeat.
Production rolling upgrade
We upgrade MongoDB, the search nodes and the Graylog nodes one node at a time, so the load balancer keeps ingestion running on the remaining nodes. We confirm the step order against the release notes for the target version, set is_leader to false on follower Graylog nodes where the cluster design requires it, and check the message journal before each step. The deliverable is a change record with node-by-node sign-off.
Post-upgrade validation
We confirm that inputs are receiving messages, pipeline rules still parse and route as before, streams and index sets resolve, and dashboards render. We also test that event definitions fire and send notifications to their configured channels. The deliverable is a validation checklist with results compared against the baseline and signed off by your owners.
Ongoing support
We track releases and advisories for the Graylog 7.x line, schedule upgrades into your maintenance windows and handle platform incidents under a retainer. Graylog Open offers community support, and 24/7 support is part of Graylog Enterprise, so confirm which vendor channel your team relies on. The deliverable is a support runbook, an escalation path and a maintained version record.
What drives cost and duration
This table lists the factors that most change the effort of a Graylog upgrade or support engagement, why each one matters, and how to reduce its impact before work starts.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Graylog server nodes and cluster shape | Each node adds build, configuration and test work. Confirm that MongoDB and the Data Node cluster already match the recommended multi-node layout. | Document the current topology. Bring MongoDB and Data Node to the recommended shape before scheduling the upgrade. |
| Search backend and major version | OpenSearch 1.x is deprecated from Graylog 7.0 and is removed in Graylog 8.0. Data Node is the recommended backend, so an OpenSearch move adds migration work. | Plan the move to Data Node or a supported OpenSearch version early. Check the compatibility matrix for each version pair. |
| Distance between current and target versions | Every release step must fit the compatibility matrix for MongoDB, the search backend and Graylog. Larger version gaps usually mean more stops and more testing. | Map the full upgrade path from your current release to the target. Confirm each stop against the compatibility matrix before work starts. |
| Inputs, pipeline rules, content packs and plugins | Each input, pipeline rule, content pack and custom plugin needs retesting on the new release. Complex parsing and custom code often drive the largest testing effort. | Inventory all inputs, rules and packs. Export content packs, limit custom plugins and build regression tests on sample messages. |
| Graylog edition | Graylog Security requires OpenSearch 2.0 or later, which can force a backend upgrade before the Graylog upgrade. Enterprise and Security features also need their own configuration and testing. | Confirm the edition and its feature set in writing. Check the OpenSearch requirement before choosing the upgrade order. |
| Installation method | Debian or RPM packages and Docker Compose follow different upgrade steps and rollback paths. Mixed methods across nodes add risk and steps. | Use one installation method per environment. Record exact package or image versions and the rollback steps before each change. |
| Number of environments and change windows | Each environment is upgraded and tested separately. Short or fixed change windows limit how many rolling steps fit into one window. | Keep staging close to production. Agree change windows, rollback criteria and sign-off roles in writing before scheduling. |
| Compliance evidence requirements | Assessors may ask for change records, test results, version history and access logs from the upgrade. Collecting this evidence adds effort to each step. | Agree the evidence list before work starts. Capture records as each step runs, and confirm requirements with your assessor. |
Project phases and outputs
The sequence moves from inventory and version decisions to a rehearsed, staged production upgrade, then hands over to ongoing support, with a named output at each phase.
Inventory the current deployment
Record the Graylog server version, the MongoDB version, the search backend (Data Node, self-managed OpenSearch or OpenSearch 1.x), node count, load balancer setup, plugins, content packs and custom pipeline rules. Note how Graylog was installed, whether from Debian or RPM packages or Docker Compose. Output: a dated inventory that your team signs off as the baseline for every later step.
Choose the target version
Check the target against the current Graylog documentation, which covers version 7.2, and the compatibility matrix for MongoDB and OpenSearch. Review the release notes for 7.1.10 and 7.2.0 and confirm any plugin or Graylog Security requirements. Output: a decision record naming the target version, the supported MongoDB and search backend versions, and the open risks.
Plan OpenSearch 1.x and MongoDB remediation
If OpenSearch 1.x is in use, plan the move to a supported backend. Graylog deprecated 1.x use in 7.0 and removes it in 8.0, and it recommends Data Node as the search backend. Sequence the MongoDB changes so the version lands inside the supported range before the Graylog upgrade. Output: a remediation plan with backup points, owners and a go or no-go check before each change.
Rehearse the upgrade in staging
Restore a recent production backup into a staging environment with the same node layout. Run the MongoDB, search backend and Graylog changes in the planned order, then test inputs, search, streams, pipelines, dashboards, event definitions and notifications. Repeat the rollback path to the previous package and data state. Output: a rehearsal log with timings measured in your environment and a tested rollback procedure.
Upgrade production one node at a time
Set is_leader to false on follower Graylog nodes, then take one node out of the load balancer rotation. Upgrade that node, confirm it rejoins the cluster and processes messages, and only then move to the next node. Watch the message journal and input health throughout. Output: every node reporting healthy on the target version, with ingestion stable for the window agreed in the written scope.
Validate results and hand over
Run the staging validation checklist against production, covering active inputs, search results, streams, dashboards, alerts and sign-in through your chosen authentication method. Walk your operators through the runbook, backup schedule and rollback steps. Output: a signed validation record, an updated runbook and a handover session with named owners.
Operate under ongoing support
After handover, ongoing support can cover reviews of new 7.x minor releases, compatibility checks against MongoDB and OpenSearch, patch rollouts through the same staged process, and incident response within agreed hours. The written retainer sets response expectations and exclusions. Output: a support calendar and an agreed status report on the platform's health and pending changes.
What usually goes wrong
Most Graylog upgrade problems come from version mismatches, unplanned node restarts and changes that nobody tested before production. Each risk below has a prevention step to complete before the upgrade window opens.
Server upgraded ahead of backends
Upgrading Graylog server before MongoDB or the search backend falls inside the compatibility matrix can leave the cluster running on unsupported combinations. Before each change, confirm the target Graylog version's MongoDB and OpenSearch or Data Node ranges, then upgrade the backend first wherever the matrix requires it.
OpenSearch 1.x still in place
OpenSearch 1.x is deprecated since Graylog 7.0 and is scheduled for removal in Graylog 8.0. Teams that leave it running will face a forced search backend migration on top of the server upgrade. Inventory every node's search version now and plan the move to Data Node or a supported OpenSearch release as its own change.
Restarts that drop or back up inputs
Restarting Graylog nodes without checking the message journal and load balancer behavior can drop inputs or let the journal fill. Confirm the journal is sized at 3 to 5 times daily ingest on SSDs, restart one follower at a time, and verify the load balancer drains connections before each node goes down.
Skipping staging rehearsal
Without a rehearsal on a production-like copy, plugin incompatibilities and broken processing pipelines often surface only after users start searching. Run the upgrade in staging with the same plugins, inputs and pipeline rules, then test extractors, streams, dashboards and event definitions against live-style traffic before approving production.
Graylog Security on old OpenSearch
Graylog Security requires OpenSearch 2.0 or later. Enabling it on an older OpenSearch version produces an unsupported stack that may not run its SIEM features reliably. Check the search backend version against the compatibility matrix as a gate in the Security change request, and upgrade the backend first if it falls short.
No owner for patch intake
Without a named owner, Graylog releases, compatibility changes and security fixes go unreviewed until an incident forces attention. Assign one person or team to watch release tags and documentation, triage each release against your environment, schedule staging tests and approve production windows on a regular cadence.
Recurring costs after go-live
This table lists each cost line that continues after a Graylog go-live, who is paid for it, and what moves the amount, with the one-time migration item marked separately.
| Cost line | Type | What drives it |
|---|---|---|
| Graylog Open licensing | Recurring, no license fee | Free per the Graylog pricing page, with community support only. Your team carries the operating effort. |
| Enterprise or Security subscription | Recurring, only if chosen | Enterprise starts at 15,000 US dollars per year and Security at 18,000 US dollars per year (Graylog pricing page). Minimum 10 GB per day or 100 Compute Units, priced on processed data with no per-user fees. |
| Graylog node hosting | Recurring | Compute for the Graylog server nodes, sized to ingest rate, pipeline load and search concurrency. Confirm sizing with your vendor or partner. |
| MongoDB hosting | Recurring | Configuration and metadata only, run as a replica set. Cost is mostly fixed and grows with the number of users, streams and inputs. |
| Data Node or OpenSearch hosting | Recurring | Compute and memory for the search cluster. Graylog recommends Data Node, and a separate three-node cluster is the multi-node reference design. |
| Log storage | Recurring | Sized by daily ingest times retention days times 120 percent (Graylog system architecture guidance). Retention length is the largest lever. |
| Admin time for patch intake and testing | Recurring, internal | Reviewing each 7.x minor release, testing in staging and scheduling rolling upgrades across nodes. Paid from your own team's hours. |
| Support retainers | Recurring, quoted separately | Scope depends on upgrade frequency, environments covered and response expectations. Ask for a written quote tied to the agreed scope. |
| OpenSearch 1.x migration | One-time | Required before Graylog 8.0 removes OpenSearch 1.x support. Effort depends on cluster size, index history and downtime limits. |
How the work changes by starting point
A cluster still on OpenSearch 1.x has to move before Graylog 8.0, because use of OpenSearch 1.x is deprecated since Graylog 7.0 and will be removed in Graylog 8.0. The search backend change is the largest part of this work, so it is planned ahead of the Graylog server upgrade rather than squeezed into it.
- Confirm the target search backend first: Graylog recommends Data Node, and the compatibility matrix lists the supported OpenSearch range for each Graylog release.
- Inventory every index set, index template and snapshot that depends on the 1.x cluster before any data moves.
- Plan the data move and the cutover window with the team that owns log sources, since shippers keep sending during the transition.
- Verify that searches, dashboards and event definitions return the same results on the new backend before retiring the old cluster.
- Confirm the exact supported versions with Graylog's compatibility matrix for your target release.
A package-based install on Ubuntu, Red Hat, SUSE or Debian is upgraded with the distribution's package manager, using the Graylog Debian or RPM packages for the target release. The work centers on repository configuration, service ordering and configuration file changes.
- Confirm the Graylog repository and package versions for your distribution against the installation documentation.
- Check MongoDB and the search backend against the compatibility matrix before upgrading the Graylog server package.
- Review configuration file changes between your current release and the target before restarting services.
- Use a staged package upgrade on a test node, then apply it to the rest of the cluster.
- Keep package pinning and maintenance windows documented so unplanned updates do not change the server version.
A Docker Compose install changes the upgrade unit from a package to an image. The work focuses on image pinning, persistent volumes and whether data survives container replacement.
- Pin the Graylog image to an exact release tag instead of a floating tag, so a restart cannot change the version.
- Confirm that MongoDB and the search backend images match the compatibility matrix for the target release.
- Verify that volumes for Graylog data, MongoDB and the search backend are persistent and named consistently before recreating containers.
- Back up volumes and the Compose file before pulling a new image, and test restore on a copy.
- Record image digests and tags in your change record so auditors and operators can trace the running version.
A single-node install being grown into the recommended multi-node layout is an upgrade combined with a topology change. The version upgrade and the cluster build are sequenced so that each step can be verified and rolled back independently.
- Upgrade the single node to the target version first, so the new cluster is built on a supported baseline.
- Plan the target layout: three Graylog and MongoDB nodes with MongoDB as a replica set, and three Data Nodes on their own cluster.
- Set the is_leader value to false on follower Graylog nodes, and put a load balancer in front of inputs.
- Move data and configuration in stages, and confirm that ingestion continues through each stage.
- Size storage and the message journal for the new layout using Graylog's architecture guidance, which advises planning from daily ingest and retention.
An air-gapped environment cannot pull packages or images from the internet during an upgrade, so every artifact must be mirrored and verified inside the network before work starts. The upgrade calendar also depends on how often approved artifacts can be brought in.
- Mirror the Graylog packages or images, MongoDB and search backend artifacts for each target version, along with their dependencies.
- Verify checksums or signatures of every mirrored artifact against the vendor's published values before use.
- Keep an internal registry or package repository that is updated only through an approved transfer process.
- Test the mirrored set on a staging network that matches production before the production window.
- Confirm with your security team how transfer approvals and records are handled for each release.
An install on Graylog Enterprise or Security follows the same core upgrade path as Graylog Open, but the licensed features add components that must be checked on each release. Support scope and which feature set is in use shape the verification work.
- Confirm the Enterprise or Security license and the features in use, such as data tiering, archive restore, single sign-on or SIEM content.
- Check the compatibility matrix for Graylog Security, which needs OpenSearch 2.0 or later.
- Retest licensed features such as the correlation engine, data lake archives and compliance packs after each upgrade.
- Confirm with Graylog which support channel and response terms apply to your subscription before scheduling a window.
- Ask for written scope on any licensed component that DeployOpen would test, since licensed features may need vendor-side confirmation.
What you need to provide
Start by giving us the current state of the stack in writing. Record the exact running version of each Graylog server node, the MongoDB release that holds configuration and metadata, and the search backend, whether that is Graylog Data Node or self-managed OpenSearch. Check those versions against the compatibility matrix for your target line. The matrix lists MongoDB 7.x up to 8.2.x and OpenSearch 1.1.x up to 3.7.x for Graylog 7.0 to 7.2, and Graylog Security needs OpenSearch 2.0 or later. If you still run OpenSearch 1.x, flag it now. That version has been deprecated since Graylog 7.0 and will be removed in Graylog 8.0.
Next, provide an inventory of everything the upgrade touches: inputs and their types, processing pipelines and rules, content packs, installed plugins, and event definitions with their notification targets. A configuration export and a named owner for each item let us test the target version against the full estate. Also state the target version and the reason for it, such as the latest 7.2 release or a specific 7.1 patch level that fits your change calendar and the release notes your team has reviewed.
Provide a staging environment that mirrors production in node count, MongoDB replica set layout and search cluster topology, so that the rolling upgrade is rehearsed on the same shape of system. Approve maintenance windows in advance and name the person who decides on rollback during each window. Give us access to the current backups and confirm that a restore has been tested on a recent copy. Name a Graylog admin with the administrative rights needed to make changes and to validate inputs and dashboards after each node is upgraded.
Name the person who signs off each change to production, and confirm that this approval is recorded before work begins. After handover, your team must own patch intake: a named owner who tracks new Graylog, MongoDB and search backend releases and decides when to schedule them. If audits or compliance reviews apply, define the requirement set now, including which controls, log sources and evidence formats the assessor expects. DeployOpen prepares systems and evidence for those reviews, but the independent auditor issues any conclusion.
Frequently asked questions
What drives the cost of a Graylog upgrade and how is it quoted?
The cost follows the written scope: the number of Graylog server nodes, MongoDB nodes and Data Node or OpenSearch nodes, the starting and target versions, how many inputs, pipelines, streams and dashboards need regression checks, and whether a staging environment must be built first. Quotes are fixed-scope and issued after the scope is agreed in writing. Ask for the quote to separate discovery, staging, upgrade windows, rollback testing and handover documentation, and to label each item as one-time or recurring. Ongoing support after handover is a separate retainer, quoted separately. DeployOpen does not publish a price list.
Can our own team upgrade Graylog using the release notes?
Yes, a capable team can, provided it checks the release notes and the Graylog compatibility matrix before each step. The matrix sets which MongoDB and OpenSearch versions each Graylog line supports. For example, Graylog 7.0 to 7.2 pair with MongoDB 7.x up to 8.2.x and OpenSearch from 1.1.x up to 3.7.x, and Graylog Security needs OpenSearch 2.0 or later. Confirm every component version, rehearse the steps on a copy of your configuration, and plan rolling restarts for multi-node clusters. The main risk usually sits in custom pipeline rules, extractors and storage settings, so test those explicitly.
How long does a Graylog upgrade take?
There is no fixed duration. Time depends on scope, cluster size, the number of log sources and dashboards to verify, and whether a staging environment must be built and tested before production. A single-node lab differs considerably from a medium or large deployment, which the Graylog multi-node guide describes with three Graylog and MongoDB nodes, a three-node Data Node cluster and a load balancer. The work also needs your team to provide named owners, access to non-production systems, sample log data and approved change windows. Ask for the timeline in the written scope with each phase listed.
Is Graylog Open still open source after version 4.0?
Graylog Open is free to use, but its license is not an OSI-approved open source license. Starting with Graylog 4.0 in 2020, Graylog Open is licensed under the Server Side Public License version 1 (SSPL-1.0), according to the LICENSE file in the Graylog server repository. Earlier releases were under GPL v3. Legal and procurement teams should review SSPL-1.0 against their own policies, especially if they plan to offer Graylog as a service to others. Graylog Open has no volume limits and community support, while Enterprise and Security are paid subscriptions.
When must we move off OpenSearch 1.x for Graylog?
Plan the move before you upgrade to Graylog 8.0. Use of OpenSearch 1.x has been deprecated since Graylog 7.0 and will be removed in Graylog 8.0, according to the Graylog installation documentation. Graylog recommends Data Node as the search backend. Moving off OpenSearch 1.x involves data and configuration migration, so it belongs in the same plan as the Graylog version change. Test index sets, retention and user access after the move. Confirm the target backend and its version against the compatibility matrix before you schedule the work.
Does DeployOpen provide audit reports or certifications for Graylog?
No. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform that work. DeployOpen can prepare the systems, configuration and evidence that an assessor reviews, such as documented access settings, retention configuration, patch records and change logs. Confirm with your assessor which evidence they need and when they need it, then agree in the written scope which artifacts DeployOpen will produce.
How DeployOpen scopes, delivers and supports Graylog upgrades
DeployOpen plans, tests, executes and documents Graylog upgrades inside your own infrastructure under a fixed-scope written agreement. Ongoing support for later releases is available as a retainer once the upgrade is complete.
How we scope
- The written scope lists your Graylog version, MongoDB and OpenSearch or Data Node versions, and the target release.
- We check the vendor compatibility matrix for MongoDB and OpenSearch or Data Node at every version step.
- Fixed-scope engagements are agreed in writing before work starts, and ongoing support is available as a retainer.
How we build
- We stage the upgrade in a non-production copy of your cluster before any production node changes.
- We upgrade Graylog nodes one at a time and confirm follower nodes keep is_leader set to false.
- Where OpenSearch 1.x is still in use, we plan the move to Data Node or supported OpenSearch before Graylog 8.0.
How we hand over
- You receive a written record of versions before and after, configuration changes and the rollback steps used.
- Runbooks cover node order, MongoDB replica set checks, index health checks and post-upgrade search and alert tests.
- Your team walks through the runbook with us before the production window, so operators can repeat the steps.
How we support
- Retainers cover planned minor and patch releases in the 7.x line with testing before each window.
- Support scope, response expectations and maintenance windows are written into the retainer before it starts.
- Ask for the upgrade plan, rollback steps and per-version compatibility checks as separate line items in any quote.
