Why self-hosted web analytics on an air-gapped network is a different build
Matomo On-Premise and Umami can both be self-hosted on a network with no internet access, but the install itself is the smallest part of the work. The effort sits in building an offline package set, applying updates without outbound connections, connecting the platform to your internal identity provider and confirming which features still work once external services are removed. Licence type alone does not settle the fit. Matomo is GPLv3 and its On-Premise Community edition is free with unlimited users and hits, while Umami is MIT licensed and self-hosted for free. What decides the fit is the edition, plugin and feature set you depend on, and whether the vendor supports air-gapped deployment at that edition.
That second point matters more than many teams expect. Across the open-source ecosystem, air-gapped deployment is often a paid-edition feature. Mattermost lists it under Enterprise Advanced, Rocket.Chat excludes it from its free Starter plan, and Metabase offers it only on its Enterprise plan. Analytics tools follow the same pattern in many cases, so confirm in writing whether the edition you plan to run supports disconnected operation, and whether any plugin you need is distributed under a separate proprietary licence. Matomo's Heatmap and Session Recording plugin, for example, is sold under the InnoCraft EULA rather than the GPL, so it needs its own licence review before it is carried across an isolated boundary.
Before you commit to a platform, ask the vendor and your own team four questions. Which components fetch assets, fonts, scripts, geolocation data or update metadata at runtime? How will each new release and security patch reach the isolated network, and who verifies its integrity? Which identity protocol and role mapping will the analytics console use, and is it supported without a public callback? Which reports depend on data that cannot be imported offline? Write the answers into the scope before any packaging work starts, because each unanswered item becomes an unplanned change request during rollout.
Requirements an air-gapped analytics build must meet
This table lists the requirements an analytics platform must meet before it can run on an internal or isolated network, with the evidence an assessor expects for each. Read each row as a question to answer during design: what must work offline, what must be verified, and which stack versions must be fixed in advance. The main takeaway is that the software supply chain and the version pinning are as important as the installation itself.
| Requirement | What it means for the build | Evidence to prepare |
|---|---|---|
| Offline installation from packages | Every container image, package, database dependency and PHP or Node runtime must be staged on media or a private mirror before the install window opens. | Bill of materials listing each artifact, its version and its checksum, plus a documented install runbook tested on an offline host. |
| Updates without outbound connections | Upgrades arrive as new offline bundles through the same controlled path as the original install, so the platform cannot pull patches on its own. | Written update procedure with approval steps, a record of each bundle imported and a rollback plan for failed upgrades. |
| Internal identity integration | Log in through the organization's own directory or single sign-on service on the internal network, with no dependence on a public identity provider. | Configuration showing the internal identity provider endpoints, role mapping to analytics access levels and a test log of successful and denied logins. |
| Data stays on internal hosts | Tracking data, backups, logs and archived reports remain on approved servers, and no feature sends visitor data to an external service. | Data flow diagram confirming no outbound destinations, storage location inventory and backup targets inside the boundary. |
| PHP and database versions pinned for offline mirrors | Matomo 6.0.0 requires PHP 8.1 or newer and MySQL 8.0 or newer or MariaDB 10.6 or newer, while Matomo 4.16 and 5 run on PHP 8 with older MySQL or MariaDB releases. Umami requires Node.js 18.18 or newer and PostgreSQL 12.14 or newer. Pin the exact versions and mirror them with the platform. | Version matrix naming each runtime, database and web server, with the mirror source and checksum for each. Confirm current support status with the vendor before freezing versions. |
| Software integrity checks for carried packages | Verify the signature or checksum of every package carried across the isolated boundary before import. Energy-sector scenarios under NERC CIP-013-2 expect documented verification of vendor software and patch integrity and authenticity. | Hash manifest, signed transfer log, a named approver for each import and a record of verification results kept with the change ticket. |
| Remote administration through a controlled path | Vendor or DeployOpen support access into the network must pass through an intermediate system with encryption and multi-factor authentication. Energy-sector scenarios under NERC CIP-005-7 set this expectation for interactive remote access. | Access architecture diagram, MFA configuration, session logs and a method to end active vendor sessions. |
Which analytics platforms fit an isolated network and why
Air-gapped analytics is mostly a packaging and dependency problem: every container image, package, plugin and database driver has to arrive through an approved path. The cards below compare the options that matter, the dependencies that quietly break offline, and the licence checks to run before anything crosses the boundary.
Matomo On-Premise for full feature sets
Matomo On-Premise is licensed under GPLv3 and its Community edition is free, with unlimited users and hits. It runs on PHP 8 behind a web server, with MySQL or MariaDB as its database. Matomo 6.0.0 is in beta and needs PHP 8.1 or newer, MySQL 8.0 or newer, or MariaDB 10.6 or newer, so confirm which line your mirror and patch process will follow. Matomo is the stronger choice when reporting depth and offline plugin management matter. Heatmap and Session Recording is a paid plugin under the InnoCraft EULA, not the GPL, so check that licence before carrying it into the network.
Umami for a smaller footprint
Umami is MIT licensed and tracks traffic, campaigns and conversions without cookies. A source install needs Node.js 18.18 or newer, and Umami supports PostgreSQL from version 12.14. It also publishes a prebuilt Docker image and a Compose file with a bundled PostgreSQL database, so the image can be mirrored into an internal registry and the database pinned to an approved version. Umami suits intranet and portal page metrics where web traffic is the main question. Check whether the features your owners expect are in the self-hosted build, because Umami Cloud adds email reports and a streaming API.
Plausible as a comparison point
Plausible is a common alternative in cookieless web analytics, but this page holds no researched facts on its self-hosted requirements, offline packaging or licence terms for this use. Before shortlisting it, confirm with the vendor its current edition, the components it needs (including any analytics database), how images and updates are delivered without internet access, and which features are available only in its hosted service. Treat it as a candidate to verify, not a default.
Cloud-only features are not available
Matomo Cloud and Umami Cloud run outside your network, so neither is an option for an isolated deployment. Their pricing pages describe hosted features such as Umami's email reports and streaming API, and Matomo's Cloud data residency in Frankfurt. None of these can be reached from a network with no outbound path. Map each requirement in the brief to a self-hosted option first, then record any feature that exists only in a hosted plan as a gap, to be closed by a different tool or dropped.
Google Analytics import needs review
Matomo's Google Analytics Importer is a free GPLv3 plugin that copies report data from a Google Analytics property into a new site. It is a plugin you must download, verify and carry across the boundary like any other package, and it reads from an external service at the time of import, so run it in a connected staging environment and transfer only the results. Matomo's FAQ says it imports aggregated report data only, so Visitor Log, Ecommerce Log, Custom Reports and Segmentation do not work for imported data, and some reports such as Funnels are not imported. Set that expectation with stakeholders early.
Integration points and deployment pattern for isolated networks
An analytics platform on an isolated network has to fit the existing identity, logging, time and backup services inside the boundary without reaching out to the internet. The four cards below cover the integration points that most often decide whether a deployment is operable. Confirm every identity connector against the chosen platform's own documentation before you commit to a design.
Internal identity integration
Analysts and administrators should sign in with the directory your organization already runs, not with local accounts that drift over time. Ask each candidate whether it supports SAML, OpenID Connect, or LDAP-style directory binding, and whether group membership can map to analytics roles. Confirm the required connector against the platform's documentation rather than assuming it, and test group-to-role mapping with a sample account before go-live. Document who can export raw data, since that permission matters more than the login method.
Private container and package mirror
Everything the platform needs to install and upgrade must come from a registry or repository inside the boundary. Plan an internal container registry for the application image and its database image, plus a mirror for the operating system packages and language runtimes it depends on. Each artifact crossing the isolated boundary should be verified for integrity and authenticity before it is loaded. The Umami Docker image and Compose file are a typical starting point, but confirm the exact image references and any transitive dependencies in your own build process.
Internal time source
Analytics timestamps, retention jobs and security log correlation all depend on a consistent clock. Without internet access, the platform host and database host should sync to an internal NTP source that is itself synchronized to an authoritative reference inside the boundary. Confirm the time configuration in the operating system and the database, and check that timestamps in the analytics data match the SIEM timestamps during testing. Clock drift makes incident timelines and retention reports unreliable, so treat time sync as a tested control, not a default.
Log forwarding to the existing SIEM
The analytics server is an internal application that auditors and security teams expect to see in monitoring. Forward application logs, web server access logs, database audit events and administrator sign-ins to the SIEM already used inside the boundary. Decide which fields are safe to forward, since analytics logs can contain URLs and query strings that may include sensitive values. Confirm the log format and transport the SIEM accepts, and test that failed logins and configuration changes raise alerts.
Database backup inside the boundary
The analytics database holds the historical data that reports and retention commitments depend on, so backups must stay inside the boundary and be restorable on an isolated network. Choose a backup method that the database supports natively, store copies on separate storage, and encrypt them at rest. Schedule restore tests on a separate host, because an untested backup is not evidence of recovery. Confirm the recovery point and recovery time your policy requires, and check whether the platform's own tools or the database tools carry the backup.
Rollout phases for an offline analytics deployment
This sequence moves a self-hosted analytics platform from an offline scope agreement to a tested, documented service inside a network with no internet access, with each phase closing on a named artifact.
Confirm scope and external dependencies
The team lists every analytics feature the business needs, then checks each one for a call to an external service such as a hosted geolocation database, a CDN-served script, a vendor license check or a cloud email relay. Each dependency is marked as removed, replaced with an internal service, or accepted as unavailable. The output is a feature inventory with an external-dependency register, signed by the data owner and the security lead before any build work begins.
Build the package and image bill of materials
The implementation partner and the internal platform team enumerate every artifact the deployment needs: the application release, container images, database packages, operating system packages, tracking script bundles and any reference data files. Each item gets a version, source, license and cryptographic hash recorded in a bill of materials. Packages are pulled from the vendor's published sources on a connected staging machine, and the hashes are compared against the vendor's published values where those exist. The output is a verified package set that a second reviewer has checked against the bill of materials.
Stage the build in a mirror of the target network
Before anything reaches the classified or isolated network, the team builds a copy of the target environment on a separate network with the same restrictions. The verified package set is installed using only local repositories and registries, and any step that tries to reach the internet is logged and fixed. Egress is blocked at the network layer during the test, so failures surface early. The output is a staging build with a log showing zero outbound connection attempts during install and first start.
Install and configure tracking offline
The verified package set is transferred across the boundary under the agreed media process and installed on the production hosts. The team configures the analytics application, database connection, data retention settings, IP handling and the tracking snippet, then deploys the snippet to internal sites. Sites that load assets from external CDNs are corrected so they use internal copies. The output is a working collection path with test pageviews confirmed in reports and a configuration baseline stored under change control.
Test identity and role integration
The team connects the analytics login to the internal identity provider, maps directory groups to analytics roles, and tests sign-in, sign-out, group changes and account removal for each role. Session timeouts and multi-factor requirements are checked against the organization's standard. Local fallback accounts are confirmed to be restricted and recorded. The output is a signed test report listing each role, the expected access and the observed result, with any gaps logged as open items.
Rehearse updates with a carried media set
The team runs a full update cycle using the same carried media process that will be used in production. A newer release is packaged into a media set, verified against the bill of materials, imported across the boundary, and applied to the staging mirror. The rehearsal includes a database backup, the upgrade, a smoke test of tracking and reports, and a tested rollback to the prior version. The output is a rehearsed runbook with recorded timings and a rollback result that the operations owner accepts.
Hand over runbooks and accept the service
The partner delivers the documentation set: architecture diagram, bill of materials, configuration baseline, identity mapping, backup and restore procedure, update runbook, rollback procedure and the open-items register. Operators complete a supervised handover session and perform one restore and one media-based update on their own. The customer signs acceptance against the written scope, and the signed acceptance and evidence pack are filed for future assessments. The output is a formally accepted service with an owner for every runbook.
Which analytics features depend on external services
Before you deploy, list every analytics feature you plan to use and assume none of them can reach the internet. The features that most often call out to external hosts are IP geolocation databases, update checks, plugin marketplace downloads, hosted map tiles and web fonts loaded in dashboards, and email delivery for scheduled reports. Each one can fail quietly on an isolated network: a dashboard may load slowly while it waits for a font host, a report schedule may log errors for weeks, or a country breakdown may show blank because the geolocation file was never placed on the server. The Matomo and Umami admin screens will not always tell you which feature is waiting on an external address, so the list has to come from your own testing.
Test each feature with outbound traffic blocked at the firewall or proxy, and record what fails, what times out and what silently degrades. Confirm the behavior with the vendor for your exact version rather than assuming it, since update checks, plugin installs and report mailers differ between editions. Umami's pricing page is a useful starting point because it names cloud-only capabilities such as email reports and a streaming API that are not part of the self-hosted product, so any dashboard or workflow built on them needs a replacement. For each failing feature, decide whether to disable it, replace it with an internal equivalent such as an SMTP relay on your own network, or load the required file from your offline media. Also note that the Matomo Google Analytics Importer only brings in aggregated report data, so the Visitor Log, Segmentation and Funnels will not work for imported history. Confirm that gap with the business owners before the migration is scoped.
Evidence auditors and assessors ask for from an isolated analytics platform
This table maps each piece of evidence an assessor typically asks for to the component that produces it: the analytics application, its database, the package mirror, the transfer log and the identity provider. Read it as a checklist of what to collect before an assessment, not as a statement that any particular control is met. The main takeaway is that most evidence is generated during routine operations, so it has to be captured as the work happens rather than rebuilt later.
| Evidence | What it shows | Where it comes from | Where it usually fails |
|---|---|---|---|
| Software bill of materials and package hashes | Exactly which analytics application, database and dependency versions were carried across the boundary | Mirror manifest and hash records for each offline package set, including the analytics application image or archive | Hashes recorded for some packages but not the full dependency tree, or the list is not updated after each import |
| Change records for offline updates | Who approved each update, what changed, when it was imported and how it was tested | Transfer log entries, change tickets and release notes linked to each imported package set | Updates applied by hand on the server with no ticket, or transfer media logged only in a spreadsheet |
| Access control and role mapping exports | Which internal identity groups map to which analytics roles, and who holds administrator rights | Identity provider group export and the analytics application's role and user list, taken on a fixed schedule | Local admin accounts left in place, or group mappings changed in the identity provider without a matching record |
| Backup and restore test results | That the analytics database can be recovered inside the isolated network, with the restore time and outcome recorded | Restore test logs from the database and application configuration, performed on a separate host | Backups taken but never restored, or restore tests that skipped the configuration and user data |
| Data location and retention settings | Where visitor data is stored, that it stays inside the network, and how long each data set is kept | Application configuration, database storage paths, retention job settings and the written retention policy | Retention set to a default value, or archived exports kept on removable media with no record of their location |
| Transfer log integrity | That every item carried across the isolated boundary was recorded, checked and approved by a named person | Transfer log, media custody record and hash verification output for each import | Media reused without a log entry, or hash checks performed but not kept |
| Vulnerability and patch status for carried packages | Which known issues were reviewed for the packages in use and what was decided for each | Offline vulnerability data set version, scan output and the decision record for each finding | Vulnerability data set out of date, so scan results cannot be traced to a date |
Questions buyers ask before hiring help for offline analytics
What drives the cost of an air-gapped web analytics install?
The cost depends on how much work sits around the software itself, because the analytics platform installs the same way whether or not it is connected to the internet. The main drivers are the number of sites and environments, the identity integration, the update process you need to run without outbound access, and the verification of every package carried across the boundary. Each of these is paid as implementation time, and the update process recurs for as long as the platform runs.
- One-time: scoping, offline packaging, installation, identity integration and documentation.
- Recurring: patch and version updates, package verification, and operating the platform.
- Ask any provider for a written scope that lists sites, identity sources, update cadence and evidence deliverables before agreeing a price.
How long does an air-gapped analytics installation take?
The timeline depends on the scope, the number of sites and how quickly your internal teams can provide hosts, accounts and approvals. No fixed duration applies to every environment, so ask for a timeline in the written plan rather than relying on a general estimate. Work that usually adds time includes transfer approvals for offline media, change board reviews, and testing identity integration against your internal directory. A plan should show the milestones, the internal dependencies and what happens if an approval slips.
What does our internal team need to provide for an offline install?
Your team provides the infrastructure, the access and the approvals that an outside partner cannot supply from inside your boundary. In practice that means the hosts and database servers, an identity administrator who can register the application with your internal identity provider, a change approval path, and a defined process for moving packages across the air gap. Confirm each of these in the scope before work starts, because delays in these areas usually affect the schedule more than the software work does.
- Hosts, storage and network rules for the analytics application and database.
- Identity administrator access to create client registrations and group mappings.
- Change approvals and a named owner for transfer media and their logs.
Can our own team install web analytics without an implementation partner?
A capable engineering team can usually complete a simple, single-site installation from offline packages by following the vendor's documentation. The harder part is running updates without outbound connections over time, because each release has to be downloaded on a connected system, checked, moved across the boundary and applied in order. Teams that take this on should plan for a documented update routine, a test environment that matches production, and someone who owns the process when staff change. A partner is more often brought in for multi-site rollouts, identity integration and the evidence your assessors will ask for.
Do we need a paid edition to run analytics without internet access?
Some vendors gate air-gapped support behind paid editions, while others publish free self-hosted editions that install from packages. Check the current pricing and edition pages for the exact product you plan to use before you assume either way. For example, Matomo lists its On-Premise Community edition as free, which is the starting point for self-hosting, but the offline update behavior and any add-on plugins still need to be confirmed against your own environment. Ask the vendor in writing which features, update methods and support terms apply to disconnected deployments.
Which analytics features stop working without external services?
Features that call an outside service, such as hosted maps, cloud-based email delivery, remote geolocation databases or external update checks, will fail or need a local replacement. Start by listing every feature you plan to use and every external dependency it has, then test each one in an isolated lab. Some reports may also depend on data imported from another tool, and imported aggregated data can lack the raw logs that drill-downs need. Record what works offline, what needs a workaround and what is out of scope, so the decision is documented before go-live.
How do we verify packages carried across an isolated boundary?
Verification starts with a documented process that checks the origin, integrity and approval of every file before it enters the network. Record a checksum for each package on the connected side, confirm it on the isolated side, and keep a transfer log tied to a change ticket. Your supply chain controls should address verification of vendor software and patches, and NERC CIP-013-2 is one example of a standard that requires this. Ask any partner how they document each transfer and what evidence they hand over at the end of the engagement.
What to ask an implementation partner about an isolated build
Start with the offline package chain, because it decides whether the build can be repeated. Ask how the partner builds the offline bundle for Matomo, Umami or Plausible, which upstream versions and dependencies it pins, and how each artifact is hashed and signed before it crosses the boundary. Ask who keeps the build record, how a second person verifies the bundle on the inside, and what happens when the upstream project publishes a new release during the engagement. For Matomo, confirm the PHP, MySQL or MariaDB, and web server packages are included in the bundle, since the requirements change between Matomo 5 and Matomo 6.0.0. For Umami, confirm the Node.js runtime, the PostgreSQL version and the container image are all carried in. Request the bill of materials in writing as a deliverable.
Next, ask how the partner proves the analytics stack works with outbound traffic blocked. A good answer includes a test plan run on a network where DNS and egress are denied, with the tracker script served from the internal host and not a CDN. Ask how they check for hidden external calls, such as fonts, GeoIP databases, update checks, or a Matomo plugin marketplace request, and which features they have turned off or replaced because they depend on an external service. Ask for the test results as evidence, and ask how the partner handles any feature that needs a license or service they cannot reach. Confirm in writing which features are in scope for the fixed scope and which are documented as unavailable.
Finally, ask about identity, role mapping, updates and handover. Ask how the analytics login is connected to the internal identity provider, which protocol is used, how the internal roles map to Matomo or Umami user permissions, and who approves changes to those mappings. Ask how an update is rehearsed on a staging copy, how the next bundle is carried across the boundary and verified, and how a rollback is done. Ask what runbooks, administrator training and access reviews are delivered at handover, and what support terms apply after go-live, including response expectations, patch handling and who holds the credentials. Request the fixed scope, acceptance criteria and the list of evidence files in writing before any work starts, and confirm that all of them are named deliverables.
How to choose between Matomo and Umami for a closed network
This sequence turns a general preference for either tool into a documented decision that the platform team can support offline. Each step produces an artifact that the next step depends on, so the final choice rests on tested evidence and licence obligations rather than feature lists alone.
Confirm the feature set the business needs
Product owners and the analytics lead list the reports they must have, such as funnels, ecommerce reporting, visitor logs, segmentation and heatmaps. For each item, mark whether it is required, nice to have or out of scope. Heatmaps and session recording need separate attention because Matomo's Heatmap and Session Recording plugin is a paid premium plugin under the InnoCraft EULA rather than the GPL, so the licence cost and terms must be checked before it is counted as available. This step is done when the requirements list is signed off and every premium component has a named owner and a licence review item.
Confirm the runtime the team can support
The platform team checks whether it can operate the runtime each candidate needs. Matomo 6.0.0 requires PHP 8.1 or newer and MySQL 8.0 or newer or MariaDB 10.6 or newer, and Matomo 5 runs on PHP 8 with MySQL 5.5 or later or MariaDB behind a web server. Umami needs Node.js 18.18 or newer for a source install and supports PostgreSQL from version 12.14, and it publishes a prebuilt Docker image. Ask the team which stacks are already patched and approved inside the boundary, and whether they can carry the image or packages through the offline transfer process. This step closes with a written list of the runtimes accepted for the network.
Build the offline package set
Someone on the platform team collects every installer, container image, library, database driver and plugin for the chosen candidates on an connected build host, then records versions and checksums in a manifest. Matomo's plugins and any Google Analytics Importer package need the same treatment as core files. Confirm with each vendor which dependencies pull at install time from public registries, since those must be mirrored or replaced. The step is complete when the manifest lists every artifact and the transfer media has been scanned and approved under the network's cross-domain or import procedure.
Test the install in an isolated mirror
The platform team installs each candidate in a test network with no outbound route, using only the offline package set. They record every failed fetch, missing dependency and first-run prompt that reaches an external host, including any licence check, telemetry call or update check. Run the same test with the database and web tier configured the way production will be configured. The step is complete when a clean install succeeds with outbound traffic blocked, and the team has a written log of every external dependency it found and how it was resolved.
Test updates and identity integration offline
Using the test environment, the team applies a newer release from offline media, following the vendor's documented upgrade path, and checks that the application still starts and records data. It then connects the internal identity provider for administrator and reader access, confirms that sessions, roles and logout behave as the security team requires, and verifies that no login flow calls an outside service. Ask the vendors which features, such as hosted reports, email delivery or updates, depend on external services. The step closes with a tested upgrade record and a confirmed sign-in path.
Compare results against the requirements
The analytics lead and the security reviewer score each candidate against the requirements list from step one, using the install log, the update record and the identity test. Mark any feature that works only with a paid component, depends on an external service, or failed in the mirror. This comparison should be written so a reviewer can see why each gap was accepted or rejected. The step is complete when each requirement has a pass, fail or licence-dependent status for each candidate.
Decide on licence obligations and record the choice
Legal and procurement review the licence terms that apply to the chosen configuration: Matomo's core is GPLv3 for the 5.x branch, while premium plugins and the Matomo Cloud service carry separate terms, and Umami is MIT licensed. Confirm whether the organization needs a support agreement, whether any paid plugin must be bought, and who maintains the offline packages after go-live. The decision is final when the chosen platform, its version, its licence position and its update process are recorded in the architecture decision file and approved by the system owner.
How DeployOpen scopes an isolated analytics deployment
Every isolated analytics deployment starts with a written scope, agreed before any work begins. For an air-gapped or internal network, that scope has to name the boundary the platform sits behind, the hosts and database it runs on, the offline package set that will be carried across the boundary, and the identity provider it will authenticate against. DeployOpen plans the deliverables from that document: the installed platform, the configured tracking for the sites in scope, the offline update procedure, the backup and restore runbook, and the handover documentation. The timeline follows from the written scope, so the reader should see the milestones, the dependencies on their own change windows and the people who must sign off each stage before the engagement is signed.
The scope should also settle the questions that most often change the cost of an isolated build. Decide which features the organization needs from the start, because some capabilities may depend on external services or paid editions that cannot be reached from the network, as covered elsewhere on this page. Confirm who approves each package entering the boundary, where those approvals are recorded, and which evidence the security team expects to keep. Ask the partner to show how each deliverable maps to a line in the scope, and how a change request is priced and approved if a discovery finding alters the plan.
Once the first deployment is accepted, the work does not have to end. Upgrades, security fixes and package refreshes for an isolated system recur on the organization's schedule, so many teams add a retainer for ongoing upgrades and support instead of reopening a full project each time. Ask what a retainer covers, how offline packages are prepared and verified, how response times are defined, and how the retainer interacts with the internal staff who will run the platform day to day. Confirm these terms in writing with the partner before signing, so that operating responsibilities are clear from the day the platform goes live.
How DeployOpen builds and supports offline analytics
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including air-gapped networks. For web analytics on an isolated network, the work starts with a written scope that names every package, update path and identity integration before any installation begins.
How we scope
- Written scope lists the analytics platform, edition, sites, and the internal identity provider to integrate.
- We map which features depend on external services and agree how each is handled offline.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We stage every installer, container image and dependency on approved media for transfer across the boundary.
- We configure the analytics server, database and reverse proxy to run with no outbound connections.
- We test the update process from new offline media and document the checks performed on each package.
How we hand over
- You receive runbooks for installation, offline updates, backups, restores and tracking script deployment.
- Documentation covers access control settings, data retention configuration and the evidence your assessors may request.
- Handover includes a walkthrough with your platform and security teams so they can operate the system alone.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after go-live.
- Retainers can cover package transfer cycles, patch review and recovery testing on the isolated network.
- We prepare systems, controls and evidence for compliance assessments, while independent auditors issue the reports.
