Self-host Grafana with Managed Postgres

What does this self-hosted Grafana template deploy?

This template creates one Grafana app and one separate Managed Postgres database. Lizard connects them with Grafana's GF_DATABASE_* settings, gives the app a public HTTPS address and routes traffic to port 3000.

Grafana lets you query data sources, build dashboards and set alerts. It does not store all of your metrics, logs or traces by itself. Connect this Grafana instance to Prometheus, Loki, Tempo, InfluxDB, PostgreSQL or another supported data source after deployment.

The current template source pins the official grafana/grafana:11.3.0 Docker image. The app has limits of 2 vCPUs and 2 GiB RAM. Those values are ceilings, not a fixed bill or a promise that every workload needs the full amount.

The template deploys one Grafana server. It does not include Prometheus, Loki, Tempo, an image renderer or a high-availability cluster. This keeps the first deploy small and lets you connect the data systems you already use.

How to deploy Grafana on Lizard

1. Choose Deploy Now. Sign in if needed, pick an admin username and set a strong admin password. The app gets a public URL, so do not reuse a password.
2. Wait for both services. Lizard builds Grafana, starts Managed Postgres and passes the database host, name, user and password to the app.
3. Open the HTTPS address. Sign in with the admin details from the deploy form. The template sets Grafana's public domain and root URL from the address Lizard assigns.
4. Add a data source. In Grafana, open Connections, add the system that holds your telemetry and test the connection. Use a read-only database user when a data source only needs to read data.
5. Create a test dashboard and restart the app. Confirm that the dashboard, user and data source settings return after the restart. Then set up and test the recovery steps your production use needs.

For repeatable app settings, read the Lizard CLI config reference. Keep passwords and tokens out of files you commit. If a deploy fails, check the app logs and the Managed Postgres connection values before changing the image.

Why does this Grafana template use Managed Postgres?

Grafana needs an internal database for users, dashboards, folders, data source settings, alert rules and service accounts. Grafana uses SQLite by default, but its installation guide says to use an external MySQL or PostgreSQL database for production and high-availability setups.

This template points Grafana's internal database at Managed Postgres. As a result, an app redeploy can replace the Grafana container without replacing the database records. You do not need to copy the Postgres password into the template repository; Lizard passes it through environment references.

Managed Postgres is not your metrics store unless you also add it as a Grafana data source. These are two separate jobs:

That difference matters for the grafana postgres and grafana postgresql setup. A working internal database does not add a PostgreSQL data source to the Grafana UI, and adding a data source does not back up Grafana's own settings.

Why idle Grafana can cost less on Lizard

A Grafana server often waits between dashboard views, incident checks and alert runs. Lizard meters the CPU and memory the app uses each second instead of billing the full 2 vCPU and 2 GiB limit at all times. When Grafana has little work, CPU use can fall, which can cut its Idle App Cost compared with a fixed VM that charges for its full size all month.

Idle does not mean free. Grafana and Managed Postgres can still use memory and CPU while they wait. Alert rules, short refresh intervals and background jobs also add work. Postgres data, Persistent Volumes and network egress can keep adding cost as you use them. Stopping the Grafana app stops its compute use, but any database or stored data that you keep can still cost money.

Lizard Pro costs $19 a month and includes $19 of usage. Once you use it, pay as you go. See the current CPU, memory, storage and egress rates on Lizard pricing, then check the app's own metrics after a normal week. The resource limits tell you how high use may go; the measured data tells you what you pay for.

This model suits a personal dashboard, a lab, a staging monitor or an internal Grafana instance that stays available but sees short bursts of use. A busy alerting server or a dashboard wall that refreshes all day will use more resources.

Grafana Cloud or self-hosted Grafana?

Grafana Cloud and this template solve different parts of the job. Grafana Cloud can host the Grafana UI and managed telemetry services. This template hosts the Grafana UI and its internal Postgres database; you choose and run the metrics, logs and traces backends that Grafana queries.

As of 23 September 2026, Grafana Cloud pricing lists Free at $0, Pro from $19 per month plus usage, and Enterprise from a $25,000 yearly spend commitment. Prices and limits can change, so check the source before you compare a real workload.

Grafana Cloud Free can cost less if its limits and hosted model fit. Choose this self-hosted Grafana template when you need control over the instance, want to connect private data sources or prefer a bill based on the resources your app and database use.

What survives a Grafana redeploy?

The Managed Postgres database keeps Grafana records when the app container changes. That covers dashboards saved in the UI, users, teams, folders, data source settings, alert rules and service-account records.

Do not assume that files written inside the Grafana container will survive a redeploy. Grafana's Docker paths put plugins and other local data under /var/lib/grafana. The current template does not attach a Persistent Volume there. Install required plugins on each build or startup with a pinned list, or make them part of your own image. Keep file-based provisioning in the repository so the next deploy can create it again.

A sound recovery plan covers more than the database:

• Back up Managed Postgres and test a restore.
• Keep any custom Grafana secret keys and sign-in settings safe.
• Store dashboard or data source provisioning files in version control without secrets.
• Record the plugin names and versions the instance needs.
• Test the restored instance against its data sources before an incident.

Grafana's Docker guide explains when a volume is needed. The database removes the main SQLite file from the app container, but it does not turn every local path into persistent storage.

How should you update this Grafana Docker deployment?

The template pins a Grafana image so a rebuild does not pull an untested release without warning. Before production use, check whether that pinned version still receives fixes. To update it, use your own copy of the template repository, change the image tag to a supported release, back up Postgres and test the dashboards, data sources, plugins and alert rules on a non-production instance first.

Read Grafana's release notes for database migrations and breaking changes. Pin plugin versions as well as the Grafana image. After the update, run a login test, open key dashboards, fire a test alert and confirm that a fresh restart keeps the data you expect.