DEV Community: Khanh Nguyen

Deploy Grafana to Azure with Azure CLI : From Local Docker to Durable Dashboards

Khanh Nguyen — Wed, 12 Aug 2026 20:04:12 +0000

Grafana turns data from sources such as PostgreSQL, Prometheus, and Azure Monitor into shared dashboards, charts, and alerts. While it queries that operational data, it also needs to persist its own dashboards, users, alert rules, and data-source configuration.

I usually use IaC for shared Azure environments. For this deployment, I used Azure CLI first to understand and validate each dependency directly: private networking, PostgreSQL persistence, ACR image pulls, managed identity, and Container Apps secrets.

This guide deploys Grafana on Azure Container Apps with Azure Database for PostgreSQL Flexible Server and a pinned image in ACR. By the end, you will have managed HTTPS ingress, private database connectivity, persistent Grafana state, and no registry password in the deployment.

This is a production-minded lab: no latest tag, anonymous access disabled, and no database password baked into the image. After validating the design, capture it in Bicep, Terraform, or your preferred IaC tool for repeatable deployments.

The architecture: separate what changes from what must persist

The service responsibilities are deliberately separate:

Service	Responsibility
Azure Container Apps	Runs Grafana, provides HTTPS ingress, and manages revisions
Azure Database for PostgreSQL	Stores Grafana's users, dashboards, alerting configuration, and settings
ACR	Provides a private, deployable copy of the Grafana image
User-assigned managed identity	Lets Container Apps pull from ACR without registry credentials

Grafana's internal database is different from the reporting database that dashboards query. This distinction is easy to miss: the internal database preserves Grafana itself, while data sources provide the metrics and business data displayed in a dashboard. Give Grafana a dedicated database and role; give dashboards a separate, read-only data-source account where possible.

Before you start: prepare the Azure CLI session

You need an Azure subscription, Docker, and the Azure CLI. The commands use Bash or zsh; use a shell such as Azure Cloud Shell, macOS Terminal, or WSL.

az login
az extension add --name containerapp --upgrade

az provider register --namespace Microsoft.App
az provider register --namespace Microsoft.OperationalInsights
az provider register --namespace Microsoft.ContainerService
az provider register --namespace Microsoft.ContainerRegistry
az provider register --namespace Microsoft.DBforPostgreSQL

Set names that are unique where Azure requires them. Keep secrets out of your shell history and Git repository.

RESOURCE_GROUP=rg-grafana-dev
LOCATION=canadacentral

VNET_NAME=vnet-grafana-dev
ACA_SUBNET=snet-containerapps
POSTGRES_SUBNET=snet-postgres
PRIVATE_DNS_ZONE=grafana.private.postgres.database.azure.com

POSTGRES_SERVER=pg-grafana-dev
POSTGRES_ADMIN=pgadmin
GRAFANA_DB=grafana
GRAFANA_DB_USER=grafana_app

ACR_NAME=<globally-unique-acr-name>
IDENTITY_NAME=id-grafana-acr-pull
ACA_ENV=cae-grafana-dev
APP_NAME=grafana

# Pin the version that you tested. Do not deploy :latest.
GRAFANA_VERSION=13.1.3

Collect secret values interactively. Replace these with Azure Key Vault references for a shared or production environment.

read -rsp "PostgreSQL admin password: " POSTGRES_ADMIN_PASSWORD; echo
read -rsp "Grafana database password: " GRAFANA_DB_PASSWORD; echo
read -rsp "Grafana admin password: " GRAFANA_ADMIN_PASSWORD; echo
GRAFANA_SECRET_KEY="$(openssl rand -base64 48)"

The server name, ACR name, and PostgreSQL administrator shown above are examples. Do not reuse the sample passwords or enable anonymous access from a local experiment.

Optional: validate Grafana locally

This optional check proves the image and database configuration before Azure resources are created. If PostgreSQL runs on your host, Docker Desktop exposes it as host.docker.internal.

Create a local-only .env file. Never commit it.

GF_DATABASE_TYPE=postgres
GF_DATABASE_HOST=host.docker.internal:5432
GF_DATABASE_NAME=grafana
GF_DATABASE_USER=grafana_app
GF_DATABASE_PASSWORD=replace-me
GF_DATABASE_SSL_MODE=disable
GF_SECURITY_ADMIN_PASSWORD=replace-me
GF_SECURITY_SECRET_KEY=replace-with-a-long-random-value
GF_AUTH_ANONYMOUS_ENABLED=false
GF_PANELS_DISABLE_SANITIZE_HTML=false

