Self-hosted Dynatrace alternative for air-gapped networks

Self-hosted Dynatrace alternative for air-gapped networks: the short answer

If your isolated network runs Dynatrace Managed in offline mode and a renewal or licensing review is coming up, the short answer is that OpenTelemetry, Prometheus, Grafana and Jaeger can run fully inside the enclave, provided you mirror every package, image and dependency into it before cutover. Each component is open source and self-hosted, so the stack needs no outbound connection to a vendor to collect, store, query or alert on telemetry. The harder part is not where the data sits. It is the update path: with no outbound connectivity, every collector release, Prometheus patch, Grafana security fix and plugin must arrive through a controlled import process that your team owns. The constraint you are really solving is no outbound connectivity plus a manual update cycle. Before you commit to a design, confirm with your Dynatrace account team exactly what the offline license entitles you to, what happens to telemetry history if you stop renewing, and whether the Managed build you run receives updates on a schedule your change board can accept. Then list every component the stack needs, including operating system packages, container images, Helm charts, Go or Python dependencies and Grafana plugins, and check each one against your mirror. Plan for a staging enclave or a transfer workstation that proves the mirror works before production depends on it.

The first decision is the update model. Prometheus publishes a minor release roughly every 6 weeks and generally stops fixing a minor release after those 6 weeks, so inside an air gap you must either adopt the long-term support line or budget for a regular import of new minor releases. Grafana's upgrade guidance describes monthly patch releases, and each minor release has a published support window, so a patch cadence is the minimum you should plan for. The OpenTelemetry Collector also ships frequent releases with signed artifacts, SHA256 checksums and SBOM files. Use those checksums and SBOMs in your import review so each artifact entering the enclave is verified and recorded. Finally, decide who runs the stack. Grafana's high-availability guidance expects a shared MySQL or PostgreSQL database for production, and Prometheus local storage is not clustered, so you need named owners for backups, retention and restore tests. Confirm with each vendor and project which features your environment depends on, such as SAML or SCIM in Grafana, which the authentication docs place only in Grafana Enterprise and Grafana Cloud. Those gaps belong in the risk register before the renewal date, not after it.

What an air-gapped enclave requires from a monitoring stack

An enclave stack has to keep working when nothing outside it is reachable, and every component must be installable, updatable and recoverable by your own staff. The cards below set out the requirements that follow from how Prometheus, Grafana and the OpenTelemetry Collector are built and released.

No runtime internet dependency

Every component must start, collect, store and alert without calling a public endpoint. Check that Prometheus scrape targets, Grafana plugins, data source connections and the Collector exporters all resolve to hosts inside the enclave. Confirm that no component fetches a license check, telemetry beacon or update index at startup. Test this by blocking outbound traffic in a staging copy before cutover.

Mirrored and verified packages

Mirror container images, operating system packages, Helm charts and plugin archives into an internal registry or repository before each change. Pull only the Collector contrib distribution artifacts you have verified, and check the SHA256 checksums and SBOM files that accompany each release. Keep a signed record of what was mirrored, from which release, and who approved it.

Manual update and rollback procedures

Plan updates around release cadence, because a Prometheus minor release stops receiving bug fixes after six weeks. Prefer the Prometheus long-term support line for enclaves that cannot patch often, and confirm its end-of-life date before you commit. Grafana patch releases arrive at least monthly, so decide who applies them and how you roll back a failed upgrade, including restoring the Grafana database.

Local identity and access control

Grafana authentication options such as LDAP, generic OAuth and auth proxy must point at identity services inside the enclave. SAML, team sync and SCIM are available only in Grafana Enterprise and Grafana Cloud, so confirm which provisioning features your edition needs. Apply the Grafana security hardening settings, including secure cookies and a Content Security Policy, and require authentication on the metrics endpoint.

Local storage and retention

Prometheus runs as a single-node store that is not clustered or replicated, so plan disk capacity, snapshots and backups for each instance. Default retention is 15 days, and you must set time or size limits that match your audit needs. Grafana needs MySQL or PostgreSQL rather than SQLite for production and high availability, and it runs as two or more active-active servers behind a load balancer.

Alert delivery inside the enclave

Alertmanager routes notifications to receivers that you host, such as internal mail relays or chat servers. Point Prometheus at every Alertmanager instance, not at a load balancer, and enable the cluster flags so one failed node does not silence alerts. Grafana alerting needs extra configuration in high availability to avoid duplicate notifications, so test failover before relying on it.

