Netdata on Google Cloud Run

Netdata is an open-source, real-time infrastructure and application monitoring agent that collects thousands of metrics per second and serves per-second-granularity dashboards and a REST API. This module deploys Netdata on Cloud Run v2 on top of the App_CloudRun foundation, which provisions and manages the shared Google Cloud infrastructure.

This guide focuses on the cloud services Netdata uses and how to explore and operate them from the Google Cloud Console and the command line. For the mechanics common to every Cloud Run application — service identity, ingress and load balancing, scaling and concurrency, CI/CD, Cloud Armor, IAP, Binary Authorization, VPC Service Controls, backups, and the deployment lifecycle — refer to the App_CloudRun foundation guide rather than repeating them here.

1. Overview

Netdata runs as a single container on Cloud Run v2, listening on port 19999. The deployment wires together a focused set of Google Cloud services:

Capability	Google Cloud service	Notes
Compute	Cloud Run v2	Single container, 1 vCPU / 1 GiB by default; listens on port 19999
Database	None	Netdata has no SQL database — metrics are stored on disk under `/var/lib/netdata`
Object storage	Cloud Storage	One data bucket, mounted as a GCS FUSE volume at `/var/lib/netdata`
Cache & queue	None	Netdata uses no Redis (`enable_redis` is forced `false`)
Secrets	Secret Manager	32-char `NETDATA_ADMIN_PASSWORD`, generated by default (`enable_admin_password = true`)
Ingress	Cloud Run URL / Cloud Load Balancing	Default `all` — public; a plan-time guard requires `enable_admin_password = true` to pair with it

Sensible defaults worth knowing up front:

No database. Netdata is a self-contained agent; there is no Cloud SQL instance, no db-init job, and no schema migration. database_type = NONE.
Ingress defaults to all (public), paired with a generated admin-password credential. Netdata's dashboard has no built-in authentication of its own, so a plan-time guard rejects ingress_settings = "all" unless enable_admin_password = true — both default that way together so a fresh deploy passes plan out of the box.
The dashboard is unauthenticated regardless of enable_admin_password. That flag (on by default) only generates a Secret-Manager-backed NETDATA_ADMIN_PASSWORD for an operator-side auth layer (reverse proxy / Netdata Cloud claim) — it does not, by itself, add a login page to the raw dashboard. Restrict ingress_settings to internal or front the service with enable_iap if the exposed, unauthenticated dashboard is a concern.
Single instance by default. min_instance_count = 1, max_instance_count = 1. Each Netdata instance holds its own local metrics database, so it does not scale horizontally into a shared store — keep it at one instance.
Metrics persist to a GCS FUSE bucket. /var/lib/netdata is backed by a Cloud Storage bucket (enable_gcs_storage_volume = true) so the metrics database survives restarts and scale events. This requires the gen2 execution environment.
No Redis. enable_redis is explicitly disabled; Netdata needs no cache/queue.
Health path is /api/v1/info. Startup and liveness probes hit this endpoint, which returns a 200 JSON body once the agent is initialised.
The image is version-pinned via NETDATA_VERSION. application_version = "latest" resolves to v2.2.6 at build time rather than a non-existent latest wrapper.

2. Google Cloud Services & How to Explore Them

All commands assume PROJECT and REGION are set. Service and resource names are reported in the deployment Outputs.

A. Cloud Run — the Netdata service

Netdata runs as a Cloud Run v2 service listening on port 19999. Each deployment creates an immutable revision; because Netdata keeps its metrics on a single local/ GCS-backed database, it is normally run as a single instance rather than autoscaled.

Console: Cloud Run → select the service for revisions, traffic, logs, and metrics.

CLI:

gcloud run services list --project "$PROJECT" --region "$REGION" \
  --filter="metadata.name~netdata"
gcloud run services describe <service-name> --project "$PROJECT" --region "$REGION"
gcloud run revisions list --service <service-name> --project "$PROJECT" --region "$REGION"
# Confirm the injected listener port / admin password env:
gcloud run services describe <service-name> --region "$REGION" \
  --format='value(spec.template.spec.containers[0].env)'

