DEV Community

Cover image for Running Dynatrace Managed offline in air-gapped mode
Span Observer
Span Observer

Posted on Originally published at span.observer

Running Dynatrace Managed offline in air-gapped mode

#airgapped #compliance #dynatracemanaged #isolatednetwork

Banks, defence, critical infrastructure operators, manufacturing: in many settings, production servers simply have no route to the internet. This is precisely one of the original use cases for running Dynatrace Managed offline: keeping all observability data inside your perimeter, without depending on an external service.

But a cluster cut off from the world also loses what makes day-to-day operations comfortable: the connection to Mission Control that synchronises the licence, offers new versions and makes support easier. In offline mode, these flows become manual operations, each with its own procedures, its own risk of being forgotten and its own security constraints (file transfer, integrity checks, traceability).

This article describes how to run an air-gapped Managed cluster with confidence: what changes compared with a connected cluster, how to handle licence, updates and support by hand, and how to organise file flows to stay up to date without opening a gap.

Connected vs offline: what really changes

Function Cluster connected to Mission Control Offline cluster
Licence Synchronised automatically Licence file imported manually, renewal to be planned ahead
Cluster updates Synchronised automatically from Mission Control Links emailed to licence contacts; dynatrace-managed-{version}.sh package transferred and applied manually
OneAgent / ActiveGate installers Available as soon as the update lands Not included in the cluster: an « agents bundle » to upload in the CMC (Settings > Automatic update) or copy to /var/opt/dynatrace-managed/agents
Support Remote access possible, simplified diagnostics upload Diagnostics exported and then sent offline
Licence consumption Reported automatically Usage reports exported periodically according to your contract

Inside the perimeter, nothing changes: OneAgents, ActiveGates and users talk to the cluster exactly as in connected mode. The whole difference lies at the boundary between your network and the outside world.

Dynatrace Managed offline: typical air-gapped site architecture

  • Isolated zone: cluster nodes, ActiveGates, monitored hosts. No internet egress.
  • Transit workstation or server in a connected zone, used to download packages and the licence from the links in the activation or update email.
  • Controlled transfer mechanism: data diode, decontamination station, encrypted removable media — depending on your security policy.
  • Internal repository (file share or artefact repository) where validated packages are placed, reachable from the isolated zone.

This internal repository is central: it becomes the single source of installers for your automation (Ansible, golden images, Kubernetes pipelines), which obviously cannot fetch anything from outside.

Step-by-step tutorial

Step 1 — Install the cluster in offline mode

During installation, the Linux installer runs as root on the first node. The package and the licence file have been transferred beforehand:

openssl cms -inform PEM -binary -verify -CAfile dt-root.cert.pem \
  -in dynatrace-managed-{version}.sh.sig -content dynatrace-managed-{version}.sh > /dev/null
sudo /bin/sh dynatrace-managed-{version}.sh --license-file license.lic
Enter fullscreen mode Exit fullscreen mode

The signature check (root certificate and .sig file provided in the activation email) should answer « Verification successful ». The --license-file parameter, used instead of a key, is what enables offline mode; other options are listed by --help. After installation, activate the licence in the CMC (Licensing > Activate license, through the mcsvc.dynatrace.com form opened from a connected workstation), then upload the agents bundle. By default, binaries go into /opt/dynatrace-managed and data into /var/opt/dynatrace-managed.

Step 2 — Check the connection mode in the CMC

In the Cluster Management Console, the Mission Control connection settings page should reflect the offline state. Also disable any feature that would try to reach an external resource, and make sure your firewalls log any outbound attempts: they reveal an incomplete configuration.

sudo journalctl -u dynatrace-server --since today | grep -i -E "mission|connect|timeout" | tail -n 20
Enter fullscreen mode Exit fullscreen mode

Step 3 — Manage the licence

Note the licence expiry date as soon as you import it and set a reminder at least one month ahead. To renew:

  1. Get the new license.lic file attached to the email received on the transit workstation.
  2. Transfer it through the controlled channel.
  3. Apply it in the CMC: Licensing, then More (…) > Apply license.
  4. If your contract requires it, export the consumption report and send it back through the same channel in the opposite direction.