What Dynatrace Managed offline mode gives up compared with an open-source stack

The first decision is which Dynatrace capabilities your enclave actually depends on, because an offline Managed deployment and a self-hosted OpenTelemetry, Prometheus and Grafana stack do not offer the same out-of-the-box experience. The features most often cited as the reason to stay on Dynatrace are automatic discovery of services and hosts, and AI-assisted root-cause analysis. Ask Dynatrace in writing which of these run unchanged in your offline Managed version, which need a connection to Dynatrace-hosted services, and which depend on data or model updates that an enclave cannot receive. Do not assume the answer from marketing material or from the SaaS feature list.

Your Dynatrace Platform Subscription terms also shape the trade-off. DPS is a consumption-based agreement, typically one to three years with a minimum annual commitment, and it can be shared across SaaS and Managed deployments. Confirm with your account team how an offline Managed deployment draws against that commitment, what happens to unused commitment when a workload moves out, and which contract terms cover support for an isolated environment. Those answers determine whether the cost of staying is a fixed obligation or a flexible one.

The open-source side gives you control over every component, but it does not give you the same integrated experience. OpenTelemetry supplies instrumentation and a Collector, Prometheus supplies metrics storage and alerting, Grafana supplies dashboards, and Jaeger or a similar backend supplies traces. Someone on your team must choose, mirror, configure, secure and upgrade each part, and you must rebuild the root-cause workflow with dashboards, queries and runbooks. Treat the inventory of Dynatrace features you use today as the requirements list for the new stack, and mark each one as available, assembled or lost before you commit to a cutover plan.

Which open-source components fit an isolated network

This table maps each open-source component to its role inside an air-gapped enclave, how it meets the offline constraint, and the trade-offs to check before you commit. Read the middle column for what must be mirrored into the enclave and the right column for licensing and architecture limits that affect your design.

Component	Role in the enclave	Offline fit and trade-offs
OpenTelemetry Collector	Receives OTLP from instrumented applications and routes traces, metrics and logs to backends inside the enclave	Apache-2.0 and vendor-neutral. Mirror the contrib distribution and its dependencies. Confirm component stability levels in each README before relying on them.
Prometheus with Alertmanager	Scrapes metrics from enclave targets, stores recent samples and sends alerts through Alertmanager	Apache-2.0 with no paid edition. Local storage is single-node and not replicated, and default retention is 15 days, so plan remote write to long-term storage.
Grafana	Dashboards, alerting views and data source access over Prometheus and trace backends	Relicensed to AGPL-3.0-only from Grafana 8.0. Confirm your legal team accepts AGPL obligations. SAML and SCIM are Enterprise features, so check your identity needs.
Jaeger	Distributed tracing backend storing and querying traces received from the Collector	Apache-2.0 and a graduated CNCF project. Jaeger v2 is built on OpenTelemetry Collector components, so confirm the storage backend you mirror and operate.
SigNoz (optional)	Single application for traces, metrics and logs, if you prefer one OpenTelemetry-native tool	Open core: code outside ee/ and cmd/enterprise/ is MIT, and code inside them is under a separate enterprise license. Confirm which features you need sit outside those directories.
Zabbix (optional)	Host, network and infrastructure monitoring for enclave equipment that lacks OpenTelemetry support	Zabbix 7.0 and later are AGPL-3.0, while 6.4 and earlier remain GPL-2.0. Support subscriptions are sold separately from the software.

Choosing packages, Kubernetes or bare metal inside the enclave

The Grafana installation documentation lists packages for Debian and Ubuntu, and this is often the simplest channel for a single-node or small team deployment inside an enclave. You download the matching package and its dependencies on a connected staging host, verify them, then move them across the boundary through your approved transfer process. Installation then happens from a local repository or from files, with no outbound access required.

Mirror the exact package set: Capture the Grafana package and the Prometheus, Alertmanager and OpenTelemetry Collector packages you plan to use, plus their dependencies, in one signed bundle.
Pin versions deliberately: Record the version you install so later patch releases are a planned change rather than an accidental update.
Plan the database: A package install still defaults to SQLite for configuration, which the docs say does not scale for production.
Keep the service account and paths documented: Your hardening baseline and audit evidence should name the service user, data directory and configuration file.
Track upstream patches: Subscribe your staging process to release notices so patch packages reach the enclave on a schedule.

