Grafana Pyroscope

Open Marketplace in the Azure Portal, search for Grafana Pyroscope, select the SecureAnyCloud publisher entry, and click Create.

On the Networking tab, attach a network security group that allows inbound TCP 22 from your management IP range. Also allow TCP 443 (and 80 for the HTTP-to-HTTPS redirect) from the networks that will send profiles and use the UI. The per-VM Basic Auth credential protects every route and Pyroscope's own port is firewalled off-box, but you should still restrict source ranges.

Click Review + create and wait for validation, then click Create. Deployment takes around two minutes.

RG="pyroscope-prod" LOCATION="eastus" az group create --name "$RG" --location "$LOCATION"
# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:grafana-pyroscope-ubuntu-24-04:default:latest
az vm create \
  --resource-group "$RG" \
  --name pyroscope-01 \
  --image sac1647283583153:grafana-pyroscope-ubuntu-24-04:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard
# Allow SSH (22), HTTPS (443) and the HTTP->HTTPS redirect (80) from your trusted ranges az vm open-port --resource-group "$RG" --name pyroscope-01 --port 22 --priority 1001 az vm open-port --resource-group "$RG" --name pyroscope-01 --port 443 --priority 1002 az vm open-port --resource-group "$RG" --name pyroscope-01 --port 80 --priority 1003

Replace <publisher>:<offer>:<sku> with the URN shown on the Marketplace listing's Usage Information tab.

ssh azureuser@<vm-public-ip>

Use the private key that matches the public key you supplied at deploy time. The login user for this image is azureuser.

Confirm that the Pyroscope server, the nginx proxy and the ufw firewall are running, and check the listening sockets. Pyroscope binds port 4040 on all interfaces, as single-binary mode requires, but ufw seals the port off-box. You reach Pyroscope only through nginx on port 443. The AGPL-3.0 licence ships with the image.

pyroscope --version 2>/dev/null | head -1 systemctl is-active pyroscope nginx ufw
sudo ss -ltn | grep -E ':443 |:4040 ' head -2 /usr/local/share/pyroscope/LICENSE

Expected output:

pyroscope, version 2.2.1 (branch: HEAD, revision: df3c0391b) active active active LISTEN 0 511 0.0.0.0:443 0.0.0.0:* LISTEN 0 511 [::]:443 [::]:* LISTEN 0 4096 *:4040 *:* GNU AFFERO GENERAL PUBLIC LICENSE Version 3, 19 November 2007

On the first boot of your VM, grafana-pyroscope-firstboot.service generated a Basic Auth password unique to your instance and a per-instance TLS certificate. It wrote the credentials to a root-only file. Read the file with:

sudo cat /root/grafana-pyroscope-credentials.txt

The file reports the HTTPS URL and the login:

pyroscope.url=https://<vm-public-ip>/ pyroscope.admin.user=admin pyroscope.admin.pass=<generated-per-vm>

A shipped self-test confirms the whole credential model without printing any secret. It proves the HTTP-to-HTTPS redirect and the static /healthz probe, that missing, wrong and default credentials are rejected, and that the per-VM credential is accepted:

sudo bash /usr/local/sbin/pyroscope-credcheck.sh

Expected output:

OK

The per-VM Basic Auth credential guards every Pyroscope route. Only the static /healthz probe answers without authentication. There is no default or shared login, and no password file ships in the image, so admin/admin is rejected.

You can see the gate with curl. The -k flag accepts the per-VM self-signed certificate:

AP=$(sudo grep '^pyroscope.admin.pass=' /root/grafana-pyroscope-credentials.txt | cut -d= -f2-)
curl -ks -o /dev/null -w 'healthz (no auth) -> HTTP %{http_code}\n' https://127.0.0.1/healthz
curl -ks -o /dev/null -w 'UI no auth -> HTTP %{http_code}\n' https://127.0.0.1/
curl -ks -o /dev/null -w 'UI default admin -> HTTP %{http_code}\n' -u 'admin:admin' https://127.0.0.1/
curl -ks -o /dev/null -w 'UI per-VM admin -> HTTP %{http_code}\n' -u "admin:$AP" https://127.0.0.1/

Expected output:

healthz (no auth) -> HTTP 200 UI no auth -> HTTP 401 UI default admin -> HTTP 401 UI per-VM admin -> HTTP 200

You can also confirm that the host firewall seals Pyroscope's own port off-box:

sudo ufw status | grep -E 'Status|22|80|443|lo'

Expected output:

Status: active 22/tcp ALLOW Anywhere 80/tcp ALLOW Anywhere 443/tcp ALLOW Anywhere Anywhere on lo ALLOW Anywhere

