Deploying Graylog on Kubernetes with the official Helm chart: when it fits
If your platform or security team already runs Kubernetes and wants Graylog as workloads in its own cluster, the Helm chart is a reasonable route. If you have no cluster to run it on, or your team has no Kubernetes operating experience, packages or Docker Compose are simpler starting points, and the choice should be made before any chart values are written. Graylog itself does not change much between these routes; what changes is who owns the storage, upgrades and networking when a node fails. Graylog needs three things to run. Graylog server nodes handle ingest, search and the web interface. MongoDB holds configuration and metadata, so it needs stable identity and persistent volumes. Graylog Data Node, or a self-managed OpenSearch cluster, stores log data and needs the largest and most durable volumes. Each of these maps to a Kubernetes decision: whether MongoDB comes from an operator or an external service, which storage classes back the Data Node pods, and how inputs are exposed to hosts and devices outside the cluster. Decide these before installing, because changing storage or network exposure later is far more disruptive than changing a replica count. Two licensing points belong in the plan from the start. Graylog Open is licensed under the Server Side Public License version 1 (SSPL-1.0), which is not an OSI-approved open source license, so confirm that its terms fit your legal and procurement policies. Several features, including some inputs, data tiering and SIEM capabilities, need an Enterprise or Security license on top of Graylog Open. Check which features your use case depends on against the Graylog pricing page before you commit to an architecture that relies on them.
Which chart options to decide before you install
This table compares the decisions a team makes before running the Graylog Helm chart, with the option, when it fits and what it commits the team to operate. Read each row as a question to settle in writing before the first install, and confirm every value key against the chart version you pin.
| Decision | Option | When it fits | What it commits you to operate |
|---|---|---|---|
| MongoDB source | MongoDB operator in the cluster | Your platform team already runs operators and wants MongoDB lifecycle, replica set and backups managed in Kubernetes | Operator upgrades, storage for MongoDB volumes, backup jobs and restore drills that you own alongside Graylog |
| MongoDB source | External MongoDB service | A database team already runs replica sets with backup and patching standards you want to reuse | Network paths, credentials and TLS between clusters, plus a separate change process for MongoDB versions Graylog supports |
| Data Node storage class | Fast block storage class | Index and journal volumes sit on SSD-backed storage that your cluster offers | Confirming the class supports the volume size and expansion you plan, and monitoring disk pressure on each Data Node |
| Data Node storage class | Shared or network storage class | Your only available class is network-backed and you have measured its latency under indexing load | Performance testing before go-live and a re-test whenever the storage backend changes |
| EKS provider option | Amazon EKS with its storage and load balancer integrations | Your organization already standardizes on EKS and wants AWS-native volumes and load balancers | Confirm the chart's EKS option and value keys for your chart version, plus IAM roles, EBS driver setup and EKS upgrade timing |
| EKS provider option | Generic Kubernetes settings | You run another distribution or a self-managed cluster | Storage class names, ingress and load balancer annotations you set and test yourself |
| Input exposure | HTTP ingress for the web interface and API only | You only collect logs from agents or Beats that can reach Graylog over HTTP | Ingress and TLS certificate handling, plus a documented path for Graylog's external URI |
| Input exposure | Service or load balancer for syslog and GELF ports | Network devices or hosts send TCP or UDP traffic that ingress cannot carry | Source IP preservation, port allocation per input, and firewall rules for each listener |
| Node count | Single Graylog node | A lab or small pilot where downtime for ingest and search is acceptable | No failover for ingest, and a harder path to a multi-node layout later |
| Node count | Several Graylog nodes with one leader | Production ingest that must keep running through a node restart | Leader settings, shared MongoDB and Data Node sizing, and load balancing that matches the input types you run |
How to install Graylog with the Helm chart step by step
This sequence takes a team from a chosen chart and Graylog version to a running deployment that accepts a test message, with a check at every stage so problems surface before the next component depends on them.
Confirm chart and Graylog versions
Pin the Helm chart version and read which Graylog release it deploys. Check that release against the Graylog compatibility matrix for the MongoDB and OpenSearch or Data Node versions you plan to run. Your platform team or DeployOpen engineer records these versions in the change ticket. Done when every component version is written down and each one falls inside the matrix ranges for the Graylog release. If the chart deploys a version outside the matrix, stop and confirm the mismatch with Graylog before continuing.
Prepare namespace, secrets and access
Create a dedicated namespace and apply least-privilege RBAC so only the deploying group can read the Secrets. Create the Graylog password secret and the root password hash as Kubernetes Secrets, outside the Helm values file. Kubernetes stores Secrets unencrypted in etcd by default, so confirm with your cluster owner that encryption at rest is enabled before you load credentials. Done when the Secrets exist, their values are not stored in Git, and a test account without deploy rights cannot list them.
Provision and verify MongoDB
Choose between the MongoDB operator the chart can work with and an external MongoDB you already run. Either way, confirm a replica set with an odd number of members, the MongoDB version your Graylog release supports, and authentication enabled for the Graylog database user. Connect with the Graylog user from a temporary pod to prove the credentials and network path work. Done when the replica set reports a primary and the test connection succeeds. Do not continue while MongoDB is only a single standalone instance meant for production.
Prepare storage classes for Data Node
Create or select a StorageClass for each Data Node with persistent volumes that survive pod rescheduling, and confirm the storage backend provides the throughput your ingest needs. Set the volume size from your retention and sizing calculation, not from the chart default. Ask your storage team whether volumes are replicated or local, because that changes how a node failure is recovered. Done when the test PersistentVolumeClaims bind and a test pod can write and read data on them.
Set the Graylog secret and root credentials
Generate a long random value for the Graylog password secret and store it in the same Secret, then create the root user password hash. Record both in your secret manager so the same values survive a reinstall. Confirm that the Helm values reference the Secret names rather than containing literal values. Done when a helm template dry run renders without printing any credential, and the values file contains only references.
Install the chart with pinned values
Run the Helm install with the chart version pinned, the values file under version control, and the namespace from the earlier step. Set the replica counts for Graylog server nodes and Data Nodes, the MongoDB connection, the storage class and the external URI that users and inputs will reach. Keep the Graylog follower nodes set so only one node is leader. Done when helm status reports deployed and no release revision is left in a failed state.
Verify pods, web interface and Data Node health
Check that every pod reports Ready and that restarts are not climbing. Open the Graylog web interface through the exposed address and sign in with the root account. In the system overview, confirm the cluster nodes are alive, the Data Node cluster reports healthy, and the journal is not filling. Done when all Graylog nodes and Data Nodes appear as healthy in the interface and sign-in works through the external URI.
Confirm an input receives a test message
Create a test input of the type you plan to use, such as a GELF or syslog input, and expose its port through the service you configured. Send one known test message from a host outside the cluster, then search for it in the Graylog interface by a unique string. Confirm the message is indexed and that the input shows received traffic. Done when the test string is found in search results. Only then add production sources, because a failed path is easier to fix while only one test message depends on it.
What to size before Graylog goes live on Kubernetes
Sizing for a Graylog Kubernetes deployment starts with how much data arrives and how long it must stay searchable, then carries through to journal, replicas, storage and ingress. The Graylog system architecture guidance supplies the storage and journal formulas and a medium to large layout. Everything else must be measured in your own environment before go-live.
Daily ingest and retention
Log storage follows a documented formula: daily ingest multiplied by retention days, multiplied by 120 percent. Measure daily ingest from your real sources over a representative period, not from the number of hosts you expect to connect. Then decide retention per index set, since audit, security and debug data often need different windows. Ask whether the replicas and index overhead of your chosen Data Node layout fit inside the resulting figure.
Message journal capacity
The message journal buffers incoming messages on disk before they are indexed, so it must absorb a backlog during indexer slowdowns or restarts. The Graylog architecture guidance advises three to five times daily ingest on SSDs. Set the journal volume through a persistent volume claim sized for the highest node ingest, and confirm the pod's storage class supports the write rate your inputs produce.
Graylog and Data Node replicas
The documented medium to large layout uses three Graylog nodes and three Data Nodes on their own cluster, with a load balancer in front. Map each to a separate StatefulSet or node pool so that a single node failure does not remove a whole tier. Confirm with your chart values how the Data Node cluster is scaled, and keep follower Graylog nodes configured with is_leader set to false.
Storage class performance and expansion
Data Node and journal volumes carry most of the write and search load, so storage class choice matters more than instance size. Ask your platform team for the IOPS and throughput guarantees of each class, and confirm that the class allows volume expansion before you rely on it. Test a failed pod reattaching its volume in a non-production cluster, and record how long recovery takes.
Input exposure and ingress capacity
Syslog, GELF and Beats inputs listen on ports that must be reachable from sources outside the cluster. Choose between a LoadBalancer service, a node port or an ingress controller for each protocol, and check that UDP traffic survives your load balancer. Measure the connection and message rate each input will carry at peak, since a single exposed service can become the bottleneck before Graylog itself does.
Resource requests and limits
Set CPU and memory requests and limits separately for Graylog server, Data Node and MongoDB pods, because Java heap sizing and Data Node memory both need headroom above the heap. Under-sized limits cause out-of-memory restarts during bursts, which look like ingest loss. Load test with realistic search and ingest patterns, then record observed peaks to set the final values rather than copying example numbers from a chart.
How the MongoDB and EKS choices change the install
When the chart relies on a MongoDB operator running inside the cluster, the operator manages the replica set lifecycle, while your team still owns the MongoDB version, the backup target and the upgrade window. The Graylog compatibility matrix lists MongoDB 7.x up to 8.2.x for Graylog 7.0 to 7.2, so the operator's MongoDB image must fall in that range for the Graylog release you choose.
- Patching: The operator rolls out changes to pods, but you decide when the MongoDB version changes and must check each target against the matrix first.
- Backups: Confirm whether the operator schedules backups and where they are written. Snapshots stored only in the same cluster do not protect Graylog's configuration if the cluster is lost.
- Chart expectations: Check whether the chart creates the MongoDB resource itself or expects one already in the namespace, and which replica set size it assumes.
- Credentials: Find out whether the operator generates the database user secret and how the chart reads its name, so the password reaches Graylog through a Kubernetes Secret and stays out of values files kept in source control.
Confirm the operator version and the MongoDB image it deploys in the chart documentation before you pin either one.
An external MongoDB, whether a managed service or a replica set your database team runs, moves patching and backups outside the cluster. The chart then needs only a connection string and credentials, and the availability of Graylog's configuration and metadata depends on the database service rather than on Kubernetes.
- Patching: The provider or database team applies minor patches on its schedule, but a major version change still needs a check against the Graylog compatibility matrix before you accept it.
- Backups: Confirm snapshot or point-in-time coverage, restore time and who is allowed to run a restore. Graylog's configuration lives in this database, so the restore path matters as much as the backup.
- Network path: Pods must reach every replica set member, so confirm DNS names, TLS settings and the firewall or private endpoint rules that apply to the node subnets.
- Credentials: Store the connection string in a Kubernetes Secret and reference it from the chart. Confirm whether the chart accepts a full URI or separate host, user and password fields, and whether the password can be read from the Secret instead of the values file.
Confirm that the MongoDB version your service offers is inside the range the Graylog compatibility matrix lists, because a provider may offer only some versions.
On Amazon EKS, AWS operates the Kubernetes control plane, but your team still owns node groups, storage classes, IAM roles for service accounts, ingress and the Graylog and Data Node data. Confirm in the chart documentation whether the EKS provider option exists and which settings it changes, such as storage class names or load balancer annotations.
- Storage classes: Data Node needs persistent volumes. Confirm which storage class the EKS option references, the volume type it implies, and whether the size matches the storage sizing you have done.
- Load balancers: Inputs exposed through a Service of type LoadBalancer depend on the annotations your load balancer controller reads. Confirm which annotations the option sets and which ports each input needs.
- Node placement: Spread Graylog and Data Node pods across availability zones, and confirm the node group sizes and instance types the chart expects.
- Cluster upgrades: Each EKS version change affects the API and node images. Check each step against the Kubernetes version skew policy and the Graylog compatibility matrix before upgrading.
Confirm the Kubernetes version against the Kubernetes release page and the MongoDB version against the Graylog compatibility matrix before you choose the node image.
Securing the Kubernetes layer around Graylog
The Helm chart deploys Graylog, MongoDB and Data Node as workloads on your cluster, so the cluster's secret storage, access rules, network exposure and backups decide how well Graylog is protected. The cards below are the controls to confirm before any log data arrives.
Encrypt and restrict Secrets
Kubernetes stores Secrets unencrypted in etcd by default, and Graylog's chart relies on Secrets for the admin password, the password secret and backend credentials. Confirm that encryption at rest is configured for etcd, then limit who can list and watch Secrets in the Graylog namespace using least-privilege RBAC. Where your policy requires it, pull credentials from an external store through the Secrets Store CSI Driver instead of storing them in the cluster.
Apply Pod Security Standards
Graylog server, MongoDB and Data Node pods should run in namespaces with an explicit Pod Security Standards level. Confirm that containers run as non-root, do not request privileged mode or host networking unless a component requires it, and that volumes are limited to what the chart needs. Test the chart against the enforcement level you choose in a staging namespace first, because some storage and init steps can be rejected.
Authenticate cluster operators
Kubernetes does not create user objects. Operators authenticate with X.509 client certificates, bearer tokens including OpenID Connect and JWT, webhook token authentication or an authenticating proxy. Decide which method your platform team uses for Helm deployments and cluster administration, and keep Graylog's own user accounts separate from cluster access. Review who can run helm upgrade or read the release values, since those values can expose configuration.
Limit network reach to inputs
Graylog inputs such as syslog and GELF listen on ports that the chart can expose through a Service, load balancer or node port. Publish only the ports your sources need, and restrict source address ranges at the load balancer or with network policies. Confirm that the Graylog web interface and API are reached through the intended ingress path and not directly from sender networks.
Protect MongoDB and Data Node credentials
MongoDB holds Graylog configuration and metadata, and Data Node holds the log indices, so both credential sets need the same care as the Graylog admin password. Generate them outside the chart values file, store them as Secrets with restricted access, and rotate them through a planned change. Confirm that the database and search backend accept connections only from Graylog pods and not from workloads in other namespaces.
Plan etcd and MongoDB backups
Back up etcd on a schedule using etcdctl snapshot save, and keep a tested procedure for restoring with etcdutl. Separately, plan MongoDB backups for Graylog configuration, and plan Data Node snapshots for log data according to your retention needs. Restores should be rehearsed in a separate environment, and the recovery steps should name who runs them and in what order. Use the CIS Kubernetes Benchmark as a review aid when checking these controls against your cluster.
What to confirm in the chart and your environment before committing
Pin the chart version and the Graylog version it deploys before you write any values file. A chart release and the Graylog server image it ships are two separate things, so confirm which Graylog version each chart version installs, and whether that version is one your plan can use. Graylog's current documentation covers version 7.2, and the compatibility matrix limits which MongoDB and OpenSearch lines work with each Graylog release, so check the chart's supported MongoDB topology (operator-managed or external) and its Data Node settings against that matrix, not against the chart's defaults. Ask the chart maintainers whether the topology you need, such as an external MongoDB replica set or Data Node on separate nodes, is a tested path or an unsupported customization.
Check your Kubernetes versions against the chart and the version skew policy. As of September 2026, the supported minor releases were 1.37, 1.36 and 1.35, and the skew policy allows kubelets to be up to three minor versions behind kube-apiserver, but the API server must be upgraded first and one minor version at a time. Confirm the minimum Kubernetes version the chart declares, whether your managed service (including the EKS provider option) supports it, and the upgrade order your platform team will follow. Also ask how the chart handles API deprecations between versions, since a chart that works today can break on a control plane upgrade.
Read the upgrade behavior and the license terms before you size or promise features. Ask how the chart performs rolling upgrades of Graylog server nodes, whether it migrates MongoDB or Data Node schemas, and what state must be backed up first. Then map each feature in your plan to its edition: Graylog Open is licensed under SSPL-1.0, while Enterprise and Security add features such as data tiering, correlation, SAML and OpenID Connect single sign-on, and SIEM content. A chart can deploy a feature that your license does not cover, so list those features in writing and confirm each one with Graylog before go-live. The chart's documentation and release notes are the source of truth for values, defaults and limits, so treat anything in this guide as a starting point to check, not a specification.
Questions teams ask before deploying Graylog on Kubernetes
What does it cost to deploy Graylog on Kubernetes?
The Graylog software itself has a price that depends on the edition you choose. Graylog Open is free with no volume limits and community support. Graylog Enterprise starts at 15,000 US dollars per year and Graylog Security starts at 18,000 US dollars per year, according to the Graylog pricing page. Both paid editions have a minimum of 10 GB per day or 100 Graylog Compute Units, and they are licensed on processed data with no per-user or per-device fees. Costs that come on top are the Kubernetes cluster, the storage behind your Data Node and MongoDB volumes, the compute for Graylog server nodes, and the staff time to build and run the deployment. Ask any partner for a quote that lists each of these separately, with what is one-time and what recurs.
How long does a Graylog Helm deployment take, and what drives the timeline?
The timeline depends mostly on how much of the platform is already in place and how many decisions remain open. A cluster with working storage classes, a MongoDB approach you have chosen, and a clear list of log sources moves much faster than a greenfield cluster that still needs identity, ingress and backup design. The main drivers are the MongoDB choice (operator or external), the Data Node storage classes and sizing, the number of input types and sources that need network paths, the identity provider integration, and the testing you require before go-live. Ask for a written scope with deliverables and milestones before work starts, since most engagements are fixed-scope and timelines are agreed in writing.
What must our team provide before a Graylog Kubernetes project starts?
Before work starts, the team needs to provide a short list of access and decisions:
- Cluster access with rights to create namespaces, workloads, services, secrets and persistent volume claims, in a cluster you control.
- Storage classes with the performance and reclaim behavior your Data Node and MongoDB volumes need, plus a backup target for the data.
- Identity: the provider you will use for sign-in, since Graylog Open supports Active Directory, LDAP and trusted header authentication, while Graylog Enterprise adds Okta, generic OpenID Connect and SAML.
- Network paths from log sources to the input ports, and from users to the web interface and API.
You should also name the owners for certificates, DNS and the change process, because these are often the slowest items to resolve.
Can an in-house platform team deploy Graylog on Kubernetes alone?
Yes, a platform team that already runs Kubernetes in production can deploy Graylog with the official Helm chart and the Graylog documentation. The harder parts are rarely the first install. They are the decisions that stay with you afterward: sizing the message journal and log storage, choosing retention and index rotation, separating Data Nodes from Graylog servers, and building alerting that your security team trusts. Check whether your team has experience with stateful workloads, certificate renewal, etcd backups and upgrades across Graylog and Kubernetes versions at the same time. If one of those is new to the team, a partner can cover that gap for a defined scope while your staff keep ownership of the running system.
How do Graylog upgrades differ when it runs on Kubernetes?
On Kubernetes, a Graylog upgrade touches the chart version, the container image, the Graylog server nodes, the Data Node cluster and the MongoDB replica set, and each has its own compatibility rules. Graylog's compatibility matrix lists which MongoDB and OpenSearch versions each Graylog release supports, and use of OpenSearch 1.x is deprecated since Graylog 7.0 and will be removed in Graylog 8.0. Kubernetes adds its own constraints: the version skew policy requires the API server to be upgraded one minor version at a time before the other control plane components and kubelets. Plan the order of upgrades in a written runbook, test it against a copy of your data, and confirm each documented breaking change in the Graylog release notes before you touch production.
When is it worth bringing in a partner for a Graylog Kubernetes deployment?
A partner is worth engaging when the deployment carries regulated log data, a fixed go-live date, or a team that has not yet run stateful workloads on Kubernetes. It is also a sensible choice when you need evidence for an audit, such as documented configuration, tested backups and access controls. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. It prepares systems and evidence for compliance assessments but does not issue audit reports or certifications. Ongoing support and upgrades are available as retainers after the initial fixed-scope work ends.
How DeployOpen scopes and delivers a Graylog Kubernetes deployment
DeployOpen plans and implements self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Graylog deployment on Kubernetes with the official Helm chart, we start with a written scope covering the cluster, MongoDB, Data Node storage, inputs and handover, then build and document it in your environment.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- We confirm the Kubernetes distribution, the chosen MongoDB option and the Data Node storage classes your cluster provides.
- We size daily ingest, retention and journal needs with you so the written scope reflects real storage and node counts.
How we build
- We install the official Helm chart with your values files, kept under version control in your repositories.
- We configure Data Node storage, MongoDB access and secrets, and expose only the input ports your sources need.
- We test log ingestion end to end, including a node restart, and record each result against the agreed scope.
How we hand over
- You receive the deployed configuration, values files, network and storage notes and a runbook for day-two tasks.
- We document backup and restore steps for MongoDB and Data Node so your team can repeat them without us.
- We walk your operators through upgrade handling, input changes and the checks that show the cluster is healthy.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Chart and Graylog version upgrades are planned against the documented breaking changes before they are applied.
- Support scope, response expectations and included upgrades are confirmed in writing as part of the retainer.
