Graylog Docker Compose in production

When a Graylog Docker Compose test stack needs to become production

A team with a working Graylog Docker Compose test install has usually already proved that the containers start and that logs arrive. The gap to production is persistence, secrets, network exposure, sizing and upgrades, not the first startup. A test stack that loses its volumes on a rebuild, keeps credentials in a compose file, publishes input ports to every network, or has no capacity plan is fine for trying Graylog but not for retaining logs that investigators and auditors will rely on. Graylog runs as Graylog server nodes that use MongoDB for configuration and metadata, and Graylog Data Node or self-managed OpenSearch for log storage. Docker Compose can install all of these roles on one host, but the stack still has to be engineered for each role as if it were a separate system: its own data directory, its own credentials, its own resource budget and its own upgrade path. The first decision is whether the compose file will stay a single-host design or whether the roles will move to separate hosts or to the Kubernetes path covered elsewhere in this guide.

Graylog Open is licensed under the Server Side Public License version 1 (SSPL-1.0), is free with no volume limits, and comes with community support only. Teams that need vendor support, archive restore or a correlation engine will need to plan for an Enterprise or Security license, and that choice affects what the production stack must include. The Graylog documentation covers version 7.2 as current, so the compose file, image tags and upgrade notes should be checked against that version rather than against the test install's tag. Confirm the exact image tags and the supported MongoDB and Data Node versions in the Graylog compatibility matrix before you pin anything.

Which Compose layout fits a production Graylog

This table compares three ways to lay out a Graylog Compose stack: one host, several Compose hosts, and the multi-node layout the Graylog multi-node guide describes. Read each row against your uptime needs, the operator time you can staff, and where log data will sit. The main takeaway is that the guide's three-node pattern targets medium and large deployments, so smaller teams should weigh the cost of that complexity before adopting it.

Layout	Failure it tolerates	Operator time and data location	When it fits
Single-host Compose	Container restarts only. A host failure stops ingest, search and storage until the host is restored.	Lowest effort. Graylog, MongoDB and Data Node volumes sit on one host's disks, so backups must cover that host.	Proofs of concept, small teams and low-volume sources where short outages are acceptable.
Multi-host Compose	Some host loss, if inputs, volumes and failover are designed for it. Confirm with the Graylog docs how your Compose version handles this.	Moderate effort. Each host needs its own volumes, networking between hosts and a plan for moving or restoring containers.	Teams that need separate hosts for components but do not yet need a full replica set and clustered search.
Multi-node layout from the Graylog multi-node guide	Loss of one Graylog node, one MongoDB member and one Data Node, provided the replica set and Data Node cluster keep quorum and a load balancer routes traffic.	Highest effort. Three Graylog and MongoDB nodes, three Data Nodes, a load balancer, and `is_leader` set to false on follower Graylog nodes. Data is spread across Data Node storage on each node.	Medium and large deployments, as the guide recommends. Confirm with the Graylog docs whether your Compose version supports replica-set and multi-host setups before choosing it.

Which data needs persistent volumes and how much space to plan

Three data stores must survive a container restart, and each one needs its own persistent volume. The first is MongoDB, which holds Graylog's configuration and metadata: users, roles, streams, input definitions, pipeline rules and dashboards. Losing it means losing the setup, not the logs. The second is the Graylog Data Node index data, which holds the searchable log messages. The third is the message journal on each Graylog server node, a disk buffer where accepted messages wait before they are written to the search backend. Each service in the Compose file should mount its own named volume or bind mount, and the reader should confirm that the journal path sits on storage that is not the container's writable layer.

Sizing starts with the daily ingest figure, which the reader should obtain from the team that owns the log sources before choosing any volume size. The Graylog system architecture guidance advises sizing log storage as daily ingest multiplied by retention days, multiplied by 120 percent. For the message journal, the same guidance advises 3 to 5 times daily ingest on SSDs. Retention drives the Data Node figure more than anything else. The index model documentation explains that index rotation by message count, size or time, combined with retention that deletes the oldest indices, sets how quickly storage fills and how much headroom remains. A change to rotation settings can therefore change the disk requirement, so the reader should record the index set settings alongside the volume plan.