Before approving this channel, confirm with your security team which signing keys and repository tooling your enclave accepts.",

How to deploy the stack inside the enclave with mirrored packages

This sequence moves the OpenTelemetry, Prometheus and Grafana stack across the transfer boundary in verified form, then runs it inside the enclave with local authentication and a repeatable manual upgrade path.

Inventory every package, image and chart
The platform team lists each component the stack needs: the OpenTelemetry Collector (contrib distribution if your receivers require it), Prometheus, Alertmanager, Grafana, the MySQL or PostgreSQL database that backs Grafana, exporters, and any Jaeger or Mimir components you plan to add. For each item, record the exact version, the operating system packages it depends on, and the container images or Helm charts if you deploy on Kubernetes. Confirm current release and support dates with each project before you freeze versions, since the Prometheus and Grafana cadences move over time. The inventory is done when a reviewer can rebuild the bill of materials from it without asking the author anything.
Mirror and verify artifacts across the boundary
Download the inventoried artifacts on the connected side, then copy them through your approved transfer process. The OpenTelemetry Collector releases ship with SHA256 checksums and SBOM files, so verify each checksum and archive the SBOMs with the transfer record. Where a project publishes signatures, verify those as well. Load container images into an internal registry and confirm digests match the source. The step closes when every artifact has a recorded checksum on both sides of the boundary and the SBOMs are stored with the change ticket.
Stand up the Collector and Prometheus
Deploy the OpenTelemetry Collector as a gateway that receives OTLP from applications inside the enclave, then configure it to export metrics to Prometheus. Prometheus can accept OTLP metrics at its OTLP endpoint when started with the --web.enable-otlp-receiver flag, or it can scrape targets directly. Set a local retention policy in Prometheus, remembering that its default is 15 days and that local storage is not clustered or replicated, so plan backups of the data directory. The step is complete when test telemetry from one service appears in a Prometheus query and the Collector health endpoint reports ready.
Configure Alertmanager for high availability
Install Alertmanager and point Prometheus at every Alertmanager instance rather than at a load balancer, as the Alertmanager documentation directs. If you run more than one instance, enable its cluster flags so silences and notification state are shared. Define routing and receivers for your internal notification channels, which must also be reachable without internet access. Trigger a test alert from Prometheus and confirm it arrives at the internal receiver once, not once per instance.
Deploy Grafana with a production database
Install Grafana from your mirrored packages or images and configure it to use MySQL 8.0 or later, or PostgreSQL 12 or later, instead of the default SQLite, which the installation documentation says is not suitable for production. For high availability, run two or more Grafana servers behind an internal load balancer that share the same database, and review the high availability notes on alerting duplicates and Grafana Live limitations. Place data source, dashboard and alerting definitions in provisioning files and keep them in version control. The step is done when Grafana reports a healthy database connection, the Prometheus data source loads from its provisioning file, and a dashboard recreated from code renders on every node.
Configure local authentication and hardening
Set up local accounts or an internal directory such as LDAP, which all Grafana editions support, and confirm which features you need before assuming them. SAML, team sync and SCIM provisioning are only available in Grafana Enterprise and Grafana Cloud, so verify that the features your access model depends on are present in the edition you deploy. Apply the security hardening settings: secure and SameSite cookies, a Content Security Policy, hiding the version from unauthenticated users, requiring authentication for the metrics endpoint, and domain verification. Restrict Collector receivers with authenticator extensions where the configuration docs describe them. The step closes when an unauthenticated request to the metrics endpoint is refused and an administrator login succeeds through the chosen method.
Run manual upgrade and rollback cycles
Because the enclave has no automatic updates, schedule each upgrade as a planned change. Use the Prometheus release cycle and LTS dates, the Grafana guidance on major, minor and patch releases with their support windows, and the Collector release notes to decide which versions to adopt. Repeat the mirror and checksum process from the earlier steps for each new artifact, and take a snapshot of the Prometheus data directory and the Grafana database before each change. Test the upgrade in a staging enclave first, then record a rollback procedure for each component. The cycle is complete when a rollback has been rehearsed once and the results are filed with the change record.

How manual updates work when nothing reaches the internet

