Grafana Ports
You set up grafana ports in your server settings file and firewall rules. This setup controls how users reach dashboards and how the app queries data. Teams often open broad network paths to get charts working fast. Overly broad network and role permissions let anyone on the network query raw data. A good setup limits both network paths and what each user role can run. How grafana ports work in your network The dashboard app listens on one main web port for user browser traffic. Users log in
Grafana Access Control: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up grafana ports in your server settings file and firewall rules. This setup controls how users reach dashboards and how the app queries data.
Teams often open broad network paths to get charts working fast. Overly broad network and role permissions let anyone on the network query raw data. A good setup limits both network paths and what each user role can run.
How grafana ports work in your network
The dashboard app listens on one main web port for user browser traffic. Users log in through this port to view charts and manage alert rules. You can change this listening port in the main server settings file.
Admins often place a load balancer in front of the dashboard server. The load balancer takes external traffic on standard web ports and forwards it. This design keeps the app server off the public internet.
The server also opens outbound network connections to your data sources. Each database or metric store listens on its own dedicated network port. Your firewall must allow the dashboard server to reach those specific database ports.
If you run high availability alerts, servers also talk to each other. Cluster nodes use a separate gossip port to sync alert states across servers. You should keep this cluster port closed to all outside traffic.
What native network rules solve and what they miss
Firewall rules and port settings control which machines can talk to each other. They stop outside attackers from reaching your dashboard server or internal data stores. Native role settings also decide who can log in and edit charts.
Still, network ports and app roles do not inspect live queries in flight. Once a port is open, the app uses one shared database account. Anyone with query permissions in the dashboard can run heavy or broad requests.
Grafana Access Control: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
A port rule only checks the network address and port number. It cannot tell a safe chart query from a full table dump. It also cannot mask sensitive fields like emails or phone numbers in results.
Teams also need to manage the host server where the app runs. Admins log in over SSH or kubectl ports to edit server files. Native port rules let the admin in, but do not log specific commands.
Best practices for securing dashboard traffic
Start by binding the web server to a private network address. Only let your load balancer reach the main web port on the server. Turn on TLS encryption so nobody can read traffic on the wire.
Next, lock down outbound ports from the dashboard server to your data stores. Only open the exact ports needed for your active metric and log stores. Block all other outbound traffic from the server host by default.
Review the database roles that the dashboard server uses to read data. Give that database account read permissions on specific tables or views only. Never give the dashboard database account write or admin rights on production data.
Finally, limit who can use raw query editors inside the dashboard app. Even with strict ports, an open query box lets users pull sensitive rows. Combine tight firewall rules with strict query controls to protect your data.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits inline in the protocol beside the service as an open-source proxy, a sidecar for your database or API. On every production query an agent or human runs, hoop.dev decides whether to pass, mask, block, or escalate it for review.
Before a query runs, hoop.dev guardrails check the statement against your rules, an AI Analyzer you configure can score intent or hold risky calls for human approval, and hoop.dev data masking rewrites sensitive fields in responses in memory. Explore the MIT-licensed project on GitHub.
Frequently asked questions
How do I change the main web port for the dashboard?
You edit the server settings file or pass an environment variable at startup. After you save the change, restart the server service and update your firewall.
Does the dashboard server need inbound ports open from databases?
No, the dashboard server initiates the outbound request to the database port. Your database only needs to accept inbound traffic from the dashboard server address.
Why can users still run raw queries when ports are locked down?
Firewall rules only restrict network paths between the browser, server, and database. Once traffic passes the open port, the app trusts the shared database key.