When one Graylog server is enough and when it is not
A single Graylog server suits a smaller log estate where the team can accept a restart or outage window for maintenance, while the multi-node layout suits medium to large deployments that need availability and a clear split of duties between Graylog, its metadata store and the search backend. The multi-node guide, which describes three Graylog and MongoDB nodes plus three Data Nodes in a Conventional model, targets medium-to-large scale, and Graylog says it can generally be followed at any cluster scale. Single instances follow a separate single-node guide, so start by reading the guide that matches your planned ingest, retention and uptime targets rather than assuming one layout is a smaller version of the other.
The layout also matters for licensing, even though it does not change the code. Graylog Open is licensed under SSPL-1.0, which is not OSI approved, and the same Graylog Open server software runs in both a single-node and a multi-node setup. Choosing multi-node therefore adds infrastructure and operating work but does not change which features or license terms you receive. Paid features such as index archiving, correlation and prebuilt detection content are sold by Graylog per edition, so confirm with Graylog which edition your target layout needs before you size the cluster. Ask Graylog to confirm in writing how licensing applies to each node in a multi-node cluster.
Before you commit, run a short sizing exercise. Multiply daily ingest by retention days and by 120 percent to estimate log storage, and plan the message journal at 3 to 5 times daily ingest on SSDs, as Graylog's system architecture guidance advises. If the storage and journal needs fit one host with a tolerable restart window, a single node is reasonable. If they do not, or if a lost host would stop your monitoring, plan the multi-node build and ask your implementation partner to confirm the MongoDB replica set, leader and follower settings, load balancer and heap sizing against your own hardware and change process.
Single-node and multi-node Graylog compared
This table sets a single Graylog server against the multi-node Conventional model with three Graylog and MongoDB nodes and three Data Nodes, row by row across components, topology, sizing and upgrades. Read each row as the work your team takes on at that layout, and treat the documented settings as the starting point for a design review rather than a finished configuration.
| Factor | Option A: single node | Option B: multi-node Conventional |
|---|---|---|
| Components | One Graylog server with MongoDB and a search backend on the same host | Three Graylog and MongoDB nodes plus a separate cluster of three Data Nodes |
| MongoDB topology | Single MongoDB instance on the Graylog host | MongoDB run as a replica set, initiated on the leader node only |
| Data Node placement | Can run on the same host for small setups, per the single-node guide | Kept on its own cluster, separate from Graylog and MongoDB |
| Leader and follower settings | Default is_leader setting (true) applies | is_leader set to false on follower Graylog nodes |
| Load balancer | Not required; clients connect to one host | Load balancer with a DNS record for Graylog is encouraged |
| Heap sizing | Confirm Graylog and Data Node heap against host memory | Graylog heap at half of system memory up to 16 GB; Data Node heap at half up to 31 GB |
| Journal sizing | Confirm journal against daily ingest and retention on this host | Each node's journal is 72 hours of log volume divided by the number of nodes |
| Host kernel setting | vm.max_map_count of at least 262144 on the search host | vm.max_map_count of at least 262144 on Data Node hosts |
| Upgrade path | Single restart window; confirm supported versions in the compatibility matrix | Rolling work across three nodes and a separate Data Node cluster, sequenced in your change plan |
| Operating effort | Lowest; one host to patch, back up and monitor | Highest; replica set health, load balancer, five-plus hosts and their monitoring to maintain |
Which layout fits which team situation
A single Graylog server with its MongoDB and search backend on one host fits a team that has one log source group, modest volume and can accept planned maintenance windows during which ingestion stops. The layout has the fewest moving parts, so the people running it spend their time on configuration, inputs and retention rather than on cluster membership. The main trade-off is that a failed host stops log collection and search until it is restored, so the restore path matters more than the design. Single-node sizing still needs to follow the storage guidance: the Graylog system architecture page advises sizing log storage as daily ingest times retention days times 120 percent, and giving the message journal 3 to 5 times daily ingest on SSDs.
- Operator load: One person can usually install, patch and back up the stack, but someone must own the upgrade schedule.
- Downtime tolerance: Confirm in writing with the business owners how long log collection can stop during upgrades and host repairs.
- Backups: Confirm that MongoDB configuration and the search data can both be restored to a tested state on a spare host.
- Growth path: Confirm whether a second node or a separate search backend is likely within your planning horizon, since moving later is a planned migration.
- Install method: Confirm the operating system and whether Debian or RPM packages or Docker Compose match your change-control process.
Check that the single-node guide matches your Graylog version before you start, and confirm the exact sizing numbers with your own ingest measurements.
A regulated team that must keep log collection running through a single node failure usually needs the multi-node Conventional layout. Graylog's multi-node guide targets medium-to-large deployments and describes three Graylog and MongoDB nodes plus three Data Nodes. MongoDB runs as a replica set initiated on the leader node only, the Data Node service sits on its own cluster separate from Graylog and MongoDB, and follower Graylog nodes set is_leader to false (the default is true). A load balancer with a DNS record for Graylog gives analysts and log sources one entry point. The cost is more hosts, more certificates, more monitoring and a clear operating runbook for failover.
- Separate search storage: Keeping Data Node on its own cluster means search capacity and the metadata tier can be patched and scaled independently.
- Leader settings: Confirm which node is the leader and that every follower carries
is_leaderset to false. - Heap and kernel settings: The guide sizes the Data Node heap at half of system memory up to 31 GB and the Graylog heap at half of system memory up to 16 GB, and requires
vm.max_map_countof at least 262144. - Journal sizing: Divide 72 hours of log volume by the number of nodes, then check it against the 3 to 5 times daily ingest guidance.
- Audit evidence: Ask your auditor which failover tests and configuration records they expect to see. DeployOpen prepares evidence, but the assessor decides what suffices.
Confirm the failover behavior of your load balancer and the recovery target you can support with your own staff, since the layout does not set those numbers for you.
A team that already runs an OpenSearch cluster or Graylog Data Node cluster has a different question: whether to reuse that search tier or keep Graylog on its own. Graylog 7.0 to 7.2 supports OpenSearch from 1.1.x up to 3.7.x, and Graylog Security needs OpenSearch 2.0 or later. Graylog recommends Data Node as the search backend, and OpenSearch 1.x use is deprecated since Graylog 7.0 and will be removed in Graylog 8.0. If the existing cluster is on an unsupported or deprecated version, the upgrade becomes the first task, not the Graylog install.
- Version match: Confirm your OpenSearch or Data Node version against the Graylog compatibility matrix before connecting anything.
- Shared cluster risk: Confirm whether other applications share the cluster, because log ingest can compete with them for heap and disk.
- Ownership split: Decide who patches the search tier, who manages certificates and who owns index lifecycle changes.
- Edition needs: Confirm which features you need, since Enterprise and Security features are paid and index archiving sits outside Graylog Open.
- Data Node or self-managed: Confirm whether you want Data Node to manage OpenSearch for you or your own team to operate it.
Before reusing a cluster, run a test against a copy of its current indices to confirm the version, heap and shard layout hold under your expected ingest.
How heap, journal and leader settings change the build
The sizing rules in Graylog's multi-node guide decide how much hardware each role needs, so work them out before you pick a layout. The Graylog heap is set to half of system memory, capped at 16 GB, and the Data Node heap is set to half of system memory, capped at 31 GB. Each node also needs vm.max_map_count set to at least 262144. The message journal on each node is sized by taking 72 hours of log volume and dividing it by the number of nodes, so a three-node build carries a third of that volume per node. Plan the journal on SSDs, since the system architecture guidance advises 3 to 5 times daily ingest for the journal. Those figures only mean something once you know your own daily ingest, retention period and peak rate, so confirm them before you order hardware.
Storage is the sizing rule that most often gets underestimated. The system architecture guidance advises sizing log storage as daily ingest multiplied by retention days, multiplied by 120 percent. For example, an illustrative team ingesting 50 GB per day and keeping 30 days of data would plan for 50 x 30 x 1.2 = 1,800 GB of search storage before replicas, so the Data Node cluster has to be sized on that figure, not on the raw log volume. Ask your team for measured daily ingest by source and a realistic retention requirement from your compliance owner, then size from those numbers rather than from averages.
The is_leader setting controls which Graylog node runs the leader-only background work. The multi-node guide sets is_leader to false on follower nodes, while the default is true, so every node you add must have this value set deliberately, or you risk more than one node claiming the leader role. The MongoDB replica set is initiated on the leader node only, so the leader is the first node you configure and the one you check first after any restart. For storage, the guide strongly recommends the XFS file system, which suits large index and journal files on the Data Node and Graylog hosts. Confirm the file system on each host before you load data, because moving a live journal to a different file system later is a migration task, not a configuration change.
What the extra nodes add to operations
A multi-node Graylog deployment spreads configuration, search and traffic across several machines, and each of those moves adds work your team owns after the first install. The cards below cover the recurring duties that a single server hides, so you can size the operating load before committing to a layout.
MongoDB replica set upkeep
In the multi-node model, MongoDB runs on the same nodes as Graylog as a replica set initiated on the leader node only. Your team must keep that set healthy through member additions, failovers and MongoDB version changes that stay within the Graylog compatibility matrix. Check who owns MongoDB backups and restore tests, because Graylog stores its configuration and metadata there.
Leader and follower configuration
Each follower Graylog node needs is_leader set to false, because the default is true. A mistake here, or a node rebuilt from a default template, can give you two nodes acting as leader. Keep the configuration in version control and review it after every rebuild.
Data Node cluster membership and certificates
Data Node takes over much of OpenSearch management, including certificates, cluster membership and version coordination, so you do not run those steps by hand as you would with self-managed OpenSearch. Hardening of the cluster stays with your team, including access controls, network exposure and key handling. Confirm which certificate rotations you must schedule and how a replaced Data Node rejoins.
Load balancer and DNS records
Graylog recommends a load balancer in front of the nodes, with a DNS record for the Graylog name so that clients and inputs do not depend on one host. Your team owns health checks, TLS termination, session behavior and the DNS change process during node replacement. Test a node failure in staging before inputs depend on the shared address.
Coordinated upgrades across nodes
Upgrading a multi-node cluster means sequencing Graylog servers, MongoDB members and Data Nodes so that each step stays inside the compatibility matrix. A single server can be stopped and upgraded in one window, but a cluster needs a documented order and a rollback point for each tier. Ask your vendor or implementation partner to confirm the upgrade order for the exact versions you run.
Storage and journal capacity planning
Graylog's system architecture guidance sizes log storage as daily ingest multiplied by retention days and by 120 percent, and the message journal at 3 to 5 times daily ingest on SSDs. The multi-node guide divides 72 hours of log volume across nodes for each journal. Revisit these numbers whenever ingest grows, because a full journal or index set becomes an outage risk that the cluster does not hide.
Questions buyers ask before choosing a Graylog layout
How much more effort does a multi-node Graylog layout add?
Multi-node adds more moving parts, so expect more planning, configuration and testing than a single server. The Graylog multi-node guide describes three Graylog and MongoDB nodes forming a MongoDB replica set, three Data Nodes on their own cluster, a load balancer with a DNS record, and is_leader set to false on follower nodes. Each of those components needs its own hardening, monitoring, patching and backup routine. The main effort drivers are the number of nodes, how often you upgrade, and how much of the operating runbook your team already owns. Ask for the effort split by component in any quote.
Can we start on a single node and move to multi-node later?
Yes, but plan the move before you go live. Graylog provides a separate single-node guide and a multi-node guide, and the topology change touches MongoDB replica set membership, the is_leader setting on each Graylog node, the load balancer and the Data Node cluster. Choices that are cheap on day one, such as the storage path, hostnames and heap settings, can make the later move harder if they are not documented. Confirm the exact migration steps for your Graylog version with Graylog before you commit to a sequence.
Does the Open edition scale the same way as Enterprise?
The architecture guidance is the same across editions, but the feature set is not. Graylog Open is free with no volume limits and community support, while Graylog Enterprise adds a data lake with archive restore, data tiering, a correlation engine and 24/7 support. Those paid features affect how much storage you need and how you operate it, so they should be part of the layout decision. Confirm with Graylog which components each edition requires at your expected volume, and note that Graylog Open is licensed under SSPL-1.0, which is not OSI approved.
What skills does our team need to run a multi-node Graylog cluster?
Your team needs working knowledge of Linux administration, MongoDB replica sets, OpenSearch or Graylog Data Node cluster behavior, TLS certificates, load balancing and Graylog's own configuration model. The multi-node guide also requires vm.max_map_count to be at least 262144 and recommends the XFS file system, so storage and kernel tuning are part of the job. Someone must own upgrades across Graylog, MongoDB and the search backend, since the compatibility matrix limits which versions work together. If those skills are thin, plan for training or outside help before go-live.
What should a quote for a Graylog layout include?
A useful quote lists the scope, deliverables and timelines in writing before work starts, since most DeployOpen engagements are fixed-scope. Ask for the node count and roles, the sizing method for heap, journal and storage, the MongoDB and Data Node configuration, the load balancer and DNS work, backup and restore testing, documentation, and handover. Also ask which items are one-time work and which are ongoing support or upgrade retainers. DeployOpen does not publish a price list, so a quote follows from that written scope.
Can DeployOpen plan and implement either Graylog layout?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, which covers both a single-node and a multi-node Graylog layout. The right choice depends on your log volume, retention, availability needs and team capacity, and that assessment is part of the written scope. DeployOpen is not an official partner or reseller of Graylog, so confirm any vendor-specific support terms directly with Graylog.
What must we confirm with Graylog for the version we choose?
Confirm the supported MongoDB and search backend versions for your exact Graylog release in the compatibility matrix, since Graylog 7.0 to 7.2 support MongoDB 7.x up to 8.2.x and OpenSearch 1.1.x up to 3.7.x. Check whether you will use Graylog Data Node, which Graylog recommends, or self-managed OpenSearch, and note that OpenSearch 1.x use has been deprecated since Graylog 7.0 and will be removed in Graylog 8.0. Also confirm which features you need, because archiving, correlation and Illuminate content sit in paid editions, and ask for upgrade paths before you choose the layout.
Moving from one node to a multi-node layout
This sequence moves a working single Graylog server into the Conventional multi-node layout without losing configuration or log data. Each phase ends with a check, so the team knows when it can move on to the next one.
Confirm sizing and version compatibility
The platform owner checks the current Graylog release against the compatibility matrix, confirming the supported MongoDB and search backend versions, and reviews the daily ingest and retention figures the cluster must hold. Graylog recommends Data Node as the search backend and documents OpenSearch 1.x as deprecated since Graylog 7.0, so teams still on 1.x should plan that upgrade before the move. Confirm the heap, journal and vm.max_map_count values against the multi-node installation guide for the exact version you run. The output is a written sizing record and a version pairing that the rest of the sequence relies on.
Back up configuration and current indices
The infrastructure owner takes a full backup of the MongoDB database that holds Graylog configuration, including streams, pipelines, inputs and event definitions, and records the current index set and retention settings. Keep the backup in a location the new nodes can reach, and confirm the restore procedure on a non-production copy before any production change. Log data already stored in the single-node search backend is a separate concern and needs its own plan. The output is a verified backup and a documented rollback path.
Build the Data Node cluster separately
The platform team provisions three Data Nodes on their own hosts, separate from Graylog and MongoDB, following the multi-node guide. Each node receives the heap and journal sizing from the guide, and storage uses the XFS file system the guide strongly recommends. The team confirms cluster health and that all three nodes have joined before any Graylog traffic is directed to them. Confirm the certificate and cluster membership steps in the installation documentation for your release. The output is a healthy, empty Data Node cluster.
Form the MongoDB replica set on the leader
The platform team installs MongoDB on the three Graylog and MongoDB nodes and initiates the replica set on the leader node only, as the multi-node guide describes. Confirm the replica set member names resolve between all three hosts and that the set reports a primary before continuing. Authentication and network rules for MongoDB should follow your own security baseline and the guide's instructions for your version. The output is a replica set with one primary and two secondaries.
Set is_leader to false on followers
The Graylog administrator installs the Graylog server package on all three nodes, keeps the default is_leader setting on the leader, and sets is_leader to false on both follower nodes in each follower's server configuration. Only one node should run the leader role at any time, so the administrator checks the config files on each host before starting services. Start the leader first, then the followers, and confirm each node joins the cluster in the Graylog interface. The output is one leader and two followers reporting as healthy.
Place the load balancer and DNS record
The network team creates a DNS record for the Graylog service name and places a load balancer in front of the three Graylog nodes, as the guide encourages. Health checks should target the Graylog web and API port on each node, and the team confirms that the load balancer routes requests to healthy nodes only. Log inputs such as syslog or GELF senders should point to the service name or load balancer address rather than to a single node. The output is a working service name that answers from every healthy Graylog node.
Migrate configuration and validate ingest
The Graylog administrator restores the configuration backup into the new MongoDB replica set and points the cluster at the Data Node cluster as the search backend. The team sends test messages through each input type in use and confirms that they are parsed by pipelines, appear in the right streams and reach the expected indices. Event definitions and notifications are tested with a controlled trigger, and the team confirms that search and dashboards return the expected results. The output is a signed-off test record covering inputs, streams, alerts and search.
Cut over and monitor the first cycle
The platform owner switches production senders to the load balancer address during a window agreed with the business owners, and keeps the single-node server available as a fallback until the team is satisfied. Watch journal usage, heap pressure, index rotation and replica set status for at least one full retention rotation cycle, as the sizing record defines. Decommission the old single node only after the team has recorded a successful review. The output is a stable production cluster and a closed change record.
How DeployOpen scopes and delivers Graylog deployments
DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted platforms inside the client's own infrastructure, including Graylog. For single-node versus multi-node Graylog, the layout decision follows from the written scope, sizing inputs and the environment the platform will run in.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope states the daily log volume, retention period and number of inputs that drive node count and storage sizing.
- Scope records whether the team needs Graylog Open alone or a paid edition, since that changes the feature set the build must cover.
How we build
- Builds follow the vendor's single-node or multi-node guide for the chosen layout, adapted to the client's own cloud or data center.
- Configuration covers MongoDB replica set membership, leader and follower settings, load balancer and DNS, and journal and heap sizing.
- Each build is tested for node failure, restart behavior and search backend connectivity before the environment is accepted.
How we hand over
- Handover includes written documentation of the topology, configuration values, sizing assumptions and the operating runbook.
- Backup and restore steps for MongoDB and the search backend are documented and rehearsed with the client's operations staff.
- Clients receive a list of open items, such as licensing decisions or hardware changes, that the client must confirm with the vendor.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Upgrade work covers Graylog, MongoDB and the search backend versions against the vendor compatibility matrix before changes reach production.
- Clients should ask any provider to confirm the support scope, response expectations and upgrade responsibilities in the quote.