Manual updates in an enclave follow the upstream release cadence, so the team needs to know which releases it is chasing before anything is transferred. Prometheus starts a new minor release cycle every 6 weeks, and a minor release generally stops receiving bug fixes after those 6 weeks. Prometheus long-term support releases receive bug fixes for one year, and the current LTS line is 3.13, supported until July 31, 2027. Grafana publishes major releases once a year in April or May, minor releases every other month and patch releases at least monthly, with each minor release supported for 9 months and the last minor of a major version for 15 months. OpenTelemetry Collector releases also arrive frequently, with v0.163.0 published on October 16, 2026. Choosing a support line for each component, such as a Prometheus LTS line and a Grafana minor, sets how often the enclave must absorb an update.

Every mirrored update should be installed first in a staging enclave that matches production in versions, configuration and data sources. Test the Grafana provisioning files, the Prometheus scrape and remote write settings, the Collector pipeline and any authenticator extensions against the new release, and confirm that dashboards and alert rules still evaluate. Grafana high availability also needs a check that the database schema migration completes cleanly on a copy of the production database before it runs on the live one. Keep a rollback plan with the previous package set and a backup of Grafana's database and Prometheus data directory, since Prometheus local storage is not clustered or replicated.

Confirm the transfer procedure and approval path with your security team before the first cycle. Ask who signs off on importing a package set, how media is scanned and checksummed, whether the Collector's published SHA256 checksums and SBOM files are verified on import, and how the change is recorded for audit. Confirm the schedule for security patches that cannot wait for the next planned window, and the owner who decides when an unsupported minor release must be replaced. These decisions belong to your organization's change process, so agree them in writing before the enclave depends on them.

Questions teams ask before running monitoring in an air-gapped network

What does running monitoring in an air-gapped network cost?

Most of the spend moves from software licenses to infrastructure, people and integration work, because the core components are open source. Prometheus is Apache-2.0 with no paid enterprise edition, and the OpenTelemetry Collector, Grafana and Jaeger are also open source, so the recurring costs are compute, storage, staff time for patching and on-call, and any support subscription you choose. Storage deserves attention: Prometheus keeps data in local two-hour blocks with a default retention of 15 days, so disk needs grow with series count and retention. One-time costs include design, installation, service instrumentation, dashboard and alert rebuilds, and hardening. Ask any quote for line items: components in scope, number of hosts and services to instrument, retention targets, high availability design, and who maintains the mirrored packages. Your current Dynatrace offline subscription cost comes from your agreement, not from this page.

How long does an air-gapped migration take, and what sets the pace?

The length depends on how many services need instrumentation, how many dashboards and alerts must be rebuilt, and how many approval steps the enclave requires for moving software and configuration in. The number of services to instrument usually matters most, because each service needs its own OpenTelemetry setup and validation. Release rhythm affects the work but does not set the overall length: Prometheus starts a new minor release cycle every 6 weeks, and Grafana ships patch releases at least monthly, so your change process must absorb those updates. Dual-shipping can begin once the Collector and backends pass acceptance in the enclave, and it runs alongside your Dynatrace subscription until the cutover criteria are met. Ask for a written plan with phases tied to deliverables. DeployOpen does not publish timelines; a fixed-scope agreement sets scope, deliverables and dates in writing before work starts.

What must our team supply for an enclave deployment?

Your team supplies the environment, access and decisions that no outside party can provide inside your network. Typical inputs include:

Compute, storage and network segments inside the enclave, plus the Kubernetes or virtual machine platform you intend to run.
An approved transfer process for mirrored packages, container images, Helm charts and signed release artifacts.
Identity provider details and group mappings for Grafana access, along with a decision on who holds administrator roles.
A list of services, hosts and owners to instrument, and access to their configuration and deployment pipelines.
Named staff for acceptance testing, change approval and on-call handover.

Confirm early whether your enclave permits the Dynatrace Managed endpoint and the monitoring backends to talk to each other, because that shapes the dual-shipping design.

Can our own engineers run this stack without an implementation partner?

Yes, if your team already runs Linux, container or Kubernetes platforms and has people who can write PromQL, configure OpenTelemetry pipelines and administer Grafana. Prometheus is a single-node database by design: its local storage is not clustered or replicated, so you must plan backup, retention and any remote write target yourself. Grafana needs MySQL or PostgreSQL for production and high availability, and its high availability setup requires two or more active-active servers behind a load balancer, with extra alerting configuration to avoid duplicate notifications. Teams without that experience usually need outside help for design, hardening and the first instrumentation waves. DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted platforms in your infrastructure, and ongoing support is available as a retainer. Scope and deliverables are agreed in writing before work starts.