Run the pinned image and check its health endpoint:

docker pull "grafana/grafana:${GRAFANA_VERSION}"
docker run --detach --name grafana --publish 3000:3000 \
  --env-file .env "grafana/grafana:${GRAFANA_VERSION}"

curl --fail http://localhost:3000/api/health
docker logs grafana

On Linux Docker Engine, add --add-host=host.docker.internal:host-gateway if needed. This hostname is local-only; Azure uses the PostgreSQL server FQDN.

1. Give Grafana durable, private state

Create the resource group, VNet, and two dedicated subnets. The Container Apps environment requires its own subnet. PostgreSQL Flexible Server requires a separate subnet delegated to Microsoft.DBforPostgreSQL/flexibleServers.

az group create --name "$RESOURCE_GROUP" --location "$LOCATION"

az network vnet create \
  --resource-group "$RESOURCE_GROUP" \
  --name "$VNET_NAME" \
  --location "$LOCATION" \
  --address-prefixes 10.0.0.0/16

az network vnet subnet create \
  --resource-group "$RESOURCE_GROUP" --vnet-name "$VNET_NAME" \
  --name "$ACA_SUBNET" --address-prefixes 10.0.0.0/21 \
  --delegations Microsoft.App/environments

az network vnet subnet create \
  --resource-group "$RESOURCE_GROUP" --vnet-name "$VNET_NAME" \
  --name "$POSTGRES_SUBNET" --address-prefixes 10.0.8.0/24 \
  --delegations Microsoft.DBforPostgreSQL/flexibleServers

Create and link the private DNS zone. The link allows workloads in the VNet to resolve the database server to its private address.

az network private-dns zone create \
  --resource-group "$RESOURCE_GROUP" --name "$PRIVATE_DNS_ZONE"

az network private-dns link vnet create \
  --resource-group "$RESOURCE_GROUP" --zone-name "$PRIVATE_DNS_ZONE" \
  --name grafana-vnet-link --virtual-network "$VNET_NAME" \
  --registration-enabled false

PRIVATE_DNS_ZONE_ID=$(az network private-dns zone show \
  --resource-group "$RESOURCE_GROUP" --name "$PRIVATE_DNS_ZONE" \
  --query id --output tsv)

Now create PostgreSQL and the Grafana database. PostgreSQL 18 is used here because it is currently supported by Flexible Server; choose a supported version approved by your organization.

az postgres flexible-server create \
  --resource-group "$RESOURCE_GROUP" \
  --name "$POSTGRES_SERVER" --location "$LOCATION" \
  --admin-user "$POSTGRES_ADMIN" --admin-password "$POSTGRES_ADMIN_PASSWORD" \
  --version 18 --tier Burstable --sku-name Standard_B1ms --storage-size 32 \
  --vnet "$VNET_NAME" --subnet "$POSTGRES_SUBNET" \
  --private-dns-zone "$PRIVATE_DNS_ZONE_ID"

az postgres flexible-server db create \
  --resource-group "$RESOURCE_GROUP" --server-name "$POSTGRES_SERVER" \
  --name "$GRAFANA_DB"

POSTGRES_FQDN=$(az postgres flexible-server show \
  --resource-group "$RESOURCE_GROUP" --name "$POSTGRES_SERVER" \
  --query fullyQualifiedDomainName --output tsv)

Create a least-privileged Grafana role

For a private database, run the following from a trusted machine that has network access to the VNet, such as a jump host. It creates an application role and makes it owner of the Grafana database, which lets Grafana run its own schema migrations without using the server administrator at runtime.

psql "host=$POSTGRES_FQDN port=5432 dbname=postgres user=$POSTGRES_ADMIN sslmode=require" \
  -v ON_ERROR_STOP=1 \
  -v db_name="$GRAFANA_DB" \
  -v db_user="$GRAFANA_DB_USER" \
  -v grafana_password="$GRAFANA_DB_PASSWORD" <<'SQL'
SELECT format('CREATE ROLE %I LOGIN PASSWORD %L', :'db_user', :'grafana_password') \gexec
SELECT format('ALTER DATABASE %I OWNER TO %I', :'db_name', :'db_user') \gexec
SQL

The FQDN is read from the provisioned server instead of assumed. In a production environment, manage this database setup through a reviewed migration or infrastructure workflow instead of typing credentials into an interactive terminal.

2. Prepare a private image and passwordless pull access

ACR can import the public image directly, so your deployment does not depend on Docker Hub at runtime.