Before the stack goes live, the reader should run a short test that writes a representative load, measures how much disk the Data Node and journal use per day, and compares that against the calculated figures. Ask the vendor or the Graylog documentation for the current guidance on journal and Data Node disk layout for the version in use, since the architecture page is the reference for these ratios. Plan alerts on free space for every volume listed above, because a full Data Node or journal disk stops ingestion long before anyone notices a problem in the dashboards.

Secrets, published input ports and resource limits to set before go-live

A Compose stack that runs in a test is often wrong in production in ways that only show up under load or after a restart. The cards below cover the settings that decide whether credentials stay protected, which ports reach the network, how much memory and CPU Graylog can use, and how clients reach the web interface. Confirm each value against the Graylog configuration reference for your version before you release the stack.

Keep the password secret out of Compose

Graylog reads its server password secret from configuration, and that value signs sessions and encrypts stored data, so it must be set and kept out of the Compose file itself. Put it in an environment file or a Docker secret with restricted file permissions, and never commit it to version control. Also set the initial admin password through a secret rather than a plain environment entry. Losing the password secret after data is stored can make encrypted settings unreadable, so record it in your secrets manager before first start. Confirm the variable names in the Graylog configuration reference for your release.

Store MongoDB and Data Node credentials as secrets

Graylog server nodes authenticate to MongoDB for configuration and metadata, and to Data Node for log storage, so both credentials are high-value targets on the Compose network. Mount them as Docker secrets or files read at start, rather than placing connection strings with passwords in the environment block where docker inspect can reveal them. Use a dedicated database user with only the roles Graylog needs. Rotate these credentials through a planned change, since every Graylog node must pick up the new value at the same time. Confirm the connection and certificate keys in the Graylog configuration reference.

Publish only the input ports senders use

Each input port you publish opens a listener on the host, so publish only the ports that real senders use and state the protocol for each. Syslog commonly uses UDP or TCP on port 514, GELF uses TCP or UDP on the port your input defines, and Beats uses TCP for Filebeat or Winlogbeat style shippers. Mapping a range of ports or every input by default increases exposure without benefit. Match each published port to a configured input in Graylog, and confirm the port and transport in the input settings for your release. Restrict source addresses at the firewall where possible.

Set CPU and memory limits with journal headroom

Resource limits in Compose can starve Graylog, Data Node or MongoDB if they are set to the minimum that starts the containers. Graylog's message journal sits on disk, but indexing and search need memory and CPU, and a constrained container can fall behind until the journal fills. Set limits for each service separately, leave headroom above steady-state use for indexing bursts, and set the Java heap for Graylog below its container limit. Size the journal disk from daily ingest, as the Graylog system architecture guidance describes. Confirm heap and journal keys in the configuration reference before you size the hosts.

Set http_external_uri to the address clients use

The http_external_uri setting tells Graylog which address to show to users and to put in links, including links in notifications. If it points at the container's internal address or a port the proxy does not expose, the web interface may load while links, redirects and some API callbacks break. Set it to the full scheme, host and port that users reach through your reverse proxy or load balancer, and keep it consistent across nodes. Confirm the exact behavior for your release in the Graylog configuration reference and test one link from an outbound alert.

Bind the web and API port to a proxied address

The Graylog web interface and REST API listen on a single HTTP port, and publishing it directly on all host interfaces exposes the login page and API to every network the host reaches. Bind the port to a specific internal address, or publish it only on the Docker network that your reverse proxy joins, and terminate TLS at the proxy. Keep input ports separate from this listener so that a sender network does not need access to the web interface. Confirm the bind address setting for your release in the configuration reference and verify from outside the proxy that the port does not answer.

Setup sequence for a production Compose stack

This sequence brings up MongoDB, Data Node and Graylog in dependency order, so each layer is confirmed healthy before the next one depends on it. The end state is a stack where data survives a restart and inputs are verified one at a time.

