This post is for platform engineers, SREs, and IT security teams evaluating Confluence apps that handle observability data from Grafana Cloud or self-hosted Grafana.
When a Confluence app renders your Grafana dashboards, alert states, and panel snapshots, it is handling operational data that describes the health and architecture of your production systems. Where that data is processed and stored is not a nice-to-have question. It is a security question.
GrafanaSight for Confluence is a Forge-native app that brings Grafana visibility into Confluence pages. It supports Grafana Cloud and Forge-reachable self-hosted HTTPS instances through customer-managed egress. This post explains what Forge-native means, why it matters for apps that handle monitoring data, and what specific security properties GrafanaSight provides.
GrafanaSight is a Flowdence product and is not affiliated with, endorsed by, or sponsored by Grafana Labs.
Two App Architectures: Connect vs Forge
Atlassian offers two architectures for Confluence Cloud apps: Connect and Forge. The difference is fundamental — it determines where your data lives.
Connect apps run on the vendor’s own infrastructure. When a Connect app fetches data from Grafana, that data can pass through the vendor’s servers, be processed on the vendor’s compute, and be stored in the vendor’s database. You are trusting both Atlassian and the app vendor with your data.
Forge apps run on Atlassian’s serverless infrastructure. The app’s code executes inside Atlassian’s cloud. Data is stored in Atlassian-managed encrypted Forge storage. Network egress is declared in the app’s Forge manifest and enforced at the platform level. The vendor ships code; Atlassian runs it.
For utility apps — formatting tools, emoji pickers, page templates — this distinction may not matter much. For apps that handle observability data, it matters a great deal.
Why Observability Data Deserves Forge
Grafana dashboards are not decoration. They encode operational knowledge: which services are monitored, what thresholds trigger alerts, how infrastructure is organized, and what the team considers important enough to watch.
An app that renders Grafana content in Confluence handles several categories of sensitive data:
- Dashboard metadata — panel titles, query structures, data source names, organizational hierarchy
- Alert states and rules — what is being monitored, current firing/pending/normal states, evaluation thresholds
- Annotation data — deployment markers, incident timelines, team-authored context on production events
- Panel snapshot images — rendered graphs that reveal traffic patterns, error rates, capacity utilization, and infrastructure topology
This is operational intelligence. If it passes through a vendor’s external server, that vendor has visibility into your monitoring posture. If it is stored in a vendor’s database, it is subject to the vendor’s data retention, encryption, and access control policies — not yours, and not Atlassian’s.
Forge eliminates this exposure. The data stays within Atlassian’s trust boundary from the moment it is fetched to the moment it is rendered.
GrafanaSight’s Security Model
GrafanaSight is built on Forge with a minimal, auditable security surface. Here is the specific model:
| Property | Detail |
|---|---|
| Runtime | Atlassian Forge — serverless, hosted by Atlassian |
| Forge permissions | Minimal least-privilege scopes; no write scopes to Confluence content |
| External fetch | Customer-managed egress to the exact Grafana HTTPS origin an Atlassian administrator approves |
| API method | All Grafana API calls are GET-only (read-only) |
| Credential storage | Atlassian-managed encrypted secret storage — never in macro config |
| Data storage | Atlassian-managed Forge storage — all cache within Atlassian infrastructure |
| Space isolation | Credentials and cache scoped per Confluence space |
| Licensing | Atlassian Marketplace license-gated features |
| Self-hosted Grafana | Supported when the instance uses a public HTTPS origin that Atlassian Forge can reach |
No external servers. No vendor database. No infrastructure for your security team to audit beyond what Atlassian already manages.
Declared Egress: No Surprises
Every Forge app must declare its external network access in its Forge manifest. The Forge platform enforces this at runtime — the app physically cannot make requests to undeclared endpoints.
GrafanaSight uses customer-managed egress instead of a fixed Grafana Cloud allowlist. When a space saves a Grafana URL, an Atlassian administrator approves that exact HTTPS origin before GrafanaSight connects. This supports Grafana Cloud and Forge-reachable self-hosted instances without granting the app a broad, static destination list.
Every Grafana API call GrafanaSight makes is a GET request. The app reads dashboard metadata, alert states, annotation data, and renders panel snapshots. It never writes, updates, or deletes anything in your Grafana instance.
Readers view panels, alerts, and health signals in documentation.
Product logic runs on Atlassian-managed infrastructure.
Snapshots and metadata stay inside Atlassian-managed storage.
Service Account tokens are stored as encrypted secrets.
The visual above shows the customer-facing data flow. App compute and cached data stay on Atlassian infrastructure. The external communication is limited to GET requests sent directly from Forge to the customer-approved Grafana HTTPS destination.
Encrypted Credential Storage
GrafanaSight requires a Grafana service account token to authenticate API requests. This token is stored using Atlassian-managed encrypted secret storage, which provides encryption at rest within Atlassian’s infrastructure.
The token is never stored in macro configuration. Macro config is visible to page editors and is included in page export data — it is not a safe location for secrets. GrafanaSight’s macro configuration contains only non-sensitive values: dashboard selectors, display preferences, and Grafana instance URLs.
Client-facing configuration views never expose token secret keys. A space admin can update or rotate the token, but the stored value is never rendered back to any UI.
Space Isolation
GrafanaSight scopes credentials and cached data per Confluence space. Each space maintains its own Grafana connection with its own service account token. There is no global credential that spans spaces.
This means:
- A team’s Grafana token in Space A cannot be used to fetch data rendered in Space B.
- Cached dashboard metadata in one space is not accessible from another space.
- Revoking a token in one space does not affect other spaces.
- Different spaces can connect to different Grafana Cloud or self-hosted instances.
For enterprises with multiple teams sharing a single Confluence instance, space isolation helps Grafana access boundaries in Confluence mirror the access boundaries already defined in Grafana.
Forge-Native Trust Signals
For an observability app, Forge-native means the app is built on Atlassian’s Forge platform: Atlassian-hosted compute, Atlassian-managed credential storage, declared external endpoints, and no vendor servers in the path. Every Flowdence product is Forge-native.
That architecture gives InfoSec teams practical trust signals during review:
- No vendor compute or storage to audit. The app’s code runs on Atlassian Forge; Flowdence does not operate any servers, databases, or storage that handle your Confluence or Grafana data.
- Atlassian’s compliance certifications cover the runtime. SOC 2, ISO 27001, and the other certifications that apply to Atlassian Cloud also apply to the Forge execution environment your installation runs inside.
- External connections are customer-approved and auditable. GrafanaSight connects only to the Grafana HTTPS destination an Atlassian administrator approves for the installation.
- Credentials stay in Atlassian-managed encrypted storage. Your Grafana service account token never leaves the Atlassian platform.
This is why we build every Flowdence product — GrafanaSight, ApprovalFlow, and MuleSight — on Forge. The security model is not a feature we add after the fact. It is the foundation the product is built on.
What This Means for Your Security Review
If your InfoSec team is evaluating GrafanaSight, here is what the Forge-native architecture gives you:
Shorter vendor security questionnaires. Most questions about data storage, encryption at rest, server hardening, backup policies, and access control are answered by “runs on Atlassian Forge.” The vendor (Flowdence) ships code. Atlassian runs it. Your existing Atlassian Cloud security assessment covers the runtime.
No new attack surface. A Connect app adds the vendor’s infrastructure to your attack surface. A Forge app does not. GrafanaSight introduces no servers, databases, or storage endpoints outside Atlassian’s boundary.
Auditable egress. GrafanaSight uses Forge customer-managed egress. An Atlassian administrator reviews the exact Grafana HTTPS origin before approving it, and the app’s Grafana access remains GET-only.
Credential storage stays in Atlassian. Grafana service account tokens are stored in Atlassian-managed encrypted secret storage and rotated through Confluence space settings. Your token management process does not need to account for a Flowdence-operated credential store.
Compliance-friendly documentation. For teams that need to document their Confluence app landscape for SOC 2, ISO 27001, or internal security reviews, GrafanaSight’s Forge-native architecture produces a clean, auditable story. We maintain a trust page with the security details your compliance team needs.
For full product documentation, see the GrafanaSight docs.
FAQ
What does Forge-native mean for a Confluence app?
Forge-native means the app runs entirely on Atlassian’s serverless infrastructure. There are no external servers to manage, audit, or trust. The app’s code executes inside Atlassian’s cloud, data is stored in Atlassian-managed encrypted storage, and network egress is declared and enforced at the platform level.
This is distinct from Connect apps, which run on the vendor’s own servers and require you to trust both Atlassian and the vendor’s infrastructure with your data.
Why is Forge better than Connect for observability apps?
Connect apps run on the vendor’s own servers, meaning observability data — dashboard metadata, alert states, panel images — passes through and is stored on third-party infrastructure. Forge apps process and store data entirely within Atlassian’s cloud.
For apps handling sensitive monitoring data, this eliminates an entire class of vendor-infrastructure concerns. Grafana data travels directly between Atlassian Forge and the customer-approved Grafana destination; it does not pass through Flowdence-operated infrastructure.
What egress restrictions does GrafanaSight have?
GrafanaSight uses customer-managed egress. An Atlassian administrator approves the exact Grafana HTTPS origin before the app connects, and all Grafana API calls are GET-only. This supports Grafana Cloud and Forge-reachable self-hosted HTTPS instances.
Grafana service account tokens are stored in Atlassian-managed encrypted secret storage, not in macro configuration or app storage. This means credentials are encrypted at rest and never exposed in page exports or macro config views.
Does GrafanaSight store monitoring data on external servers?
No. All cached dashboard metadata, alert summaries, annotation data, and panel snapshot images are stored in Atlassian-managed Forge storage within Atlassian’s infrastructure.
GrafanaSight has no external servers, databases, or storage. Flowdence ships code to the Forge platform; Atlassian runs it and stores the data.
Can GrafanaSight connect to self-hosted Grafana instances?
Yes. GrafanaSight supports self-hosted Grafana when the instance uses a public HTTPS origin that Atlassian Forge can reach. An Atlassian administrator must approve the exact destination. Localhost, private IP literals, plain HTTP, and URLs containing credentials or paths are not supported.
Related Posts
- Stop Screenshotting Grafana Dashboards
- From Dashboard to Documentation: GrafanaSight for Platform Teams