az acr create --resource-group "$RESOURCE_GROUP" --name "$ACR_NAME" \
  --location "$LOCATION" --sku Basic --role-assignment-mode rbac

# Required for managed-identity pulls by Azure Container Apps.
az acr config authentication-as-arm update --registry "$ACR_NAME" --status enabled

ACR_LOGIN_SERVER=$(az acr show --resource-group "$RESOURCE_GROUP" --name "$ACR_NAME" \
  --query loginServer --output tsv)

az acr import --name "$ACR_NAME" \
  --source "docker.io/grafana/grafana:${GRAFANA_VERSION}" \
  --image "grafana:${GRAFANA_VERSION}"

Pinning 13.1.3 avoids the ambiguity of latest. Tags can still be moved, so for an immutable production release, record and deploy the imported image digest. When you upgrade, test the new version, import it, and deploy it as a new Container Apps revision.

Create a user-assigned managed identity and grant it pull-only access to this registry.

az identity create --resource-group "$RESOURCE_GROUP" \
  --name "$IDENTITY_NAME" --location "$LOCATION"

IDENTITY_ID=$(az identity show --resource-group "$RESOURCE_GROUP" --name "$IDENTITY_NAME" \
  --query id --output tsv)
IDENTITY_PRINCIPAL_ID=$(az identity show --resource-group "$RESOURCE_GROUP" --name "$IDENTITY_NAME" \
  --query principalId --output tsv)
ACR_ID=$(az acr show --resource-group "$RESOURCE_GROUP" --name "$ACR_NAME" --query id --output tsv)

az role assignment create \
  --assignee-object-id "$IDENTITY_PRINCIPAL_ID" \
  --assignee-principal-type ServicePrincipal \
  --role AcrPull --scope "$ACR_ID"

If your registry uses the newer RBAC + ABAC repository-permission mode, use Container Registry Repository Reader instead of AcrPull, ideally scoped to the grafana repository.

3. Run Grafana with secrets outside the image

Retrieve the Container Apps subnet ID, then attach it when you create the environment.

ACA_SUBNET_ID=$(az network vnet subnet show \
  --resource-group "$RESOURCE_GROUP" --vnet-name "$VNET_NAME" --name "$ACA_SUBNET" \
  --query id --output tsv)

az containerapp env create \
  --resource-group "$RESOURCE_GROUP" --name "$ACA_ENV" --location "$LOCATION" \
  --infrastructure-subnet-resource-id "$ACA_SUBNET_ID"

Create the app with external HTTPS ingress. Secrets are stored by Container Apps and referenced with secretref:. They are not image labels, plain environment-variable values in source control, or ACR credentials. This lab passes secret values through the CLI; use Key Vault references for production to avoid exposing secret values to the local process environment.

az containerapp create \
  --resource-group "$RESOURCE_GROUP" --name "$APP_NAME" --environment "$ACA_ENV" \
  --image "${ACR_LOGIN_SERVER}/grafana:${GRAFANA_VERSION}" \
  --user-assigned "$IDENTITY_ID" \
  --registry-server "$ACR_LOGIN_SERVER" --registry-identity "$IDENTITY_ID" \
  --ingress external --target-port 3000 --transport auto \
  --cpu 0.5 --memory 1Gi --min-replicas 1 --max-replicas 1 \
  --secrets \
    grafana-db-password="$GRAFANA_DB_PASSWORD" \
    grafana-admin-password="$GRAFANA_ADMIN_PASSWORD" \
    grafana-secret-key="$GRAFANA_SECRET_KEY" \
  --env-vars \
    GF_DATABASE_TYPE=postgres \
    "GF_DATABASE_HOST=${POSTGRES_FQDN}:5432" \
    "GF_DATABASE_NAME=${GRAFANA_DB}" \
    "GF_DATABASE_USER=${GRAFANA_DB_USER}" \
    GF_DATABASE_PASSWORD=secretref:grafana-db-password \
    GF_DATABASE_SSL_MODE=require \
    GF_SECURITY_ADMIN_USER=admin \
    GF_SECURITY_ADMIN_PASSWORD=secretref:grafana-admin-password \
    GF_SECURITY_SECRET_KEY=secretref:grafana-secret-key \
    GF_AUTH_ANONYMOUS_ENABLED=false \
    GF_PANELS_DISABLE_SANITIZE_HTML=false