Confirm version compatibility before pulling images
Choose the Graylog version first, then check the Graylog compatibility matrix for the MongoDB 7.x range and the Data Node or OpenSearch range that version supports. Pin the exact image tags for Graylog, Data Node and MongoDB in the Compose file so a routine pull cannot change versions. Done when every pinned tag appears in the matrix for the chosen Graylog release and the file contains no floating tags such as latest. Confirm the Data Node and OpenSearch status with your team, since OpenSearch 1.x use has been deprecated since Graylog 7.0 and is slated for removal in Graylog 8.0.
Create persistent storage for each stateful service
Create host directories or named volumes for the MongoDB data path, the Data Node data path and the Graylog message journal, and keep them separate so one service cannot overwrite another. Set ownership to the UID the container runs as, and confirm the paths sit on SSD-backed storage with room for the journal. Sizing guidance from the Graylog system architecture page suggests giving the journal 3 to 5 times daily ingest on SSDs, and log storage at daily ingest times retention days times 120 percent. Done when a test file written from inside each container persists after the container is removed and recreated.
Generate and inject secrets outside the Compose file
Generate the Graylog password secret, the root password hash, the MongoDB credentials and the Data Node admin password using a cryptographically strong generator, then store them in an env file or a secrets manager with restricted file permissions. Reference them from Compose through environment substitution or Compose secrets rather than writing them into the YAML. Confirm the Compose file and any version-controlled config contain no secret values by searching the repository for the generated strings. Done when docker compose config renders without exposing the values in logs or shared output.
Bring up MongoDB and confirm it is healthy
Start the MongoDB service alone and wait for it to report healthy through a container healthcheck that runs a ping against the configured credentials. Authenticate with the application user to confirm the account works and that unauthenticated access is refused. Initialize the replica set if your design uses one for the Graylog deployment. Done when the healthcheck reports healthy, an authenticated ping succeeds, and an unauthenticated connection is rejected. Graylog must not start until this check passes.
Bring up Data Node and confirm cluster health
Start Data Node after MongoDB is healthy, using the pinned image and the data path created earlier. Confirm the node joins as a cluster and reports a green or yellow status through its cluster health API, with the expected node count. Verify the certificate setup you chose, whether the Graylog CA or your own certificates, is accepted by the node. Done when the health endpoint reports the expected status and the node restarts with its indices still listed. Treat a red status as a blocker and resolve it before moving on.
Start Graylog and verify the web interface, API and journal
Start the Graylog server container, then sign in to the web interface with the admin account and call the API status endpoint with an access token. Check the server logs for connection errors to MongoDB and Data Node, and confirm the message journal directory is being written to and the journal utilization stays low under no load. Done when you can sign in, the API returns a healthy status, and the journal reports no errors in the logs.
Open input ports one at a time and send test messages
Publish one input port in the Compose file, create the matching input in Graylog, and send a known test message from a host you control. Search for that exact message in the Graylog search view and confirm the fields parsed as expected. Repeat for each additional input type only after the previous one passes, so a failure can be traced to a single port. Done when each test message appears in search with the expected source and fields. Confirm with your network team which ports are reachable from each source network, because published ports in Compose do not replace firewall rules.
Set index rotation and retention, then run a restart test
Configure the index set with rotation and retention settings that match your retention requirement, then confirm the rotation strategy and the retention action in the index set details. Finally, stop the whole stack with docker compose down (without removing volumes), start it again, and confirm the test messages, users, inputs and index sets all still exist. Repeat the restart for each service individually to confirm each one recovers its own data. Done when the search for the earlier test messages returns results after a full restart and the configuration is unchanged.

How to handle upgrades by situation

A move between releases in the 7.x line, such as from one 7.1 build to a later 7.1 build, keeps the same major version and usually the same backend requirements. The work is mostly disciplined sequencing: back up, pin, restart and confirm. Even small changes can fail on a stack that was never tested with a restart, so treat each one as a change to a running system.

