When Grafana Cloud Logs or self-hosted Loki fits your team
Choose Grafana Cloud Logs if your team would rather buy a managed log store than operate one, and your data can legally and contractually leave your own infrastructure. Choose self-hosted Loki if logs must stay inside your cloud account, data center or air-gapped network, or if you already have people who run object storage, Helm charts and log shippers and want to keep the per-GB economics under your control. The deciding questions are residency, volume, retention and staffing, in that order of how often they end the discussion.
Residency comes first because it is a yes or no answer. Grafana Cloud's Pro tier is priced per GB for processing, write and retention, and its Enterprise tier, starting at a 25,000 US dollar yearly commit, adds Public Cloud, Federal Cloud and Bring Your Own Cloud deployment options, according to the Grafana pricing page. If your regulator, customer contracts or internal data classification require log data to stay in a specific region or account, confirm with Grafana which deployment option satisfies that rule before you model cost. Self-hosted Loki keeps chunks and the index in your object store, but Loki has no built-in authentication layer, so you must place an authenticating reverse proxy in front of it and manage tenant isolation through X-Scope-OrgID yourself.
Volume and retention decide the cost comparison. The free tier covers 50 GB ingested per month with 14 days of retention, which suits a small estate or a pilot. Above that, Pro charges per GB processed, written and retained, and retention defaults to 30 days, so a long retention requirement multiplies the bill. Self-hosted Loki has no retention limit by default because the compactor keeps logs indefinitely until retention_enabled is set, which means you pay object storage and staff time for every day you keep. Ask for a quote from Grafana against your measured daily ingest and your retention period, and ask your own team to estimate object storage growth at that volume. If you need the staffing side, check whether your team already runs S3-compatible storage and Kubernetes, because the Loki Helm chart is now maintained in the grafana-community/helm-charts repository rather than by Grafana Labs, according to the GEL Helm docs.
How Grafana Cloud Logs and self-hosted Loki compare on each factor
This table sets Grafana Cloud Logs against self-hosted Loki across licensing, storage, deployment, retention, authentication, shipping and chart ownership. Read each row against your own data volume, residency rules and team capacity, and treat cells marked as items to confirm as questions for your environment and your Grafana Labs contract.
| Factor | Grafana Cloud Logs | Self-hosted Loki |
|---|---|---|
| Licensing | Hosted service under Grafana Labs commercial terms, so review the agreement for your use | Grafana Loki is AGPLv3 licensed, so review the AGPL obligations with counsel if you modify and offer it to users |
| Where data is stored | Stored in Grafana Labs-operated Grafana Cloud infrastructure, region to confirm in your contract | Compressed chunks and index in object storage you choose, such as S3, Google Cloud Storage or Azure Blob Storage |
| Control over storage location | Limited to the Grafana Cloud offerings; Enterprise adds Public Cloud, Federal Cloud or Bring Your Own Cloud options | Full control within your own accounts, data centers or air-gapped networks, subject to your own design |
| Deployment modes | Managed by Grafana Labs, with no mode choice for you to make | Monolithic, simple scalable (to be removed in Loki 4.0) or microservices, chosen by daily volume |
| Retention controls | Free tier keeps 14 days; Pro retention is 30 days; custom retention is listed under Enterprise | Retention is disabled by default in the compactor and must be enabled, with global, per tenant or per stream rules of at least 24 hours |
| Authentication | Handled by the Grafana Cloud platform; confirm the access model for your teams | No built-in authentication, so you must run an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium |
| Shipper support | Grafana Alloy is the supported shipper for Loki, with Fluent Bit, Fluentd and the Docker logging driver also accepted | Same shipper set as Grafana Cloud, since the Loki endpoint is the same; confirm your tenant headers |
| Helm chart ownership | Not applicable, since Grafana Labs operates the service | The OSS Loki Helm chart is maintained in the grafana-community/helm-charts repository, not by Grafana Labs, as of March 16, 2026 |
| Editions | Free tier (50 GB ingested per month), Pro and Enterprise (from a 25,000 US dollar yearly commit) | Single open-source edition; Grafana Enterprise Logs is a separate paid product to evaluate on its own terms |
What control, data location and compliance change in each model
Choosing between Grafana Cloud Logs and self-hosted Loki moves who holds the log data, who enforces access, and who produces the evidence an assessor asks for. The cards below separate those decisions so each can be checked against your own requirements before you sign anything.
Where the log data sits
With self-hosted Loki, chunks and the index live in the object store you choose, inside your cloud account, data center or air-gapped network. With Grafana Cloud, logs are held in Grafana's hosted service. Grafana's published Enterprise options include Public Cloud, Federal Cloud and Bring Your Own Cloud deployment, but those apply only to the Enterprise tier. Confirm with Grafana Labs which regions are available for your account and which assurance reports cover them.
Who can read the logs
Logs often contain credentials, personal data and internal hostnames, so the list of people and services with query access matters as much as the storage location. A self-hosted Loki deployment gives your team full control over which administrators can reach the object store and the query path. In Grafana Cloud, the provider's staff and administrative roles sit in a different trust boundary, so ask for the documented access controls and support access procedures in writing.
How authentication is enforced
Loki has no built-in authentication layer. The Loki documentation says you must run an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium in front of it, and that work sits with your team. Grafana Cloud handles user authentication for its hosted endpoints, but you still need to decide how log shippers authenticate and how their tokens are rotated. Test both paths before you rely on either.
Tenant isolation
When Loki runs with auth_enabled set to true, it separates tenants by the X-Scope-OrgID header on every request. That header is only as trustworthy as the proxy that sets it, so a misconfigured gateway can let one team read another team's streams. Grafana Cloud separates customer stacks at the platform level. Ask the vendor how isolation is tested and how you would verify it for your own teams.
Retention and deletion control
In self-hosted Loki, retention is disabled by default, so logs are kept indefinitely until you set retention_enabled. Your team then owns retention rules, per tenant or per stream, and the deletion procedure for data subject requests or legal holds. Grafana Cloud's free tier keeps logs for 14 days, and the Pro tier's published retention is 30 days, with longer retention priced per GB. Confirm how deletion requests are honored in each model and how long backups persist.
Evidence for an assessment
DeployOpen prepares systems, controls and evidence for compliance assessments in your self-hosted Loki environment, including access configuration, retention settings and backup records. DeployOpen does not issue audit reports, attestations or certifications, and independent auditors and certification bodies make those determinations. For Grafana Cloud, the evidence you receive comes from Grafana Labs. Request its current assurance reports and confirm they match the framework your assessor will use.
How cost differs for a small team, a growing team and a regulated enterprise
A small team on Grafana Cloud's free tier pays no platform fee, but the tier is capped. The published free allowance is 50 GB of logs ingested per month with 14 days of retention. Inside that envelope, the team's only logs-related cost is its own time to configure shipping, dashboards and alert rules. The cap is the main decision point: once ingestion regularly exceeds 50 GB in a month, or the team needs logs kept longer than 14 days, the free tier stops fitting.
- Ingestion ceiling: The 50 GB monthly limit applies to what you send, so verbose debug logging or a new noisy service can exhaust it early in the month.
- Retention ceiling: At 14 days, incident reviews or audit requests that reach back further need a different plan or an export.
- Recurring cost: None on the published free tier, but this figure is set by Grafana Labs and can change, so confirm the current terms on the pricing page.
- Staff time: Setting up agents and log pipelines still takes engineering hours, even with no invoice.
- Exit path: Starting here is cheap to try, but moving later means re-plumbing shippers and rebuilding dashboards.
Before committing, measure your actual monthly ingestion for a few representative weeks and confirm which retention your audit or incident process requires.
A growing team that outgrows the free cap moves to Pro, where costs are metered. The published Pro figures are 0.050 US dollars per GB for processing, 0.400 US dollars per GB for write and 0.100 US dollars per GB for retention. The 19 US dollar monthly platform fee includes 50 GB ingested, and retention is 30 days. Because the components are per GB, the monthly bill rises with volume, and it also rises with how long you keep data. Your bill is driven by how much you ingest, how much you write and how long you retain, so each lever should be modeled separately.
- Platform fee: A fixed 19 US dollars per month that includes 50 GB ingested.
- Per-GB components: Processing, write and retention are billed per GB, so volume and retention period drive the total.
- Retention choice: Pro retention is 30 days, and keeping data beyond that is a separate decision you should confirm with Grafana Labs.
- Cost drivers you control: Dropping debug lines, filtering noisy streams and shortening retention reduce the metered components directly.
- Recurring nature: Every component recurs monthly, so savings from log hygiene compound over time.
Ask for a worked estimate from your own ingestion profile and check whether the 30-day retention satisfies your policy.
A regulated enterprise often needs terms that the self-service tiers do not cover. The published Enterprise tier starts at a 25,000 US dollar yearly commit and offers custom retention plus Public Cloud, Federal Cloud or Bring Your Own Cloud deployment, according to the Grafana pricing page. The commit is the floor, so total spend depends on negotiated volume, support and the deployment option chosen. Procurement, legal and security reviews add internal effort that the published price does not show.
- Yearly commit: Starting at 25,000 US dollars per year, and the final amount follows from negotiated scope.
- Custom retention: Retention beyond the Pro 30-day setting is available on this tier, so confirm the length your policy needs.
- Deployment model: Public Cloud, Federal Cloud or Bring Your Own Cloud options each change where data lives and who operates it.
- Internal review cost: Security, legal and data-residency reviews take staff time that recurs at each renewal.
- Negotiation levers: Volume commitments, support terms and retention length are the items to price.
Request a written quote that itemizes commit, overage, retention and deployment option, and ask how each renews.
A team that runs Loki itself pays for infrastructure and people rather than a Grafana Cloud meter. The main cost components are object storage for compressed chunks and the index, compute for the Loki components, staff time to deploy and upgrade the Helm chart, and the team's own support load for incidents and tenant access. Loki is AGPLv3 licensed, so the software itself carries no license fee. The Helm chart is maintained in the grafana-community/helm-charts repository rather than by Grafana Labs, which means your team owns more of the upkeep decisions. Object storage costs rise with retained volume, compute rises with ingestion and query load, and staff time rises with the number of environments and the depth of your Kubernetes skills.
- Object storage: Recurring cost that grows with retained volume, so retention settings are the main lever.
- Compute: Scales with ingestion rate and query concurrency, and the deployment mode you choose affects its shape.
- Staff time: Recurring for deployment, upgrades, backups and on-call, and the largest cost for small teams.
- Authentication layer: Loki has none built in, so an authenticating reverse proxy is a component you must run and maintain.
- Support: Community support or your own engineers, with no vendor SLA unless you buy one from a third party.
Ask your infrastructure team to estimate object storage, compute and on-call hours for your real retention and volume, and confirm which of those costs you already carry.
What your team runs in each model
This table lists the recurring operating tasks for each model and who performs them. Read each cell as a division of work between Grafana and your team. The main takeaway is that self-hosting moves object storage, upgrades, access control and on-call to your staff, so confirm that staffing before you choose.
| Operating task | Under Grafana Cloud Logs | Under self-hosted Loki |
|---|---|---|
| Object storage setup and lifecycle | Grafana operates storage. Your team has no bucket to create or manage. | Your team creates and secures the bucket, sets lifecycle rules and backs it up. Confirm which store you can support in production. |
| Loki upgrades | Grafana applies service upgrades. Your team tracks changes that affect agents and queries. | Your team plans, tests and applies Loki and Helm chart upgrades. The OSS chart is maintained by grafana-community, so confirm your support path. |
| Deployment mode choice | Not applicable. Grafana selects and scales the service architecture. | Your team picks monolithic, simple scalable or microservices. Simple scalable is removed in Loki 4.0, so plan a move. |
| Retention configuration | Set retention in your plan. The Pro tier documents 30 days, billed per GB retained. | Your team enables the compactor, sets retention_enabled and defines rules per tenant or stream. Retention is off by default. |
| Authenticating reverse proxy | Grafana handles access to the hosted endpoint. Confirm how your identity provider and tokens are managed. | Your team runs nginx, HAProxy, OAuth2 Proxy or Pomerium in front of Loki, because Loki has no built-in authentication. |
| Shipper configuration | Your team configures agents such as Grafana Alloy to send logs to the hosted endpoint. | Your team configures the same agents plus the self-hosted endpoint and the X-Scope-OrgID tenant header when auth is enabled. |
| Monitoring Loki itself | Grafana monitors the service. Your team watches ingestion volume against plan limits and agent health. | Your team monitors ingestion, compactor, storage and query health, and builds alerts for each component. |
| On-call coverage | Grafana handles hosted service incidents. Your team covers agents, alerts and log access issues. | Your team covers host or pod failures, storage incidents and upgrade rollbacks, including out of hours. Confirm staffing levels. |
What self-hosting leaves with your team after the install
The install is the smallest part of owning Loki. Once it runs, your team keeps the work that a managed service would otherwise carry: choosing and securing the object store, setting retention, building access control in front of the API, and keeping the shipper and Helm values current. The Loki storage documentation recommends Amazon S3, Google Cloud Storage and Azure Blob Storage for production. It notes that S3-compatible stores such as MinIO and the local filesystem are supported but not typically recommended for production. Decide which store you will use, who owns its bucket policies and encryption keys, and how you will back it up before the first log arrives. Confirm with your own cloud or storage team whether your chosen store meets your data residency and durability requirements.
Retention is the setting most often missed. Loki retention is handled by the compactor and is disabled by default, so logs are kept indefinitely until retention_enabled is set. Retention can be global, per tenant or per stream selector, and each stream rule must be at least 24 hours. Someone must decide the retention period for each log class, write those rules, and check that the compactor is running and deleting data as intended. Authentication is a second gap. Loki has no built-in authentication layer, and its documentation requires an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium in front of it. Multi-tenant setups also depend on the X-Scope-OrgID header being set and enforced correctly at that proxy, so your team must design, test and patch that layer.
The work with the most recurring cost is keeping the pipeline current. Grafana Alloy is Grafana's supported log shipper for Loki, and Loki also accepts Fluent Bit, Fluentd and the Docker logging driver, so each shipper configuration needs an owner and an upgrade path. The OSS Loki Helm chart is now maintained in the grafana-community/helm-charts repository rather than by Grafana Labs, so your team should confirm which chart source and support path it will rely on. Plan for Loki's own upgrades as well. The simple scalable deployment mode is slated for removal in Loki 4.0, so a deployment built on it will need a migration. A fixed-scope implementation can cover the initial design, object store setup, retention rules, proxy configuration and documentation. The ongoing patching, chart updates and on-call work stay with your team unless you contract a retainer.
How to move logs from Grafana Cloud to self-hosted Loki, or back
This sequence moves log ingestion, retention and access from Grafana Cloud to a self-hosted Loki deployment (or the reverse) with both paths running in parallel before the shipper is switched, so the team can verify queries, retention and access before any source stops sending to the old destination.
Inventory log sources, volumes and retention needs
The platform or observability lead lists every log source, the shipper that sends it today, the approximate daily volume per source, the retention each team needs, and the dashboards, alert rules and saved queries that depend on Grafana Cloud. Ask Grafana Labs for your current ingestion and retention figures from your own account, since the free tier and Pro rates in the Grafana pricing page apply to what you actually send. The step is done when the list is signed off by the teams that own each source, and every dashboard and alert has an owner.
Choose the Loki deployment mode from volume
Using the daily volume ranges in the Loki deployment modes documentation, the team picks monolithic, simple scalable or microservices. Note that the docs say simple scalable mode is being deprecated and will be removed with Loki 4.0, so a new build should be checked against that roadmap before it is chosen. The output is a written decision that names the mode, the expected daily volume and the owner of the Kubernetes or VM layout if one is needed.
Stand up storage, authentication and shipper configuration
The platform team provisions object storage (the Loki docs recommend Amazon S3, Google Cloud Storage or Azure Blob Storage for production), enables multi-tenancy if needed, and places an authenticating reverse proxy in front of Loki, because Loki has no built-in authentication layer. Retention is disabled by default, so the team sets retention deliberately in the compactor configuration. The shipper, such as Grafana Alloy, Fluent Bit or Fluentd, is configured against the target. The step is done when a test stream is written, queried through the proxy with the correct tenant header, and the retention setting is confirmed in the running configuration.
Run both paths in parallel
Each source is sent to Grafana Cloud and to the new Loki instance at the same time, using a second destination in the shipper. The team compares ingested line counts, label sets, parsing results and dashboard panels over a period agreed in advance, and checks that the query results match for the same time ranges. Expect differences in how labels are applied, since Loki indexes only labels and queries use LogQL, so queries must be rewritten and tested rather than copied. The step is done when the agreed comparison shows no missing streams and each critical dashboard returns the expected results.
Cut over the shipper and retire the old destination
Once the parallel run passes, the shipper configuration is changed so that each source writes only to the target, starting with the lowest-risk sources. The on-call team confirms that alerts fire from the new location, and the old destination is kept receiving nothing new for an agreed period before the Grafana Cloud stack is reduced. Record the cutover time for each source. The step is done when every source appears in the target, no source still writes to the old destination, and the change log is signed off.
Handle historical data, alerts and access manually
Historical logs do not move automatically, so the team decides with compliance and the data owners whether to export a defined window, keep the old account readable for a set time, or accept a gap. Grafana Cloud alert rules, contact points, access policies and team permissions must be recreated and tested in the target. Confirm with Grafana Labs what can be exported and in what format for your account before the decision is made. The step is done when a written record shows what was migrated, what was exported, and which alerts and access rules were rebuilt and tested.
Migrate dashboards and check query language compatibility
Dashboards, saved queries and recording or alerting rules are exported and checked against the target Loki version, since the query language and shipper configuration must be verified for that release, including the Loki releases page for the version you run. Panels that depend on Grafana Cloud-only features or data sources are flagged for redesign. The output is a dashboard inventory with each panel marked as moved, rewritten or retired, and a sign-off from the owners of each dashboard.
Plan the reverse path with the same inventory
Moving back to Grafana Cloud is also a migration, so the same inventory, parallel run and cutover steps apply in reverse. The team confirms Grafana Cloud plan limits and retention for its expected volume against the Grafana pricing page, and recreates the self-hosted object storage, proxy and retention settings as a documented decommissioning plan. The step is done when the reverse path has its own signed inventory and cutover record, so that a later move is not started from memory.
Why Loki's AGPLv3 license and release path matter to a self-hosting decision
Running Loki yourself means taking on its license obligations. Grafana Labs announced on April 20, 2021 that Loki and its other core projects would move from Apache License 2.0 to AGPLv3. The AGPL reaches network use: if you modify Loki and make it available to users over a network, the source obligations can apply to your changes. Ask counsel to review how your internal log platform, any patches to Loki, and any internal tooling that talks to it fall under AGPLv3 before you go live. The Grafana Labs licensing page is the starting point for that review, not a substitute for it. A hosted service carries a different set of terms, so the license question is one you answer for self-hosting only.
Plan the upgrade path before you deploy. The latest release in the supplied facts is Loki v3.7.8, published September 17, 2026, on the Loki releases page. The Loki documentation states that the simple scalable deployment mode is being deprecated and will be removed with the Loki 4.0 release. If your design uses simple scalable mode, you will need a migration to monolithic or microservices mode before that major version arrives. Confirm the Loki 4.0 release date and migration guidance with Grafana Labs, and read the release notes for each minor version for breaking changes to configuration keys, retention settings and the compactor. Test each upgrade in a non-production environment that uses the same object store and authentication proxy as production.
Ask your Grafana Cloud sales contact, in writing, which upgrade commitments apply to the hosted service: who performs version upgrades, how much notice you get before a change, whether breaking changes are documented in advance, and what happens to your retention and tenant settings during a migration. With self-hosting, the upgrade work, object store maintenance, Helm chart changes and the reverse proxy in front of Loki stay with your team or your implementation partner, and each one needs a named owner and a test plan. Put those responsibilities into the written scope of work so that an upgrade does not fall between two parties.
What buyers ask before choosing between Grafana Cloud Logs and self-hosted Loki
What does self-hosting Loki cost, and who gets paid for what?
Self-hosted Loki has no license fee, since Loki is AGPL-3.0 licensed, but the cost moves to infrastructure and people. You pay your cloud or data center provider for compute, object storage for compressed chunks and the index, and network traffic, and you pay staff or a services partner to install, operate and upgrade the stack. Infrastructure is recurring and scales with ingest volume and retention. Labor is mostly one-time for the build and recurring for upkeep. Grafana Cloud Pro, by contrast, bills processing at 0.050 US dollars per GB, write at 0.400 US dollars per GB and retention at 0.100 US dollars per GB, with a 19 US dollar monthly platform fee that includes 50 GB ingested, according to the Grafana pricing page. Model both with your real daily volume and retention period. Ask a quote to separate one-time build work, recurring support and infrastructure estimates.
How long does a self-hosted Loki rollout take?
No fixed duration applies to every environment, so treat any single number as a claim to verify. The timeline is driven by the deployment mode you choose, the object storage you already run, whether you need multi-tenant access, how many log sources must be shipped, and how many retention rules and dashboards must be migrated. Loki documents monolithic mode for up to about 20 GB of logs per day, while simple scalable mode is being removed in Loki 4.0 and microservices adds Kubernetes operating work, so a mode decision made early avoids rework. A fixed-scope written agreement is the right place to pin down milestones and deliverables before work starts. Ask for the rollout plan to list each source, each tenant and each acceptance test.
Can our team run self-hosted Loki without outside help?
A team with Kubernetes or Linux operations experience and object storage administration can run Loki, but it needs several skills at once. Those include object storage design, compactor and retention configuration, reverse proxy authentication, since Loki has no built-in authentication layer and documents running an authenticating proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium in front of it, and shipper configuration with Grafana Alloy, Fluent Bit or Fluentd. Backup, upgrades and capacity planning also need an owner. Check whether your on-call rotation can absorb these tasks alongside existing duties. If the gap is large, DeployOpen can plan, implement, document and support the stack inside your own infrastructure, with ongoing support available as a retainer.
Are the free tier's 50 GB and 14-day limits enough for a pilot?
They can be enough for a narrow pilot, but only if your ingest stays under 50 GB per month and you accept 14 days of retention. The free tier is limited to 50 GB of logs ingested per month with 14 days retention, according to the Grafana pricing page. Check your current daily volume from one or two sources, multiply it across the pilot window, and confirm that the retention you need for investigations and audits fits inside 14 days. Pilots that include production-grade audit log sources often exceed the cap quickly. Note that a self-hosted pilot has no such cap, but it still needs object storage and operator time. Test both options against a real sample of your own logs.
When does Grafana Enterprise become the right step?
Enterprise becomes the right step when a commercial requirement outweighs the operating work of open source. On the Grafana Cloud side, the Enterprise tier starts at a 25,000 US dollar yearly commit and offers custom retention and Public Cloud, Federal Cloud or Bring Your Own Cloud deployment, according to the Grafana pricing page. Self-hosted, Grafana Enterprise Logs adds capabilities for multi-tenant access control that open source Loki does not provide. Ask Grafana Labs to confirm the current feature set, support terms and end-of-life dates for any edition before you commit. Compare that commitment against the cost of building and operating the controls yourself.
What should a quote for self-hosted Loki include?
A useful quote lists the written scope, the deliverables and the acceptance tests before any price appears. DeployOpen works from fixed-scope agreements, and its quotes follow from that written scope, since it does not publish a price list. Ask for these items to be named individually:
- Deployment mode, object storage target and backup approach
- Authentication design, including the reverse proxy and tenant header handling
- Log sources, shipper configuration and retention rules per stream or tenant
- Dashboards, alerting, documentation and the handover plan
- Support or retainer terms for upgrades after go-live
Separate one-time build work from recurring support. Also ask what infrastructure costs remain with your cloud provider, since those are not part of a services quote.
Can DeployOpen implement, harden or support either model?
DeployOpen can implement, harden and support self-hosted Loki inside your own cloud accounts, data centers or air-gapped networks, as part of a fixed-scope engagement. Its work includes planning, customization, integration, hardening, backup, upgrades, documentation and support. It does not operate or resell Grafana Cloud, and it is not an official partner or reseller of Grafana Labs unless a fact supplied with the topic says so. For Grafana Cloud, DeployOpen could help with shipper setup, integration and security testing, but confirm the exact scope in writing. Ongoing support, upgrades and continuous testing are available as retainers.
Can we move logs from Grafana Cloud to self-hosted Loki later?
Moving logs is possible in principle, but the exact path depends on export options, retention windows and shipper configuration, so confirm each step with Grafana Labs and your own environment. Forward-looking, the safer step is to keep shippers vendor-neutral, since Grafana Alloy is a distribution of the OpenTelemetry Collector and Loki also accepts OpenTelemetry logs over HTTP, Fluent Bit, Fluentd and the Docker logging driver. Historical data is the harder part, because Grafana Cloud's 14-day free retention limits what you have to migrate and Loki retention is off by default until configured. Ask for a written export and re-ingest test with a sample of your own logs before committing.
How DeployOpen scopes, delivers and supports a self-hosted Loki platform
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. For a Loki decision, that means working from a written scope that shows which logs stay in your environment, what your team would run, and what a managed service would take off your hands.
How we scope
- Inventory log sources, daily volumes, retention needs and who queries logs before any design choice.
- Document the object storage target, deployment mode and tenancy model in the written scope.
- Confirm the authenticating reverse proxy and identity integration Loki needs, since it has no built-in authentication layer.
- Agree in writing which parts of the Grafana Cloud comparison you want costed against your own volumes.
How we build
- Deploy Loki on your chosen object store, with the compactor and retention settings your scope defines.
- Configure shippers such as Grafana Alloy or Fluent Bit against the sources listed in the inventory.
- Set up the Loki Helm chart or VM-based install, recording the chart source and version you actually deploy.
- Test ingestion, query latency and retention behavior against the scope before handover.
How we hand over
- Deliver runbooks for tenant onboarding, retention changes, backup and restore of the object store.
- Document the architecture, configuration keys and upgrade path so your team can operate the stack.
- Walk your platform and security staff through alerting on ingestion failures and storage growth.
- Provide evidence and configuration records that your auditors can review, without issuing any audit opinion ourselves.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Ask any provider, including us, for the written scope, the named support boundaries and what a quote covers.