The app is intentionally fixed at one replica. Grafana's application state lives in PostgreSQL, but a multi-replica Grafana design still needs deliberate consideration for plugins, sessions, provisioning, alerting, and load balancing. Start with one replica; scale only after validating those behaviours for your Grafana version and plugins.

4. Confirm the deployment and persistence

Retrieve the endpoint and open it in a browser:

GRAFANA_FQDN=$(az containerapp show --resource-group "$RESOURCE_GROUP" --name "$APP_NAME" \
  --query properties.configuration.ingress.fqdn --output tsv)
echo "https://${GRAFANA_FQDN}"

Sign in with admin and the password supplied as GRAFANA_ADMIN_PASSWORD on Grafana's first start. Grafana applies GF_SECURITY_ADMIN_PASSWORD only when it creates the initial admin user; later changes require Grafana's supported password-management path. If the revision does not become healthy, tail the container logs:

az containerapp logs show --resource-group "$RESOURCE_GROUP" \
  --name "$APP_NAME" --type console --follow

The most common failures are straightforward:

Symptom	Likely cause	First check
Image pull fails	Identity role has not propagated or has the wrong ACR role	Verify the role assignment and wait briefly before retrying
`no such host` / DB connection fails	Private DNS zone is not linked or the FQDN is wrong	Confirm the zone link and use the server's Azure FQDN
TLS or authentication failure	Database SSL or credentials are incorrect	Keep `GF_DATABASE_SSL_MODE=require` and rotate/reapply the secret
Grafana starts but settings disappear	Grafana is using SQLite or the wrong database	Check `GF_DATABASE_*` variables and startup logs

For a quick persistence check, create a throwaway dashboard, trigger a new Container Apps revision with the same image, and confirm that the dashboard remains after the revision becomes active. If it disappears, stop and fix the database configuration before inviting users.

Production next steps

The CLI workflow makes the Azure relationships visible. Before using it for a shared production environment, codify the deployment as IaC and add:

Azure Key Vault references and a secret-rotation process.
Microsoft Entra ID, a custom domain, and restricted ingress or a WAF.
PostgreSQL backups, a restore test, and a production-appropriate compute tier. Consider verify-full for the Grafana-to-PostgreSQL TLS connection after validating the container's CA trust.
Diagnostics and alerts for revision failures, database capacity, and authentication issues.
Versioned Grafana provisioning, plugin governance, and tested image upgrades.

Clean up

For a disposable lab, delete the resource group after confirming it contains no shared resources:

az group delete --name "$RESOURCE_GROUP" --yes --no-wait

Deletion stops the ongoing costs for resources in that group. Check your subscription afterward for any separately scoped diagnostics, backups, or retained resources you intentionally created.

References

I Used Codex to Clean Up 77,000 Emails

Khanh Nguyen — Wed, 22 Jul 2026 05:30:03 +0000

A few days ago, I needed to find an old email in a Gmail account I had barely touched for years.

Opening the inbox was overwhelming.

It contained 77,502 emails, including 72,356 unread messages. Important conversations were buried beneath newsletters, promotions, job alerts, receipts, and automated notifications.

Manually reviewing tens of thousands of emails was not realistic, and deleting everything was not an option.

Instead, I used Codex with a connected Gmail workflow to analyze the mailbox, design a safer organization system, and clean up the inbox in controlled stages.

Understanding the problem

Before changing anything, I asked Codex to analyze the mailbox and identify where most of the volume was coming from.

The analysis revealed that more than 92% of the mailbox consisted of updates and promotions.

That changed how I approached the cleanup.

The real problem was not simply the number of emails. It was that high-priority conversations and low-priority notifications were competing for the same space.

The inbox needed structure before it needed deletion.

The system behind it

The prompts I used

The workflow was driven by a small set of prompts:

How many emails are in my mailbox?

Analyze my mailbox and suggest how to organize it using labels, rules, and a cleanup schedule.

Start with labels and archive first.

The most important instruction was:

Start with labels and archive first.

That constraint kept the workflow controlled and reversible.

Archiving removed messages from the inbox without deleting them, while labels made it easier to review what had been classified before taking stronger action.

Rules and label structure

I used a few simple rules based on Codex’s recommendations and my own preferences to reduce the risk of removing something important:

Keep Finance and Security emails visible
Archive newsletters, job alerts, and routine notifications
Exclude starred and important messages
Preserve the original read and unread state
Keep cleanup actions reversible

Instead of organizing messages only by sender, I grouped them according to what I might need to do next:

Action/Finance
Action/Security
Career/Job Alerts
Reading/Tech
Cleanup/30 Days