Port 4040 is deliberately absent from the allow list. It is reachable only through loopback and nginx.

In a browser, go to https://<vm-public-ip>/. The certificate is self-signed and generated per VM, so your browser warns on the first visit. Accept the warning, or install a CA-signed certificate as described in Step 11.

When prompted for HTTP Basic Auth, enter user admin and the pyroscope.admin.pass value from Step 5.

After you authenticate, the Pyroscope UI opens. Choose a service and a profile type, then explore the flamegraph.

The image runs Pyroscope in single-binary mode, so Pyroscope profiles itself and pushes those profiles back to its own store. Real profiling data is present immediately, with no external agent to install.

Confirm that the profile-type catalogue is populated, and render a CPU flamegraph over the HTTP API:

AP=$(sudo grep '^pyroscope.admin.pass=' /root/grafana-pyroscope-credentials.txt | cut -d= -f2-)
# The profile types Pyroscope is collecting about itself curl -ks -u "admin:$AP" -XPOST https://127.0.0.1/querier.v1.QuerierService/ProfileTypes \
  -H 'Content-Type: application/json' -d '{}' | jq -r '.profileTypes[].ID' | head
# Render a CPU flamegraph and summarise it curl -ks -u "admin:$AP" -G https://127.0.0.1/pyroscope/render \
  --data-urlencode 'query=process_cpu:cpu:nanoseconds:cpu:nanoseconds{}' \
  --data-urlencode 'from=now-1h' --data-urlencode 'until=now' \
  --data-urlencode 'format=json' \
  | jq '{numTicks: .flamebearer.numTicks, frames: (.flamebearer.names|length), units: .metadata.units}'

Expected output (values grow as the instance runs):

block:contentions:count:contentions:count block:delay:nanoseconds:contentions:count goroutines:goroutine:count:goroutine:count memory:alloc_objects:count:space:bytes memory:alloc_space:bytes:space:bytes memory:inuse_objects:count:space:bytes memory:inuse_space:bytes:space:bytes mutex:contentions:count:contentions:count mutex:delay:nanoseconds:contentions:count process_cpu:cpu:nanoseconds:cpu:nanoseconds { "numTicks": 1350000000, "frames": 662, "units": "samples" }

In the web UI, select the pyroscope service and the process_cpu profile type to explore the same data as an interactive flamegraph.

To profile your own services, instrument them with the Grafana profiling SDKs, or scrape existing pprof endpoints with Grafana Alloy. Point either one at your instance with the Basic Auth credential. For example, a Go application can use the Pyroscope Go SDK:

import "github.com/grafana/pyroscope-go" pyroscope.Start(pyroscope.Config{ ApplicationName: "my.go.app", ServerAddress: "https://<vm-public-ip>", BasicAuthUser: "admin", BasicAuthPassword: "<pyroscope.admin.pass>", })

SDKs exist for Go, Java, Python, Ruby, .NET, Node.js and Rust. Alloy's pyroscope.scrape and pyroscope.write components can pull pprof endpoints and forward them here. Each service appears as its own entry in the UI's service selector, alongside the built-in pyroscope self-profile.

The password is stored as a bcrypt hash in the nginx htpasswd file. To rotate it, regenerate the entry, which prompts for the new password, and reload nginx:

sudo htpasswd -B /etc/nginx/.pyroscope.htpasswd admin
sudo systemctl reload nginx

htpasswd -B prompts for the new password and writes a fresh bcrypt hash. If you rely on /root/grafana-pyroscope-credentials.txt, update the record there. Otherwise, keep your new password in your own secret store.

The image ships a per-VM self-signed certificate, so TLS works out of the box. For production, point a DNS name at the VM and install a CA-signed certificate, for example with Let's Encrypt:

sudo apt-get update && sudo apt-get install -y certbot python3-certbot-nginx
sudo certbot --nginx -d pyroscope.example.com

Certbot obtains a certificate, rewrites the nginx TLS configuration to use it, and sets up automatic renewal. Make sure port 80 is reachable from the internet for the ACME HTTP-01 challenge.

Single-binary mode stores profiles on the VM's local disk, which suits a self-contained instance. To retain more data or run a distributed deployment, point Pyroscope at S3-compatible object storage. Edit the service's storage flags in /etc/systemd/system/pyroscope.service, for example -storage.backend=s3 with the matching -storage.s3.* settings. Then run:

sudo systemctl daemon-reload
sudo systemctl restart pyroscope

See the Pyroscope configuration reference for the full set of object-storage and component options.

To remove the VM and its resource group entirely, run the command below from a workstation with the Azure CLI:

az group delete --name pyroscope-prod --yes --no-wait