Graylog Data Node or self-managed OpenSearch: which fits your team
Choose Graylog Data Node if you want Graylog to handle OpenSearch certificates, cluster membership, new node joins and the correct OpenSearch version and extensions, and your team would rather not run those tasks by hand. Choose a self-run OpenSearch cluster if you already operate OpenSearch in production, have a reason to own the cluster directly (for example, a standard OpenSearch tooling set or an existing platform team that manages every search cluster the same way), and can staff the upgrade and patch cycle yourself. Graylog documents Data Node as the recommended search backend, so the default path is Data Node unless one of those conditions clearly applies.
Data Node does not remove the security work. Graylog's self-managed OpenSearch guidance states that its install steps do not configure security settings, so every component must be secured before production use. With self-managed OpenSearch, you own TLS for node and client traffic, the security plugin configuration, role mapping, and restricting access to the default ports 9200/tcp and 9300/tcp. Graylog warns that without a security plugin, data is readable by anyone with network access to the machine. Confirm with Graylog which hardening steps Data Node performs for you in your version, and write down which controls remain your responsibility.
Check version fit before you choose. Graylog 7.2 supports self-managed OpenSearch from 1.1.x up to 3.7.x, and Graylog Security needs OpenSearch 2.0 or later, while Graylog deprecates OpenSearch 1.x for removal in Graylog 8.0. Indices created before OpenSearch 2.0 are incompatible with 3.x. Data Node migration wizard works only from an existing OpenSearch instance, so Elasticsearch users must first move to OpenSearch. Note that Data Node metrics and the Cluster Management dashboard require a Graylog Enterprise license, so confirm your edition before you plan operations around those views. Ask your Graylog contact to confirm which of these applies to your current version and edition.
How the two storage options compare on the factors that matter
This table compares who installs and runs the search cluster under each option, how far Graylog Data Node automates it, and what your team still owns. Read each row as a question to answer for your own environment, then check the Enterprise-only and version notes before you commit.
| Factor | Graylog Data Node | Self-managed OpenSearch |
|---|---|---|
| Who installs and manages the cluster | Data Node installs and manages OpenSearch, including the correct OpenSearch version and its extensions | Your team installs, configures, patches and upgrades every OpenSearch node |
| Certificates and cluster membership | Data Node handles certificates, cluster membership and adding new nodes | Your team creates certificates, manages node membership and changes cluster topology |
| Supported version range for Graylog 7.2 | Graylog recommends Data Node as the search backend for Graylog 7.2 | OpenSearch 1.1.x to 3.7.x per the Graylog compatibility matrix; confirm the exact build you deploy |
| Hardening responsibility | Graylog's guidance covers the Data Node path, so confirm with Graylog which security settings Data Node applies by default | Graylog's guides do not configure OpenSearch security, so your team must secure all components before production use |
| Enterprise-only Data Node views | Cluster Management dashboard and Data Node metrics require a Graylog Enterprise license; without it the tab shows static example data | Not applicable, so monitor the cluster with tools your team selects and operates |
| Licensing of the search layer | Data Node is part of the Graylog stack, so confirm its license terms with Graylog before you deploy | OpenSearch is licensed under Apache-2.0, and the OpenSearch FAQ does not describe any paid edition |
| Migration path | Data Node includes a migration wizard for an in-place move from an existing OpenSearch instance | Migrating into Data Node requires an OpenSearch backend, so Elasticsearch users must first move to OpenSearch |
| Ongoing operating effort | Lower routine cluster work for the team, but you still own Graylog server and MongoDB operations | Higher routine cluster work, including version planning, certificates and node changes, recurring over the life of the system |
What Graylog Data Node takes over from your team
Graylog Data Node takes over the lifecycle work that a self-managed OpenSearch cluster otherwise leaves to your operators. According to the Graylog Data Node installation docs, the component handles certificates, manages cluster membership and adds new nodes, and it ensures the correct OpenSearch version and its extensions are installed. For a team that would otherwise hand-build TLS certificates, join nodes to the cluster and align package versions with each Graylog release, this removes a recurring set of steps and a common source of drift. Graylog's own guidance calls Data Node the preferred method of data management, so this is the default to test first.
The handover is narrower than it sounds. Data Node does not design your network, so you still decide which subnets carry node-to-node and Graylog-to-storage traffic, and you still restrict access to the ports your environment exposes. Storage sizing stays with you: Graylog's system architecture page advises sizing log storage as daily ingest times retention days times 120 percent, and your disks, retention policy and replica choices determine whether that holds. Backups, snapshot repositories and restore testing are also yours to design and rehearse. The host operating system still needs patching, time sync, kernel and firewall configuration, and monitoring of disk and heap pressure.
Before you commit, confirm three things in writing with Graylog and in your own environment: which OpenSearch version your target Graylog release installs through Data Node, how Data Node certificates are rotated in your change process, and who owns host patching during a Data Node upgrade. DeployOpen can plan, implement and document this split under a fixed-scope engagement, with the scope, deliverables and timeline agreed before work starts. Ask for the handover runbook as a deliverable so your team can run the cluster after the engagement closes.
When to choose Data Node and when to run your own OpenSearch
Data Node suits teams that run Graylog but have no one who already operates a search cluster day to day. Graylog's documentation names Data Node as the recommended search backend, and it manages OpenSearch for you: it handles certificates, cluster membership and adding new nodes, and it ensures the correct OpenSearch version and extensions are installed. That shifts a large share of routine cluster work to the Graylog side, although your team still owns capacity, retention and access decisions.
- Certificate handling: Data Node manages the certificates used inside the cluster, so you do not hand-build that trust chain for every node.
- Version alignment: Data Node keeps OpenSearch aligned with the Graylog release you run, which matters because the compatibility matrix limits which OpenSearch lines each Graylog release supports.
- Node additions: Scaling out follows Graylog's own procedure rather than a manually assembled cluster join.
- Metrics access: Cluster Management metrics require a Graylog Enterprise license, so confirm whether that tier is in your budget.
- Staff skills: Someone still needs to size storage, watch disk and heap, and run recovery tests.
Confirm with Graylog which Data Node version matches your planned Graylog release and whether your Graylog edition includes the monitoring you expect.",
Running your own OpenSearch fits teams that already operate OpenSearch for other workloads, or that have internal standards for patching, backup, monitoring and access control that a separate Data Node cluster would not follow. In that case, Graylog points at an existing cluster as a self-managed search backend. The trade-off is that the OpenSearch cluster becomes your responsibility, including the version lines Graylog supports, which for Graylog 7.2 run from OpenSearch 1.1.x to 3.7.x.
- Version constraints: Graylog 7.2 supports OpenSearch 1.1.x up to 3.7.x, and Graylog Security needs OpenSearch 2.0 or later. OpenSearch 1.x use is deprecated and will be removed in Graylog 8.0.
- Index compatibility: Indices created before OpenSearch 2.0 are incompatible with 3.x, so check the index history of any cluster you plan to reuse.
- Security configuration: Graylog's guide does not configure security settings for self-managed OpenSearch, so you must secure the cluster yourself.
- Shared-cluster risk: A cluster shared with other workloads needs index-level and role-level separation that you design and test.
- Version track: Confirm which OpenSearch release line your platform team plans to keep under maintenance, since OpenSearch maintenance windows are finite.
Confirm your current OpenSearch version and whether it falls inside the range your Graylog release supports before you commit.",
Air-gapped and tightly controlled networks need the installation method, package source and update path settled before anything is deployed. Both options can run offline in principle, but the work of obtaining, verifying and updating packages falls on your team, and Data Node adds a component that must also be sourced and kept current. Teams in these environments should weigh how often they can accept updates against Graylog's version support and OpenSearch's maintenance schedule.
- Package provenance: Decide how packages enter the enclosure and how you verify them, whether you use Data Node's bundled OpenSearch or your own tarball, RPM or Debian packages.
- Port restriction: Graylog's self-managed guide tells operators to restrict OpenSearch ports 9200/tcp and 9300/tcp, and warns that without a security plugin the data is readable by anyone with network access.
- Security plugin: Plan TLS, authentication and role-based access before go-live, since Graylog does not configure these for self-managed OpenSearch.
- Update cadence: OpenSearch releases a new minor version about every eight weeks, so budget a regular offline transfer cycle for patches.
- Migration path: Data Node's migration wizard works only when the backend is OpenSearch, so plan the move if you start self-managed and later switch.
Confirm with your security authority which packages can be imported, how often patch bundles can cross the boundary, and whether your authorization covers a bundled OpenSearch.
Which OpenSearch versions a self-managed cluster can run with Graylog 7.2
A self-managed OpenSearch cluster behind Graylog 7.2 must run a version from 1.1.x up to 3.7.x, according to the Graylog compatibility matrix. Graylog Security needs OpenSearch 2.0 or later, so the floor is higher if you plan to use it. OpenSearch 3.9.0 is the current release, but it sits above the 3.7.x ceiling for Graylog 7.2 self-managed deployments, so it is not a valid target for that pairing. Confirm the matrix against the exact Graylog patch level you will install before you pick a version, because supported ranges change between Graylog releases.
Check your existing indices before any version change. Indices created before OpenSearch 2.0 are incompatible with 3.x, so a cluster that has held data since the 1.x or early 2.x era cannot be moved to 3.7.x and expected to keep old logs searchable. Record the creation version and date of each index set, then test the upgrade on a non-production cluster with a copy of your data. Decide whether older indices will be reindexed, kept on a 2.x line, or allowed to age out under your retention policy, and confirm that choice with your compliance owner before production work starts.
OpenSearch 1.x is deprecated in Graylog, and Graylog's installation documentation states that its use will be removed in Graylog 8.0. If you run 1.x today, moving to a supported 2.x or 3.x line is a dated requirement that should sit in your Graylog upgrade plan now. Data Node takes a different approach: it installs and manages the OpenSearch version and its extensions for you, so version alignment becomes part of Graylog's own upgrade path. With a self-managed cluster, your team owns each version check, each rolling upgrade and each compatibility review.
What stays your responsibility in a self-managed cluster
Graylog Data Node takes over OpenSearch installation, certificates, cluster membership and version alignment, but a self-managed OpenSearch cluster leaves security configuration with your team. The cards below cover the controls that Graylog's own guides do not set for you, and what to confirm before any production data lands in the cluster.
Security configuration is not set for you
Graylog's self-managed OpenSearch guide states that it does not configure security settings, so every component must be secured before production use. Treat hardening as a build step, not a follow-up task. Confirm the security settings, certificates and node-to-node trust in your own change record before the first log is indexed, and assign an owner for each.
Restrict ports 9200 and 9300
OpenSearch listens on 9200/tcp for client traffic and 9300/tcp for node transport by default. Graylog's guidance is to restrict both, because without a security plugin the stored data is readable by anyone with network access to the host. Confirm with your network team that only Graylog servers and approved administrators can reach these ports, and test that from outside the allowed segment.
Security plugin and TLS
The OpenSearch Security plugin provides TLS for node and client traffic, which is the control that stops other hosts on the path from reading or altering log data in transit. Confirm that the plugin version matches your OpenSearch release, that certificates are issued from a CA your team controls, and that rotation is documented, since Data Node would otherwise handle this for you.
Authentication backends
The Security plugin supports SAML, OpenID Connect, Active Directory and LDAP, Kerberos and JSON Web Token authentication. Pick the backend that matches your identity provider, and decide whether local accounts exist at all. Confirm how Graylog server nodes authenticate to the cluster, how service credentials are stored, and who can rotate them when a person leaves the team.
Role and index access
Role-based access control, document-level and field-level security and field masking let you limit which Graylog service account can read which indices and which fields. Design roles per index pattern and per team before you create them, so that a broad admin role is not used for daily log access. Confirm that the Graylog service role can write only to its own indices, and that analysts cannot delete data by accident.
Audit logging and monitoring
Audit logs record security-relevant events in the cluster, such as authentication attempts and changes to security configuration. Enable them, decide where they are shipped, and keep them outside the cluster they describe. Confirm retention with your compliance lead, because Graylog's retention settings govern message data and do not replace an audit trail for the search backend itself.
Upgrades, backups, monitoring and skills for each option
This table compares who handles upgrades, version lifecycle, backups, monitoring, failure handling and skills under Graylog Data Node and a self-managed OpenSearch cluster. Read each row as a question to answer for your own team, since the split of work depends on who will own the cluster day to day. The main takeaway is that Data Node shifts cluster-level version alignment to Graylog, while your team keeps snapshots, hardening and capacity monitoring in both models.
| Area | Graylog Data Node | Self-managed OpenSearch |
|---|---|---|
| Version alignment | Graylog Data Node installs and manages the OpenSearch version and its extensions that match the Graylog release. | Your team chooses the OpenSearch version, checks it against the Graylog compatibility matrix (1.1.x to 3.7.x for Graylog 7.2) and plans each upgrade. |
| Version lifecycle | Follows the Graylog release line. Graylog states OpenSearch 1.x is deprecated and will be removed in Graylog 8.0. | OpenSearch 1.x reached end of life on May 6, 2025. Versions get fixes during maintenance, but confirm the support window for your chosen line on the OpenSearch releases page. |
| Upgrade path | Graylog-driven upgrades via the Data Node component, including the in-place migration wizard for existing OpenSearch clusters. | Your team runs the rolling upgrade and confirms index compatibility, since indices created before OpenSearch 2.0 are incompatible with 3.x. |
| Backups and snapshots | Confirm with Graylog which snapshot and restore steps apply to Data Node and who owns the repository configuration. | Your team owns snapshot repositories, retention and restore testing, and must confirm them before production use. |
| Monitoring | Data Node metrics and the Cluster Management dashboard require a Graylog Enterprise license. Without it, the tab shows static example data. | Your team picks the metrics stack for cluster health, shard state, heap and disk. Confirm which OpenSearch metrics your tooling exposes. |
| Failure handling | Data Node manages cluster membership and adding nodes, so node replacement follows Graylog's documented procedure. | Your team handles node loss, shard recovery and split-brain prevention directly, following OpenSearch cluster guidance. |
| Hardening effort | Graylog's self-managed OpenSearch guide does not configure security settings, so hardening is still your job even with Data Node. | Your team enables the Security plugin, TLS, access restriction to ports 9200 and 9300, and role mapping before production. |
| Skills required | Linux administration, Graylog administration and enough OpenSearch knowledge to read cluster health and snapshot status. | Linux administration, OpenSearch cluster administration, security plugin configuration and a documented upgrade runbook. |
How to move in place from self-managed OpenSearch to Data Node
This sequence moves an existing Graylog log store from a self-managed OpenSearch cluster to Graylog Data Node without rebuilding your log history from scratch. Each step ends with a check you can record before moving on.
Confirm the search backend is OpenSearch
Start by confirming that your current Graylog deployment indexes logs into OpenSearch and not Elasticsearch. Graylog's migration wizard only works when the search backend is OpenSearch, so an Elasticsearch user must first move to OpenSearch as a separate project before using Data Node. Check the search backend setting in your Graylog configuration and the cluster information shown in the Graylog system pages, and record the backend type and version. The step is done when the team has written confirmation that the backend is OpenSearch and that the Graylog version in use is covered by the Data Node migration documentation.
Review index compatibility and OpenSearch version
Review the OpenSearch version and the indices it holds against the Graylog compatibility matrix for your Graylog release. For Graylog 7.2.x with self-managed OpenSearch, the supported range is 1.1.x to 3.7.x, and indices created before OpenSearch 2.0 are incompatible with 3.x, so any older index data must be checked before the move. Confirm which indices are present, their creation versions and whether the cluster is healthy. The step closes when a written compatibility review lists the OpenSearch version, the index creation versions and any blocking issues, and the team has signed off on it.
Back up configuration and index data
Before any change, take a verified backup of the MongoDB configuration database and the OpenSearch indices, and store it outside the cluster being migrated. Record the Graylog configuration, streams, pipelines, inputs, event definitions and retention settings, because these live in MongoDB and must survive the move. Confirm the backup can be restored by testing a restore into a separate environment. The step is complete when the backup has been restored successfully in a test environment and the restore log is kept with the change record.
Prepare the Data Node cluster and secure it
Install the Graylog Data Node cluster in your own infrastructure, following the Data Node installation documentation for your version. Data Node manages OpenSearch certificates, cluster membership and the OpenSearch version and extensions, but it does not replace your security review. Confirm that the Data Node ports are reachable only from Graylog servers and administrators, that TLS is in place, and that access controls match your policy. The step is done when the new cluster reports healthy, is reachable from every Graylog server, and a security review has accepted the network and access settings.
Run the migration wizard
Open the Data Node migration wizard in Graylog and point it at the existing self-managed OpenSearch instance, following the steps shown for your Graylog version. Schedule the run in a maintenance window agreed with the operations and log-owning teams, and keep ingest status under watch during the run. Monitor cluster health, indexing errors and the Graylog system log while the wizard copies or moves data. The step closes when the wizard reports completion without unresolved errors and the migration log is saved with the change record.
Validate searches, dashboards and retention
After the migration, test searches across the time ranges your analysts use, and compare result counts for a sample of known events against the pre-migration results. Check that dashboards, saved searches, streams and event definitions still return data, and that index rotation and retention settings delete the oldest indices as configured. Confirm that alerts still fire with a controlled test event. The step is complete when the sample results match the pre-migration record, the alerts test passes, and the retention check is recorded.
Close out and retire the old cluster
Once validation passes, keep the old OpenSearch cluster read-only for a period agreed with your data retention owner, then decommission it according to your records policy. Update runbooks, architecture diagrams, monitoring targets and access lists to reflect the Data Node cluster, and remove firewall rules that no longer apply. Record the final state, including versions, backup locations and open items, and confirm the exact procedure against the Graylog documentation for your version before the next upgrade. The step is done when the change record is signed off and the old cluster has a documented retirement date.
Which Data Node views need a Graylog Enterprise license
Data Node metrics and the Cluster Management dashboard require a Graylog Enterprise license. Without one, that tab shows static example data rather than your cluster's actual state. Before you choose Data Node, confirm that the views your operators need for capacity and health are included in the edition you plan to buy, because the Graylog Open edition does not give you a live view of the Data Node cluster. This is a licensing boundary, not a difference in the OpenSearch engine underneath, so a self-managed OpenSearch cluster still exposes its own health and node data through the tools you run around it.
The operational risk is specific. If your team relies on the Data Node views to decide when to add nodes, when disk is filling, or whether a cluster member has left, a Graylog Open deployment gives you no trustworthy signal in that screen. You would need to build that monitoring elsewhere, such as the OpenSearch APIs with your existing metrics stack, and keep it running alongside Graylog. Ask Graylog which Data Node metrics are visible at each edition, and test the view on a non-production cluster before you rely on it for an on-call runbook.
The Enterprise cost is driven by data volume rather than headcount. According to the Graylog pricing page, Graylog Enterprise starts at 15,000 US dollars per year, with a minimum of 10 GB per day or 100 Graylog Compute Units, and it is licensed on processed data with no per-user or per-device fees. A larger daily ingest therefore raises the license tier, while adding administrators does not. When you request a quote, ask for the price at your actual daily volume, confirm whether the Data Node views are included in that tier, and confirm what happens to licensing if your ingest grows after signing.
Frequently asked questions about Graylog Data Node and self-managed OpenSearch
Who pays for the work of running the search backend under Graylog?
Your organization pays for the staff or service time that runs the search backend, plus the hosts, storage and network that carry it. OpenSearch is Apache-2.0 licensed, and the OpenSearch FAQ does not describe a paid edition, so the software itself carries no license fee. Graylog Open is free, but Graylog Enterprise is a paid edition, starting at 15,000 US dollars per year according to Graylog's pricing page, and the Data Node metrics and Cluster Management dashboard require an Enterprise license. The recurring costs are patching, certificate renewal, version upgrades, monitoring and capacity growth. Ask Graylog to confirm which license terms apply to Data Node itself. If you engage DeployOpen, the work is agreed as a fixed scope in writing before it starts, and ongoing support is available as a retainer. Ask for the quote to split one-time build work from recurring operations.
Can our team migrate from self-managed OpenSearch to Data Node alone?
Yes, if your team has the skills and a test environment, because Graylog Data Node includes a migration wizard for an in-place move from an existing self-managed OpenSearch instance. The wizard only applies when the current search backend is OpenSearch. Elasticsearch users must first move to OpenSearch before they can use it. Read the prerequisites in Graylog's Data Node installation guide before you plan a change window. Check that your current OpenSearch version falls within the supported range for your Graylog release, and that indices created before OpenSearch 2.0 are handled, since those are incompatible with 3.x. A full rehearsal on a copy of production data is the safest test. DeployOpen can plan, execute and document the migration under a fixed-scope agreement if your team prefers outside help.
How long does a Data Node migration or new build take?
No researched duration is available for this work, so ask for a written timeline rather than relying on a general figure. The schedule depends on the data volume in your existing indices, the number of search nodes, whether you run a multi-node layout, the state of your current OpenSearch version, and how many Graylog inputs, streams and dashboards need validation afterward. Graylog's system architecture guidance sizes log storage as daily ingest multiplied by retention days and then by 120 percent, so the storage footprint is a good starting input for scoping. Graylog 8.0 will remove OpenSearch 1.x, so a version upgrade may also be part of the schedule. Ask any provider, including DeployOpen, to list each phase, the assumptions behind it, the test windows and the sign-off points before work begins.
What must our team provide before a Data Node project starts?
Your team must provide the target infrastructure, the access to run it, and a named owner who can make decisions during the project. That includes hosts or virtual machines for Graylog server nodes, MongoDB and the Data Nodes, plus the cloud account, data center or air-gapped network where they will run. Graylog's multi-node guide recommends three Graylog and MongoDB nodes with MongoDB as a replica set, three Data Nodes on their own cluster and a load balancer for medium to large deployments. You also need a certificate authority or a decision on how certificates will be issued, an identity source if you plan to use single sign-on, a backup location with a tested restore path, and a change window for cutover. Confirm each item against your own environment and the Graylog documentation before scoping.
Does Graylog Data Node lock us into Graylog?
Data Node locks your search layer to the Graylog ecosystem in one practical sense: it is the component that manages OpenSearch for Graylog, handling certificates, cluster membership and node additions. The log data itself is indexed in OpenSearch, which is Apache-2.0 licensed, so the stored indices are not held in a proprietary format. Graylog-specific configuration is different. Streams, processing pipelines, event definitions and index set settings live in Graylog and its MongoDB database. Those parts only carry over to another platform through export and rebuilding, so the lock-in sits mostly in the Graylog layer and its alerting content. Ask Graylog to confirm what exports are available for each object type in your Graylog version.
What changes if we later move off Graylog?
The indexed log data can stay in OpenSearch, so an exit mostly means moving the ingest and search layer, not the stored history. Your collectors, syslog and Beats inputs, and GELF senders would need to point at a new pipeline. Graylog streams, pipelines, event definitions and dashboards will need to be exported where possible and rebuilt where not. OpenSearch Security Analytics can match ingested logs against Sigma rules, record findings and correlate them across log types, so some detection logic may map to it, but that mapping needs testing against your own rules. Plan the exit with an inventory of every Graylog object, a list of the alert recipients and a parallel run period. DeployOpen can scope a migration of this kind as a fixed-scope project.
What does Data Node manage, and what must we still harden?
Data Node manages certificates, cluster membership, the addition of new nodes, and the correct OpenSearch version and extensions. It does not remove your hardening work. Graylog's self-managed OpenSearch guide states that it does not configure security settings, so all components must be secured before production use. Restrict access to the OpenSearch ports, which default to 9200/tcp and 9300/tcp, and be aware that without a security plugin the data is readable by anyone with network access to the machine. Review what Data Node configures by default in the installation guide, then decide your authentication, role mapping, audit logging, backup encryption and network segmentation. Check these controls with your security team and record them as evidence.
How DeployOpen would scope a storage decision and deployment
The first scoping decision is whether the search backend is Graylog Data Node or a self-managed OpenSearch cluster, because it changes who owns certificates, cluster membership, version alignment and the hardening work. DeployOpen plans either option inside the client's own cloud accounts, data centers or air-gapped networks. The plan starts with a written inventory: the Graylog version in use, the MongoDB version, the OpenSearch or Elasticsearch version on any existing cluster, the planned Graylog Open or paid edition, and the retention and daily ingest figures that drive storage sizing. Confirm the current compatibility rules with the Graylog compatibility matrix before fixing any version, since support ranges change between releases.
Implementation covers the choice made in scoping. With Data Node, the work centers on node sizing, certificate handling, placement and the upgrade sequence Graylog defines. With self-managed OpenSearch, the work adds TLS for node and client traffic, role mapping, restricted access to the OpenSearch ports, backup configuration and a documented upgrade path, because Graylog's guide does not configure security settings. Hardening, backup, runbooks and evidence for compliance readiness are written into the scope rather than left as follow-up. If a migration from an existing self-managed OpenSearch cluster is in scope, the Data Node migration wizard and its prerequisites should be tested in a non-production copy first.
DeployOpen does not publish prices. Most engagements are fixed-scope, so deliverables, timelines and responsibilities are agreed in writing before work starts, and a quote follows from that written scope. Ask any provider, DeployOpen included, to separate one-time work (design, deployment, migration, hardening, documentation) from recurring work (patching, upgrades, monitoring, backup verification), and to state who holds the Graylog and OpenSearch licenses and subscriptions. Ongoing support, upgrades and continuous testing are available as retainers, and the choice between a retainer and internal ownership is worth deciding before the build starts. DeployOpen is not an official partner of Graylog or OpenSearch, and its work does not change the license terms of either product.
How DeployOpen delivers and supports Graylog storage deployments
DeployOpen plans, implements, hardens, documents and supports self-hosted platforms inside your own infrastructure, so the Data Node or self-managed OpenSearch decision is made against your network, retention and security requirements. Engagements are fixed-scope, with the scope agreed in writing before work starts.
How we scope
- We confirm daily ingest, retention period and index sizing before choosing the search backend.
- We document which Graylog edition and license terms apply to the storage layer you select.
- We agree in writing who owns certificates, cluster membership, upgrades and OpenSearch hardening.
- We confirm the target Graylog and OpenSearch versions against the vendor compatibility matrix.
How we build
- We deploy either Graylog Data Node or a self-managed OpenSearch cluster inside your cloud account or data center.
- We configure TLS, restrict OpenSearch ports and set access controls before any production log ingestion.
- We test index rotation, retention and node failure behavior against the agreed scope.
- Where you migrate in place from self-managed OpenSearch, we plan the steps and rollback path together.
How we hand over
- You receive configuration records, architecture diagrams and a runbook for the storage layer.
- We document the upgrade path, including which OpenSearch versions remain supported for your Graylog release.
- We walk your platform and security teams through certificate rotation and node addition procedures.
- We list the items your team must confirm with the vendor, such as Enterprise-only Data Node views.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- We can run scheduled upgrades to new Graylog or OpenSearch versions as part of a retainer scope.
- Security testing of the Graylog and OpenSearch deployment can be scoped as a separate engagement.
- Support terms, response expectations and any SLA are defined in the retainer agreement, not assumed.