Back up first: dump MongoDB and snapshot the Graylog and Data Node volumes while the stack is stopped, and store the copies outside the Docker host.
Check the matrix: confirm that your MongoDB and Data Node or OpenSearch versions still fall inside the range the compatibility matrix lists for the target release.
Pin the tag: replace latest in docker-compose.yml with the exact release, such as graylog/graylog:7.1.10, and commit the change to version control.
Stop and start in order: stop the Graylog servers, bring up any backend service whose version changed, then start Graylog nodes one at a time and wait for each to report healthy before starting the next.
Keep the rollback path ready: retain the previous image tag and the volume snapshots, so a failed node can be restored and redeployed on the old tag.

After the restart, confirm that inputs have reconnected, the message journal is draining, and searches return data from both before and after the change.

Security controls for a Compose-hosted Graylog

A Compose stack puts the web interface, inputs, database, search backend and stored logs on one host or a small set of hosts, so a gap in any one of them exposes the others. The cards below cover the controls that connect those pieces: who can reach the ports, which services stay internal, how secrets are kept out of files and shells, what containers may do, and how backups are protected.

Restrict who reaches published ports

Only the web interface, the API and the input ports you intend to expose should be published on the host. Each published port is a reachable service, and inputs such as syslog or GELF accept data from any sender that can route to them. Check the host firewall and any cloud security group against an explicit list of source networks for each port, and confirm that the web interface sits behind TLS, typically through a reverse proxy you control.

Keep MongoDB and Data Node internal

MongoDB holds Graylog configuration and metadata, and Data Node holds every indexed log message. Neither should publish a port to the host or to any external network. Place them on a private Compose network that only the Graylog services join, and verify with a port scan from outside the host that they are closed. Review this after every change to the ports section of the Compose file.

Protect secrets from the repository and shell

Passwords, the Graylog password secret, and certificate keys belong in files or a secrets mechanism with restricted permissions, not in the Compose file or in environment entries that appear in docker inspect output and shell history. Keep secret files out of version control, set their owner and mode so only the service user can read them, and plan how they are rotated. Ask your team which secret store they already operate before choosing one.

Limit container privileges

Run Graylog containers as a non-root user where the image supports it, drop Linux capabilities the service does not need, and avoid privileged: true. Set no-new-privileges and make the root filesystem read-only where the image allows writes only to the data volumes. Confirm each setting in a test run, because some Data Node and MongoDB images expect to write to paths you must mount explicitly.

Pin and approve image sources

Use image tags that name an exact version, or digests, and pull only from a registry your organization has approved. A floating tag such as latest can change behavior during a routine pull. Record the versions in your change log, and confirm that the Graylog, Data Node and MongoDB versions pair with the compatibility matrix before each pull. Mirror approved images into a registry you control where your policy requires it.

Protect volume backups and authentication

Volume backups contain the log data itself, so they need the same access control and encryption as the live volumes, and a restore test that proves they can be read. For sign-in, Graylog Open supports Active Directory, LDAP and trusted header authentication. OpenID Connect and SAML single sign-on are Enterprise features, so confirm which method your organization requires before the first user is created.

What the stack needs after go-live

Compose will keep containers running, but it will not notice when Graylog's message journal fills, when a Data Node drops out of the cluster, or when MongoDB stops accepting writes. Someone has to own the recurring checks from the day the stack takes live traffic. The core list is short: watch journal and buffer growth on each Graylog container, confirm Data Node and MongoDB health, take and test backups of MongoDB and index data, compare disk use against the retention plan you set in the index set configuration, and collect a support bundle when a node misbehaves. Each task needs a named owner and a schedule, not a note in a runbook nobody opens. The volume of this work depends on your environment, so estimate it with your own team rather than relying on a generic figure. Ask yourself how many Graylog, Data Node and MongoDB containers you run, how often your input traffic changes, and whether anyone on call already watches the Graylog system pages. Hours per week will rise during the first months, when retention and journal sizing are still being tuned, and fall once the baselines are stable. The Graylog documentation explains how the journal and storage relate to ingest, which gives you the baseline to alert against.

