InfluxDB stores time-series IoT data efficiently, and Grafana turns it into dashboards, the standard self-hosted pairing for visualising sensor data over time. InfluxDB listens on port 8086 by default, Grafana on port 3000, and Node-RED (already covered elsewhere on this site) is the simplest way to get MQTT telemetry into InfluxDB in the first place.
The problem this solves
MQTT and Node-RED, covered in this site’s other guides, move and process data well, but neither is built for answering “what did this value look like over the last month” or “show me every sensor on one screen”. That’s a time-series database and a visualisation layer’s job specifically, which is where InfluxDB and Grafana come in: InfluxDB stores readings efficiently indexed by time, and Grafana queries that data and renders it as charts, gauges and tables on a dashboard you can actually look at.
Installing InfluxDB
curl -fsSL https://repos.influxdata.com/influxdata-archive.key
| sudo gpg --dearmor -o /usr/share/keyrings/influxdb.gpg
echo "deb [signed-by=/usr/share/keyrings/influxdb.gpg]
https://repos.influxdata.com/ubuntu $(lsb_release -cs) stable"
| sudo tee /etc/apt/sources.list.d/influxdb.list
sudo apt update && sudo apt install influxdb2
sudo systemctl enable --now influxdbInfluxDB listens on port 8086 by default. On first visiting http://your-server-ip:8086, a one-time setup wizard creates your initial organisation, bucket (InfluxDB 2.x’s term for what earlier versions called a database) and an API token, the credential everything else, Node-RED and Grafana included, will use to read and write data. Save that token securely; it’s shown once during setup.
It’s worth knowing InfluxDB 3.x exists as the current generation, using standard SQL rather than 2.x’s Flux query language, and is InfluxData’s own recommendation for new deployments. This guide uses 2.x specifically because it remains extremely widely deployed, stable, and is what the overwhelming majority of current tutorials and Node-RED/Grafana integration examples assume; the core concepts (buckets, tokens, time-series storage) carry across either version.
Installing Grafana
sudo apt install -y apt-transport-https software-properties-common
curl -fsSL https://apt.grafana.com/gpg.key | sudo gpg --dearmor -o /usr/share/keyrings/grafana.gpg
echo "deb [signed-by=/usr/share/keyrings/grafana.gpg] https://apt.grafana.com stable main"
| sudo tee /etc/apt/sources.list.d/grafana.list
sudo apt update && sudo apt install grafana
sudo systemctl enable --now grafana-serverGrafana listens on port 3000 by default. The default login is admin/admin, with a forced password change on first login, not something to skip given everything else this site covers about not leaving default credentials in place.
Securing both before going further
Neither service should be reachable directly from the open internet without the same hardening discipline applied throughout this site: put both behind an Nginx reverse proxy with HTTPS via Let’s Encrypt, and close ports 8086 and 3000 to direct external access once that’s working, accessing both only through the proxy. The VPS Security Hardening Checklist covers the baseline this builds on.
Feeding data in from Node-RED
With Node-RED already running and subscribed to your MQTT broker, install the InfluxDB nodes:
# Via Node-RED's palette manager
node-red-contrib-influxdbAn InfluxDB out node, configured with your server’s address, the API token from setup, and the target bucket and organisation, takes any message and writes it as a time-series point. A typical flow: MQTT in node subscribed to a sensor topic, a function node shaping the payload into InfluxDB’s expected field/tag structure, then the InfluxDB out node writing it. Tags (indexed, used for filtering, like device ID or location) and fields (the actual measured values) are a genuinely important distinction in InfluxDB’s data model worth understanding early, since querying performance depends heavily on using tags correctly rather than treating everything as a field.
Connecting Grafana to InfluxDB
In Grafana, add a new data source, select InfluxDB, and enter your server’s address (http://localhost:8086 if both run on the same VPS), the API token, organisation and bucket from the InfluxDB setup. Grafana auto-detects which InfluxDB product and query language you’re using based on the connection details. Save and test; a successful connection confirms before building any dashboard.
Building your first panel
Create a new dashboard, add a panel, select the InfluxDB data source, and write a basic query for a specific measurement and tag (for example, every reading from a specific sensor’s temperature field over the last 24 hours). Grafana’s query builder handles most common patterns without needing to write raw Flux or SQL by hand, though both are available for more complex queries once you’re comfortable. A simple time-series line chart is the natural starting panel type; gauges, single-stat panels and tables are worth exploring once the basic data flow is confirmed working.
Retention: deciding how long to keep data
InfluxDB buckets support retention policies, automatically deleting data older than a configured window. For most projects on this site, keeping full-resolution data for a few months and either discarding or downsampling older data is a reasonable default, set during bucket creation or adjustable afterward, worth deciding deliberately rather than letting a bucket grow unbounded and eventually fill the VPS’s disk.
Alerting from Grafana directly
Beyond visualisation, Grafana supports alert rules directly, watching a query’s result against a threshold and notifying via email, Slack, or a webhook when crossed. This overlaps with the threshold-alerting patterns covered in this site’s Node-RED guide; which to use is mostly a matter of preference, Grafana’s alerting lives alongside the dashboards you’re already building, while Node-RED’s gives more flexible custom logic.
Frequently asked questions
Do I need both InfluxDB and Node-RED, or could Grafana read directly from MQTT?
Grafana doesn’t natively store historical data itself, it queries a data source. Some MQTT-direct Grafana plugins exist for live values, but for genuine history (charts over days, weeks, months), a real time-series database like InfluxDB sitting between MQTT and Grafana is the standard, reliable pattern this guide covers.
How much VPS capacity does this combination need?
More than MQTT and Node-RED alone, since both InfluxDB and Grafana are genuinely more resource-hungry. 2 vCPU and 2-4GB RAM is a reasonable starting point for most home or small business telemetry volumes, scaling with how much historical data you retain.
Can ThingsBoard replace this entire combination?
Largely yes, ThingsBoard bundles equivalent dashboard and storage capability into one platform. This guide’s combination suits projects wanting more granular control over the exact visualisation and storage behaviour, or already invested in a Node-RED-centric stack.
Is InfluxDB the only time-series database option?
No, TimescaleDB (a PostgreSQL extension) and Prometheus are both viable alternatives with different trade-offs. InfluxDB is covered here because it’s purpose-built for this exact use case and pairs particularly smoothly with Grafana and Node-RED’s existing ecosystem of integrations.
Can I share a dashboard with someone who doesn’t have a Grafana login?
Yes, Grafana supports public dashboard links and snapshot sharing for read-only access without requiring a full account, useful for sharing a view with a customer or colleague without granting them broader access to your Grafana instance.
Designing a dashboard people actually look at
A common early mistake: cramming every available data point onto one busy dashboard, which paradoxically makes it harder to spot what actually matters. A more effective pattern, one overview dashboard with the handful of metrics that matter most at a glance (current status, any active alerts, the headline numbers), with detailed per-device or per-sensor dashboards a click away for anyone who needs to dig deeper. Grafana’s folder and dashboard-linking features support this hierarchy directly, worth setting up deliberately rather than letting every new sensor get bolted onto one increasingly cluttered screen.
Troubleshooting common problems
Grafana shows “No data” despite InfluxDB clearly having data. Almost always a query time-range or tag-filter mismatch; confirm the dashboard’s selected time range actually covers when the data was written, and double-check tag values in the query match exactly (including case) what Node-RED actually wrote.
InfluxDB write requests fail from Node-RED. Check the API token hasn’t been mistyped or has expired, and confirm the bucket and organisation names match exactly; InfluxDB’s error messages here are usually specific enough to point at the actual mismatch if you read them carefully.
Dashboard panels load slowly as historical data grows. Often means a query without a tag filter is scanning more data than necessary; adding appropriate tag filters (by device or site, for example) rather than always querying the full dataset, combined with the retention/downsampling policies covered above, usually resolves this.
Annotations: marking events on your charts
Beyond plotting raw values, Grafana supports annotations, markers on a chart noting when something specific happened (a firmware update, a maintenance window, a known fault). These can be added manually or pushed automatically from Node-RED via Grafana’s API, useful for visually correlating a data anomaly with a known event without having to cross-reference a separate log.
What happens to data already in InfluxDB if I later switch to InfluxDB 3.x?
InfluxData provides migration tooling between major versions, though it involves a genuine migration step rather than an automatic, transparent upgrade, since the underlying storage engine and query language both change between 2.x and 3.x. Worth factoring into the decision if long-term data continuity matters for your specific project.
Can multiple Node-RED flows write to the same InfluxDB bucket safely?
Yes, InfluxDB handles concurrent writes from multiple sources without issue, a common pattern when several separate flows or even separate VPS instances all feed data into one central time-series store.
Is it possible to build a Grafana dashboard that updates in near real-time?
Yes, Grafana supports auto-refreshing dashboards at configurable intervals (down to a few seconds), suitable for genuinely live monitoring, balanced against the query load that frequent refreshing places on InfluxDB for larger dashboards with many panels.
Using dashboard variables for reusable panels
Rather than building a separate dashboard for every device, Grafana’s template variables let one dashboard adapt to a dropdown selection, picking a specific device or site and having every panel’s query update accordingly. This is worth setting up once a handful of similar devices exist (multiple sensors of the same type, for example), since it replaces what would otherwise be near-identical dashboards duplicated per device with one maintainable dashboard that scales as more devices are added, without any further dashboard-building work required per new device.
Do I need separate InfluxDB buckets per project, or can everything share one?
Either works; separate buckets give cleaner isolation and independent retention policies per project, while one shared bucket with good tagging keeps things simpler for smaller setups. There’s no strict rule, consistency with however you’ve structured the rest of your stack matters more than which specific pattern you choose.
Can Grafana connect to data sources other than InfluxDB at the same time?
Yes, Grafana supports many data source types simultaneously and can combine panels from different sources on one dashboard, useful if a project eventually mixes InfluxDB telemetry with, for example, a separate PostgreSQL database holding business data.
Is it possible to embed a Grafana panel into another website or application?
Yes, via Grafana’s panel embedding feature, generating an iframe-embeddable URL for a specific panel, useful for surfacing a live chart inside an existing internal tool without rebuilding that visualisation elsewhere.
Knowing when this combination has outgrown a single VPS
The same growth signals covered in this site’s complete guide apply specifically here too: dashboard panels becoming noticeably slower to load, or InfluxDB’s disk usage climbing faster than expected, are the clearest early indicators that retention policies need tightening or the VPS needs more resources, well before either service becomes genuinely unusable. Catching this early, by glancing at disk usage periodically rather than waiting for a problem, is considerably less disruptive than reacting to a database that’s already filled the disk and started rejecting writes from every connected device at once.
Should I run InfluxDB and Grafana in Docker rather than installing them directly?
Either approach works equally well; Docker, covered in this site’s Docker guide, suits a VPS already running several other services that way, while direct installation as shown in this guide is simpler if these are the only services on the box.
A realistic first project to build with this combination
Rather than trying to wire up every sensor in a project at once, a sensible first build: pick a single, already-working MQTT topic from the broker covered in this site’s Mosquitto guide, get it flowing through Node-RED into InfluxDB, and get one Grafana panel showing it correctly before adding anything else. This single working chain, sensor to broker to database to chart, proves every piece of the architecture is correctly connected, and every subsequent sensor added afterward is then just repeating a pattern you’ve already confirmed works, rather than debugging several new things simultaneously the first time anything goes wrong.
Once that first panel is reliably updating, the natural next steps follow in roughly this order: add a second and third sensor to the same dashboard to confirm multi-source queries work as expected, set a sensible retention policy before historical data accumulates unmanaged, and only then start building out the kind of multi-panel, variable-driven dashboards covered earlier in this guide. Building in this order, rather than attempting the full polished dashboard from the first afternoon, is the difference between a smooth, confidence-building setup and a frustrating one where it’s unclear which of five simultaneous new pieces is actually misconfigured.