Step 4 — Prepare an update package

On the transit workstation, download the target version and its published checksum. Build a dated folder:

mkdir -p transfer/{version}
mv dynatrace-managed-{version}.sh transfer/{version}/
sha256sum transfer/{version}/* > transfer/{version}/SHA256SUMS
Enter fullscreen mode Exit fullscreen mode

Add the release notes and your runbook. After the transfer, check the checksums again in the isolated zone:

cd {internal-repo}/{version} && sha256sum -c SHA256SUMS
Enter fullscreen mode Exit fullscreen mode

Step 5 — Apply the update

First things first: node health in the CMC, disk space (df -h) and a recent NFS backup. Then apply the update in semi-automatic mode (packages uploaded in the CMC) or manually: copy the package to /opt/dynatrace-managed/installer/upgrade on each node, then run ./dynatrace-managed-{version}.sh --upgrade as root, one node at a time, waiting for each node to finish before the next. Follow the progress:

sudo journalctl -u dynatrace-server -f
Enter fullscreen mode Exit fullscreen mode

Do not skip intermediate versions if the release notes require a migration path: offline, that path must be prepared in a single transfer.

Step 6 — Distribute OneAgent and ActiveGate

Once the agents bundle is uploaded, the matching installers are served by your own cluster. Your automation can fetch them from the isolated zone:

curl -o oneagent.sh -H "Authorization: Api-Token {token}" \
  "https://{your-domain}/e/{environment-id}/api/v1/deployment/installer/agent/unix/default/latest?arch=x86"
sudo /bin/sh oneagent.sh --set-host-group={group} --set-network-zone={zone}
Enter fullscreen mode Exit fullscreen mode

For Kubernetes, the Dynatrace Operator and component images must be pushed to an internal registry, and the DynaKube configured with apiUrl: https://{your-domain}/e/{environment-id}/api and image references pointing to that registry.

Step 7 — Prepare offline support

In an incident, support will need logs. Identify in advance the CMC diagnostics export function, where the resulting archives are stored and the procedure for getting files out (with a content review if your rules require it). For a monitored host:

sudo tar czf diag-{host}-$(date +%F).tgz /var/log/dynatrace/oneagent/
Enter fullscreen mode Exit fullscreen mode

Best practices

  • Transfer schedule: a fixed monthly slot for importing updates and the licence prevents gradual obsolescence.
  • Systematic integrity checks: checksums verified before and after transfer, recorded in a log.
  • A single internal repository for all Dynatrace binaries, versioned and read-only for automation.
  • The cluster monitoring itself: an operations environment tracks the nodes’ disks, CPU and services, since no external alert will come.
  • Licence reminders in several tools (team calendar, ITSM): an expired licence offline cannot be fixed in one click.

Frequently asked questions

Do OneAgents behave differently on an offline cluster?

No. Inside the perimeter, OneAgents, ActiveGates and users talk to the cluster exactly as in connected mode; only exchanges with the outside world (licence, updates, support) become manual.

Where does automation get the installers from?

Once the agents bundle (delivered separately from the cluster) is uploaded, the OneAgent and ActiveGate installers are served by your own cluster through the environment API. Container images, on the other hand, must be pushed to an internal registry.

How do I avoid a licence expiring?

Note the expiry date as soon as you import the licence, set reminders at least one month ahead in several tools, then import the new licence into the CMC after bringing it in through the controlled channel.

Conclusion

Running Dynatrace Managed air-gapped is entirely viable, provided you accept that everything Mission Control used to automate becomes a documented process: licence, updates, agent distribution, support. With a reliable internal repository, systematic integrity checks and a regular transfer schedule, your isolated cluster stays as up to date and as useful as a connected one — without ever exposing your data.

span.observer is an independent community blog, not affiliated with Dynatrace LLC. Dynatrace is a trademark of Dynatrace LLC. Always check values (ports, versions, sizes) against the official documentation for your Managed version.

Originally published on span.observer. French version: https://span.observer/fr/mode-offline-air-gapped/.

Top comments (0)