See App_CloudRun for scaling, concurrency, execution environment, and traffic splitting.

B. Cloud Storage — metrics persistence

A dedicated Cloud Storage bucket is provisioned and mounted as a GCS FUSE volume at /var/lib/netdata, where Netdata keeps its metrics database, alarm log, and health state. This persists monitoring history across revision restarts and redeploys. GCS FUSE requires the gen2 execution environment.

Console: Cloud Storage → Buckets.

CLI:

gcloud storage buckets list --project "$PROJECT" --filter="name~netdata"
gcloud storage ls gs://<data-bucket>/          # bucket name is in the Outputs

See App_CloudRun for GCS Fuse and CMEK options.

C. Secret Manager

By default (enable_admin_password = true) a single 32-character secret (secret-<prefix>-netdata-admin-password) is generated and injected as NETDATA_ADMIN_PASSWORD. No other application secrets are created (there is no database password because there is no database).

Console: Security → Secret Manager.

CLI:

gcloud secrets list --project "$PROJECT" --filter="name~netdata-admin-password"
gcloud secrets versions access latest --secret=<secret-name> --project "$PROJECT"

See App_CloudRun for injection and rotation details.

D. Networking & ingress

By default the service uses ingress_settings = "all" (public) paired with enable_admin_password = true — the module's validation guard requires the password flag whenever ingress is all, and both default that way together. The dashboard itself has no built-in login regardless, so for a genuinely locked-down deployment set ingress_settings = "internal" (VPC-only) or front the public service with enable_iap / an external HTTPS load balancer + basic-auth. The netdata_url output reports the service URL (port 19999).

Console: Cloud Run (service URL); Network services → Load balancing.

CLI:

gcloud run services describe <service-name> --region "$REGION" --format='value(status.url)'
gcloud compute addresses list --project "$PROJECT"

See App_CloudRun.

E. Cloud Logging & Monitoring

Container logs flow to Cloud Logging; Cloud Run metrics flow to Cloud Monitoring, with an optional uptime check (targeting /api/v1/info) and alert policies.

Console: Logging → Logs Explorer; Monitoring → Dashboards / Alerting.

CLI:

gcloud run services logs read <service-name> --project "$PROJECT" --region "$REGION" --limit 50

3. Netdata Application Behaviour

No database bootstrap. There is no db-init job and no schema migration. The agent writes its round-robin metrics database directly to /var/lib/netdata (the GCS FUSE volume) on first start.
Metrics persistence. Monitoring history survives restarts only because /var/lib/netdata is backed by the Cloud Storage bucket. If you disable enable_gcs_storage_volume (or the bucket is empty), each new revision starts with a blank metrics database.
Unauthenticated dashboard. Netdata's local dashboard and REST API on port 19999 have no built-in login, even though ingress_settings = "all" and enable_admin_password = true are both the module defaults. Set ingress_settings = "internal" or place an authenticating proxy in front if the publicly-exposed, unauthenticated dashboard is a concern. enable_admin_password provides a stable credential for that proxy / for the Netdata Cloud claim flow — it does not lock the raw dashboard by itself.
Health path. Startup and liveness probes target /api/v1/info, which returns a 200 JSON body once the agent is initialised. Verify it:
```
# from within the VPC (or after port-forwarding / LB):
curl -s "$NETDATA_URL/api/v1/info" | head
```
Single-instance operation. Because each instance owns its local metrics DB, keep min_instance_count = max_instance_count = 1. Scaling out produces independent, non-federated agents, not a shared dashboard.
Netdata Cloud (optional). To centralise multiple agents, claim this instance to Netdata Cloud post-deploy (via a claim token / rooms env) — an operator step, not provisioned by the module.

4. Configuration Variables

Variables are grouped exactly as they appear on the deployment platform. Only settings specific to or notable for Netdata are listed; every other input is inherited from App_CloudRun with its standard behaviour.