Which Dynatrace offline features do we lose when we move?

Confirm the exact feature set with Dynatrace against your offline license and deployed version, because the entitlements for disconnected operation are defined in your agreement and documentation. In general terms, the open stack changes how several capabilities work. Automatic discovery that OneAgent provides becomes instrumentation work, because OpenTelemetry requires you to add SDKs or auto-instrumentation to each service. AI-assisted root-cause analysis becomes queries, dashboards and alert rules that your team writes and tunes. Real user monitoring is not covered by OpenTelemetry, so browser session data needs a separate tool. Dynatrace's own configuration can be exported as Monaco configuration-as-code files, which helps you keep a record of alerting and dashboards before you retire them. Ask for a written inventory of features in use, then map each one to a replacement or an accepted gap.

How do we dual-ship telemetry to Dynatrace and the new stack during cutover?

Send the same OpenTelemetry data to both destinations from one OpenTelemetry Collector, using one exporter for Dynatrace's OTLP endpoint and others for the new backends. Dynatrace ingests traces, metrics and logs over OTLP, and Prometheus can receive OTLP metrics at its OTLP path when started with the --web.enable-otlp-receiver flag, so metrics go to Prometheus and traces go to Jaeger. Logs need their own backend decision. Run the two paths side by side, compare metric values, trace coverage and alert behavior for each service, and move a service only when its dashboards and alerts match acceptance criteria. Confirm the Dynatrace Managed OTLP endpoint address, token scopes and network rules inside your enclave before you configure the exporter. Keep the Collector configuration under version control, and follow the security guidance on configuration best practices for authentication and exporter credentials.

How do we keep packages and security patches current without internet access?

Build an intake process that moves signed artifacts into the enclave on a fixed schedule, verifies them, and records what was deployed. Grafana publishes packages for Debian, Ubuntu, RHEL, Fedora and SUSE, plus Docker images and Helm charts, and its upgrade guidance says patch releases arrive at least monthly while each minor release is supported for 9 months. Prometheus long-term support releases receive bug fixes for one year, and the current LTS line is 3.13, supported until July 31, 2027, so many teams follow that line for stability. OpenTelemetry Collector releases ship with SHA256 checksums and SBOM files, which your intake can check. Confirm which mirroring tool your organization approves, how vulnerability feeds reach the enclave, and who signs off on each import. The Grafana installation documentation is a useful starting list of packages to mirror.

How does Grafana authentication work inside a closed network?

Grafana supports LDAP, generic OAuth, Entra ID, Okta, GitHub, GitLab, Google OAuth, auth proxy and JWT in every edition, so an identity provider inside your enclave can handle sign-in without internet access. SAML, team sync, active sync and SCIM provisioning are available only in Grafana Enterprise and Grafana Cloud, so confirm whether your access model depends on them before choosing an edition. Grafana's security hardening guidance covers secure and SameSite cookies, a Content Security Policy, Trusted Types, hiding the version from unauthenticated users, requiring authentication for the metrics endpoint and domain verification against DNS rebinding. Apply those settings during build, and keep the admin account separate from daily users. Ask your security team to review the chosen identity provider, token lifetimes and role mappings before go-live.

Evidence assessors ask for from an offline monitoring stack

An assessor reviewing an air-gapped monitoring stack wants to see what was brought into the enclave, how it was verified, how it is configured and who changed it. The six items below tie together the records that show the stack is controlled, not just running. Each one should exist before the first assessment, not be reconstructed afterward.

Package inventory and mirror records

Keep a dated list of every package, container image, plugin and chart that entered the enclave, with its version and the source it was mirrored from. Record who approved each transfer and the media or transfer path used. For Prometheus, Grafana and the OpenTelemetry Collector, this inventory is the baseline for every later vulnerability and upgrade decision. Ask your team to confirm that the inventory covers transitive dependencies, not only the top-level packages.

Checksum and SBOM verification logs

Store the output of every checksum comparison and every software bill of materials check performed before a component was accepted. The OpenTelemetry Collector releases ship SHA256 checksums and SBOM files, so these are the first artifacts to verify. A failed or skipped check should be logged with the reason and the decision that followed. Confirm which signature verification steps your own process requires, because not every component publishes the same artifacts.

