Which fits: Grafana Cloud or a self-hosted Grafana stack
Grafana Cloud fits a small team that does not want to operate storage, upgrades and high availability itself. Grafana Cloud has a free tier and a Pro tier that starts with a 19 US dollar monthly platform fee plus usage, according to the Grafana pricing page, so the cost is a recurring subscription that grows with active series, logs and users. It also gives you the cloud-only features that the self-hosted editions do not include, such as SAML, team sync, active sync and SCIM provisioning, which the Grafana authentication docs list as Enterprise and Cloud features. If your renewal is driven by usage-based bills, the first step is to pull a month of billing detail and identify which meter (series, log volume, traces or users) is climbing, because that tells you whether reducing telemetry or changing the operating model will help most.
Self-hosting fits when telemetry must stay inside your environment or when you already have platform engineers who can run the stack. Grafana, Prometheus, Mimir and Loki all run in your own cloud account or data center, and Loki is built to keep its chunks and index in object storage you control. The work is real: Grafana needs MySQL 8.0 or later or PostgreSQL 12 or later for production and high availability, Prometheus local storage is not clustered or replicated, and Loki retention is disabled by default, so logs accumulate until you set retention_enabled. Confirm with your own staff how many hours a month they can give to upgrades, backups and on-call before you commit, because the cost sits in people as much as in servers.
The decision turns on four questions: where the data must reside, how much platform capacity your team has, whether you need the cloud-only identity features, and how much operating effort you will accept. Ask Grafana Labs in writing which features you would lose on exit, and check the Grafana Cloud and self-hosted editions against your identity requirements before you choose. Map each answer to a line item in the cost comparison that follows, so the decision rests on the same numbers your finance and security teams will review.
Which option fits which scenario
This table matches common team situations to the option that usually fits better and the reason, based on the supplied facts. Read each row against your own staffing, data residency and identity requirements, then confirm the open points before deciding.
| Scenario | Better fit | Reason |
|---|---|---|
| Small team with no platform engineers | Grafana Cloud | Someone must patch, back up and upgrade Grafana, Prometheus and Loki. Grafana's upgrade guidance expects regular minor and patch releases, so a team without that capacity usually carries more risk self-hosting. |
| Regulated organization that must keep telemetry in its own environment | Self-hosted stack | Telemetry stays in your accounts, data centers or air-gapped network. Confirm with your assessor which controls apply to logs that contain personal or customer data. |
| Team that needs SAML, SCIM or team sync | Grafana Cloud or Grafana Enterprise | SAML, team sync, active sync and SCIM are listed only for Grafana Enterprise and Grafana Cloud. Open-source Grafana supports LDAP, generic OAuth and other providers, so confirm your identity provider fits those options. |
| Team with an existing Kubernetes platform | Self-hosted stack | Grafana publishes Helm charts, and Loki and Prometheus run on the same cluster as your workloads. Confirm the storage class, object store and ingress your platform team will use. |
| Multi-team estate with high log volume | Self-hosted Loki in simple scalable or microservices mode | Loki's monolithic mode suits up to about 20 GB of logs per day. Above that, the simple scalable mode is being deprecated, so plan a microservices layout and confirm the Loki 4.0 timing. |
| Team that needs long-term metrics beyond local retention | Self-hosted Mimir or Grafana Cloud | Prometheus local storage defaults to 15 days and is not clustered or replicated. Long-term storage needs Mimir or another remote write target, which adds operating work. |
| Team with mixed licensing and vendor review needs | Self-hosted stack | Grafana, Mimir and Loki are AGPL-3.0-only and Prometheus is Apache-2.0. Have legal review AGPL obligations for any modified services you expose to users. |
Why the same open-source projects still lead to different work
Grafana, Prometheus and Loki are open source whether you buy Grafana Cloud or run the stack yourself, so the software is not what separates the two paths. The difference is who runs upgrades, storage, high availability and access control, and in the self-hosted case that work lands on your team. Licensing is the first thing to check. Grafana, Loki and Grafana Mimir are licensed under AGPL-3.0-only, while Prometheus is licensed under Apache-2.0. Grafana Labs also offers Grafana Enterprise as a commercial option outside the AGPL. Under the AGPL, obligations to offer source to users can apply to a modified version that users interact with over a network, which is how a shared dashboard is typically used. Confirm how those terms apply to any changes you plan with your counsel before you build on them.
Self-hosting moves several controls onto your side of the line. Grafana's upgrade guidance describes major releases once a year, minor releases every other month and patch releases at least monthly, with each minor release supported for 9 months, so someone must schedule and test those changes. For high availability, Grafana expects two or more active-active servers behind a load balancer, sharing a MySQL 8.0 or later or PostgreSQL 12 or later database, because SQLite does not scale for production. Alerting also needs extra configuration to avoid duplicate notifications. On access control, LDAP, generic OAuth, Entra ID and Okta work in every edition, but SAML, team sync, active sync and SCIM provisioning are listed only for Grafana Enterprise and Grafana Cloud. Loki has no built-in authentication and needs an authenticating reverse proxy in front of it.
Start with a short decision list. Write down your identity requirements and check whether SAML or SCIM is a hard requirement. If it is, the self-hosted path means either a Grafana Enterprise license or a different identity pattern, and you should confirm which applies with Grafana Labs before you commit. Next, name the owner of the Grafana patch cycle, the Prometheus minor releases that arrive every six weeks, and the Loki upgrade path, and name who is on call when Prometheus fails, since its local storage is not clustered or replicated. Finally, ask counsel to review the AGPL position for every change you expect to make to Grafana or Loki before anything reaches production.
How scaling and operations differ by component
Grafana is the most stateless part of the stack, but its configuration database decides whether you can run it for production. By default it stores configuration in SQLite 3, and the installation docs state that SQLite does not scale for production, so a high availability setup needs MySQL 8.0 or later or PostgreSQL 12 or later.
- Configuration database: SQLite is the default. Production and high availability require MySQL 8.0+ or PostgreSQL 12+.
- High availability: The docs describe two or more active-active servers behind a load balancer sharing that database, with database-backed auth tokens so users can reach any node.
- Alerting in HA: Alerting needs extra configuration to avoid duplicate notifications, and Grafana Live has limitations in HA.
- Upgrade cadence: Major releases arrive yearly in April or May, minor releases about every other month, and patch releases at least monthly. Each minor release is supported for 9 months, and the last minor release of a major version for 15 months.
- SSO features: SAML, team sync, active sync and SCIM are limited to Grafana Enterprise and Grafana Cloud.
Grafana Cloud runs the database, load balancing, upgrades and HA behavior for you. Check which authentication and alerting features your team depends on, and confirm the database and upgrade plan in your own environment before committing.
Prometheus stores its metrics on a single node. Its local storage is a time series database in two-hour blocks with a write-ahead log, and the default retention is 15 days, configurable by time or size. The storage docs state that local storage is not clustered or replicated and should be managed like any other single-node database.
- Single-node storage: Plan disk size and backups around one server, and plan a failover approach yourself.
- Long-term storage: Remote write and remote read send samples to and from external systems such as Grafana Mimir, which is AGPL-3.0-only and horizontally scalable.
- Alerting: Alertmanager can run as a cluster for high availability, and Prometheus should point at every Alertmanager instance rather than a load balancer.
- Release cycle: A new minor release starts every 6 weeks, and after those 6 weeks a minor release generally stops receiving bug fixes. LTS releases receive bug fixes for one year, and the current LTS line is 3.13, supported until July 31, 2027.
- Accuracy: The Prometheus docs say it values reliability over precision, so it is not a fit where 100% accuracy is required.
Grafana Cloud operates the metrics backend, retention and scaling behind the same query interface. Confirm your retention targets, the upgrade window you can accept, and how Alertmanager will be run before you size the self-hosted option.
Loki scales by deployment mode, and the mode you pick determines how much operational work you take on. The docs describe a monolithic mode for a single binary, up to about 20 GB of logs per day, a simple scalable mode with separate read, write and backend targets approaching 1 TB per day, and a microservices mode for very large clusters.
- Monolithic mode: A single binary, suited to smaller volumes and simpler operations.
- Simple scalable mode deprecation: The docs state this mode is being deprecated and will be removed with Loki 4.0, so new builds should plan a move to microservices or another supported layout.
- Object storage: Chunks and the TSDB index belong in S3, Google Cloud Storage or Azure Blob Storage. MinIO and filesystem storage are supported but not typically recommended for production.
- Retention: The compactor applies retention, and it is disabled by default, so logs are kept until you enable it.
- Authentication: Loki has no built-in authentication, so an authenticating reverse proxy must sit in front of it.
Grafana Cloud handles Loki's storage, retention and scaling for you, so the mode decision and the compactor settings become your responsibility only when you self-host. Confirm your daily log volume, the target deployment mode for your Loki version, and who owns object storage lifecycle policies.
Which features exist only in the cloud
Grafana Cloud bundles some capabilities that the self-hosted stack does not include in its open-source editions. Each one has a condition under which it matters, and each has a self-hosted substitute that someone has to design, buy or operate. Check these against your identity, upgrade and staffing requirements before choosing a path.
SAML single sign-on
SAML is available only in Grafana Enterprise and Grafana Cloud, according to Grafana's authentication docs. It matters when your identity provider issues SAML assertions and you cannot move the Grafana login to OAuth or OIDC. Self-hosted teams can use generic OAuth, Entra ID, Okta, GitHub, GitLab, Google OAuth, auth proxy or JWT instead, or buy Grafana Enterprise. Confirm which protocol your identity provider supports for each Grafana user group.
Team sync and group mapping
Team sync is listed as a feature of Grafana Enterprise and Grafana Cloud only. It keeps Grafana teams aligned with groups in your directory, so folder and dashboard permissions follow joins and departures without manual edits. Without it, a self-hosted team usually maps roles through the OAuth claims or the auth proxy headers, and a scheduled script or provisioning file keeps teams current. Ask who owns that mapping and how a removed user loses access.
Active sync and SCIM provisioning
Active sync and SCIM provisioning are Enterprise and Cloud features in the Grafana authentication docs. They push account creation, changes and deactivation from the identity provider into Grafana. This matters for audit trails of access removal and for leavers who must lose access on the same day. A self-hosted team typically relies on login-time group checks, a periodic reconciliation job, or a deprovisioning step in its identity governance tooling, and must test that disabled users cannot keep active sessions.
Managed upgrades and scaling
Grafana Cloud runs the platform, so the provider applies upgrades and scales the services. Self-hosted, you own the cadence: Grafana publishes major releases yearly, minor releases every other month and patch releases at least monthly, with each minor release supported for 9 months. Plan a staging environment, a rollback path and a time window for each upgrade, and budget engineer hours for each cycle. Confirm which Grafana version your Loki, Mimir or Prometheus pair supports before moving either one.
Hosted storage and backend operation
Grafana Cloud operates the long-term metrics, logs and traces storage for you. Self-hosted, you must size object storage, run the Mimir or Loki components at your chosen deployment mode, configure retention with the Loki compactor, and back up the Grafana database. Prometheus local storage is not clustered or replicated, so a single node failure loses recent data unless you add remote write to a second store. Ask your team who is on call for storage capacity alerts and restores.
Enterprise tier minimum commitment
Grafana's pricing page lists an Enterprise tier with a minimum commitment of 25,000 US dollars per year. Whether that tier matters depends on whether you need the cloud-only identity features above or Grafana Enterprise support. Self-hosted teams can avoid the commitment by staying on open-source editions and building their own identity and operations controls, which shifts cost to staff time and integration work. Ask Grafana for the current Enterprise terms and what the minimum covers before you compare it with an implementation scope.
What moving from Grafana Cloud to self-hosting involves
The sequence turns a hosted Grafana Cloud stack into a self-hosted Grafana, Prometheus or Mimir and Loki setup in which every dashboard, alert rule, data stream and user login is accounted for and verified before the cloud stack is retired.
Inventory data sources, dashboards and alert rules
Your team lists every data source, dashboard, folder, alert rule, contact point and log stream in the Grafana Cloud stack, and notes which collector (Grafana Alloy, Prometheus or another agent) sends each one. Platform engineering or the team that owns the stack does this work, and the output is a written inventory with an owner for each item. The step is done when every dashboard and rule has a named owner and a destination, and nothing is left unassigned.
Export dashboards, folders and alert rules
Because Grafana's migration assistant only moves content into Grafana Cloud, you export dashboards, folders and alert rules through the Grafana HTTP API and store the JSON in version control. Engineers with admin access to the cloud stack run the export and check that panel queries still reference the data source names you will use locally. The step is complete when each exported file loads without errors in a test instance and the export is stored under change control.
Stand up self-hosted Grafana with provisioning
Install self-hosted Grafana with a production database, either MySQL or PostgreSQL, rather than the default SQLite, and load data sources, dashboards and alerting resources through provisioning files so the setup can be rebuilt from code. Platform engineers handle installation, hardening and high availability, including the alerting configuration needed to avoid duplicate notifications when there are two or more active nodes. The step is done when a fresh deployment reproduces the exported dashboards and a test alert fires once.
Repoint metrics to Prometheus or Mimir
Change the Grafana Alloy or Prometheus remote write configuration so samples go to your own Prometheus or Mimir endpoint, and confirm that every scrape job and recording rule still produces the same series names and labels. Your monitoring engineers own this change, and Alertmanager receives alerts from the new Prometheus instance. The step is complete when the self-hosted backend shows current samples for each job and the labels match the cloud dashboards.
Move logs to Loki with object storage and retention
Deploy Loki in the mode that fits your daily log volume, store chunks and the index in object storage such as Amazon S3, Google Cloud Storage or Azure Blob Storage, and set retention explicitly, because it is disabled by default. Logging engineers repoint Alloy or other shippers and check tenant headers if auth is enabled. The step is done when log queries return the same results as the cloud stack for a known set of events and retention settings match your policy.
Run both stacks in parallel and cut over
Send telemetry to the Grafana Cloud stack and the self-hosted stack at the same time, then compare dashboard values, alert firing and query results for a period you agree in advance. Operations leads sign off each service when the self-hosted results match and the on-call team has tested alert routing. The step produces a signed cutover record for every data source, and the cloud stack stays in place until that record exists.
Migrate users and authentication
Recreate teams, folders and permissions in the self-hosted Grafana, then configure authentication through your identity provider. SAML, team sync, active sync and SCIM are available only in Grafana Enterprise and Grafana Cloud, so confirm with your identity team which of these features your organization depends on and which OAuth or LDAP options cover the rest. The step is complete when each user group signs in through the new instance and has the access it had in the cloud stack.
Retire the Grafana Cloud stack
Once the parallel run and user cutover are signed off, disconnect collectors from Grafana Cloud, archive the exported configuration and remove the cloud stack and its billing relationship after a final export. Confirm with your contracts or finance team which data retention and deletion obligations apply to the cloud stack. The step is done when no collector sends data to the cloud, the archive is stored under your retention policy and the account is closed in writing.
Questions buyers ask before choosing self-hosting
What does self-hosting Grafana, Prometheus and Loki actually cost in staff time?
Self-hosting moves cost from a vendor invoice to your payroll and infrastructure bills. The main recurring components are the people who run the stack, the servers or Kubernetes capacity, object storage for Loki and any long-term metrics store, and upgrades. Prometheus has no paid enterprise edition, so its software cost is zero, but the operating effort is real: Prometheus local storage is not clustered or replicated and should be managed like any other single-node database. Ask any implementation partner for a written scope that lists who operates each component, how backups and upgrades are handled, and which on-call hours are included, then compare that with your current Grafana Cloud usage and fees.
Who needs to be on staff to run a self-hosted Grafana stack?
Plan for owners of four areas: Prometheus and any remote storage, Loki and its object store, Grafana with its database and authentication, and the telemetry pipeline such as Grafana Alloy or OpenTelemetry Collectors. Grafana recommends MySQL or PostgreSQL for production and high availability, so someone must own those databases too. Engineers need working knowledge of PromQL, Kubernetes or your hosting platform, object storage, TLS and access control. Someone must also be on call for alerting, because Alertmanager and Grafana alerting each need deliberate configuration to avoid duplicate notifications in high availability setups.
How long does a migration from Grafana Cloud take, and what drives the timeline?
The timeline depends on how many dashboards, alert rules, data sources and users you have, how much telemetry you must keep, and whether you need parallel running. Grafana's migration assistant only moves data into the cloud, so leaving requires manual export of dashboards, folders and alert rules through the HTTP API, repointing Alloy or Prometheus remote write, and moving logs into Loki. Retention decisions matter too: Loki retention is disabled by default, so you must set it deliberately. Ask for a fixed-scope plan with a parallel-run period and a cutover checklist before agreeing to a date.
Can our own team run the migration without outside help?
A team with Kubernetes or Linux operations experience and one or two engineers who know PromQL and Loki can often run a small stack alone, especially when deployment is limited to a single monolithic Loki instance. Outside help is most useful for the first deployment, high availability design, object storage setup, authentication and the cutover. Grafana's own guidance sets a small deployment at under 25 concurrent users on 2 cores and 2 to 4 GB of RAM, which is a starting point only. DeployOpen plans, implements, hardens, backs up and documents self-hosted platforms in your environment, and ongoing support is available as a retainer if your team wants help after handover.
Which Grafana Cloud features are hard to replace in a self-hosted setup?
Grafana documents that SAML, team sync, active sync and SCIM provisioning are available only in Grafana Enterprise and Grafana Cloud, so self-hosted Grafana OSS needs another route for those needs. Many teams cover single sign-on through generic OAuth, Entra ID, Okta or LDAP, which all editions support, and cover team mapping through identity provider groups where supported. Grafana Enterprise is a commercial option that adds some of these features. Ask your vendor or partner to confirm which exact features your organization depends on, and check the Grafana authentication documentation before assuming a replacement exists. Managed Mimir or Loki operations and hosted uptime are also what you take on yourself.
Does the AGPL license restrict internal use of Grafana, Loki or Mimir?
Grafana, Loki and Mimir are licensed under AGPLv3, and that license governs distribution and network-facing modifications. Grafana Labs relicensed Grafana, Loki and Tempo from Apache License 2.0 to AGPLv3 on April 20, 2021, and offers Grafana Enterprise as a non-AGPL commercial option. Running unmodified software internally for your own staff is generally treated differently from offering a modified version to outside users, but the answer depends on how you use and change the code. Have your legal or compliance team review your specific use, and confirm any modifications, plugins or bundled agents, since plugins, SDKs and agent software carry other licenses.
What skills and infrastructure does the stack need for security and access control?
You need to secure several layers. Grafana's security hardening guidance covers secure and SameSite cookies, a Content Security Policy, hiding the version from unauthenticated users, authenticating the metrics endpoint and domain verification against DNS rebinding. Loki has no built-in authentication layer, so you must place an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium in front of it, and enable multi-tenancy with the X-Scope-OrgID header if teams share a cluster. Prometheus is not designed for untrusted access, so restrict who can reach it. Assign an owner for these controls before go-live and document how they are tested.
How DeployOpen helps teams decide and move
DeployOpen helps teams make this decision on the basis of their own telemetry, not a generic comparison. We start by inventorying what is actually running: which Grafana Cloud data sources, dashboards and alert rules are in use, how many active series and log streams are written each month, and which teams depend on the Grafana Cloud identity model. We then map that inventory onto the self-hosted components that would replace each part: Prometheus or Mimir for metrics, Loki for logs, Grafana with its supported database for dashboards, and an authenticating reverse proxy in front of Loki, since Loki has no built-in authentication layer. The output is a written scope with the decisions the client must make, such as whether Grafana Enterprise is needed for SAML and SCIM, and what retention each data type requires.
Migration is usually easier when the telemetry pipeline is decoupled first. DeployOpen typically helps teams point Grafana Alloy or Prometheus remote write at a self-hosted target in parallel with the existing cloud feed, so both receive the same samples for a comparison window. During that window, we check dashboard queries against both backends, confirm alert rules fire once rather than twice (Grafana's high availability docs note that alerting needs extra configuration to avoid duplicate notifications), and export dashboards and folders through the HTTP API with provisioning files kept in Git. Confirm with your own team the expected query load, the upgrade cadence you can sustain, and who answers the pager when a Prometheus instance fails, because a single Prometheus server is not clustered or replicated.
How DeployOpen helps you evaluate, implement or migrate
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For the Grafana Cloud decision, we help you define what should stay hosted, what should run in your environment and what staffing that choice requires.
How we scope
- Start with a written inventory of your Grafana, Prometheus, Loki and Grafana Cloud usage, including data sources, dashboards and alert rules.
- Agree the scope, deliverables and timeline in writing before work starts, since most engagements are fixed-scope.
- Confirm the features your teams rely on that are cloud or Enterprise only, such as SAML and SCIM, so gaps are known before design.
How we build
- Design the target topology, including Grafana high availability on MySQL or PostgreSQL and the Loki deployment mode that fits your daily log volume.
- Set up Prometheus and Mimir or Loki on your cloud accounts, data centers or air-gapped networks, with object storage and retention configured.
- Configure authentication, reverse proxies in front of Loki, and hardening settings, and test the stack with your own workloads.
How we hand over
- Provide provisioning files and as-code definitions for data sources, dashboards and alerting so the setup can be rebuilt from version control.
- Deliver runbooks for upgrades, backups, retention changes and on-call escalation, written for your own operations staff.
- Document the cost components and staffing model so your team can compare the running cost with a Grafana Cloud quote.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover, if your team wants external capacity.
- Plan upgrades around Grafana and Prometheus release cycles and the support windows published for each release line.
- Ask us to prepare controls and evidence for compliance assessments, while independent auditors issue any audit reports or certifications.
