Grafana Cloud provides hosted dashboards and observability services. For a home lab, the useful question is how your measurements reach those services and what happens when the internet connection fails. You can retain a local Prometheus server and send selected metrics outward; a public IP address is not a requirement for that approach.
What runs at home and what runs in the cloud?
Prometheus collects numeric measurements from configured targets. An exporter makes information such as CPU time or network counters available in a format Prometheus understands. Grafana queries a data source and draws dashboards. Running Grafana alone does not collect every device’s statistics or provide unlimited metric storage.
With local Prometheus and Grafana, you manage collection, database, dashboard service and disk capacity. With Grafana Cloud remote write, collection still happens at home, while selected samples are copied into the cloud metric service. The hosted dashboard interface needs no local Grafana installation, but the collector, credentials and forwarding configuration still require maintenance.
Start with the existing Prometheus installation guide if you do not yet have working local metrics. Confirm that targets are healthy locally before adding the cloud connection. Forwarding an empty or broken collection does not make the measurements useful.
Connect from behind NAT or CGNAT
A normal cloud data-source connection cannot reach a private home address directly. That is different from Prometheus remote_write, which initiates outbound HTTPS requests to your Grafana Cloud endpoint. Ordinary home NAT does not require a port-forwarding rule for this outgoing connection. Network policy must still allow the destination, DNS resolution and HTTPS traffic.
Keep Prometheus and exporters on trusted networks. Opening an unauthenticated metrics endpoint to the internet is unnecessary for this method. Metrics can include revealing machine names, service labels and operational information even when they do not contain document contents.
Prepare your stack and credentials
- Visit the Grafana Cloud website, choose an appropriate plan and create a stack.
- Find that stack’s Prometheus remote-write endpoint and metrics instance ID. Use the generated details for your own stack; an example URL copied from another installation is not interchangeable.
- Create an access policy token with the required metrics-write scope for that stack. A dashboard login password or read-only data-source credential is not the write credential.
- Store the token in a private file readable by the Prometheus service. In Docker, the path must exist inside the container through an appropriate read-only mount, rather than merely on the host.
Do not paste the token into public screenshots, support tickets or a repository. Rotate it if exposed, update the file and check forwarding again. Keep the instance ID and token paired with the correct endpoint.
Add remote write to the existing configuration
The following is a configuration fragment, not a replacement for your complete prometheus.yml. Merge it with the existing global settings and scrape jobs. If remote_write already exists, add an entry to its list instead of defining the key twice. Replace the deliberately invalid example endpoint and instance-ID placeholder.
remote_write:
- url: "https://metrics.example.invalid/api/prom/push"
basic_auth:
username: "REPLACE_WITH_METRICS_INSTANCE_ID"
password_file: "/etc/prometheus/grafana-cloud-token"
write_relabel_configs:
- source_labels: [__name__]
regex: "up|node_cpu_seconds_total|node_memory_.*|node_filesystem_.*|node_network_.*"
action: keepThe optional write_relabel_configs filter selects metric names to forward. It does not limit the total to a fixed number of series: different label combinations, interfaces, filesystems and CPU cores produce separate series. Nor does it remove those metrics from local storage. A dashboard needing a filtered-out measurement will show gaps in the cloud.
Use the matching Prometheus validation tool to check your complete configuration before reloading the service. Keep a working copy for rollback. Confirm file permissions and mounts as well as YAML syntax; a syntactically valid configuration can still reference an unreadable token file.
Verify the connection before importing dashboards
First query up locally and note the target’s labels. Then select the hosted metrics data source in Grafana Cloud Explore and look for current samples with the expected labels. Allow for collection and forwarding intervals. An old sample does not prove forwarding is still healthy.
If local data exists but cloud data does not, inspect Prometheus’s remote-write logs and status metrics. Check the endpoint, token scope, instance ID, token-file access and outbound connectivity. An authentication failure is different from a queue backing up during an internet outage. Changing dashboard colours or reinstalling an exporter will not resolve the wrong cloud credential.
Import dashboards only after this simple query works. Check their expected exporter, metric names, variables and data source. Network byte-counter rates represent bytes per second unless converted; CPU counters need rates and appropriate aggregation. A panel title alone does not establish the correct unit or measurement.
Plan retention, privacy and cost
Review the current plan allowances for active series, retention and billing before enabling every exporter. Measure your own usage rather than multiplying an assumed series count by the number of machines. Add one job, inspect the result and expand deliberately.
Local storage is constrained by retention settings and available resources. Cloud retention follows the chosen service plan. Longer history also needs useful labels and stable collection: retaining years of misleading measurements will not explain a problem.
Cloud copies remain outside your home, which may suit remote access but changes the data-handling decision. Review labels and restrict stack access. A local installation also needs permissions, updates and backups; physical ownership by itself does not make it private.
Understand outages and alternatives
During an ISP outage, a functioning local stack can remain accessible from the LAN. Cloud dashboards require an available route to the cloud. Remote-write buffering and recovery have limits, so do not assume an indefinitely long outage will upload every missing sample afterward.
A cloud alert can help detect missing home telemetry only when the rule, missing-data behaviour, contact point and notification policy are configured and tested. A target returning up=0 is different from the entire collector disappearing. Test both cases and the actual delivery channel before relying on an alert.
Private Data Source Connect is another option: a locally managed agent creates an outbound SSH tunnel so the cloud can query a private data source. It does not grant unlimited storage or make cloud queries entirely local. Grafana Alloy is an alternative collector for supported integrations; its configuration syntax differs from Prometheus YAML.
Choose the simplest arrangement that answers your questions. A local dashboard may be enough for occasional home troubleshooting. Hosted dashboards can be useful when you want managed services and remote visibility, provided you understand the collection, data-sharing and recovery responsibilities.