Configuration as code through provisioning

Define Grafana data sources, dashboards and alerting resources in YAML or JSON files loaded at startup, and keep them in version control. Reviewers can then compare the running state against the reviewed files and see each change as a commit with an approver. Manual edits in the UI are the usual gap, so ask whether your process blocks them or detects them. Grafana also documents Terraform and Git Sync as additional options.

Access control and authentication configuration

Document which identity provider the enclave uses for Grafana, the roles granted to each group, and the hardening settings applied, such as secure and SameSite cookies and a Content Security Policy. Check whether your edition provides the authentication method you need, since SAML, team sync and SCIM are limited to Grafana Enterprise and Grafana Cloud. Export the configuration file and the role assignments as dated evidence.

Backup and retention settings

Record the Prometheus retention period and size limit, the location and schedule of local storage snapshots, and the database backups for Grafana configuration. Prometheus local storage is not clustered or replicated, so a single node failure can lose recent samples unless a backup or remote write target exists. Confirm the retention periods your regulator or internal policy requires, and test restores on a schedule with the results saved.

Upgrade and change records

Keep a change log that links each upgrade to its approved ticket, the release notes reviewed, the test results and the rollback plan. Prometheus minor releases stop receiving bug fixes after six weeks, so the cadence of your upgrade decisions is itself evidence. Grafana patch releases arrive at least monthly, and LTS lines are the usual choice where change windows are rare. Confirm the support window of every version in production and record any exception you have approved.

Where DeployOpen fits in an air-gapped rollout

DeployOpen plans, implements, hardens, backs up, documents and supports the self-hosted stack inside your own enclave, so the work lands on systems your team controls rather than on a hosted service. For an air-gapped Dynatrace replacement, that typically means scoping the OpenTelemetry Collector, Prometheus, Alertmanager and Grafana deployment, the package mirror that feeds them, the Grafana database backend, and the backup and restore path for Prometheus data and Grafana configuration. Each of those pieces needs a named owner on your side before any installation starts.

Most engagements are fixed-scope, so the systems in scope, the deliverables, the documentation and the timelines are agreed in writing before work begins. Ask for the scope to state which Dynatrace features are being replaced and which are being accepted as gaps, and which controls and evidence will be handed over for your internal or external assessors. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that work. Ongoing support, upgrades and continuous testing are available as retainers, which suits enclaves where a Prometheus or Grafana minor release must be validated, mirrored and approved before it reaches production.

Before you request a quote, confirm three things with your own team: who can physically or logically move approved packages across the boundary, which change process governs enclave updates, and whether your security team wants testing of the deployed stack included in the scope. DeployOpen does not publish a price list, so the quote follows from that written scope and the environment you describe. Ask the proposal to separate one-time work (design, installation, hardening, dashboard and alert rebuild, cutover) from recurring work (patching, mirror refreshes, backup verification and support), because those two lines drive very different budgets.

How DeployOpen works on this

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source monitoring inside the client's own infrastructure, including air-gapped networks. For an enclave that replaces Dynatrace Managed in offline mode, the work starts with a written scope that maps each telemetry source, retention need and alert to a component that can run without internet access.

How we scope

Inventory every host, application and log source currently reported through Dynatrace Managed inside the enclave.
Agree in writing which signals, dashboards and alerts move, and which are retired or deferred.
Define the transfer path for packages, images and updates across the air gap, with the approval process your security team requires.

How we build

Deploy OpenTelemetry Collector, Prometheus, Grafana and Jaeger from mirrored package and container repositories, with no outbound dependencies.
Configure Prometheus storage, retention and Alertmanager high availability to match the agreed scope and hardware.
Set Grafana authentication, provisioning and security hardening settings, and test the stack against the agreed scope before handover.

How we hand over

Deliver the written scope, architecture diagrams, configuration as files, and runbooks for the offline update procedure.
Document the manual update cycle, including how release and patch notices are tracked and verified inside the enclave.
Provide evidence of configuration and controls so your internal team or an independent auditor can review them.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer, which you can confirm against your update calendar.
Ask for a quote based on the written scope, which should itemize build, testing, documentation and retainer components separately.

Self-hosted Dynatrace alternative for air-gapped networks