Graylog or Loki: which log platform fits your team
Choose Graylog if your security team needs indexed full-text search, streams, and alerting on log data in near real time. Choose Grafana Loki if your platform team needs to keep large volumes of logs cheaply and query them mainly by labels. The decision turns on three things: the query pattern your analysts will use, which team will operate the platform day to day, and whether the license terms of each product matter to your organization. Graylog Open is licensed under SSPL, which is not OSI approved, and its paid Graylog Enterprise and Graylog Security editions carry yearly prices and minimum volumes that you should confirm before you commit. Loki is licensed under AGPLv3, which is an OSI-approved license, but Loki has no built-in authentication layer, so you will need to place an authenticating reverse proxy in front of it.
Graylog fits best when analysts run ad hoc searches across many fields, build dashboards, and need event definitions that page on-call staff through PagerDuty, Slack, or email. Its architecture is heavier: Graylog server nodes, MongoDB for configuration and metadata, and either Graylog Data Node or self-managed OpenSearch for storage. Check that the OpenSearch version you plan to use appears in the Graylog compatibility matrix, since OpenSearch 1.x use is deprecated in Graylog 7.0 and will be removed in Graylog 8.0. Loki fits best when the team already runs object storage and Grafana, queries by stream labels, and accepts that content filtering across unlabeled text is slower. Its recommended production stores are Amazon S3, Google Cloud Storage, and Azure Blob Storage, and retention is disabled by default, so you must set it deliberately.
Before you choose, confirm three points with each vendor and in your own environment: which Graylog features your security team requires, since index archiving, correlation, and prebuilt detection content sit in paid editions, and whether your legal or procurement team accepts SSPL in place of an OSI license. Then test your own query workload against a sample of production logs on both platforms. A team that mostly answers questions like which hosts logged a given string will feel the indexing model differently from a team that mostly filters by service and environment labels. Ask DeployOpen for a written scope that covers the sizing, licensing and operating model for your case before you commit to either platform.
Which platform fits which scenario
This table maps common operating scenarios to the platform that fits better, with the reason tied to indexing, alerting or storage design. Read each row as a starting point: where neither platform fits the requirement, the final column names the next comparison or option to weigh.
| Scenario | Better fit | Reason and what to confirm |
|---|---|---|
| SOC alert triage on authentication logs | Graylog | Event definitions run on indexed, searchable messages, and streams can route authentication events to alerting. Confirm whether paid Graylog Security detection content is needed for your use cases. |
| Platform team debugging microservices | Grafana Loki | Loki indexes labels rather than full text, so high-volume application streams are cheap to keep and query by label. Confirm your label design keeps cardinality low. |
| Regulated team needing audit-style retention | Graylog | Graylog's index rotation and retention are explicit and per index set. Archiving and data tiering sit in paid Enterprise or Security editions, so confirm those before relying on them. Loki retention is disabled by default and must be enabled deliberately. |
| Team already running OpenSearch | Graylog | Graylog can store logs in self-managed OpenSearch within the supported version range. Confirm version compatibility in the Graylog compatibility matrix before upgrading either side. |
| Team with an object storage platform already in place | Grafana Loki | Loki stores compressed chunks and its index in object storage, so existing S3-compatible or cloud object capacity can be reused. Confirm the store's production suitability, since the docs do not typically recommend S3-compatible stores such as MinIO for production. |
| Security team needing built-in SIEM-style correlation without a separate product | Neither alone | Neither platform is a full SIEM out of the box for this need. Compare Graylog against the Elastic Stack in Graylog vs ELK Stack vs Loki, or consider Security Onion for network monitoring and packet capture. |
| Authenticated access to the log store for many teams | Graylog | Graylog has its own user authentication and roles. Loki has no built-in authentication layer and needs an authenticating reverse proxy in front of it, which adds components to design and operate. |
| Mostly host-level intrusion detection with file integrity monitoring | Neither alone | Both are log platforms, not host intrusion detection engines. Consider Wazuh or OSSEC for host-based detection, and check whether either log platform will receive their output. |
How Graylog and Loki are built and what that means for operations
Graylog and Loki both separate the component that handles queries and configuration from the component that holds the bytes, but they do it in very different ways. The cards below cover which stateful parts each platform runs, how Loki scales by deployment mode, and what each stateful piece means for the people who will be paged when it fails.
Graylog server nodes and MongoDB
Graylog runs as server nodes that ingest, process and serve searches, with MongoDB holding configuration and metadata. Graylog 7.2 supports MongoDB 7.x up to 8.2.x, according to the compatibility matrix. Your team will own MongoDB backups, upgrades and replica set health alongside Graylog itself, so confirm who on your side can operate both before you commit to the design.
Graylog search backend choice
Log data lives in a search backend. Graylog recommends Graylog Data Node, while self-managed OpenSearch from 1.1.x up to 3.7.x is also supported. Use of OpenSearch 1.x is deprecated since Graylog 7.0 and will be removed in Graylog 8.0, so any OpenSearch 1.x estate needs a migration plan. Indexed storage is what makes search fast, and it is also the largest recurring infrastructure cost.
Loki deployment modes
Loki offers three deployment modes: monolithic as a single binary, simple scalable with separate read, write and backend targets, and microservices for very large clusters. Monolithic is documented for up to about 20 GB of logs per day, and simple scalable approaches 1 TB per day. Simple scalable is being deprecated and will be removed with Loki 4.0, so a platform team choosing it today should plan a move to microservices.
Loki object storage and TSDB index
Loki keeps compressed log chunks and its index in object storage, with TSDB as the recommended index store for Loki 2.8 and newer. Amazon S3, Google Cloud Storage and Azure Blob Storage are the recommended production stores, while MinIO and local filesystem stores are supported but not typically recommended for production. Your team will manage bucket policies, lifecycle and cost, and must confirm how the compactor runs before relying on retention.
Graylog multi-node layout
For medium to large deployments, Graylog recommends three Graylog and MongoDB nodes with MongoDB as a replica set, plus three Data Nodes on their own cluster and a load balancer. Follower Graylog nodes must have is_leader set to false. This layout means roughly nine stateful or stateful-adjacent machines to patch, back up and monitor, so compare it honestly against the operating capacity of your team.
Operational meaning of each stateful part
Every stateful component adds a failure mode and a recovery path. In Graylog, losing MongoDB or the search backend affects configuration and search, while the message journal protects in-flight data. In Loki, the compactor controls retention, and retention is disabled by default, so logs persist until you turn it on. Ask each vendor or your own engineers to walk through backup, restore and retention for every stateful piece before you size the platform.
Capability comparison: indexing, alerting, retention and sign-in
This table compares how Graylog and Grafana Loki index, query, alert, retain and authenticate logs, using only the documented facts. Read each row against your team's detection and retention needs, and treat any cell that says to confirm as an open question for a test environment.
| Capability | Graylog | Grafana Loki |
|---|---|---|
| Indexing model | Indexes log data in a search backend: Graylog Data Node (recommended) or self-managed OpenSearch 1.1.x to 3.7.x | Stores compressed log chunks and an index in object storage; TSDB is the recommended index store for Loki 2.8 and newer |
| Storage backend | MongoDB for configuration and metadata, plus Data Node or OpenSearch for log data | Amazon S3, Google Cloud Storage or Azure Blob Storage recommended for production; MinIO and local filesystem supported but not typically recommended |
| Query style | Search and dashboards over indexed fields; confirm the query language and field behavior in a test environment | Label-based selection of log streams; confirm the query syntax and performance at your volume in a test environment |
| Alerting | Event definitions for real-time and historical monitoring; notifications to PagerDuty, Slack and email listed for Graylog Open | Confirm alerting options and rule evaluation with your Loki and Grafana setup, as alerting depends on the surrounding stack |
| Pipelines and routing | Streams and processing pipelines route and transform messages on ingest | Confirm routing and transformation options with the shipper you choose, such as Grafana Alloy, Fluent Bit or Fluentd |
| Archiving and retention control | Index rotation by message count, size or time; retention deletes the oldest indices. Index archiving is in paid Enterprise or Security | Retention applied by the compactor and disabled by default; can be set globally, per tenant or per stream selector, with a minimum of 24 hours per rule |
| Multi-tenancy | Confirm tenant separation options for your Graylog edition with the vendor | Multi-tenant when auth_enabled is true; tenant identified by the X-Scope-OrgID header on every request |
| Built-in authentication | Graylog provides user authentication; confirm supported methods such as LDAP or OIDC for your edition | No built-in authentication layer; you must place an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium in front |
| License | Graylog Open under SSPL-1.0 since Graylog 4.0, not OSI approved | AGPLv3, announced April 20, 2021 for Loki and other core Grafana Labs projects |
| Paid features | Enterprise and Security editions add data tiering, correlation, archive restore, risk scoring and prebuilt detection content | Confirm which features sit in Grafana Enterprise Logs with Grafana Labs before you plan around them |
How Graylog and Loki handle sign-in and access control
Loki has no built-in authentication layer, and its documentation says to place an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium in front of it. Your team must design, deploy and operate that sign-in layer: choosing the identity provider the proxy trusts, terminating TLS, setting session lifetimes and deciding how a user's identity reaches Loki. Loki will not check identity on its own, so the network path to its HTTP port must allow only the proxy. Review the Loki authentication documentation with your identity team before choosing a proxy, because that proxy becomes the control point for every query and every push.
Loki tenancy is a separate mechanism. When auth_enabled is true, Loki reads the X-Scope-OrgID header on each request to decide which tenant's data to serve, and it keeps tenants' data apart. This isolates data by header value, which answers a different question from which person may read which logs. The proxy should set or overwrite that header from the authenticated identity, so a client cannot choose another tenant by sending its own value. Test that a credential for tenant A returns nothing from tenant B, and document which group or claim maps to which tenant. The multi-tenancy documentation describes the header behavior those tests should confirm.
Graylog manages users inside its own platform, so it does not depend on a separate proxy for its user model. Its user authentication documentation describes how users and external directory options are configured. Confirm which SSO and directory options apply to your edition and version before committing, since available options can depend on the edition and release line. For either platform, the security test is the same: who can query which logs, how sessions are issued, how they expire, how access is revoked when someone leaves, and who owns the proxy or identity configuration after go-live. Write those answers into your acceptance criteria and run revocation tests on a staging environment before granting production log access.
Licensing and paid editions for Graylog and Loki
Graylog Open is licensed under the Server Side Public License version 1 (SSPL-1.0) starting with Graylog 4.0 in 2020, replacing the GPL v3 used by earlier releases. SSPL is not an OSI-approved open source license, so procurement teams with an open-source-only policy should treat Graylog Open as source-available rather than open source. The free edition has no volume limits and community support only.
- Paid editions: Graylog Enterprise and Graylog Security are commercial products. Per the Graylog pricing page, Enterprise starts at 15,000 US dollars per year and Security at 18,000 US dollars per year, each with a minimum of 10 GB per day or 100 Graylog Compute Units.
- Licensing basis: Pricing is tied to processed data, with no per-user or per-device fees, so the cost moves with ingest volume rather than headcount.
- Features behind the paywall: Index archiving, the correlation engine, reporting and prebuilt Illuminate detection content are in the paid editions, not Graylog Open.
- Enterprise extras: Per the pricing page, Enterprise adds a data lake with archive restore, data tiering and 24/7 support.
- Security extras: Security adds SIEM features such as risk scoring, anomaly detection, investigations and compliance packs.
Confirm current pricing, minimums and included features in a written quote, since the figures above come from the published pricing page at the time of research.
Grafana Loki is licensed under the GNU Affero General Public License version 3 (AGPLv3). Grafana Labs announced on April 20, 2021 that Loki and its other core projects would move from Apache License 2.0 to AGPLv3. AGPLv3 is an OSI-approved open source license, which matters for organizations whose policy requires OSI approval.
- OSI status: AGPLv3 is OSI-approved, unlike SSPL, so it generally passes open-source-only procurement rules.
- Change history: Loki moved from Apache 2.0 to AGPLv3 in 2021, so older forks or documentation may reflect the earlier license.
- Paid edition: The facts supplied for this comparison do not name a paid Loki edition. Grafana Enterprise Logs is the product to examine for commercial support and features.
- Feature scope: Confirm with Grafana Labs which capabilities, such as authentication, support terms or enterprise integrations, sit in Enterprise Logs rather than the open-source build.
- Cost driver: Without a paid edition in scope, licensing cost is driven by your own infrastructure and any commercial support contract you choose.
Before relying on this summary, check the Grafana Enterprise Logs documentation and ask Grafana Labs for the current edition list and terms in writing.
SSPL and AGPLv3 both allow you to use the software internally, but they differ in obligations when you modify it or make it available to others over a network. Both licenses are copyleft in different degrees, and their interaction with service offerings is a legal question, not an engineering one. The points below are questions for counsel, not conclusions.
- Internal use: Ask counsel whether running Graylog Open or Loki inside your own organization, without offering it to third parties, triggers any source disclosure duty under either license.
- Offering as a service: Ask whether providing a log platform to customers or affiliates as a hosted service under SSPL carries obligations that differ from AGPLv3's network clause.
- Modifications: Ask counsel how each license treats internal patches, custom processing pipelines and plugins you build on top of the platform.
- OSI policy: Ask whether your policy treats SSPL as acceptable, since it is not OSI-approved, while AGPLv3 is.
- Paid editions: Ask whether purchasing a commercial Graylog or Grafana license changes your obligations for the non-commercial parts of the stack.
Record counsel's written answers in your procurement file before choosing between the two platforms.
What drives the running cost of each platform
Graylog's running cost is mostly storage and cluster capacity, and the biggest driver is how long you keep logs. Graylog's system architecture guidance sizes log storage as daily ingest times retention days times 120 percent. As an illustrative example, a team ingesting 50 GB per day and keeping logs for 30 days would plan for about 1.8 TB of index storage. Add a message journal sized at 3 to 5 times daily ingest on SSDs, three MongoDB nodes in a replica set, and a separate Data Node cluster for the medium to large layout. Loki's main infrastructure line is object storage for compressed chunks and the index, plus the compactor that applies retention. Loki retention is disabled by default, so storage grows until you set retention_enabled. Confirm your own ingest figures before you size either platform.
Recurring operations need different skills. Graylog requires people who can run MongoDB within the supported 7.x to 8.2.x range and a search backend within 1.1.x to 3.7.x, either Graylog Data Node or self-managed OpenSearch. Use of OpenSearch 1.x is deprecated and will be removed in Graylog 8.0, so version planning is an ongoing task. Loki requires object storage administration, compactor and retention checks, and an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium, because Loki has no built-in authentication. Licensing is the other recurring line. Graylog Open is free with community support, while Graylog Enterprise starts at 15,000 US dollars per year and Graylog Security at 18,000 US dollars per year, with a 10 GB per day or 100 Graylog Compute Unit minimum, according to Graylog's pricing page. Loki is AGPLv3, but confirm with Grafana Labs what support would cost before assuming a support budget of zero.
Detection content and alerting are where a working SIEM diverges from a bare log platform. Graylog Open includes event definitions and notifications, but prebuilt Illuminate detection content and correlation sit in the paid Enterprise or Security editions, so a Graylog Open team writes its own detections. On Loki, your team builds alert rules and dashboards, and you should confirm which rule tooling your chosen version provides. Ask for a written quote that states the scope of each phase, the editions and processed data volume covered, the sizing inputs used (daily ingest, retention days, journal size, node counts), and who performs upgrades for MongoDB, the search backend, the proxy and the Graylog or Loki versions. Ask specifically how Graylog 8.0 and the removal of simple scalable mode in Loki 4.0 are handled.
Moving logs between Graylog and Loki
This sequence moves log senders, routing, history, alerts and dashboards from one platform to the other while both run in parallel, so each change can be checked before the old store is retired.
Inventory senders, inputs and retention needs
List every source that sends logs today, the protocol it uses (syslog, GELF, Beats, or agent-based shipping), the Graylog inputs and streams that receive it, and the retention each stream must meet. The security team owns the list of log sources that feed detections, and the platform team owns the list of hosts and agents. Done means each sender has a row with its protocol, its destination stream or index set, and its required retention, and both teams have signed off on the list. Flag any source that Loki cannot ingest directly, such as a vendor appliance that only speaks syslog, so that a relay is planned for it.
Map streams and pipelines to labels and shipper config
Translate each Graylog stream and processing pipeline rule into a Loki design choice: which fields become stream labels, which stay in the log line for filtering, and where parsing moves into Grafana Alloy or Fluent Bit. Keep label cardinality low, because Loki indexes labels rather than full message content. Write the shipper configuration in version control, and reference the Loki send-data documentation for supported agents. Done means a mapping document exists for every stream, and a test host ships logs to a non-production Loki tenant with the expected labels. The reverse direction follows the same steps: Loki stream selectors become Graylog streams, and Graylog extractors take over parsing that Alloy previously did.
Decide which history stays and where it lives
Decide what historical data must move and what can expire. Graylog stores logs in indices managed by rotation and retention, and it can export archives only where the edition supports it, so confirm with Graylog what export and restore options your edition provides. Loki keeps chunks and its index in object storage, and its retention is disabled by default until retention is enabled in the compactor. Name the store that holds each history class, such as the old Graylog indices, an exported archive, or the new Loki object bucket. Done means a written retention decision for each stream, with an owner and a named store, and the decision is checked against any regulatory retention your organization must meet.
Run both platforms in parallel with dual shipping
Configure senders to ship to both Graylog and Loki at the same time, so the new platform receives live data while the old one still serves searches and alerts. Make sure each sender adds a consistent tenant identifier for Loki when auth_enabled is set, and that the authenticating reverse proxy in front of Loki applies the same access rules you use in Graylog. Done means the same events appear in both platforms for a sample of hosts, and the difference in event counts is explained by known parsing or label differences. Record any sender that drops events in either platform before continuing.
Rebuild event definitions as Loki alert rules
Graylog alerts come from event definitions with notifications to channels such as email, Slack or PagerDuty. Loki alerting is handled by its ruler and an alerting backend, so each event definition must be rewritten as a rule that queries Loki with LogQL and routes to the same channels. Keep the detection logic, thresholds and grouping documented side by side with the original definition. Where a Graylog correlation or Security feature is used, confirm in the paid edition's documentation whether an equivalent exists in your target platform before rebuilding it. Done means every rule has a source event definition, a test that fires it on a known input, and a named owner who signs off on the expected behavior.
Re-create dashboards, saved searches and access rules
Rebuild each Graylog dashboard and saved search as a Grafana dashboard or LogQL query, and check that the same panels and filters answer the same questions. Access rules do not transfer automatically: Graylog's user and role model must be mapped to access in Grafana and to the reverse proxy that protects Loki, which has no built-in authentication. Confirm the single sign-on options available in each platform and edition before assigning roles. Done means each dashboard has a reviewed equivalent, every role has a documented mapping, and a test user confirms that they see only the tenants or streams they are entitled to.
Validate query results and alert behavior
Compare query results between the platforms for the same time windows, using counts by host, by source and by event type. Investigate every mismatch, which often comes from timestamp handling, field extraction or label choices rather than missing data. Replay known test events through alert rules and confirm that each one fires in the new platform and notifies the same channel. Done means a signed validation record shows matching counts within the tolerance agreed by the security and platform teams, and every alert has a passing test. Keep this record, because auditors and incident responders may later ask how detections were verified after the change.
Retire the old store once retention allows
Stop dual shipping only after the new platform has reached the agreed retention for live searches and the historical decision in the earlier step is satisfied. Remove Graylog inputs and senders in stages, keep a read-only copy of the old configuration and any exported data for the retention period you set, and then decommission the Graylog and MongoDB or OpenSearch components. Done means senders no longer write to Graylog, the exported history is stored where the retention decision says, and the decommissioning record names what was deleted and when. Expect the highest switching cost in this step and the alert and dashboard rebuild, because those are the parts that depend on analyst habits and cannot be copied from one product to the other.
Where Graylog and Loki projects usually run long
Graylog projects run long when the stateful layers are sized and owned as an afterthought. Implementing Graylog means installing the Graylog server nodes, a MongoDB replica set for configuration and metadata, and either Graylog Data Node or a self-managed OpenSearch cluster for log storage. Then the team configures inputs such as syslog, GELF and Beats, builds streams and processing pipelines, and writes event definitions for alerting. The usual overrun comes from index sizing and message journal tuning. Graylog's system architecture guidance sizes log storage as daily ingest times retention days times 120 percent and suggests a journal of 3 to 5 times daily ingest on SSDs. Confirm those numbers against your own ingest estimate before the first node is provisioned, and confirm which OpenSearch line you will run, since the compatibility matrix limits supported versions.
Loki projects run long at the label design and the authentication layer, not at installation. Implementing Loki means choosing a deployment mode (monolithic, simple scalable or microservices), configuring object storage such as S3, Google Cloud Storage or Azure Blob Storage, and tuning the compactor. Retention is disabled by default, so set retention_enabled explicitly or logs accumulate indefinitely. Loki also has no built-in authentication, so the team must build an authenticating reverse proxy in front of it and map identities to tenants through the X-Scope-OrgID header when auth_enabled is true. The most expensive overrun is unbounded label cardinality. Every distinct label combination creates a new stream, so labels should be limited to low-cardinality fields and high-cardinality values kept in the log line. Review label sets with a sample of real traffic before rollout.
Before either project starts, the team must supply four inputs. These are an ingest estimate in gigabytes per day, a retention requirement per log source that reflects compliance and investigation needs, the identity source the platform will authenticate against, and a named owner for each stateful component, including MongoDB, the search backend or object store, and the retention settings. Alert tuning is the other common source of delay on the Graylog side and the Loki side alike, because noisy event definitions or ruler rules generate fatigue that consumes the analyst time the project was meant to free. Write the alert ownership and tuning cycle into the scope, and get the quote from the written scope, so retention, identity and ownership are fixed before work begins.
Questions buyers ask before choosing Graylog or Loki
Which costs more to run, Graylog or Loki?
Neither answer holds across every workload, because the cost follows ingest volume and retention. Graylog stores indexed log data in a search backend (Graylog Data Node or self-managed OpenSearch) and keeps configuration in MongoDB, so storage and cluster capacity grow with daily ingest times retention. Graylog's system architecture guidance suggests sizing log storage as daily ingest times retention days times 120 percent. Loki keeps compressed chunks and its index in object storage, which is typically cheaper per gigabyte, but you still pay for compute, the object store and the operating work. The license cost also differs: Graylog Open is free with no volume limits, while the paid Graylog Enterprise starts at 15,000 US dollars per year and Graylog Security at 18,000 US dollars per year, according to the Graylog pricing page. Ask for a quote built on your measured ingest, retention and query load.
Can Loki work as a SIEM without added tooling?
Not on its own. Loki is a log store with LogQL queries and no built-in detection content, correlation engine or case management, so a security team would need to add rules, alert routing and investigation workflow. Grafana Loki can be paired with Grafana alerting and other tools, but you should confirm which detection, correlation and triage features you need and which components will provide them. Graylog covers more of this out of the box: event definitions handle real-time and historical alerts, and the paid Graylog Security edition adds SIEM features such as risk scoring, anomaly detection and prebuilt threat detection content. If your team needs a ready SIEM layer, weigh that gap against the engineering time to build it on Loki.
Does Graylog Open include alerting?
Yes, Graylog Open includes event definitions for real-time and historical monitoring, and its product page says notifications can be sent to PagerDuty, Slack and email. What Graylog Open does not include are the paid features that many security teams expect next: the correlation engine, archive restore, data tiering and prebuilt Illuminate detection content sit in Graylog Enterprise or Graylog Security. Confirm the exact alert conditions, notification channels and retention you need against the Graylog Open product page and the current edition documentation before you rely on the free edition for production detection.
What sign-in work does Loki require?
Loki has no built-in authentication layer, so you must place an authenticating reverse proxy in front of it. The Loki documentation names nginx, HAProxy, OAuth2 Proxy and Pomerium as examples. You will also need to decide how tenants are separated: when auth_enabled is true, Loki is multi-tenant and each request must carry an X-Scope-OrgID header. Your proxy therefore has to authenticate users, map them to tenants and set that header safely, and your team must maintain that configuration and its certificates. Graylog, by contrast, provides user authentication inside the product, and you should check its user authentication documentation for the single sign-on and directory options your environment requires.
Can our team operate Graylog or Loki itself?
Yes, if you have the skills and the time to run them, and the work differs by platform. Graylog needs administrators who can run Graylog server nodes, MongoDB and a search backend, and the recommended multi-node layout uses three Graylog and MongoDB nodes with MongoDB as a replica set and three Data Nodes on their own cluster. Loki needs people who can run the storage and compactor configuration, manage object storage, operate the chosen deployment mode, and build the authentication and alerting layers. Loki's simple scalable mode is being deprecated and will be removed in Loki 4.0, so plan on monolithic or microservices modes. If you lack this capacity in house, DeployOpen can plan, implement, harden, back up and document either platform inside your infrastructure under a fixed-scope engagement, and ongoing support is available as a retainer.
How long does a migration between Graylog and Loki take?
The duration depends on scope, and no fixed timeline applies. The work includes re-mapping log sources and inputs, rebuilding parsing and routing, recreating alert and dashboard logic, backfilling or accepting a retention gap, and validating that detections still fire. Scope also depends on how many sources you have, how much history you keep, and how much custom detection content you must rebuild. Ask for a written scope with deliverables and a timeline before you commit, and treat any duration you hear without that scope as an estimate, not a commitment.
Is a fixed-scope engagement available for this work?
Yes. Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Typical work includes planning the architecture, implementing the platform in your cloud accounts, data centers or air-gapped networks, integrating sources, hardening, backing up, and documenting the result. DeployOpen does not publish a price list, so the quote follows from the written scope. To get a quote, prepare your daily ingest, retention targets, source inventory, identity provider, and the detection use cases you need on day one.
How DeployOpen helps choose, implement or migrate
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Graylog vs Grafana Loki, we start by testing which platform fits your detection, retention and team model before any build begins.
How we scope
- Map your log sources, daily ingest, retention targets and the teams that will search and alert on them
- Agree whether Graylog Open, a paid Graylog edition or Loki alone covers your required alerting and access controls
- Define the written scope, deliverables and timelines before work starts, since most engagements are fixed-scope
- Confirm the authentication layer, reverse proxy and identity provider you will need in front of Loki
How we build
- Size the deployment for your ingest and retention, including MongoDB, the search backend or object storage, and the Loki deployment mode
- Configure inputs, streams, pipelines or log shippers such as Grafana Alloy, and test event definitions or alert rules end to end
- Test access control, tenant separation and retention behavior against the requirements in the written scope
- Document licensing constraints, including SSPL and AGPLv3 obligations, for your legal and procurement review
How we hand over
- Deliver architecture diagrams, runbooks, backup and restore procedures, and upgrade notes for each component
- Provide a configuration record covering index rotation or retention settings, alert routes and user roles
- Walk operations and security staff through daily searches, alert triage and retention changes
- Document the evidence your compliance assessor may request, though audit reports come from independent auditors
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- Plan upgrades around Graylog's OpenSearch version limits and Loki's deprecation notices for simple scalable mode
- Ask us to review migration paths if you later move between Graylog and Loki, or add a SIEM layer
- Confirm retainer scope, response expectations and upgrade responsibilities in writing before signing
