When is Grafana OSS enough, and when does Grafana Enterprise pay off?
If you run a self-hosted Grafana for one team, with dashboards, alerts and a handful of data sources, the AGPL open source build is usually enough. It includes dashboards, alerting, provisioning of data sources and dashboards from YAML or JSON files, and the same core query experience as Enterprise. Authentication is the first place to check: all editions support LDAP, generic OAuth, Entra ID, Okta, GitHub, GitLab and Google OAuth, auth proxy and JWT, so a team that already signs in through one of those providers can stay on OSS. The Grafana authentication docs (grafana.com) list SAML, team sync, active sync and SCIM provisioning as Enterprise and Grafana Cloud features only, so confirm which of these your identity provider requires before you assume OSS covers it.
Enterprise becomes worth evaluating when specific requirements appear in your change or audit backlog. The main ones are SAML single sign-on, team sync with your identity provider, data source permissions, auditing, scheduled PDF reporting by email, Vault integration for secrets, and the premium data source plugins such as Splunk, ServiceNow, Datadog and Oracle Database. Enterprise is a commercial license, not a free upgrade. The Grafana pricing page lists self-hosted use of Grafana Visualization with Enterprise Plugins with a 25,000 US dollar minimum annual commit, and it does not publish a separate self-managed Enterprise price, so ask Grafana Labs sales for a written quote that states the commit, the term and what support is included. Enterprise also includes 24x7x365 support and training from the core Grafana team, which matters only if your team needs a contractual response path.
Before you decide, test the requirement rather than the feature list. Write down which users, teams and data sources must be restricted, which reports must go out on a schedule, and which plugins your alerts depend on. If OSS can meet each item with provisioning, folder permissions and an external reporting job, stay on OSS and re-check at each major release. If the list is short but one item is non-negotiable, such as SAML for an audited sign-in path, the license may still be cheaper than building and maintaining a workaround. Also note that a production deployment needs MySQL 8.0 or later or PostgreSQL 12 or later for configuration, not SQLite, under either edition, so the database and high availability work is a cost you carry regardless of the license choice.
Which features sit in OSS and which sit in Enterprise
This table lists the Grafana capabilities that the docs place in Enterprise alongside the features both editions share. Read each row against your identity, reporting and data source needs, and treat any OSS cell marked for confirmation as a question for the Grafana documentation for your version. The main takeaway is that the OSS build covers core authentication and dashboards, while SAML, team sync, reporting, Vault integration and auditing sit in Enterprise.
| Capability | Grafana OSS (AGPL) | Grafana Enterprise (self-managed) |
|---|---|---|
| Core authentication (LDAP, generic OAuth, Entra ID, Okta, GitHub, GitLab, Google OAuth, auth proxy, JWT) | Yes | Yes |
| SAML single sign-on, team sync, active LDAP sync, SCIM provisioning | No | Yes |
| Data source permissions and query or resource caching | Not listed as OSS; confirm for your version | Enterprise feature per Grafana docs |
| Scheduled PDF reporting by email and dashboard PDF export | Not listed as OSS; confirm for your version | Enterprise feature per Grafana docs |
| Custom branding, usage insights and recorded queries | Not listed as OSS; confirm for your version | Enterprise feature per Grafana docs |
| Vault integration for secrets and auditing | Not listed as OSS; confirm for your version | Enterprise feature per Grafana docs |
| Request security and runtime settings updates | Hardening guidance is published; confirm which controls are Enterprise-only | Enterprise feature per Grafana docs |
| Premium data source plugins | Premium plugins not included | Splunk, ServiceNow, Datadog, Oracle Database, Snowflake, MongoDB, Jira, New Relic |
| Availability in paid Grafana Cloud | Not applicable to the self-managed OSS build | Many features also in paid Grafana Cloud accounts |
How licensing, support and updates differ between editions
The two editions differ in what you license, who supports you and how often you must upgrade. Grafana OSS carries an open license and a community release rhythm, while Enterprise adds a commercial agreement, vendor support and exclusive plugins. Read each card against your own compliance, support and upgrade obligations.
AGPLv3 license for core Grafana
Since the April 20, 2021 relicense, Grafana, Loki and Tempo are licensed under AGPLv3, and Grafana Enterprise is offered as a separate non-AGPL commercial option. Using the open build internally carries the AGPL's obligations for modified versions that users interact with over a network. Ask your legal team whether any internal modifications or embedded deployments trigger source disclosure, and whether a commercial license matters for your distribution model.
Plugins and SDKs keep other licenses
The April 2021 relicense covered Grafana itself, but plugins, SDKs and agent software kept their own licenses. A dashboard stack can therefore mix AGPLv3 core code with plugins under different terms. Inventory every plugin you install, record its license and confirm it matches your policy before rolling it out to production or redistributing the stack.
Enterprise support from the core team
Grafana Enterprise is documented with 24x7x365 support and training delivered by the core Grafana team. This matters most when an outage on a monitoring stack blocks incident response and your internal staff cannot diagnose the fault alone. Confirm the severity levels, response commitments and named contacts in your written order, because the documentation describes the support coverage but not the response times.
Open source release cadence
Grafana OSS ships major releases once a year, in April or May, minor releases 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. Plan an upgrade window at least once a year, and schedule patch rollouts monthly so you stay inside the supported range.
Enterprise purchase through sales
Grafana Enterprise is bought or trialed by contacting the Grafana Labs sales team, so there is no self-serve checkout for the self-managed edition. The public pricing page lists a 25,000 US dollar minimum annual commit for self-hosted use of Enterprise plugins. Ask for a written quote that covers the license term, the plugins included, support scope, renewal terms and whether a trial is available before you commit.
What the free build needs to run in production
The first decision for the free build is the configuration database. Grafana stores its configuration in SQLite 3 by default, but the installation docs state that SQLite does not scale for production. For any production or high availability deployment, you need MySQL 8.0 or later or PostgreSQL 12 or later, and that database becomes a component your team must back up, patch and restore. Confirm which database engine your platform team already operates, who owns its backups, and how it will be reached from each Grafana node before you commit to the OSS build.
High availability in the free build follows an active-active pattern: two or more Grafana servers sit behind a load balancer and share the MySQL or PostgreSQL database. Database-backed auth tokens let a user land on any node, which removes the need for sticky sessions. Two limits need planning rather than discovery in production. The docs say alerting needs additional configuration to avoid duplicate notifications from multiple nodes, and Grafana Live has limitations in HA. Test alert routing and live dashboard updates under a node failure before you rely on them, and write down which features your users will accept running in a degraded mode.
Provisioning is where the free build is strongest for teams that want configuration under version control. Data sources, dashboards, plugins and alerting resources can be defined in YAML or JSON files loaded at startup. The provisioning docs also point to further as-code options, including Terraform and Git Sync. These tools are part of the open-source workflow and do not require Grafana Enterprise, but the pipeline that applies them, the secrets they reference and the review process around them are your responsibility. Confirm whether your team will manage provisioning files through Git, Terraform or both, and who approves changes to production alerting rules.
Which edition fits which team situation
A small platform or operations team that logs in with local accounts, LDAP, GitHub or Google OAuth, and has no external audit on its roadmap usually gets what it needs from Grafana OSS. The free build supports LDAP, generic OAuth, Entra ID, Okta, GitHub, GitLab and Google OAuth, auth proxy and JWT, so most day-to-day access patterns are already covered without a commercial license. The Enterprise license matters less here than the choices made around the free build, such as the database and high availability layout. Illustrative example: a five-person team running one Grafana instance for infrastructure dashboards and alerts on a single Git-backed provisioning repository would have little reason to pay for features it cannot yet use.
- Authentication fits the free build: SAML, team sync, active sync and SCIM are the features that move to Enterprise, and this team may not need any of them.
- Provisioning covers configuration: data sources, dashboards and alerting resources can be defined in YAML or JSON files loaded at startup.
- Database choice matters more: production use needs MySQL or PostgreSQL rather than the default SQLite.
- Edition changes are reversible in planning: a team can start on OSS and add a license later if its requirements change.
Before you decide, confirm which authentication methods your users need and whether an auditor will ask for access reviews that require team sync.
A team that manages user access through Entra ID or Okta and wants group membership to drive Grafana team and role assignments is where the Enterprise edition starts to matter. The free build supports OAuth with these providers, but SAML single sign-on, team sync and active synchronization are documented as Enterprise features, and SCIM provisioning is listed the same way. If your identity provider is the system of record for who may see which dashboards, the gap between OAuth login and group-driven access is the deciding factor. Illustrative example: an organization that removes an engineer from an Okta group expects Grafana team membership to change without a manual step in Grafana.
- Team sync removes manual mapping: group membership from the provider maps to Grafana teams, which reduces drift between the directory and Grafana.
- Active sync handles departures: it covers removal of users and group changes between logins, which OAuth login alone does not.
- Protected roles stay protected: Enterprise lets administrators exempt roles from conversion between authentication types.
- Cost is a fixed commitment: the pricing page lists self-hosted Enterprise with a 25,000 US dollar minimum annual commit, so budget it against the number of identity-driven controls you actually need.
When the free build is enough: if OAuth login and manual team administration meet your access model. Confirm with your identity team whether SCIM or SAML is a hard requirement, and ask Grafana Labs for a written quote tied to your deployment.
A regulated team, such as one in banking, healthcare or public sector, usually needs evidence of who changed what, how secrets are stored and how access is restricted. Grafana Enterprise documents auditing, Vault integration for secrets, request security and runtime settings updates, and these features are the core reason a regulated organization considers the license. Grafana OSS can still be hardened with the documented security settings, including secure and SameSite cookies, a Content Security Policy, and authentication required for the metrics endpoint, but those settings do not replace an audit trail or a central secrets store. Illustrative example: an assessor asks for a log of dashboard and data source changes over a review period, and the team must produce it from the system rather than from memory.
- Auditing is the main gap: confirm the audit events Enterprise records and whether your retention and export needs are met.
- Vault keeps credentials out of files: Enterprise adds Vault integration for secrets, which matters if your policy forbids stored data source credentials in configuration.
- Hardening is available either way: the security hardening guidance applies to both editions.
- Compliance is your evidence to build: DeployOpen prepares systems and evidence for assessments, but auditors and certification bodies issue the findings.
Before you commit, ask your assessor which controls must be evidenced from the tool itself and which can come from surrounding processes.
A team whose dashboards must read from Splunk, ServiceNow, Datadog or Oracle Database, or that reports to a service desk and scheduled distribution list, has a concrete reason to look at Enterprise. These connectors are listed as premium data source plugins in the Enterprise docs, alongside Snowflake, MongoDB, Jira and New Relic. Scheduled PDF reporting by email and dashboard export as PDF are also Enterprise features. If your reporting path depends on one of these sources, the question is whether the plugin is worth the license or whether you can reach the same data another way. Illustrative example: a platform team that already exports Datadog metrics to Prometheus may not need the Datadog plugin at all.
- Plugin needs are specific: list the exact data sources and confirm each one is in the Enterprise plugin set.
- Scheduled reports are a separate case: PDF reporting by email is an Enterprise feature, so a monthly management report may be the deciding factor.
- Data source permissions and caching are also Enterprise features, which matters when several teams share a data source.
- Alternatives exist: a team may route data through Prometheus, Loki or an export job and keep the OSS build.
Confirm the plugin version and support path with Grafana Labs before you rely on it in a production dashboard, and ask whether the data source you need is included in your quote.
What each edition costs and what drives the bill
This table breaks down who gets paid for what under Grafana OSS and self-managed Grafana Enterprise, and which costs recur. Read each row as a cost component: the license line is only one part of the total, and the rest depends on your hosting, database and staff time.
| Cost component | Grafana OSS | Grafana Enterprise (self-managed) |
|---|---|---|
| License | Zero license fee. Grafana is AGPLv3 under the Grafana Labs licensing page. | Commercial license sold by Grafana Labs sales. The pricing page lists a 25,000 US dollar minimum annual commit for self-hosted use with Enterprise Plugins. |
| Published price | None needed. No vendor fee applies to the open-source build. | No separate self-managed Grafana Enterprise price is published. Ask Grafana Labs for the written quote (source: Grafana pricing page). |
| Configuration database | SQLite by default, but production and HA need MySQL 8.0+ or PostgreSQL 12+ (source: Grafana installation docs). Your cloud or DBA team pays for hosting and backups. | Same database requirement. Enterprise does not remove the need to run and back up MySQL or PostgreSQL. |
| Load balancing and HA nodes | Two or more active-active servers behind a load balancer are needed for HA (source: Grafana HA docs). Your infrastructure team pays for nodes and the balancer. | Same HA architecture. Ask whether the quote covers any support for HA design or alerting deduplication setup. |
| Upgrades and patching | Your team plans and tests upgrades. Minor releases every other month and patches at least monthly (source: Grafana upgrade guidance). | Same upgrade cadence, plus support and training from the core Grafana team (source: Grafana Enterprise docs). Ask whether support hours and response terms are in the quote. |
| Implementation and integration effort | Your staff or a partner builds SSO, provisioning and data source setup. SAML and team sync are not available in OSS. | Enterprise features such as SAML, team sync and Vault integration reduce custom work but still need configuration and testing. |
| Operating effort | Recurring staff time for monitoring, backups, security hardening and version tracking. | Same recurring staff time. Support does not replace on-call ownership of your Grafana stack. |
| Ask for in a written quote | Not applicable. Budget the hosting, database, balancer and staff time separately. | License term, annual commit, included plugins, support tier and hours, renewal and uplift terms, and whether trials or ramp pricing apply. |
Moving from OSS to Enterprise and back
This sequence moves a running Grafana OSS instance onto Grafana Enterprise only after the feature gap is confirmed, the database and version are checked, and access, permissions and reporting have been verified. It also shows what a team loses if it later moves back to the open-source build.
Confirm the feature gap through a trial
Start by listing the Enterprise features your team actually needs, such as SAML single sign-on, team sync, data source permissions, scheduled PDF reporting, auditing, Vault integration or the premium data source plugins. Request a trial through the Grafana Labs sales team, since Enterprise is purchased or trialed that way, and test each item against a copy of your own dashboards and identity provider. The step is done when every required feature has been exercised in the trial and a written list of confirmed gaps exists. Ask Grafana Labs to confirm which features apply to your exact edition and deployment.
Check database and version compatibility
Confirm that your Grafana instance stores its configuration in MySQL 8.0 or later or PostgreSQL 12 or later, since SQLite is not suited to production or high availability. Record the running Grafana version and confirm with Grafana Labs that the matching Enterprise build is available for that version and your packaging method (packages, Docker images or Helm charts). If you still run SQLite, plan the database migration first. The step closes with a documented version matrix and a tested database backup.
Plan the SAML and team sync cutover
Map the current authentication setup to the Enterprise options: SAML single sign-on, team sync with the auth provider, and active LDAP synchronization. Identify protected roles that must be exempt from conversion between authentication types, and document which local accounts remain as break-glass access. Run the new login path in a staging instance first, comparing team memberships and role assignments with production. The step is complete when a staging login reproduces production access for every team and the break-glass path has been tested.
Migrate data source permissions and provisioned resources
Export your data sources, dashboards, alerting resources and plugin definitions, which are usually kept as YAML or JSON provisioning files or in a Git-based workflow. Reapply data source permissions in Enterprise so each team sees only the sources it needs, and check that provisioned resources still load at startup without manual edits. Confirm that any Enterprise data source plugins you rely on are installed and configured. The output is a reconciled inventory in which every data source and dashboard has a documented owner and permission set.
Validate reporting, auditing and secrets handling
Schedule a test PDF report by email, export a dashboard as PDF, and confirm the branding and recipients match your requirements. Turn on auditing and verify that sign-in, permission changes and configuration changes appear in the audit records your compliance or security team reviews. If you use Vault integration for secrets, confirm that credentials resolve from Vault and that no secrets remain in plain configuration files. The step closes when a reviewer has signed off on sample report output and audit entries.
Cut over and monitor high availability behavior
Switch users to the Enterprise instance during a window agreed with your operations team, keeping the previous OSS configuration and database backup available for rollback. If you run two or more active-active servers behind a load balancer, confirm that alerting has been configured to avoid duplicate notifications and that the limitations for Grafana Live in high availability are understood by users. Watch sign-in failures and alert delivery for the first days of operation. The step is done when the monitoring dashboard shows stable logins and alert delivery with no unexplained errors.
Plan the reverse path and what stops working
Moving back to the open-source build is possible only if you accept that Enterprise-only features stop working. SAML, team sync, active sync and SCIM provisioning revert to what the OSS authentication options allow, so users must be re-mapped to alternatives such as LDAP, generic OAuth or the other methods the OSS edition supports. Scheduled PDF reporting, data source permissions, auditing, Vault integration and the Enterprise data source plugins also stop functioning, and dashboards or alerts that depend on them need redesign. Document each dependency and ask Grafana Labs to confirm the supported downgrade path for your version before you start.
Questions buyers ask before choosing an edition
Can Grafana OSS use SAML single sign-on or team sync?
No. According to the Grafana authentication docs, SAML, team sync, active sync and SCIM provisioning are available only in Grafana Enterprise and Grafana Cloud. Grafana OSS supports LDAP, generic OAuth, Entra ID, Okta, GitHub, GitLab and Google OAuth, auth proxy and JWT. If your identity provider requires SAML or you need group-to-team mapping, the Enterprise license is the decision point. Confirm with your identity team which protocol your IdP and your group model require before you price anything.
What drives the cost of Grafana Enterprise, and do we need a quote?
Yes, you need a quote. The Grafana pricing page lists self-hosted Grafana Visualization with Enterprise Plugins as an enterprise feature with a 25,000 US dollar minimum annual commit, and it does not publish a separate self-managed Enterprise price. The license is a recurring annual cost, while the OSS build itself is free to download. Ask Grafana Labs sales for the self-managed price, what the annual commit covers, whether support and training are included, and whether a trial is available. Your own infrastructure, staff time and any partner work are separate line items.
How long does a move from OSS to Enterprise take?
The license switch itself is a configuration and procurement step, but the elapsed time depends on what you move. Teams that only need SAML or team sync can change the authentication configuration in a short window, while teams that also rebuild data source permissions, reporting, Vault integration or provisioned dashboards need more testing. Grafana stores configuration in SQLite 3 by default, and production and high availability need MySQL 8.0 or later or PostgreSQL 12 or later, so a database move can extend the schedule. Ask any implementer for a written scope with a timeline before work starts.
Can our team run Grafana Enterprise without an implementation partner?
It depends on your in-house skills and the scope. Grafana publishes installation packages for Debian, Ubuntu, RHEL, Fedora, SUSE, macOS and Windows, along with Docker images and Helm charts, so a team with Linux and Kubernetes experience can install it. The harder parts are SSO integration, high availability and hardening. High availability uses two or more active-active servers behind a load balancer sharing a MySQL or PostgreSQL database, and the docs note that alerting needs extra configuration to avoid duplicate notifications. Grafana Enterprise includes 24x7x365 support and training from the core Grafana team, which covers some of the gap. An external partner is one option, and a fixed-scope written agreement is how DeployOpen typically works.
What does the work need from our identity and database teams?
Your identity team needs to supply the SAML or OAuth configuration, the group model used for team sync, and a decision on whether protected roles should be exempt from authentication type conversion. Your database team needs to provision MySQL 8.0 or later or PostgreSQL 12 or later for configuration storage, with backups and failover planned for a high availability setup. Confirm with both teams who owns the identity provider certificates, the database credentials and the load balancer, because these are the most common blockers in a production rollout. Grafana also notes that Grafana Live has limitations in high availability, so confirm that dashboards you rely on for live data work in that layout.
Do provisioning and Git Sync reduce operating effort?
They reduce manual drift, which lowers ongoing effort, but they do not remove the need for review. Grafana provisioning loads data sources, dashboards, plugins and alerting resources from YAML or JSON files at startup, and Grafana documents further as-code options including Terraform and Git Sync. This is available in the OSS build as well as Enterprise, so it does not decide the edition on its own. Ask your team whether they already keep infrastructure in Git and whether a review process exists for dashboard changes. Those practices determine how much the as-code options save.
Which Enterprise features matter for security and audit reviews?
Auditing, Vault integration for secrets, data source permissions and the request security settings are the features most often reviewed. The Grafana Enterprise docs list auditing, Vault integration and data source permissions among Enterprise features, while the security hardening guide recommends secure and SameSite cookies, a Content Security Policy, Trusted Types and authenticated metrics endpoints, which apply to self-hosted installs regardless of edition. Confirm with your security team which controls they need written evidence for, and ask Grafana Labs whether the audit log format meets your retention rules. DeployOpen prepares systems and evidence for compliance assessments, but it does not issue audit reports or certifications.
Risks to check before signing a license
Five risks sit at the edges of the free build: plugin licenses, paid authentication features, HA behavior and release cadence. Each one is cheaper to confirm before cutover than after, so raise them with Grafana Labs in writing and test them in your own environment.
Plugin licenses differ from Grafana
Grafana, Loki and Tempo moved to AGPLv3, but Grafana Labs states that plugins, SDKs and agent software keep other licenses. The premium plugins for Splunk, ServiceNow, Datadog and Oracle Database are included in Enterprise, so a plugin you run today may carry terms you have not read. Ask Grafana Labs for the license text of each plugin you depend on, and confirm whether the self-hosted Enterprise plugin option requires the minimum annual commit before you assume the AGPL covers it.
SAML and team sync stay paid
The authentication docs list SAML single sign-on, team sync, active sync and SCIM provisioning as available only in Grafana Enterprise and Grafana Cloud. The OSS build still supports LDAP, generic OAuth, Entra ID, Okta, GitHub, GitLab, Google OAuth, auth proxy and JWT, so it may fit if your identity provider uses one of those. During a migration, map every group-based role and every provisioned user, then test the replacement login path in staging before cutover. Confirm with your identity team which protocol each Grafana application uses.
Alerting needs HA configuration
Grafana high availability runs two or more active-active servers behind a load balancer, sharing a MySQL or PostgreSQL database. The HA docs say alerting needs additional configuration to avoid duplicate notifications, because nodes that evaluate the same rule can each send a page. Before go-live, fire a test alert with every node running, confirm which instance sends notifications, and check whether the procedure differs between OSS and Enterprise. Ask Grafana Labs for the current steps for your version.
Grafana Live has HA limits
Grafana Live, which drives live streaming updates in dashboards, has documented limitations when Grafana runs in high availability. Those limits can affect any team that expects live panels to behave the same on every node, so list the dashboards that depend on live updates and check them against your node count and load balancer settings. Run a failover test with a live panel open to see whether updates stall or reconnect. Ask Grafana Labs which live features are affected in your version and whether Enterprise changes that scope.
Minor release support is short
Grafana ships major releases once a year in April or May, minor releases 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. An OSS install that falls behind therefore loses support sooner than many teams plan for. Confirm with Grafana Labs whether Enterprise customers receive different support periods, and schedule upgrade testing of your plugins and alerting before each minor release reaches end of support.
How DeployOpen scopes Grafana work
This sequence turns the question of OSS or Enterprise into a written scope that names which features the team needs, which identity and data source requirements drive the decision, and what the deployment will look like before any license is bought.
Inventory the features your teams actually use
DeployOpen starts with a working session where your Grafana owners list the functions they depend on today and the ones they expect to need within your planning horizon. Typical items include SAML single sign-on, team sync, data source permissions, scheduled PDF reports, auditing and the premium data source plugins. Each item is tagged as needed, nice to have or not required. The output is a feature register that you approve in writing, so the license question rests on named requirements rather than on the edition list.
Map identity and access requirements
Next, DeployOpen reviews your identity provider, directory, group structure and role model against the authentication options in the open-source build. Where a requirement such as SAML, team sync, active directory synchronization or SCIM provisioning is listed as Enterprise or Cloud only in the authentication docs, it is flagged for a license decision. Your identity team confirms the mapping and the protected role rules. The deliverable is an access design document that lists which controls depend on the paid edition.
Confirm data sources and plugin dependencies
DeployOpen lists every data source in use, including the metrics, log and ticketing systems, and checks which ones require a premium plugin from the Enterprise catalog. It also records which data sources need per-team permissions and whether query caching matters for your load. Your data owners confirm access boundaries for each source. The output is a data source inventory that shows which connections work on the open-source build and which need a licensed plugin, so that the plugin cost is attached to a specific system.
Define the reporting, audit and secrets controls
DeployOpen documents how scheduled PDF reporting, dashboard export, audit trails, and secret storage are expected to work for your governance and compliance teams. Where the team plans to use Vault integration or needs auditing evidence, the requirement is written with the control owner and the evidence format. The check at the end is a signed control matrix that states which items the open-source build can cover with configuration and which depend on Enterprise features. DeployOpen does not certify these controls; your auditor assesses them.
Size the deployment and backing database
DeployOpen reviews the expected user count, data volume and availability target, then selects the database and topology. Grafana uses SQLite by default, and the installation docs state that MySQL or PostgreSQL is required for production and high availability. High availability uses two or more active-active servers behind a load balancer, and alerting needs additional configuration to avoid duplicate notifications. The output is an architecture note with the chosen database, node count and load balancer approach, which the infrastructure team reviews before build.
Prepare a cost comparison for the written scope
DeployOpen prepares a side-by-side view of the open-source deployment and an Enterprise option, covering the components each one needs, who pays for each part, and what recurs. For the Enterprise path, the pricing page's minimum annual commit is noted as a published figure, and the sales team quote is requested in writing. Costs for DeployOpen's implementation work follow from the agreed scope and are quoted separately. The deliverable is a decision sheet that lists what to ask Grafana Labs and DeployOpen to quote.
Record the decision and the upgrade path
Once the team chooses an edition, DeployOpen documents the decision, the configuration baseline and the provisioning approach, so dashboards, data sources and alerting rules can be defined as code. The upgrade plan follows Grafana's published release cadence, including the support windows for minor releases. The closing check is an approved decision record with a named owner for license renewal, upgrades and any future edition change, so the choice can be revisited without a rebuild.
How DeployOpen scopes and delivers either edition
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted Grafana inside your own cloud accounts, data centers or air-gapped networks, whichever edition you choose. We start by confirming which features your teams need, because that answer decides whether the open-source build or a licensed Enterprise deployment is the right base.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope lists the data sources, authentication model, reporting needs and audit requirements for your Grafana deployment.
- We confirm with Grafana Labs which Enterprise features and plugins your scope requires, since licensing is handled by Grafana Labs, not DeployOpen.
How we build
- We deploy Grafana on the platform your scope names, with MySQL or PostgreSQL configuration storage for production and high availability.
- We configure authentication, including SAML, team sync or LDAP where your edition supports them, and test each login path before handover.
- We apply security hardening settings such as secure cookies, a Content Security Policy and authenticated metrics endpoints, then run security testing against the result.
How we hand over
- Data sources, dashboards and alerting resources are defined as provisioning files or as-code so the configuration can be reviewed and rebuilt.
- Handover documentation covers the edition in use, the features enabled, the upgrade path and the owners of each configuration file.
- Compliance evidence is prepared for your assessor, but DeployOpen does not issue audit reports, attestations or certifications.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped in writing separately from the initial build.
- Upgrade planning follows Grafana's published release and support windows, so patching work is scheduled against the minor versions you run.
- Quotes are based on the written scope, so ask for line items covering the Grafana Labs license, DeployOpen labor, and any recurring retainer.