The Graylog operations pages cover monitoring, journal and buffer problems, support bundles, backups and capacity checks in detail, so use them as the reference for each procedure instead of rebuilding them here. What this topic adds is the Compose-specific layer: where the volumes live on the host, which container logs you read first, and how a restore of MongoDB and Data Node data is rehearsed on a separate stack. Test a restore before you need one. A backup that has never been restored is an assumption, not a control. Before go-live, agree on who receives alerts, who performs the monthly disk and retention review, and who can run a restore. Confirm with Graylog which backup approach your Data Node and MongoDB versions support, and confirm the MongoDB version against the compatibility matrix for your release. Write these answers into the handover document so operations can run the stack without the people who built it.

Limits to confirm for your environment

A Compose stack looks simple, but several limits depend on your own versions, hardware, licensing and change controls. The cards below list what to confirm with the sources named in each one before you commit to a single-host layout for production.

Docker and Compose versions

Confirm that your Docker Engine and Compose plugin meet the requirements in the Graylog installation documentation for the Graylog release you plan to run. Compose files that work on a laptop often rely on newer syntax, healthcheck behavior or volume options that older hosts lack. Pin the image tags you test, and record the exact engine and Compose versions in your build runbook so a later host rebuild does not drift.

Single host capacity for ingest and retention

Confirm whether one host can carry your daily ingest, your retention period and the message journal on fast disks. Graylog's system architecture guidance sizes log storage as daily ingest multiplied by retention days and then by 120 percent, and advises a journal of 3 to 5 times daily ingest on SSDs. If the result exceeds the disk and memory you can dedicate to one machine, a multi-node layout with separate Data Nodes is the safer design.

Graylog Open fit for your license

Confirm that Graylog Open, licensed under SSPL-1.0, fits how your organization uses and distributes software. SSPL is not an OSI-approved open source license, so legal and procurement teams should review the LICENSE text themselves before a production rollout. Record the decision, the release you deploy and the reviewer who approved it.

Inputs and integrations that need Enterprise

Confirm, input by input, whether each source you plan to onboard works on Graylog Open or requires an Enterprise or Security license. Some collectors, authentication options and detection features are gated by edition, and a Compose file can publish a port for an input that your license does not cover. List every source from your inventory and mark its edition requirement before you publish any input port.

Compose layout against audit and change control

Confirm that a Compose-based stack, with its environment files, bind mounts, published ports and manual upgrade steps, meets what your auditors and change board expect for a production system. Ask who approves image updates, where secrets are stored, how configuration changes are reviewed and how evidence of backups and restores is kept. Single-file deployments often need extra documentation to satisfy these reviews.

Supported backend versions for your Graylog release

Confirm that the MongoDB and search backend versions in your Compose file are supported for the Graylog release you deploy. Graylog publishes a compatibility matrix that lists supported MongoDB and OpenSearch or Data Node versions, and OpenSearch 1.x use is deprecated for Graylog 7.0 and later. Check the matrix before each upgrade, because a backend version that worked earlier may fall outside the supported range.

Questions teams ask before running Graylog on Compose

Is Docker Compose a supported way to run Graylog in production?

Graylog documents Docker Compose as one of its installation methods, alongside Debian and RPM packages, so it is a supported path, but the production work sits in what the Compose file does not do by default. The stack has to keep MongoDB and Data Node data on persistent volumes, keep secrets out of the file, publish only the input ports you need, and set resource limits. Confirm the exact compose file version, image tags and Data Node settings against the current installation docs for the Graylog version you plan to run, since those change between releases.

How much effort does a production hardening pass for Graylog on Compose take?

The effort depends on how many services, hosts and input types the stack carries, not on the Compose syntax itself. The main drivers are the number of Graylog server nodes, whether MongoDB runs as a single instance or a replica set, how many inputs are exposed, how secrets are sourced, whether backups and restore have been tested, and how much log volume the storage is sized for. Sizing is a factor too: the Graylog system architecture guidance advises storage of daily ingest times retention days times 120 percent, with the message journal at 3 to 5 times daily ingest on SSDs. Ask any partner for a written scope that lists each service, each volume, each input and each acceptance test, with a fixed price and timeline agreed before work starts.

