When is open source Grafana Loki enough, and when does Grafana Enterprise Logs earn its place?
Open source Loki is enough when one trusted team runs the platform and access is already controlled outside the log store. Grafana Enterprise Logs (GEL) earns its place when you must enforce who can read which logs inside the store itself. Loki turns on multi-tenancy with auth_enabled and identifies tenants by the X-Scope-OrgID header, but it has no built-in authentication layer, so the Loki multi-tenancy docs expect an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium in front of it. If each tenant reaches Loki through its own proxy route and the platform team owns that configuration, the free edition covers the job. You then own the proxy rules, their upgrades and their audit trail.
GEL adds controls that sit inside the store. According to the GEL docs, it provides tenant management through a built-in API or the official GEL plugin, token-based authorization with configurable access, label-based access controls on log queries, and cross-tenant queries that aggregate results across tenants. Choose the paid edition when several business units or customers must be separated by policy, when a proxy rule alone is not an acceptable enforcement point for your auditors, or when a team needs label-level restrictions on queries. If you do not need cross-tenant queries, do not pay for them. Ask Grafana Labs in writing whether an existing Loki cluster can take the GEL binary, which the docs describe as a drop-in, and what the quote covers in tenants, support and upgrades.
The long-term support status changes the answer for new buyers. According to the GEL docs, the long-term support version is 3.6, and existing customers keep receiving support, bug fixes and security fixes, but no new features arrive through February 1, 2029, when GEM, GEL and GET reach end of life. A new contract therefore buys a feature set that stops growing now and ends on a fixed date. Before you sign, confirm which GEL version a new contract ships, what upgrade path exists after February 1, 2029, and whether your deployment uses the chart Grafana Labs maintains in the Loki repository, because the community Helm chart no longer supports GEL. If you need the access controls, decide the migration or exit path now, while the contract terms are still open.
Which features differ between Loki and Grafana Enterprise Logs?
This table compares open source Grafana Loki with Grafana Enterprise Logs (GEL) on the capabilities that matter for multi-tenant log platforms. Read each row as a question about your access model: where a documented fact answers it, the cell says so, and where the documentation is silent, the cell tells you what to confirm with Grafana Labs before you commit.
| Capability | Grafana Loki (open source) | Grafana Enterprise Logs (GEL) |
|---|---|---|
| Licensing | AGPL-3.0 licensed; Grafana Labs moved Loki from Apache 2.0 to AGPLv3, announced April 20, 2021 | Commercial offering under a Grafana Labs subscription; confirm current terms with Grafana Labs |
| Base engine | Open source Loki project, label-indexed with compressed chunks in object storage | Based on the open source Loki project; a GEL binary can be dropped into an existing Loki deployment |
| Tenant management | Multi-tenancy is enabled with auth_enabled and tenants are identified by the X-Scope-OrgID header | Tenant management through a built-in API or the official GEL plugin |
| Token-based authorization | Not provided by Loki itself; you must place an authenticating proxy in front of it | Token-based authorization with configurable access, documented in the GEL docs |
| Label-based access controls on queries | Not documented as a built-in feature; confirm any query-level restriction with Grafana Labs or your proxy design | Label-based access controls on log queries, documented in the GEL docs |
| Cross-tenant queries | Querying across tenants is not documented as a built-in feature; confirm before relying on it | Cross-tenant queries aggregate results across tenants, documented in the GEL docs |
| Built-in authentication | None. The Loki documentation says you must run an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium | Not covered in the GEL facts supplied here; confirm how GEL authenticates users and whether it replaces the proxy layer |
| Helm chart source | OSS chart is maintained in grafana-community/helm-charts, which as of March 16, 2026 no longer supports GEL | GEL users are directed to the chart maintained by Grafana Labs in the Loki repository |
| Deployment modes | Monolithic, simple scalable (to be removed in Loki 4.0) and microservices | Scalable logging cluster in your own data center; confirm which Loki deployment modes GEL supports |
How licensing, support and updates differ for each edition
Grafana Loki and Grafana Enterprise Logs share a codebase lineage but differ in license, who supports them, and how long they receive changes. The four items below set out those differences so you can judge which edition fits a new deployment and which terms to confirm before you sign.
Loki is licensed under AGPLv3
Grafana Loki is licensed under the GNU Affero General Public License version 3. Grafana Labs announced on April 20, 2021 that Loki and its other core projects would move from Apache License 2.0 to AGPLv3, so any version you deploy today carries AGPL terms rather than Apache terms. Check which Loki release line your team will pin, and record the license of each component in your stack before rollout.
GEL is a commercial build on Loki
Grafana Enterprise Logs is a commercial offering that the Grafana docs describe as based on the open source Loki project, intended for a scalable logging cluster in your own data center. The GEL binary can be dropped into an existing Loki deployment, which makes the move easier, but the features and support terms come from a paid agreement. Ask Grafana Labs which features are included in your subscription and whether the binary and chart versions are tied to a specific license key.
Support and fixes for existing GEL customers
Existing GEL customers continue to receive support, bug fixes and security fixes, but they do not receive new features. This matters most for teams that planned to rely on new GEL capabilities or on roadmap changes. Confirm in writing the scope of security patches, the response times in your contract, and how long each patched release line will be maintained before you commit to an upgrade path.
LTS 3.6 and the February 2029 end of life
The GEL long-term support version is 3.6, and GEM, GEL and GET all reach end of life on February 1, 2029. Once you adopt 3.6, you will have support and security fixes through that date, but no new features. For a new buyer, this means the commercial edition is a fixed feature set with a known end date, so plan a migration path or a renewal decision well before February 2029 and confirm the exact upgrade options in writing.
What AGPL means for internal use
AGPL obligations are triggered by distribution and by offering a modified version over a network. An internal-only Loki deployment that your staff use without modification generally carries lighter obligations than a modified Loki exposed to customers or partners through a service. The exact duties depend on how you modify, host and expose the software, so have your counsel confirm the position for each deployment pattern you plan before production use.
Track Loki releases and chart changes
The community Helm chart for OSS Loki is maintained in a separate repository and no longer supports GEL, so GEL users are directed to the chart maintained in the Loki repository by Grafana Labs. Keep both release tracks in your change log, pin chart and binary versions together, and test upgrades in a non-production cluster. Check the Loki GitHub releases page for the current release before you choose a starting version.
How tenant isolation works in open source Loki and where GEL changes it
Open source Loki becomes multi-tenant only when auth_enabled is set to true, and from that point every request must carry an X-Scope-OrgID header that names the tenant whose data is read or written. The header is an identifier, not a credential. Loki has no built-in authentication layer, so the documentation requires an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium in front of it. That proxy must verify who the user is and decide which tenant value to set. Your team owns that mapping, along with the rules for which users may reach Grafana, the write path and the query path. Before you go further, confirm the header handling in your proxy configuration by testing a request from a user in one team against another team's tenant ID.
Grafana Enterprise Logs moves tenant administration and access checks into the product. According to the GEL docs, it adds tenant management through a built-in API or the official GEL plugin, token-based authorization with configurable access, and label-based access controls applied to log queries. It also supports cross-tenant queries that aggregate results across tenants, which matters when a platform or security group needs one view over several business units. The practical difference is where enforcement sits. A proxy rule that routes a user to tenant A protects tenant A only as long as every path to Loki goes through that proxy and the rule is correct. With store-side controls, the access decision is tied to the tenant token and the label selectors, so a team can be limited to specific streams even inside its own tenant. Confirm with Grafana Labs exactly which GEL features apply to your Grafana version and deployment method before you rely on them.
Illustrative example: a bank runs one Loki tenant per business line, and the payments team's proxy maps its staff to payments. Under OSS Loki, a mistake in the proxy's header rule or a direct connection to the Loki port could let a payments user request logs from retail. Under GEL, the store would still check the token and label rules for each query, so the same mistake would be blocked at the second control. Both designs need network controls that keep clients away from Loki itself. The choice between them depends on how many teams share the cluster and how strictly each must be separated.
What does each edition cost to run, and what is still unpublished?
This table lists the cost components of running Grafana Loki or Grafana Enterprise Logs yourself, who gets paid for each one, and whether it is one-time or recurring. GEL pricing is not published in the sources we have, so the rows show what to request in writing before comparing totals. Read the table as a checklist: the license line is the only one that differs by edition in kind, while storage, compute and team time carry most of the running cost in either case.
| Cost component | Who is paid, and for what | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Software license or subscription | Open source Loki carries no license fee under AGPLv3. GEL is a commercial offering from Grafana Labs, and its price is not published in our sources. | Loki: none. GEL: recurring, terms to confirm in writing | Node count, support level and contract length. Ask whether pricing is per node, per volume or per tenant, and whether the term renews automatically. |
| Object storage and retention | Your cloud provider or storage vendor is paid for chunk and index storage. Loki keeps logs indefinitely until retention is enabled in the compactor. | Recurring | Daily ingest volume, retention period and per-tenant or per-stream retention rules. Set retention deliberately, since it is disabled by default. |
| Compute for the chosen deployment mode | Your infrastructure team or cloud account pays for read, write and backend capacity. Simple scalable mode is being removed in Loki 4.0, so plan on monolithic or microservices. | Recurring | Deployment mode, query load and ingest rate. Confirm with Grafana Labs which mode GEL supports and how its sizing guidance maps to your volume. |
| Reverse proxy and tenant mapping (team time) | Your staff build and maintain the authenticating proxy that Loki requires. With GEL, tenant management and label-based access controls are built in, which can reduce custom mapping work. | One-time build, then recurring maintenance | Number of identity groups, tenants and access rules. Fewer custom mapping rules usually means less ongoing effort, so model this per edition. |
| Upgrade and chart work | Your platform team handles Helm chart changes and version upgrades. The OSS Loki chart in grafana-community no longer supports GEL, so GEL users follow the chart maintained in the Loki repository. | Recurring, per upgrade cycle | Edition, chart source, custom configuration and how many clusters run the stack. Ask Grafana Labs which chart and release track applies to your edition. |
| Support and incident response | Open source Loki relies on community channels and your own staff. GEL customers receive vendor support under their agreement, and the GEL long-term support version 3.6 receives fixes through February 1, 2029. | Recurring | Support tier, response commitments and whether the vendor's support window matches your planned lifetime. Request the SLA in writing. |
| End-of-life planning for new buyers | GEL 3.6 receives no new features after its long-term support period begins, so new features would require a different path. Confirm what migration or upgrade terms apply at February 1, 2029. | One-time planning, with a recurring risk | Your roadmap needs and how long you plan to stay on GEL 3.6. Ask for the end-of-life migration path and any fees for it in the quote. |
| What to request in a GEL quote | Grafana Labs issues the written quote. Ask for line items for license, support, term length, renewal terms and any end-of-life migration commitments. | Pricing is not published in our sources | Node or volume basis, number of tenants, support level and contract length. Compare the quote against your own sizing for storage, compute and team time. |
Which edition fits which team situation?
When one team or internal platform group runs the logging cluster and every user is trusted to read every log stream, open source Loki covers the core job. Ingestion, label-based queries, storage in object storage and retention through the compactor are all available in the AGPL build, so the question is rarely whether logs can be stored and searched. The free edition is adequate when the access model is a single shared trust boundary, enforced at the edge by an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium.
- Trust boundary: all readers see all streams, so no tenant isolation is needed inside Loki.
- Access enforcement: you build and run the authenticating proxy yourself, since Loki has no built-in authentication layer.
- Scale path: confirm which deployment mode fits your daily volume, because simple scalable mode is being removed in Loki 4.0.
- Upgrade risk: GEL becomes worth evaluating only if the trust boundary changes later.
- Operating cost: your team carries the object store, Helm chart and shipper work in every case.
Confirm with your security team that a single shared read scope is an accepted risk, and document who holds administrative access to the cluster and its object store.
When several business units, customers or regulated entities send logs into one cluster and tenants must not see each other's data, the free edition needs careful design. Loki identifies tenants with the X-Scope-OrgID header once authentication is enabled, but the tenant management, token-based authorization and label-based access controls on queries are features Grafana documents for GEL. GEL also adds cross-tenant queries that aggregate results across tenants, which matters if a central security team needs one view over many tenants. Treat GEL as worth evaluating when the isolation requirement is written into a control or contract and your team cannot prove it with proxy rules alone.
- Tenant identification: open source Loki relies on the header your proxy sets, so the proxy becomes part of the isolation boundary.
- Query-level controls: GEL documents label-based access controls on log queries, which the free edition does not provide.
- Central visibility: GEL documents cross-tenant queries, useful when one team must search across tenants.
- Token management: GEL documents token-based authorization with configurable access, while the free edition leaves that design to you.
- Support path: GEL is in long-term support with no new features through February 1, 2029, which affects a multi-year plan.
Confirm which tenants must be isolated, who may query across them, and what audit evidence your assessor expects for access decisions.
Teams already running open source Loki often ask whether they can add tenant controls without rebuilding. The GEL docs say a GEL binary can be dropped into an existing Loki deployment, which lowers the migration question to configuration and licensing rather than a new log store. The decision depends on whether the controls you need are the ones GEL documents and whether you can accept a fixed long-term support line. Keep the existing object storage, index and retention settings in view, because they carry over.
- Binary swap: the GEL docs describe dropping the binary into an existing Loki deployment, so confirm this against your version and deployment mode.
- Chart changes: the community Helm chart no longer supports GEL, and GEL users are directed to the chart maintained in the Loki repository.
- Support window: GEL version 3.6 is the long-term support line, with no new features through February 1, 2029.
- Stored data: confirm chunk and index formats, retention rules and tenant IDs remain valid after any change.
- Staying open source: if controls are met with your own proxy, the existing estate needs no licensing change.
Ask the vendor to confirm in writing which GEL version matches your current Loki release and what the upgrade path looks like.
What the February 2029 end of life means for a new GEL purchase
The February 2029 end of life changes the answer for a buyer signing a new GEL contract today. According to the GEL docs, the GEL long-term support version is 3.6, and existing customers keep support, bug fixes and security fixes but receive no new features through February 1, 2029, when GEM, GEL and GET reach end of life. A new buyer therefore gets a stable, feature-frozen log cluster with a fixed horizon, not a product that keeps moving with Loki. Before you sign, ask Grafana Labs in writing which version you will be issued, whether that version is the 3.6 LTS line, and what the support terms are for the months before February 1, 2029.
The trade-off is predictability against runway. A stable feature set suits a team that wants fixed multi-tenant controls, such as the tenant management API or plugin, token-based authorization and label-based access controls, and does not need new capabilities for the next few years. The limited runway is the risk. Plan the migration before the date arrives, and confirm with the vendor whether renewal is offered past February 2029, what the migration path to a successor offering looks like, whether data in GEL's storage format can be read by the successor, and whether a binary swap or a re-ingestion is required. Get those answers in the contract, not in conversation.
Open source Loki is the other path. According to the Loki GitHub releases page, v3.7.8 was published September 17, 2026, and OSS Loki continues to receive releases, so it does not carry the same end-of-life date. The cost is that you own the access control layer: Loki has no built-in authentication, so you must run an authenticating reverse proxy in front of it, and per-tenant controls are not the same as GEL's label-based access. Ask Grafana Labs and your own security team which controls your access model requires before choosing between a supported, time-limited GEL line and an open source build your team supports.
How to move from open source Loki to GEL, or back
This sequence takes a team from a working open source Loki deployment to Grafana Enterprise Logs with tenant access controls in place, and gives a tested route back if GEL does not fit. Each step ends with a check that shows whether it can be closed.
Record the current Loki version and configuration
The platform engineer who runs Loki exports the running version, the Loki configuration file, the object storage bucket layout, the compactor settings and the authentication setup, including whether auth_enabled is set. Store the copy in version control so every later change can be compared against it. Confirm the version against the Loki releases page before planning the change. The step is done when someone other than the author can rebuild the current deployment from the stored files alone.
Review the GEL binary and Helm guidance
The platform lead reads the current Grafana Enterprise Logs documentation on dropping the GEL binary into an existing Loki deployment and the GEL Helm guidance for Kubernetes. Note which GEL version and long-term support line the team is buying into, and confirm the support window in the GEL docs before committing. Record any configuration keys or deployment requirements that differ from open source Loki. The step is done when the team has a written list of differences that the change must address.
Move the Helm chart to the Grafana Labs GEL chart
The platform engineer replaces the open source Loki chart with the chart Grafana Labs maintains in the Loki repository for GEL. The community chart in grafana-community/helm-charts no longer supports GEL, so teams still using it must switch. Render the chart templates in a non-production cluster and diff them against the current manifests. The step is done when the rendered output differs only where the GEL documentation says it should.
Configure tenant management and access tokens
The security or platform team sets up tenant management through the built-in GEL API or the official GEL plugin, then defines token-based authorization and the label-based access controls on log queries that each tenant needs. Map each existing X-Scope-OrgID value to a GEL tenant and remove any cross-tenant access that is not intended. Confirm the token scope with a test user from each tenant. The step is done when each test user can read only their own tenant and any cross-tenant query is limited to the roles that were approved.
Validate queries, ingestion and retention
The operations team runs a fixed set of LogQL queries from dashboards and alerts against both the old and new clusters over the same time window, then compares result counts and labels. It also confirms that log shippers such as Grafana Alloy, Fluent Bit or Fluentd still write to the same endpoints and that the authenticating reverse proxy passes the tenant header correctly. Check that retention settings in the compactor match the old values, since retention is disabled by default in Loki unless it was enabled. The step is done when the comparison shows matching results and the retention behavior is documented.
Cut over and keep the old cluster for rollback
The team schedules the cutover with the owners of dependent alerts and dashboards, points shippers and query clients at the GEL endpoint, and keeps the open source cluster and its object storage read-only for an agreed rollback period. The timing should follow the team's own change process, since this guide does not set a duration. The step is done when new logs arrive in GEL, all tenants can query their data, and the on-call team has signed off on the cutover runbook.
Check GEL-only settings before reverting to open source
If the team moves back to open source Loki, the platform engineer first lists every GEL-only setting, tenant definition, token and access rule in use, and confirms which ones have no equivalent in the open source configuration. Tenant access rules that depended on GEL controls must be replaced with an authenticating reverse proxy in front of Loki, because Loki has no built-in authentication layer. Confirm each replacement with the current Loki authentication documentation. The step is done when every GEL-only dependency has a mapped replacement or has been formally accepted as lost.
Revert the chart and confirm the rollback
The platform engineer restores the open source Loki chart and configuration from the version-controlled copy made in the first step, reapplies the tenant mapping through the reverse proxy and reruns the query comparison against the stored baseline. The team then confirms that log shippers, alerts and tenant isolation behave as they did before the GEL cutover. Confirm each command and configuration key against the Loki and Grafana Labs documentation at the time of the change. The step is done when the baseline comparison passes and the rollback is written into the change record.
What do buyers ask before choosing or hiring help for Loki or GEL?
What drives the cost of Grafana Loki versus Grafana Enterprise Logs?
The open source Loki binary carries no license fee, so the recurring costs sit in infrastructure, staff time and any outside help. Grafana Enterprise Logs (GEL) is a commercial offering based on Loki, and its license cost comes from Grafana Labs, which publishes no price in the sources we reviewed. Ask Grafana Labs for a written GEL quote covering tenant count, support level and the long-term support version you would run. For either option, the cost drivers are object storage volume, ingestion rate, retention period, the number of tenants, and the engineering hours needed to run the cluster. Request a quote that separates license, support, implementation and recurring operations so you can compare them line by line.
How long does a Loki or GEL evaluation or migration take?
No duration for either evaluation or migration is supplied in our research, so treat any number you hear as a claim to verify. The duration depends on the deployment mode you choose, the volume of logs you ingest, how many shippers and sources you migrate, how much identity and tenant design work is needed, and whether you have a test cluster ready. Retention settings and historical data handling also add time. Ask any implementation partner for a written scope with deliverables and a timeline before work starts, and confirm which parts are in and out of that scope.
What does running Loki need from our own team?
Loki stores compressed chunks and its index in object storage, so your team needs an object store that meets Loki's production guidance. The Loki docs recommend Amazon S3, Google Cloud Storage or Azure Blob Storage, and note that S3-compatible stores and local filesystems are not typically recommended for production. Loki also has no built-in authentication, so you need an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium in front of it. Your team must also configure shippers, which can be Grafana Alloy, Fluent Bit, Fluentd, the Docker logging driver or OpenTelemetry over HTTP. Identity integration sits in the proxy layer, so confirm which team owns that component.
Can we migrate to Loki or GEL ourselves?
Yes, many teams do this with internal staff, but it depends on the skills and capacity you have. Loki's documentation covers installation, storage, retention and multi-tenancy, and the shipper docs cover common agents. GEL can be dropped into an existing Loki deployment according to the GEL docs, which lowers the change for teams already running Loki. The risks are in the parts that vendor docs cannot decide for you: tenant boundaries, label design, retention policy and access control on queries. DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms in your own infrastructure, and most engagements are fixed-scope with agreed deliverables in writing.
Does GEL's February 2029 end of life mean we should choose open source Loki?
Not automatically, but it changes the decision for new buyers. According to the GEL docs, the GEL long-term support version is 3.6, and existing customers continue to receive support, bug fixes and security fixes but no new features through February 1, 2029, when GEM, GEL and GET reach end of life. A new buyer therefore takes on a product with a fixed feature horizon. Open source Loki is AGPLv3 licensed and is maintained as a project, with v3.7.8 published on September 17, 2026, so it receives ongoing development. Weigh whether you need the multi-tenant access controls GEL adds, and confirm the support and upgrade path for whichever edition you choose.
Which GEL features should we verify before paying for Enterprise Logs?
Verify the specific access controls your auditors and tenants require. According to the GEL docs, GEL adds tenant management through a built-in API or the official GEL plugin, token-based authorization with configurable access, label-based access controls on log queries, and cross-tenant queries that aggregate results across tenants. Open source Loki is multi-tenant when auth_enabled is true and uses the X-Scope-OrgID header, but it does not provide the label-based query controls described above. Test these features in a non-production cluster with your own tenant model. Ask Grafana Labs to confirm how each feature behaves in the exact release you plan to deploy.
Does Loki's simple scalable mode affect our choice?
Yes, it affects the deployment plan for any new cluster. The Loki documentation states that simple scalable deployment mode is being deprecated and will be removed with the Loki 4.0 release. Monolithic mode covers smaller volumes, with the docs citing up to about 20 GB of logs per day, and microservices mode suits very large clusters but adds Kubernetes operating complexity. Confirm the mode your expected volume requires and plan an upgrade path before Loki 4.0 arrives. Ask any vendor or partner how they will handle that transition for your cluster.
How DeployOpen scopes and supports either edition
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so the Loki or GEL decision is made against your tenancy model, storage and identity setup. We start from the access model you need, then write the scope around it before any work begins.
How we scope
- Each engagement starts with a written scope covering tenants, access requirements and the Loki or GEL edition chosen.
- We record which tenants need label-based access controls and whether cross-tenant queries are required.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- We confirm your object store, reverse proxy and identity provider choices so they are named in the scope.
How we build
- We deploy the chosen Loki or GEL build into your cloud account, data center or air-gapped network.
- We configure the authenticating reverse proxy in front of Loki, which the project requires for access control.
- We set retention, the compactor and tenant headers, then test that each tenant sees only its own logs.
- We run security testing against the log platform and its access path before handover.
How we hand over
- Handover includes documentation of the deployment, configuration keys, tenant onboarding and retention settings.
- We document the upgrade path, including how a GEL binary would be replaced or retained in an existing cluster.
- Compliance evidence is prepared for your assessor, though DeployOpen does not issue audit reports or certifications.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover Loki version upgrades, including checks against the deployment mode you run.
- Ask us to confirm which support path, edition and end-of-life date applies before you sign a written scope.