This made the labels more useful.

A sender-based label tells me where an email came from. An action-based label tells me why the email still matters.

The results

After applying the workflow, the inbox became significantly smaller and easier to navigate.

The inbox was reduced from 77,502 to 28,745 emails, a 62.7% reduction.

During the cleanup:

48,296 emails were archived
461 emails were moved to Trash
Read and unread states were preserved
Finance and security emails remained visible
No permanent bulk deletion was performed

The goal was not to erase years of email history.

It was to remove low-value messages from the inbox while keeping useful information searchable and recoverable.

Final takeaway

The biggest improvement was not simply archiving 48,296 emails.

It was turning an abandoned inbox into a system where:

Important messages remain visible
Useful emails remain searchable
Routine notifications leave the inbox
Low-value messages become easier to review
Future cleanup becomes more manageable

Codex helped handle the scale, but the workflow succeeded because the prompts were clear, the actions were staged, and the important decisions remained reversible.

This article was created with AI assistance

I Moved My n8n Instance from Render to Azure

Khanh Nguyen — Wed, 10 Jun 2026 04:01:55 +0000

My n8n instance on Render worked perfectly.

It was fast, simple, fully managed, and cost-effectiveness. And I barely had to think about infrastructure.

So why move it?

Because I wanted:

More control over my environment
Centralized cloud billing in Azure
Hands-on experience with Infrastructure as Code (IaC), GitHub Actions, and cloud security
A real-world project instead of another tutorial

This post shares what I built and what I learned along the way.

Repository

git clone https://github.com/TQKNG/lab-n8n-azure.git

Check out README file for full guide

What I Wanted to Build

I wanted a fully reproducible deployment where I could:

Deploy everything from GitHub Actions
Authenticate to Azure without long-lived secrets (OIDC)
Run n8n securely behind HTTPS
Add identity + edge protection layers
Tear everything down when not needed

Think: personal SaaS-grade infrastructure, but lightweight

Architecture

This setup adds two important layers compared to a basic VM deployment:

Cloudflare as the edge layer
Azure AD (Entra ID) as the identity gate

What Gets Deployed

Compute

Ubuntu 22.04 LTS VM (Azure)
Trusted Launch enabled
SSH key-based access

Networking

Virtual Network (isolated subnet)
Network Security Group (restricted ports)
Public IP behind controlled ingress

Application

n8n (Docker container)
Caddy reverse proxy (HTTPS + routing)

Edge & Identity

Cloudflare (DNS + protection layer)
Azure AD (Entra ID authentication gate)

GitHub Actions Pipeline

To trace logs, I use below manually triggered workflows. These allows full lifecycle control from GitHub. Feel free to customize it based on your own workflow setup.

Setup → initialize repo variables
OIDC bootstrap → configure Azure trust
Verify → test authentication
Deploy → run Bicep infrastructure
Start → validate VM + n8n endpoint
Teardown → destroy resources safely

Key Security Layers

This architecture is intentionally layered:

Cloudflare → edge protection + TLS
Azure AD → identity verification before access
NSG → network-level filtering
Caddy → HTTPS termination + reverse proxy
Docker → container isolation

This creates a simple zero-trust-inspired flow.

What I Learned

Azure OIDC is a game changer. No more storing long-lived secrets in GitHub.
Bicep is actually pleasant. Much easier than ARM templates and still powerful.
Cloudflare simplifies edge security. It reduces direct exposure of Azure resources.
Infrastructure as Code changes everything. Even a small project becomes reproducible and disposable.

Next Step

Add Azure Key Vault for secrets
Add automated backups for n8n workflows
Move monitoring to Azure Monitor dashboards
Restrict SSH via IP allowlist or JIT access
Evaluate Azure Container Apps instead of VM
Add cost automation (auto shutdown dev environment)

Resources

Project

GitHub Repository: https://github.com/TQKNG/lab-n8n-azure
n8n Documentation: https://docs.n8n.io
Cloudfare Developer Docs: https://developers.cloudflare.com/

Azure

Bicep Docs: https://learn.microsoft.com/azure/azure-resource-manager/bicep
Azure OIDC with GitHub Actions: https://learn.microsoft.com/azure/developer/github/connect-from-azure-openid-connect
Azure Well-Architected Framework: https://learn.microsoft.com/azure/architecture/framework

CI/CD & Infra

GitHub Actions Docs: https://docs.github.com/actions
Docker Docs: https://docs.docker.com
Caddy Server Docs: https://caddyserver.com/docs