Why an air-gapped network needs a Datadog alternative that runs inside it
If your network is isolated from the internet, Datadog cannot be used as designed, because its monitoring, APM and log platform runs only as a hosted service in its regional sites. The practical path for a disconnected network is a self-hosted stack of Prometheus, Grafana and Loki, with OpenTelemetry collectors gathering telemetry from your workloads and sending it to storage that sits entirely inside your boundary. Datadog's documentation states that each of its sites is completely independent and that data cannot be shared across sites, so a disconnected network has no way to reach a Datadog site at all, and the question becomes which self-hosted components cover what you need.
The constraint has consequences beyond connectivity. Every agent, collector, dashboard plugin, alert notifier and container image must be obtained in advance, verified, and carried across the boundary by a documented process. Your procurement and supply chain controls, including the software integrity and authenticity checks that NERC CIP-013-2 describes for utilities, will likely apply to these packages as well. Some regulated environments also require that remote access to monitoring systems follow strict perimeter rules, so decide early how operators reach Grafana and who can export data out of the network. Ask your security team which of these obligations applies to your monitoring stack before you choose components.
The short answer on options is that the open-source components are self-hosted by design: Prometheus is Apache-2.0 and has no paid enterprise edition, Grafana is AGPL-3.0 and its installation docs cover packages and Helm charts, and OpenTelemetry sits in front of them as a vendor-neutral collection layer. Some commercial platforms restrict air-gapped deployment to paid editions, so confirm the licensing of any product you shortlist before assuming it can run offline. The sections that follow cover the offline packages and updates, the storage sizing for a disconnected Prometheus and Loki setup, and how Datadog's integrations map to replacements.
What an air-gapped monitoring stack has to satisfy
An isolated network removes the hosted dependency that Datadog assumes, so the monitoring stack must work from artifacts you have verified and stored locally. The cards below cover the requirements that shape the design: no calls to hosted sites, offline updates, software verification at the boundary, vendor access control, and storage that you size and manage yourself.
No dependency on hosted sites
Datadog runs only in its own regional sites, and each site is independent, so telemetry cannot be routed to a hosted endpoint from a disconnected network. The stack must run entirely on local hosts: Prometheus scraping targets inside the enclave, Grafana reading from a local database, and Loki receiving logs from local shippers. Check every component for outbound calls at startup and during alerting, including plugin catalogs, update checks and license callbacks, and block them at the boundary so failures are visible.
Offline packages and updates
Every package, container image, Helm chart and rule file must be mirrored into the enclave before it is needed. Grafana publishes Debian, RHEL, SUSE and Docker artifacts, and Prometheus ships as a single binary, so build an internal repository and image registry from which all installs and upgrades run. Plan an update path that carries new releases across the boundary on a fixed schedule, and confirm which Grafana minor releases remain supported long enough to match your change window.
Verified artifacts before crossing the boundary
NERC CIP-013-2 requires supply chain procurement processes to address verification of software integrity and authenticity for vendor software and patches, and the same discipline applies to any monitoring stack in an isolated enclave. Record checksums and signatures for each package, verify them on the inside, and keep a manifest of every exporter, dashboard plugin and rule set. Confirm with each vendor which signing keys and checksum files they publish, and whether plugins you use are signed.
Remote vendor access controls
NERC CIP-005-7 requires Interactive Remote Access to high and medium impact systems to pass through an Intermediate System with encryption and multi-factor authentication, and to include methods to detect and disable active vendor sessions. If your monitoring stack sits in an energy environment, route any vendor support session to Grafana, Prometheus or Loki through that controlled path. Outside energy, apply the same logic: no standing vendor access, time-boxed sessions and logged actions against the monitoring hosts.
Local identity and authentication
Grafana's SAML, team sync and SCIM provisioning are available only in Grafana Enterprise and Grafana Cloud, so an isolated deployment must confirm which identity option it can use. LDAP, generic OAuth and auth proxy work in all editions, and each needs an identity source reachable inside the enclave. Decide where user accounts, group mappings and service accounts live, and test that a directory outage does not lock out the operators who must respond.
Local storage and retention planning
Prometheus stores data on a single node and is not clustered or replicated, and its default retention is 15 days. Without internet access you cannot push history to a hosted store, so decide retention, disk size and any remote write target inside the enclave before go-live. Back up Grafana's database, which must be MySQL or PostgreSQL for production, and test restores from media you carry in, since no external copy will exist.
Which open-source options fit a disconnected network
This table compares the open-source components that would form a self-hosted monitoring stack inside a disconnected network, against the constraint of running with no internet access. Read each row for licensing, the offline fit and the trade-off to check before you commit. The main takeaway is that the core stack is workable offline, but storage design, database choice and licensing of optional parts need explicit decisions.
| Component | Role and offline fit | Licensing | Trade-offs to check |
|---|---|---|---|
| Prometheus | Scrapes metrics over HTTP from targets inside the enclave and evaluates alert rules. Runs without external services once installed from offline packages. | Apache-2.0, with no paid enterprise edition of the project | Local storage is not clustered or replicated, and it defaults to 15 days of retention. Plan for remote write to long-term storage if you need history. |
| Grafana | Dashboards and alerting that query Prometheus and Loki. Packages and Docker images can be mirrored into the enclave. | AGPL-3.0-only for Grafana since the April 20, 2021 relicense, with Grafana Enterprise as a commercial option | Production needs MySQL 8.0 or later or PostgreSQL 12 or later, because SQLite does not scale. SAML and SCIM are only in Enterprise, so confirm your identity needs. |
| Loki | Log storage and querying for the disconnected network, fed by agents or the OpenTelemetry Collector. | AGPL-3.0, as relicensed with Grafana, Loki and Tempo on April 20, 2021 | Log volume drives object storage sizing. Confirm the object store you can run inside the enclave and how it is backed up. |
| Jaeger | Distributed tracing backend that receives OpenTelemetry traces. Jaeger v2 is built on OpenTelemetry Collector components. | Apache-2.0 and a graduated CNCF project (graduated October 2019) | Trace storage needs its own backend and sizing. Confirm which storage option you will run and how trace retention is managed offline. |
| OpenTelemetry Collector | Receives, processes and exports telemetry from applications and hosts in the enclave, replacing Datadog Agent pipelines. | Vendor-neutral, open-source CNCF framework (Apache-2.0 for its components) | The Collector is not a backend. Each receiver, processor and exporter you use must be packaged and vetted for the offline build. |
| Zabbix | Host, server and network monitoring for systems that cannot run Prometheus exporters, with agents and proxies inside the isolated network. | AGPL-3.0 from Zabbix 7.0. Versions up to 6.4 remain GPL-2.0. Technical support is sold separately. | Zabbix does not cover APM or log analytics. Check the license version you deploy, and confirm whether paid support is required for your change control. |
| SigNoz | OpenTelemetry-native platform covering traces, metrics, logs and alerts in one application. | Open core: code outside the ee/ and cmd/enterprise/ directories is MIT, and code inside them is under a separate enterprise license | Confirm that every feature you need sits in the MIT code. Features in the enterprise directories may require a paid agreement. |
| Grafana Enterprise | Commercial edition of Grafana with features such as SAML and team sync, relevant to controlled access in an isolated network. | Commercial, non-AGPL option from Grafana Labs | Treat it as a paid dependency. Ask Grafana Labs for its terms for offline installation, updates and support before you plan around it. |
Where Datadog's hosted model stops working offline
Datadog cannot reach a disconnected network because its backend only runs as a hosted service. Datadog operates separate regional sites, including US1, US3, US5, EU1, AP1, AP2, UK1, US1-FED and US2-FED, and Datadog's documentation states that each site is completely independent and that data cannot be shared across sites. Telemetry from an isolated environment has no path to a Datadog site, and there is no documented option in the supplied material to run the Datadog backend or UI inside your own network. Any plan for an air-gapped estate has to start from that fact rather than from the Datadog feature list.
The Datadog Agent is open source, which often leads to the question of whether it can serve as an offline monitoring core. Its user space components are Apache-2.0 and its eBPF code is GPL-2.0, according to the Datadog Agent repository. The Agent collects and forwards data, but the backend that stores, queries, alerts on and displays that data is not open source. An open Agent therefore does not give you an offline Datadog, and it still needs a destination it can reach. On a disconnected network, the Agent's useful role is limited to what it can send to an internal system you run yourself.
Before committing to a replacement, confirm with Datadog in writing whether any offline, on-premises or disconnected option exists for your account, your region and your compliance scope, and what the vendor does not support. Ask for that answer in the vendor's own terms, and record it alongside your network boundary requirements. The practical decision then becomes which self-hosted components will receive, store and display telemetry inside the isolated network, and how their packages and updates will cross the boundary.
How to deploy Prometheus and Grafana inside the boundary
This sequence moves Prometheus, Grafana, Alertmanager and the log and trace backends into a disconnected network with every package and image verified before import. It ends with a stack that can be rebuilt from files and updated from new media.
Build the offline package and image set
The platform team lists every package, container image, Helm chart and rule file the stack needs, then pulls them on a connected staging host. For Kubernetes clusters, the kubeadm config images list and pull commands fetch control plane images in advance, so the cluster can be built without internet access. Check each artifact's checksum and signature against the publisher's release materials before it crosses the boundary. Done when the manifest lists every artifact with a recorded hash and an owner who approved the transfer.
Mirror images into the internal registry
Push the verified container images into a private registry inside the network and record the image digests in the deployment manifest. If the cluster is built with kubeadm, point kubeadm init at that registry with the --image-repository flag so nodes never reach a public source. Confirm that every workload references the internal registry by digest, not by a mutable tag. Done when a test pod on each node pulls its image from the internal registry without outbound access.
Install Prometheus and Alertmanager
Install Prometheus from an operating system package or a verified container image, and set its local retention to match the storage you have sized, since the default is 15 days. Start Prometheus with the OTLP receiver flag only if your OpenTelemetry Collectors will send metrics to it. Deploy Alertmanager as a cluster using its cluster flags, and configure Prometheus to point at every Alertmanager instance rather than a load balancer. Done when Prometheus shows all scrape targets as up and a test alert reaches the receiver through each Alertmanager instance.
Set up Grafana with MySQL or PostgreSQL
Install Grafana from the packages or container image in your mirror, and point its configuration database at MySQL 8.0 or later, or PostgreSQL 12 or later, instead of the default SQLite. The Grafana docs state SQLite does not scale for production, so use the external database for any production or high availability deployment. For high availability, run two or more active-active Grafana servers behind a load balancer sharing that database, and configure alerting to avoid duplicate notifications. Done when two Grafana nodes serve the same dashboards and a login session works on either node.
Deploy Loki and Jaeger for logs and traces
Deploy Grafana Loki for logs and Jaeger for distributed traces, both fed by an OpenTelemetry Collector inside the boundary. Size object storage for logs and traces against the retention you set, because those costs recur every month. Confirm the Collector's exporters point only at internal endpoints. Jaeger is Apache-2.0, and its v2 line is built on OpenTelemetry Collector components, so check the release notes for the version you mirror. Done when a test service emits a trace and a log line that appear in Grafana through their data sources.
Configure provisioning and as-code rebuilds
Define data sources, dashboards and alerting resources as YAML or JSON provisioning files that Grafana loads at startup, and store them in an internal Git repository. Grafana documents further as-code options, including Terraform and Git Sync, which you can evaluate for your change process. Apply the security hardening settings from the Grafana docs, including secure cookies, a Content Security Policy and authentication on the metrics endpoint. Done when a clean Grafana instance rebuilt from the repository reproduces the same data sources and dashboards without manual edits.
Review and import each update from new media
Carry each new release across the boundary on new media, verify its checksums and signatures, and review the release notes for breaking changes before import. Grafana's upgrade guidance describes patch releases at least monthly and minor releases every other month, and Prometheus minor releases stop receiving bug fixes after six weeks, so plan imports on that cadence and prefer LTS lines for Prometheus where they fit. Stage the update in a test environment, then roll it to production. Done when the change record shows the verified hashes, the test results and the rollback point.
Document the boundary controls and evidence
Record the controls that the platform relies on: how media is approved and scanned, who can import packages, how access to the monitoring stack is authenticated, and where the configuration repository is kept. Ask your assessor which evidence they expect for supply chain and change control, since requirements vary by sector. Keep logs of every import and every configuration change. Done when a reviewer can trace any running component back to an approved artifact and a recorded change.
Sizing storage and retention without a managed backend
Prometheus keeps its own data on local disk, so storage sizing is a decision you own. Prometheus writes samples into a local time series database organized into two-hour blocks, with a write-ahead log in front of them. The default retention is 15 days, and you can set retention by time or by size. Local storage is not clustered or replicated, so it has to be managed like any other single-node database: plan disk capacity with headroom, back up the data directory on a schedule you can restore from, and monitor free space so the server does not stop ingesting when the disk fills. In a disconnected network, there is no hosted service to fall back on, so these checks belong in the runbook from the start.
For longer history, Prometheus supports remote write and remote read, which send samples to and read them from an external long-term storage system. Inside an isolated network, Grafana Mimir is the usual option to evaluate because it is built for long-term Prometheus storage and runs entirely on your own hardware. Mimir is AGPL-3.0-only, so confirm with your legal team how that license applies to your deployment before you commit. Mimir adds components to install, upgrade and back up through the same offline package process as the rest of the stack, so treat it as a second system with its own capacity plan.
Do not size storage from published figures or from another organization's cluster. Run a pilot on the network you will actually use and measure your own active series count and sample ingestion rate over at least one full business cycle, then multiply by the retention you need and add headroom for compaction and growth. Ask your team to confirm the retention period that your operational and compliance obligations require, because that number, not the Prometheus default, drives disk size. Record the results so the sizing can be repeated when new exporters or services are added.
Common questions about air-gapped Datadog alternatives
Can Datadog integrations be replaced one for one in an air-gapped network?
No, not one for one. Most Datadog integrations rely on the Datadog Agent and its hosted backend, so each one needs a replacement path: a Prometheus exporter, an OpenTelemetry Collector receiver, or a Grafana data source. Some integrations have a direct equivalent and some do not. Build a table that maps every integration in use to its replacement, then confirm each mapping against the exporter's documentation and test it on your own data before you retire the Datadog monitor it feeds. The Datadog Agent is open source, but its backend and UI are not, so the agent alone does not restore the hosted features.
What does the work need from our own team?
Your team owns the decisions that only your organization can make. Expect to provide the following:
- Named owners for the monitoring platform, its alert rules and its on-call routing
- Access to the isolated network, change windows and a process to carry approved packages across the boundary
- A list of the systems, metrics, logs and traces that matter for each service, plus the dashboards and alerts people rely on today
- Sign-off on retention periods and on which data may be stored in the isolated network
The platform engineers who will operate the stack should take part in design and testing from the start, not only after installation.
Can our own staff run an air-gapped Prometheus and Grafana stack without outside help?
Some teams can, especially those already running Linux, Kubernetes or Prometheus in connected environments. The harder parts are offline package management, certificate handling, storage sizing, and keeping alert rules and dashboards under version control. Grafana documents packages for common Linux distributions, Docker images and Helm charts, and it requires MySQL or PostgreSQL for production and high availability, which adds a database to operate. Assess your team's skills against that list. Engagements with DeployOpen are fixed-scope and agreed in writing, and ongoing support is available as a retainer if you want help after go-live.
How long does a pilot take in an air-gapped environment?
No duration has been established for this work, so ask for a scope rather than a timeline. The length of a pilot depends on how many integrations and dashboards you need to replace, how quickly approved packages can cross your boundary, whether the target environment already has a database and container platform, and how many people can review results. A written scope from DeployOpen will set out the deliverables and the timeline before work starts. Ask for the pilot's exit criteria as well, such as which services must report, which alerts must fire, and what evidence your reviewers need.
How do updates reach a disconnected network?
Updates arrive as reviewed packages carried across the isolation boundary. Each release of Prometheus, Grafana, Loki and their exporters should be downloaded in a connected staging zone, checked for integrity and authenticity, and then transferred under your change control. Prometheus releases follow a six-week minor cycle, and Grafana publishes patch releases at least monthly, so plan a recurring intake process rather than an occasional one. NERC CIP-013-2 is a useful reference for supply chain verification if you operate in the energy sector. Confirm the exact cadence and the support windows for each component with its project before building the process.
What drives the cost of running this stack?
Most of the cost is people and infrastructure, not licenses, since Prometheus is Apache-2.0 and has no paid enterprise edition. The main components are:
- Staff time to design, operate, patch and document the stack, which is the largest recurring cost
- Compute and memory for Prometheus, Grafana, Loki and their supporting services
- Storage for metrics and logs, which grows with retention and cardinality
- Offline package intake, testing and change control
- External support, if you buy an implementation or a retainer
One-time costs include design, integration mapping and migration. Recurring costs include storage, staff and support. Ask any provider for a quote that separates these lines, and ask what changes the price if your retention period or data volume grows.
Can Grafana Cloud or Datadog be used at all in an isolated network?
No. Datadog runs only as a hosted service in its regional sites, and its documentation states that each site is independent, so an isolated network cannot reach it. Grafana Cloud is also a hosted service, so it cannot run inside a disconnected network either. The self-hosted open-source components are the path for isolated environments: Prometheus, Grafana and Loki can run entirely inside your own infrastructure. Check any tool you plan to use against its offline documentation, because some vendors restrict air-gapped deployment to paid editions.
Evidence assessors ask for from an isolated monitoring stack
An isolated monitoring stack is only as defensible as the records behind it. The cards below cover the artifacts you keep on your side of the air gap, from imported packages to restore tests. DeployOpen prepares this evidence, but auditors and certification bodies issue any assessment or certification.
Offline package inventory with hashes
Keep a manifest of every package, container image and rule set carried across the boundary, with its version, source, SHA-256 hash and the signature check result. Store the manifest outside the isolated network so it survives a rebuild. Before each transfer, confirm that the hashes on the import media match the manifest and that signatures verify against the publisher keys you trust. This is the evidence behind the software integrity question in NERC CIP-013-2 if you are in scope for it. Ask your vendors which signing keys they publish.
Change log of imported releases
Record each import as a dated entry that names the Prometheus, Grafana, Loki and exporter versions brought in, who approved the transfer and what changed compared with the previous release. Prometheus minor releases stop receiving bug fixes after six weeks, so the log shows whether you stayed on a supported line. Compare the log against the release cycle and the Grafana upgrade guidance when you plan the next import.
Configuration as code in version control
Keep Prometheus rules, Alertmanager routes, Grafana data sources, dashboards and alert rules in a Git repository that sits inside the isolated network. Grafana provisioning loads these resources from YAML or JSON files at startup, so a reviewed commit can be traced to the running state. Require review for changes to alert routing and data sources, and check that the repository state matches the deployed configuration after each change window.
Access reviews for Grafana and remote sessions
Review who holds Grafana administrator, editor and viewer roles, and which vendor or engineer sessions reach the network through remote access. Grafana's SAML, team sync and SCIM provisioning are limited to Grafana Enterprise and Grafana Cloud, so on the open-source edition the review is manual unless you use a supported OAuth or LDAP integration. For CIP-005-7 scope, record how interactive remote access passes through the intermediate system and how active vendor sessions are detected and disabled.
Backup and restore test records
Keep dated records of restore tests for Grafana's configuration database, Prometheus data where you need it and the Loki object storage. Grafana needs MySQL or PostgreSQL for production, so the database backup and restore procedure belongs in this record. Note the restore time you observed, the version restored and who verified that dashboards and alert rules worked afterward. A backup that has never been restored in the isolated network is not yet evidence.
How DeployOpen deploys monitoring under an air-gapped constraint
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including air-gapped networks. For Datadog alternative work, we scope a self-hosted monitoring stack that runs fully inside the isolated boundary, with the offline packages, storage plan and integration mapping agreed in writing before work starts.
How we scope
- Written scope lists which telemetry sources, dashboards and alert rules move off Datadog
- We confirm the isolated network boundary, approved transfer media and who handles package intake
- We agree storage retention and sizing assumptions with your team before any build begins
- Engagements are fixed-scope, with deliverables and timelines confirmed in writing first
How we build
- Offline package bundles for Prometheus, Grafana and Loki are prepared and checked before transfer
- Exporters and OpenTelemetry Collector pipelines are configured for each in-scope source
- Grafana provisioning files keep data sources, dashboards and alert rules in version control
- Security hardening settings are applied and tested against the agreed configuration baseline
How we hand over
- Runbooks cover offline updates, backups, storage capacity checks and restore procedures
- Each dashboard and alert rule is listed against the Datadog monitor it replaces
- Access, authentication and retention settings are documented for your audit and assessment teams
- Handover sessions train operators on daily use, alert routing and troubleshooting
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- Retainers can cover reviewing vendor release notes and preparing offline upgrade bundles
- DeployOpen prepares evidence for compliance assessments but does not issue audit reports or certifications
- Independent auditors and certification bodies make the final assessment decisions
