Should you run Grafana yourself or use Grafana Cloud?
Run Grafana yourself if your telemetry must stay inside infrastructure you control, and your platform team can operate the stores behind it. Use Grafana Cloud if you would rather pay Grafana Labs to run the stores and accept its usage pricing. The split is less about the Grafana front end, which installs from packages, Docker images or Helm charts on either path, and more about who runs the metrics, logs and traces backends. Self-hosting means you own Prometheus or another metrics store, Loki with its object storage, the database behind Grafana (MySQL 8.0 or later or PostgreSQL 12 or later for production and high availability), backups, upgrades and on-call. Grafana Cloud moves that work to Grafana Labs, which matters most when the team is small, the telemetry volume is modest, or no one wants to carry a storage tier at 3 a.m.
Data residency is the first gate. Grafana Cloud Enterprise offers deployment on Public Cloud, Federal Cloud or Bring Your Own Cloud, but it starts at a 25,000 US dollar per year spend commit, according to the Grafana pricing page, so the bring-your-own-cloud option is a fit for larger buyers with a residency requirement they cannot meet on Pro. Grafana Cloud's free tier, capped at 10k active metric series per month, 50 GB each of logs, traces and profiles per month and 14 days retention, is a reasonable place to evaluate with a small estate, but it will not hold regulated audit data for the retention periods most compliance programs expect. Confirm the exact retention and region terms with Grafana Labs before you commit telemetry to any hosted tier. Self-hosting also needs a sizing decision: Grafana's installation docs size small deployments under 25 concurrent users at 2 cores and 2 to 4 GB of RAM, and the stores behind it grow with series count and log volume, not with the number of dashboards.
Tolerance for operating the backends decides the rest. If your Kubernetes or VM estate already runs Prometheus with a Prometheus-compatible long-term store and a Loki deployment, the marginal cost of self-hosting Grafana is mostly the database, load balancing and authentication work. Note that Loki has no built-in authentication and needs an authenticating reverse proxy in front of it, and that Grafana's SAML, team sync and SCIM provisioning are available only in Enterprise and Grafana Cloud, so identity design differs by model. Before you decide, ask your team to estimate how many hours a month they can give to upgrades, retention tuning and incident response, and ask Grafana Labs for a written Pro usage estimate based on your actual series and log volumes, since Pro charges per usage unit and cost moves with telemetry growth.
How self-hosted Grafana and Grafana Cloud compare on the factors that decide the choice
This table compares where Grafana and its telemetry stores run, what each deployment model costs and includes, and how identity, high availability and as-code options differ. Read each row against your data location rules and team size, since the Grafana Cloud rows depend on usage that you must estimate for your own environment.
| Factor | Self-hosted Grafana | Grafana Cloud |
|---|---|---|
| Control and data location | You choose the host, network and storage, so telemetry stays in your own infrastructure | Telemetry is stored in Grafana Labs' hosted service; Enterprise adds Public Cloud, Federal Cloud or Bring Your Own Cloud deployment |
| Licensing and editions | AGPLv3 Grafana OSS at no license fee; Grafana Enterprise is a separate commercial license from Grafana Labs | Hosted subscription with free, Pro and Enterprise tiers, per the Grafana pricing page |
| SAML, team sync and SCIM | SAML, team sync, active sync and SCIM require Grafana Enterprise, per the Grafana authentication docs | SAML, team sync, active sync and SCIM are included, per the Grafana authentication docs |
| Configuration store | SQLite 3 by default; MySQL 8.0 or later or PostgreSQL 12 or later needed for production and HA, per the Grafana installation docs | Managed by Grafana Labs; you do not select or operate the configuration database |
| High availability | Two or more active-active servers behind a load balancer on a shared database; alerting needs extra setup to avoid duplicate notifications, per the Grafana HA docs | Availability of the hosted service is Grafana Labs' responsibility; confirm its availability terms in the contract |
| Free tier caps and retention | Not applicable; limits come from your hardware, storage and retention settings | 10k active metric series per month, 50 GB each for logs, traces and profiles per month, 14 days retention, 3 active Grafana Visualization users, per the Grafana pricing page |
| Pro usage pricing | Your own compute, storage and staff time; no Grafana Labs usage fee | 19 US dollar monthly platform fee plus metrics from 6.50 US dollars per 1k series (13 months retention) and Grafana Visualization from 8 US dollars per active user, per the Grafana pricing page |
| Enterprise minimum | Grafana Enterprise license priced separately from the open-source build; confirm terms with Grafana Labs | 25,000 US dollar per year spend commit with custom retention and premium support, per the Grafana pricing page |
| Provisioning and as-code | YAML or JSON provisioning files loaded at startup; Terraform and Git Sync documented as further options, per the Grafana provisioning docs | Supports the same provisioning concepts; confirm which as-code paths your tier exposes before relying on them |
Where your data sits and what compliance means in each model
Running Grafana yourself keeps dashboards, configuration and telemetry inside infrastructure you control, while Grafana Cloud moves storage and administration to Grafana Labs. The cards below cover the questions a compliance lead should answer before choosing, and the points that need written confirmation from Grafana Labs or your assessor.
Where telemetry is stored
In Grafana Cloud, metrics, logs, traces and profiles are stored in Grafana Labs' hosted environment, and the region and hosting provider are choices you must confirm for your account. Self-hosted Grafana writes to whichever metrics, logs and trace stores you build, so residency follows your own data center, cloud account or air-gapped network. Ask Grafana Labs in writing which regions are available to your tier before you commit.
Who holds administrative access
In a self-hosted deployment, your team holds root access to the Grafana servers, the database behind them and the storage buckets, so access reviews and break-glass procedures are yours to write. In Grafana Cloud, the provider operates the platform and you administer only the stack, users and data sources. Document which party can reach logs and metrics at the infrastructure layer before an assessor asks.
Enterprise Cloud deployment options
Grafana Cloud Enterprise, which starts at a 25,000 US dollar per year spend commit, offers deployment on Public Cloud, Federal Cloud or Bring Your Own Cloud. Bring Your Own Cloud keeps data in an account you own, which can narrow the residency question, but it still needs written terms on operations and support. Confirm with Grafana Labs which deployment options are offered for your jurisdiction and whether they hold the attestations your framework requires.
Secure cookies and SameSite settings
The Grafana security hardening guidance recommends secure and SameSite cookies, which you configure yourself when Grafana runs on your servers. Session protection depends on the reverse proxy, TLS termination and cookie settings you choose, and none of this is visible to you in Grafana Cloud. Include the cookie configuration in your hardening baseline and test it during your security assessment.
Content Security Policy and Trusted Types
Grafana's hardening guidance recommends a Content Security Policy and Trusted Types, which reduce the impact of injected script in the browser. Self-hosting means you set and test these headers against your own plugins and dashboards, and you own the regression testing after each upgrade. Confirm with Grafana Labs how the hosted service applies equivalent browser protections so you can compare the two models fairly.
Authentication on the metrics endpoint
The hardening guidance recommends requiring authentication for the metrics endpoint and hiding the Grafana version from unauthenticated users. Self-hosted operators must check that scraping endpoints are not reachable from untrusted networks and that version information is not exposed. These checks belong in your evidence pack, because an assessor will expect proof that the configuration was tested, not only documented.
What Grafana Cloud usage pricing and self-hosting costs each include
Grafana Cloud Pro bills in two layers. The 19 US dollar monthly platform fee includes a usage allowance and 8x5 email support, and everything above that allowance is metered: metrics from 6.50 US dollars per 1k active series at 13 months retention, logs, traces and profiles at 0.050 US dollars per GB for processing, 0.400 per GB for write and 0.100 per GB for retention with 30 days retention, and Grafana Visualization from 8 US dollars per active user, according to the Grafana pricing page. The meters that move your bill are active series, GB ingested, retention length and active viewers. A new label such as a pod name on every metric multiplies series count, and a verbose log pipeline multiplies GB written. Ask the vendor to model your current series count, daily log volume and named-user count against each meter, and to state which of these are billed monthly versus at a committed rate.
Self-hosting moves those meters onto your own infrastructure, where the bill is mostly people and capacity. Budget for compute and disk for Grafana, the metrics store (for example Prometheus, with its local storage that is not clustered or replicated), a log store and a database for Grafana configuration. Recurring costs include storage growth, backups, Grafana patch releases (published at least monthly), minor upgrades and the on-call time needed to keep alerting working. Many of these are one-time costs at build (architecture, provisioning as code, authentication setup) followed by recurring operations. For a written quote from any implementation partner, request an itemized list covering the one-time build, each recurring operations task, the storage and retention assumptions, the support hours and who carries the on-call duty. Confirm that any hardware or cloud quote is priced for your retention target, not only for today's volume.
What your team runs in each hosting model
The Grafana server holds dashboards, data source definitions, users and alert rules. Self-hosted, your team installs it from packages or the Docker image or Helm chart, and chooses a database for configuration. SQLite is the default, but the installation docs say it does not scale for production, so high availability needs MySQL 8.0 or later or PostgreSQL 12 or later. High availability means two or more active-active Grafana servers behind a load balancer sharing that database, with database-backed auth tokens so users can reach any node. Under Grafana Cloud, Grafana Labs runs the server, its database and upgrades. Your team still owns users, folders, provisioning files and alert routing inside the tenant.
- Database choice: You select, back up and patch MySQL or PostgreSQL yourself when self-hosted.
- Load balancing: You own the load balancer and session behavior; Grafana Live has documented limitations in high availability.
- Alert duplication: The HA docs say alerting needs extra configuration to avoid duplicate notifications.
- Hardening: Cookies, Content Security Policy, Trusted Types and metrics endpoint authentication are settings you apply.
- Upgrades: Grafana documents major releases once a year, minor releases every other month and patch releases at least monthly, each minor supported for 9 months.
Check the upgrade calendar and your patch window before committing, and confirm which HA behaviors your alerting setup depends on.
Prometheus scrapes targets over HTTP, stores samples in a local time series database and evaluates alert rules. Its storage docs state that local storage is not clustered or replicated and should be managed like any other single-node database. Under self-hosting, your team decides how to run replicas, how long to keep data (15 days by default, configurable by time or size), and whether to add remote write to long-term storage. Alertmanager handles grouping, inhibition and silences and can run as a cluster for high availability. Prometheus should point at every Alertmanager instance, not a load balancer. Grafana Cloud hosts the metrics store and its retention is a plan setting, not a server you tune.
- Single-node storage: Replication, failover and disk capacity are your design work when self-hosted.
- Retention: The default is 15 days; longer history requires disk sizing or remote storage.
- Alertmanager cluster: Use the cluster flags and list every instance in Prometheus configuration.
- Release cadence: A new minor release cycle starts every 6 weeks, and minor releases generally stop receiving fixes after that window.
- LTS line: Prometheus LTS releases get bug fixes for one year; the current LTS line is 3.13, supported until July 31, 2027.
Confirm which Prometheus line you will standardize on and who applies its minor upgrades.
Loki indexes labels only and keeps compressed log chunks and its index in object storage. Self-hosted, your team picks a deployment mode: monolithic for up to about 20 GB of logs per day, simple scalable, or microservices for very large clusters. Simple scalable mode is deprecated and will be removed in Loki 4.0, so a new design should plan for a different mode. The compactor applies retention, which is disabled by default, so logs persist until you enable it. Loki has no built-in authentication, so you must place an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium in front of it. Grafana Cloud runs the write, read and storage path and bills by GB processed, written and retained.
- Object storage: Amazon S3, Google Cloud Storage and Azure Blob Storage are the recommended production stores; MinIO and local filesystems are not typically recommended for production.
- Compactor: Retention settings, including per-stream rules of at least 24 hours, are configured and checked by your team.
- Tenancy: Multi-tenant mode depends on auth_enabled and the X-Scope-OrgID header on each request.
- Authentication proxy: The proxy, its certificates and its access rules are your responsibility under self-hosting.
- Shipping: Grafana Alloy is Grafana's supported shipper, with Fluent Bit, Fluentd and OpenTelemetry also supported.
Confirm the expected daily log volume, the deployment mode it implies, and whether the Loki version you choose will still have a supported path.
Upgrade effort is where the two models differ most in day-to-day work. Grafana publishes a predictable cadence, with patch releases at least monthly and each minor release supported for 9 months, the last minor of a major version for 15 months. Under Grafana Cloud, Grafana Labs applies these upgrades to the hosted service on its schedule. Under self-hosting, your team tests each Grafana, Loki and Prometheus release against your dashboards, plugins, provisioning and alert rules, then schedules the rollout across the database, load balancer and object storage. Separate component cycles mean three calendars, not one. The supplied release dates show the rhythm: Grafana 13.2.0 shipped on August 18, 2026 and patch releases followed on October 13, 2026.
- Grafana cadence: Major releases arrive once a year in April or May, minors every other month.
- Support windows: Minor releases are supported for 9 months; the final minor of a major gets 15.
- Loki changes: Breaking mode removals, such as simple scalable mode in Loki 4.0, need planning ahead of time.
- Prometheus cycle: Six-week minor cycles and a one-year LTS window set a separate calendar.
- Testing: Self-hosted teams need a staging environment to validate each upgrade before production.
Before you commit, ask Grafana Labs which hosted upgrade notice you receive and map your internal change window against each component's support end date.
Moving between self-hosted Grafana and Grafana Cloud
The sequence moves dashboards, data sources, agents and alert routing from one Grafana to the other, and ends with a documented record of what was moved, what was left behind and what still needs confirming.
Inventory dashboards, data sources and alert rules
The team that owns Grafana lists every dashboard, data source, plugin, folder, contact point and alert rule in the source instance, and marks which ones are actively used. Export the inventory from the source, not from memory, and record which items were created by hand in the UI versus by provisioning files or Terraform. Those hand-built items are the ones most likely to be lost in a move. The step is done when the inventory is reviewed by the people who receive the alerts and the dashboard owners have confirmed which items stay.
Export configuration as code
Convert the inventory into provisioning YAML or JSON files for data sources, dashboards and alerting resources, or into Terraform definitions if the team already manages Grafana that way. Grafana's provisioning model loads these files at startup, and Git Sync is another documented option for keeping dashboards in a repository. Moving from self-hosted to Grafana Cloud, or back, is easier when the definitions live in Git, so the platform engineer should commit them before any import. The step closes when a fresh test instance built only from the repository reproduces the dashboards and data sources without manual edits.
Reconcile data source endpoints and credentials
Each data source definition points at an endpoint, and those endpoints differ between a self-hosted Prometheus, Loki or Tempo and their Grafana Cloud equivalents. The platform engineer maps every old URL to its new one, moves credentials into a secrets store rather than leaving them in plain provisioning files, and confirms that query permissions match the access model of the target edition. Authentication methods also differ: SAML, team sync, active sync and SCIM are available only in Grafana Enterprise and Grafana Cloud, so confirm which identity features the target tier actually provides. The step is complete when each data source returns expected results from a test query on the target.
Re-point collection agents and shippers
Agents and shippers still send data to the old stack until they are re-pointed. Grafana Alloy is Grafana's supported log shipper for Loki, and it can be reconfigured to write to a new endpoint with new credentials, which is usually the only change needed for the collection path. Teams running Prometheus should also re-point remote write, and any Fluent Bit, Fluentd or OpenTelemetry Collector pipelines need the same update. Run old and new pipelines in parallel for a short window agreed with the operations team, then stop the old path. The step is done when every source shows data arriving at the new destination and the old endpoint shows no new writes.
Plan for retention differences
Retention is the most visible difference between the two sides. The Grafana Cloud free tier keeps data for 14 days, and Grafana Cloud Pro logs, traces and profiles are listed with 30 days of retention. Self-hosted Loki keeps logs indefinitely until retention is enabled in the compactor, and Prometheus defaults to 15 days of local storage. Before cutover, the team should write down the retention each data type needs for dashboards, audits and incident reviews, then compare that with the target tier. Any gap is a decision for the data owner, and it should be recorded before the old store is switched off. Confirm the current retention options with Grafana Labs, since plan terms change.
Confirm the migration path for historical data
Moving dashboards and configuration is generally a matter of definitions, but moving historical metrics and logs is a separate question that depends on the specific stores in use. The team should ask the platform vendor, and check its own storage layout, whether historical samples or log chunks can be exported and imported, in what format, and at what volume. If history cannot move, the usual choice is to keep the old store read-only for the retention window and query it from Grafana until it expires. Record the answer for each store separately. This step is done when the team has a written statement for each store saying whether history migrates, is retained in place or is discarded.
Cut over alerting without duplicate notifications
Alert rules and notification routes must move without firing twice. Disable notifications on the old instance or pause the duplicated rules before enabling the same rules on the new one, and confirm that contact points and notification policies on the target send to the intended recipients. The Grafana high availability documentation notes that alerting needs extra configuration to avoid duplicate notifications in multi-node setups, so check that guidance for the chosen deployment. Run a controlled test alert, confirm one notification per recipient, and only then retire the old rules. The step is complete when the on-call team confirms the test was received once.
Validate, document and retire the old stack
Run a checklist against the inventory from the first step, covering dashboards, data sources, agents, retention decisions, historical data statements and alert routes. Each item should have a named owner and a result. Keep the provisioning repository as the single source of truth afterward, and record the date of cutover, the versions involved and the rollback plan. Only after the checklist and a defined observation period is the old instance decommissioned, and its credentials and data stores are removed according to the retention decisions made earlier. The step is done when the signed checklist and the decommissioning record are stored with the runbook.
How the parts connect in a self-hosted Grafana stack
A self-hosted Grafana stack has four trust boundaries, and each one is a place where your team, not a vendor, decides who can read or write data. The data path starts at the agents on your hosts and Kubernetes nodes. Alloy or another collector scrapes or receives metrics and logs and writes them to Prometheus for metrics and to Loki for logs. Prometheus keeps its own local time series storage, which the Prometheus storage docs say is not clustered or replicated, so it needs to be run and backed up like any other single-node database. Loki has no built-in authentication layer, so the write and query endpoints must sit behind an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium, with tenants separated by the X-Scope-OrgID header when auth_enabled is true. Every boundary you add is one more component you patch and monitor.
Grafana sits at the top of this path and holds the most sensitive state: its configuration database and its data source credentials. The installation docs say SQLite does not scale for production, so plan for MySQL 8.0 or later or PostgreSQL 12 or later from the start. High availability uses two or more active-active Grafana servers behind a load balancer sharing that database, with database-backed auth tokens so a user can land on any node. Authentication is the second boundary. LDAP, generic OAuth, Entra ID, Okta, GitHub, GitLab, Google OAuth, auth proxy and JWT are available in every edition, while SAML, team sync, active sync and SCIM are limited to Enterprise and Grafana Cloud, which is a decision to settle before you design the login path. Confirm with your identity team which of these your directory and SSO setup needs. The load balancer and the proxy in front of Loki are where TLS, the secure and SameSite cookie settings, and the Content Security Policy recommended in the security hardening docs are enforced.
Alerting crosses the same boundaries and is the part teams most often misconfigure. Alertmanager should be pointed at every instance rather than through a load balancer, and the Grafana HA docs warn that alerting needs extra configuration to avoid duplicate notifications. Before go-live, test each path end to end: a metric that stops arriving, a log line that reaches only the intended tenant, a failed Grafana node that users recover from without re-login, and a restored database backup. Record the owner of each boundary, including who patches the proxy, the database and the collectors. In a managed Grafana Cloud setup, the provider runs the stores and most of the path, so these ownership questions shift to your team's agreements with the vendor rather than disappearing.
Questions buyers ask before choosing a hosting model
What does self-hosting Grafana cost in staff and infrastructure?
Self-hosting moves the bill from a usage invoice to your own payroll and hosting spend. The software itself is free under AGPLv3 for the OSS build, so the recurring cost is the people who patch, back up, scale and secure the stack, plus the compute and storage it runs on. Grafana's installation docs size a small deployment under 25 concurrent users at 2 cores and 2 to 4 GB of RAM, but the metrics, logs and traces stores behind it are the real drivers. Prometheus storage is local and not clustered, and Loki needs object storage. Ask your team to cost on-call time, upgrade cycles (Grafana publishes patch releases at least monthly), and storage growth from retention settings. Compare that total against Grafana Cloud Pro pricing, which you can read on the Grafana pricing page.
How long does migrating to self-hosted Grafana take?
No supplied fact gives a migration duration, so treat any timeline as something to agree in writing rather than assume. The work depends on how many dashboards, data sources, alert rules and users you have, and whether you move the metrics, logs and traces stores along with Grafana. Grafana supports provisioning of data sources, dashboards and alerting resources from YAML or JSON files, and it documents Terraform and Git Sync as further as-code options, which can make a rebuild repeatable. Your team needs access to the Grafana configuration database (SQLite by default, MySQL 8.0 or later, or PostgreSQL 12 or later for production), identity provider settings and the destination stores. Ask for the scope and deliverables in writing before work starts.
Can a platform team run self-hosted Grafana alone?
A small team can run a single Grafana instance, but production and high availability need more than that. Grafana's docs say SQLite does not scale for production, so MySQL or PostgreSQL is required for high availability, with two or more active-active servers behind a load balancer. Alerting needs extra configuration to avoid duplicate notifications, and Grafana Live has limitations in HA. The harder part is the stores behind it: Prometheus is single-node for local storage, Loki has no built-in authentication and needs an authenticating reverse proxy in front of it, and Loki's simple scalable mode is being removed in Loki 4.0. Count the skills you need in observability, databases, object storage, identity and security hardening, and confirm whether your team can cover them with on-call coverage.
When does the Grafana Cloud free tier stop being enough?
The free tier stops being enough when you exceed its caps or need longer retention. Per the Grafana pricing page, the free tier includes 10k active metric series per month, 50 GB each of logs, traces and profiles ingested per month, 14 days retention and 3 active Grafana Visualization users per month. Crossing any of these moves you toward Pro, which starts with a 19 US dollar monthly platform fee plus usage, with metrics from 6.50 US dollars per 1k series at 13 months retention. Watch active series count, because cardinality from labels grows quickly, and confirm with Grafana Labs how usage is measured before you commit. Teams that need SAML or team sync should also check the authentication docs, which list those features as Enterprise and Grafana Cloud features.
When does the 25,000 US dollar Grafana Enterprise commit make sense?
The Enterprise commit makes sense when you need its contractual or hosting terms more than the lower-cost options. Grafana Cloud Enterprise starts at a 25,000 US dollar per year spend commit and offers custom retention, premium support and deployment on Public Cloud, Federal Cloud or Bring Your Own Cloud, according to the Grafana pricing page. For self-managed deployments, the Grafana Enterprise docs describe a paid license, and features such as SAML, team sync, data source permissions and auditing are part of that edition. Many of those identity features are also available in paid Grafana Cloud accounts, so compare the two before assuming a self-managed license is needed. Ask Grafana Labs which features and support levels are included at each tier.
Does Grafana Cloud keep data in our own cloud account?
Only on the Enterprise tier, and only through the Bring Your Own Cloud option. The Grafana pricing page lists deployment on Public Cloud, Federal Cloud or Bring Your Own Cloud under the Enterprise tier, so the standard Pro and free tiers should be treated as Grafana Labs-hosted. If data residency, network placement or key control is a requirement, ask Grafana Labs in writing which regions, cloud accounts and retention controls apply, and whether logs, traces and profiles can stay inside your boundary. Self-hosting keeps all of that inside your infrastructure by design, which is the main reason regulated teams choose it.
What does a fixed-scope DeployOpen engagement cover for Grafana?
A DeployOpen engagement covers the self-hosted platform work you agree in writing before it starts. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, including your cloud accounts, data centers or air-gapped networks. For Grafana, that can include the database backend, high availability layout, provisioning, identity integration, and hardening guidance such as the security settings Grafana documents. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications. Scope, deliverables and timelines are set in a written scope, and a quote follows from that scope. Ongoing support and upgrades are available as retainers.
How do I compare Grafana Cloud and self-hosted costs fairly?
Compare the full lifetime cost of each model, not only the licence line. For Grafana Cloud, the costs are the platform fee, usage for series, logs, traces and profiles, retention and active users, all listed on the Grafana pricing page. For self-hosting, the costs are infrastructure for Grafana, metrics and log stores, object storage, backups, and the staff time to operate, upgrade and secure them. Both sides have recurring costs, and the cost of moving later matters too. Ask each vendor or partner for a written breakdown tied to your series count, log volume, retention and user count, and model those numbers with your own telemetry before deciding.
How DeployOpen scopes, delivers and supports self-hosted Grafana
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For Grafana, that means the dashboards and the metrics, logs and traces stores behind them run in your cloud account, data center or air-gapped network, with the choice made against your own requirements.
How we scope
- Scope starts with which telemetry stores you would run yourself and which you would keep hosted.
- Written scope lists the Grafana edition, authentication integrations, data sources, retention targets and hosting environment.
- Most engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- Grafana is deployed with MySQL or PostgreSQL for configuration, never SQLite, when high availability is in scope.
- Data sources, dashboards and alerting resources are defined as code using provisioning files.
- Hardening follows the Grafana security guidance, with cookie, content policy and metrics endpoint settings tested before handover.
How we hand over
- Handover documents the deployed topology, backup and restore steps, upgrade path and retention settings.
- Access controls, identity provider configuration and the reverse proxy in front of Loki are documented and tested.
- Your team receives runbooks for alert routing, Alertmanager clustering and the storage components you chose to run.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover Grafana minor and patch releases, which Grafana publishes on a regular cadence, and related store upgrades.
- Ask any provider to confirm in writing which versions, response windows and environments a support agreement covers.