Can an in-house team run Graylog on Compose without outside help?

Yes, many teams can, provided someone owns the Compose files, the storage layout and the upgrade process. The skills that tend to be missing are not Docker skills but operational ones: restoring MongoDB and Data Node from backup, sizing the journal, handling certificates for Data Node, and planning index rotation and retention. A useful self-check is whether the team has ever restored the stack from backup on a clean host and whether it can explain how each input is exposed. Outside help is most useful for the first hardening pass, a written runbook and a handover, while day-to-day running can stay in house.

What does a partner need from our team before starting a Graylog Compose project?

A partner needs enough information to write a fixed scope before any build work begins. Typically this includes the target host or cloud accounts and their network layout, the log sources and their protocols, expected daily ingest and retention periods, identity requirements such as LDAP or single sign-on, backup and monitoring tools already in use, and the change window for the first production cutover. Access to a non-production environment and named contacts for security review and sign-off also speed up the work. Ask the partner to list what they need from you in the quote so gaps are visible early.

How are Graylog upgrades handled when the stack runs on Compose?

Upgrades on Compose change image tags, configuration and sometimes database and search backend requirements, so they need a planned sequence rather than a simple image pull. Plan around the compatibility matrix for the target version, since Graylog 7.0 to 7.2 have stated MongoDB and OpenSearch version ranges, and note that OpenSearch 1.x use has been deprecated since Graylog 7.0 and will be removed in Graylog 8.0. Take a backup of MongoDB and Data Node before each step, test the upgrade on a copy of the stack, and read the breaking-change notes for API and parsing behavior. Ask any partner whether upgrades are part of the fixed scope, a separate change, or a retainer.

Does Graylog Open have licensing or volume limits I should plan for?

Graylog Open is free with no volume limits and community support, according to the Graylog pricing page. Its license is the Server Side Public License version 1 (SSPL-1.0), which is not an OSI-approved open source license, so have your legal team review it against your internal policy before you build on it. Some inputs and features need an Enterprise or Security license, which are priced on processed data with a minimum, so check which inputs and capabilities your design depends on before you commit. Ask any quote to state which features are Open and which need a paid license.

When should we move from Compose to Kubernetes or the multi-node guide?

Move when the single-host Compose stack can no longer meet your availability, capacity or operating model needs. Common triggers include a requirement for several Graylog server nodes behind a load balancer, a need for MongoDB as a replica set, separate Data Node hosts for storage, or an existing Kubernetes platform your team already operates. 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, with is_leader set to false on follower Graylog nodes. Ask a partner to show how the Compose design maps to that layout and what changes in inputs, storage and upgrades.

How DeployOpen scopes and delivers a production Graylog stack

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including Graylog stacks run with Docker Compose. The work starts with a written scope that covers volumes, secrets, input exposure, resource limits and upgrade handling before any container is deployed.

How we scope

Confirm the Graylog, Data Node and MongoDB versions against the compatibility matrix before writing the scope.
Record the daily ingest, retention period and journal sizing that the persistent volumes must hold.
Agree in writing which inputs are published, on which ports, and which hosts and networks may reach them.

How we build

Define named volumes for Graylog, Data Node and MongoDB with backup paths and ownership set before first start.
Move passwords, the password secret and certificates out of the Compose file into a secrets mechanism you approve.
Set container memory and CPU limits, then test the stack under representative ingest and search load.

How we hand over

Deliver the Compose files, environment templates, runbooks for restarts, upgrades and rollbacks, and a configuration record.
Walk your operations team through volume backups, restore tests and the procedure for upgrading image tags.
Document every open decision, such as moving to a multi-node layout, so your team knows what to revisit later.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer, scoped to your stack and version.
Ask your DeployOpen contact to confirm the support hours, response terms and upgrade cadence in the written quote.