Self-hosted inventory management for air-gapped facilities

Self-hosted inventory management for air-gapped facilities: why isolation changes the build

For a depot or plant with no internet route, Odoo, ERPNext and OpenBoxes can all be self-hosted, but the edition and the update path decide what the site can actually run. Stock, spares and controlled assets still need counting, traceability and an audit trail when the network is closed, so the platform has to work entirely on local servers, local registries and local devices. Start by confirming which features the site needs (barcode scanning, lot and expiry tracking, multi-warehouse transfers, reporting) and whether each is included in the edition you would deploy. Odoo's barcode app is Enterprise-only, and Odoo's Community edition is LGPL-3.0 licensed, so a scanning requirement can turn a free core into a paid subscription before any isolation question arises.

Isolation changes the install and the update cycle. Every container image, package and language dependency must be mirrored inside the boundary before the first deployment. Kubernetes, if used for the stack, can be prepared offline by listing and pulling control plane images in advance and pointing kubeadm init at a private registry with --image-repository. Updates then arrive as signed media that someone must verify, stage on a test copy and promote, rather than as a pull from a vendor repository. Odoo's upgrade service, for example, runs against an upgraded test database that should be tested before production, and that process needs a site owner who can own the calendar. Ask each partner to show how a new minor release for ERPNext or Odoo would move from a vendor release to the isolated production site, and who signs off each package crossing the boundary.

Barcode devices and data export are where the closed network is most visible. Handhelds and label printers must reach the application server on the local network only, so confirm browser support, certificate handling for the internal hostname, and whether label printing depends on any external service. On the way out, exports of stock and asset records must follow the transfer rules that govern the facility, which means writing down what leaves the boundary, in what format, by whom and under which approval. Confirm that the platform's data import and export tools cover the bulk movements you need, and that test copies made for training or upgrades are neutralized so that live records do not leak into lower environments. Treat these as acceptance criteria in the scope, not as details to settle after go-live.

Which requirements an isolated inventory system must meet

This table maps each requirement that can apply to an isolated inventory system to the rule or control that creates it, and to what that means for the build. Read each row against your own status: a requirement applies only where your site is a covered entity, a registered entity or a firm under the named rule. The main takeaway is that offline operation does not remove these obligations, so the offline package path, the device access model and the export process each need evidence of their own.

Requirement	Source and what it asks	What it means for the build
Encryption in transit and at rest	FTC Safeguards Rule (16 CFR 314.4) for covered financial institutions, covering customer information over external networks and stored at rest	Encrypt database volumes, backups and media used to carry data out; confirm which links count as external for your network design
Multi-factor authentication	FTC Safeguards Rule (16 CFR 314.4) for any individual accessing an information system	Apply MFA to the inventory application, admin consoles and handheld logins; confirm how local directory or offline identity sources support it
Change management and activity logging	FTC Safeguards Rule (16 CFR 314.4) requires change management procedures and logs of authorized user activity	Keep an application change record, log stock adjustments and user actions, and export logs to a store the site can review offline
Record preservation	SEC Rule 17a-4(b) for broker-dealers: bills, bank statements and business communications kept at least three years, the first two easily accessible	Retain purchase, transfer and adjustment records on local storage with a tested restore; confirm applicability with your compliance team
Software integrity of carried packages	NERC CIP-013-2 supply chain controls for verifying integrity and authenticity of vendor software and patches, where the site is in scope	Build an offline package repository, verify checksums and signatures before import, and record each media transfer and its approval
Vendor remote access control	NERC CIP-005-7 requires interactive remote access to pass through an intermediate system with encryption and MFA, and to detect and disable vendor sessions	Block standing vendor access; allow time-limited sessions through a controlled jump point, with monitoring and a documented way to end them
Penetration testing and vulnerability assessment	FTC Safeguards Rule (16 CFR 314.4(d)(2)) where continuous monitoring is not in place: annual testing and assessments at least every six months	Plan test windows on the isolated network and use an offline vulnerability feed where the scanner needs one; confirm current scanner capabilities

Which platforms fit an air-gapped inventory setup and why

Three platform choices shape an isolated depot or plant: the Odoo edition, the ERPNext deployment method, and whether a stock-focused platform fits better. Each one changes how updates, barcode devices and support reach a network that has no internet access.

Odoo Community for isolated stock control

Odoo Community is published under LGPL-3.0 and gives you the open source core of the inventory application that you can install and run inside your own network. Installing it on-premise is documented through packaged installers and source installation, so you own the database, the patching and the restore process. Confirm with Odoo which inventory features you need are in Community, because barcode scanning and Studio are part of the paid Enterprise and Custom offerings. Expect your own staff or partner to carry the upgrade work without the Enterprise upgrade service.

Odoo Enterprise on-premise activation

Odoo Enterprise adds features such as mobile apps, Studio customization and the version upgrade service, and its source code is not publicly available. On-premise Enterprise databases are activated by entering a subscription code, so the air-gapped site must hold a valid code and the subscription must stay current before any update can be applied. Standard support covers the first three years after a major release, and security patches are only provided during that window. Ask the vendor how the subscription code is validated without internet access and how upgrade packages are delivered to isolated sites.

ERPNext deployment with bench or frappe_docker

ERPNext is licensed under GPL-3.0 and built on the MIT-licensed Frappe Framework, so you can run it without a license fee. You can install it manually with the bench command line tool, with Docker Compose, or with the production images and Compose files in frappe_docker, which include MariaDB, Redis, workers, the scheduler and Nginx. Bench-based installs depend on package and image sources you must mirror into the enclave, so plan a local registry and package repository. Frappe warranty coverage requires a listed version and a matching Frappe Cloud support plan, so check which support model applies to a closed network before you commit.

ERPNext version support and release cadence

Frappe lists version 15 as supported until the end of 2027 and version 16 until the end of 2029, and version 14 reached end of life on January 31, 2026. Both supported majors ship frequent minor releases, so a depot that updates rarely can fall behind quickly. Each release must be carried across the air gap as a verified package, which means you need a repeatable media process and a test environment that mirrors production. Confirm which version your partner will certify for offline operation and how security fixes between minor releases will be delivered.

Server Scripts and data import limits in ERPNext

Custom logic for stock rules often starts as Server Scripts, which run Python on document events. From version 15 they are disabled by default and must be enabled with the server_script_enabled setting, and Frappe Cloud public shared benches do not allow them. Bulk stock loads through the Data Import tool work best in batches, since the documentation advises importing only a few thousand records at a time. Confirm how your depot will load opening stock, how barcode labels are generated, and who approves enabling server scripts on a self-hosted site.

OpenBoxes for depot stock platforms

OpenBoxes is a stock platform built for supply chains, and it fits depots that mainly need stock levels, locations and requests between sites rather than full manufacturing or accounting. Its footprint is lighter than a full ERP, which can help where IT staff and hardware are limited. Its license, installation options, offline update path and barcode device support are not covered by the sources used for this page, so request written confirmation of each. Ask how it handles lot and expiry tracking, and whether its reporting can run on a closed network.

Deployment patterns for depots, plants and central control

Each facility runs its own complete stack inside its isolated network, with its own database, application server, document storage and users. Nothing depends on another site being reachable, which suits a plant that must keep shipping during a network outage. The cost is that every site needs patching, backups and someone who can restart services, so the staffing model has to be agreed before go-live.

Offline installs: Build a private container registry or package mirror inside the enclave and load it from signed media. Every image, Python dependency and OS package the install uses should be present before the network is closed.
Barcode devices: Put handhelds on a dedicated wireless segment with access only to the local application server. Confirm browser or client support for the scanner model and test label printers on the same segment.
Backups: Hold the primary backup on local storage in the facility and a second copy on removable media stored in a separate secured room. Test a restore on a spare host, not only the backup job's exit code.
Updates: Each site receives releases separately, so version drift between sites is likely unless a release calendar is enforced.

Ask the partner how the registry is populated, who approves each media transfer, and how the site's restore time is measured.

How an air-gapped inventory rollout runs, phase by phase

The sequence moves a stock system from requirements and boundary rules to a verified offline build, a tested staging install, a reconciled stock baseline, and a repeatable media-based update cycle. Each phase closes with a named artifact that the next phase depends on.

Review the boundary and requirements
The client's security, operations and warehouse leads define what crosses the isolated network, who may import or export data, which locations and devices are in scope, and which edition features are needed, such as barcode scanning or multi-company support. DeployOpen maps those needs to a candidate platform and a transfer procedure. The phase closes with a signed scope document and a data transfer rule set that the client's security team has approved.
Build the offline package set
On a connected build host, the team pulls the application images, language packs, database and operating system packages, and any container registry content the platform needs, then records each item with its version and checksum. The build host is separate from the closed network and is controlled by the client's change process. The output is a signed bill of materials for the offline build, with hashes that the receiving side can verify before anything is loaded.
Install and test in a staging enclosure
The verified media is carried into a staging enclosure that mirrors the production network rules, with no route to the internet. The team installs the platform, confirms that it starts and runs its background jobs without outbound calls, and checks that the authentication integration, backups and logging work on the closed network. Any package that fails verification is rejected and rebuilt from the bill of materials. The phase closes with a staging acceptance record listing each test and its result.
Migrate data and validate the stock count
Item masters, locations, units of measure and opening balances are loaded in controlled batches and reconciled against a physical count performed by warehouse staff. Discrepancies are investigated and corrected in the source records, not patched silently in the system. Lot, serial and expiry fields are checked where the facility needs them. The phase closes with a reconciled stock baseline signed by the site owner and the finance contact.
Test barcode devices and labels on the closed network
Scanners, handhelds and label printers are connected to the isolated network and tested for receiving, picking, moves and counts. The team confirms that the browser or client software on each device is supported, that label templates print correctly, and that the devices keep working when a site loses wider connectivity. Device and label configurations are recorded with their firmware and software versions. The phase closes with a device test log and an approved label set.
Cut over to production with a rollback plan
The team moves the validated baseline and configuration into production during an agreed window, with a rollback point and a documented decision owner. Operators run a set of live transactions, such as a receipt, a transfer and a shipment, and confirm the results against the expected stock position. Old paper or spreadsheet processes are retired only after this check passes. The phase closes with a cutover record that names the production build, the baseline date and the signed acceptance.
Run the first media-based update cycle
The first patch or minor release is built on the connected side, verified against a new bill of materials, carried across on media and applied first in staging, then in production. The team confirms the update path, rollback steps and the backup restore test before the cycle is closed. This rehearsal shows whether the procedure works in practice and where it needs improvement. The phase closes with a completed update record and a revised runbook that the site team can follow without outside help.

How updates and security patches reach a closed network

Updates reach an isolated facility only through a controlled, verified transfer, so the update plan starts with the version policy of each platform rather than with the install. For Odoo, the Community edition is the free core, and security patches are provided only during standard support. Odoo states standard support runs three years after a major release, with Odoo 20.0 planned until September 2029 and Odoo 18.0 until September 2027, so a facility running an older major version must know the date its patches stop. Odoo SaaS versions, released every two to three months, cannot be run in an isolated facility, so the plan must target a self-hosted version. For ERPNext, the Frappe support policy requires the customer to be on a listed version, and version 15 is planned for support until the end of 2027 and version 16 until the end of 2029. Confirm which of these dates applies to your chosen release with the vendor before you commit.

Every package, container image and database script carried across the boundary should be checked against a hash or signature published by the vendor, staged on a quarantine host, scanned, and logged before it reaches production. The control logic matches NERC CIP-013-2, which expects procurement processes to address verification of software integrity and authenticity for vendor software and patches. Ask your implementation partner to document the chain of custody for each transfer, including who approved the media, the checksum comparison and the date it was loaded.

Major upgrades need more than a patch cycle. Odoo's upgrade service works on a database copy that should be tested before production, and on-premise use requires an Enterprise subscription because the Community edition has no access to that service. For ERPNext, the tested copy is the rehearsal of the migration on a database duplicate with the same customizations, Server Scripts and data. Plan each upgrade as a scheduled event with a rollback point, and confirm with your vendor how the upgrade tool or migration scripts are packaged so they can be carried across by media.

What auditors and regulators ask for from an isolated inventory system

What access records do auditors expect from an air-gapped inventory system?

Auditors expect a complete list of who accessed the system, when, from which device and what they changed. The application's audit log and the authentication logs from your directory or identity source are the primary evidence, and they should cover administrators, warehouse operators and service accounts. Odoo and ERPNext both record document-level changes, but the level of detail depends on configuration and on which features are enabled, so confirm this in the chosen version. The FTC Safeguards Rule at 16 CFR 314.4 requires covered financial institutions to log the activity of authorized users, which is the requirement most often cited for this evidence. Logs stored only on the isolated host need a documented retention period, a secure copy process and a review record showing someone looked at them. DeployOpen prepares the logging configuration and the evidence set for your assessor, but does not issue audit reports or certifications.

How do change logs prove what changed in stock and configuration?

Change logs show each stock movement, adjustment, price change and configuration edit, with the user, timestamp and before and after values. The inventory module's stock ledger, the application audit trail and the version history of the deployment repository together show both data and system changes. Change management is a named requirement under the FTC Safeguards Rule, so assessors will ask for documented procedures as well as the logs. Keep the change approval record for module installs, upgrades and custom code, because on an isolated network these changes arrive through media and need their own trail. Confirm with the vendor which events each edition records, since audit features can differ between community and paid editions.

What backup and restore tests will an assessor ask to see?

Assessors ask for backup schedules, storage location and proof that restores work, not just that backups run. Keep a dated record of at least one full restore to a separate host, including the time taken, the checks performed on stock balances and the person who signed off. For an isolated facility, document where the backup media is stored, who can access it and how it is encrypted at rest. Odoo's documentation describes database duplication with neutralization for test copies, which is useful for restore drills that should not touch live data. The restore test result is evidence of recoverability, so it should be repeated after upgrades. DeployOpen can design the backup and restore test plan and produce its records, but the acceptable test frequency should be confirmed against your own control framework.

How long must inventory and transaction records be kept?

Retention depends on the regulation that applies to your business, so the first step is to name the regime and the record types it covers. For example, SEC Rule 17a-4(b) requires broker-dealers to preserve certain records, including bills receivable or payable and bank statements, for not less than three years, with the first two in an easily accessible place. Inventory records that support those financial entries may fall within a retention period set by your accounting or legal team. In the isolated system, retention means the application data, the audit logs and the backup sets are all kept for the defined period and remain readable after software upgrades. Test that old backups can still be restored into a current version. Ask your legal and compliance team to confirm the retention schedule before configuring archival or purge jobs.

How do you prove that transferred update packages are intact and authentic?

The evidence is an offline package manifest that lists every file carried across the boundary, with a cryptographic hash for each file, the source the package came from and the person who approved the transfer. Before import, the hashes are recomputed on the isolated side and compared with the manifest, and the comparison result is recorded. NERC CIP-013-2 addresses this type of control by requiring supply chain procurement processes to cover verification of software integrity and authenticity for vendor software and patches, and similar expectations appear in many security frameworks. Keep the media transfer log, the scanning results for the media and the signed approval in the same evidence folder. DeployOpen can build the manifest and transfer procedure, but the choice of hashing tool and signing method should be confirmed with your security team.

Which vulnerability assessment results should be kept for an isolated host?

Keep the scanner's dated output for the inventory application, its operating system, database and container images, along with the remediation tracking for each finding. On an isolated network, the scanner needs an offline vulnerability data source, which must also be refreshed by media and dated, so the report can be tied to the feed version used. Under the FTC Safeguards Rule, institutions that lack effective continuous monitoring must run penetration tests and vulnerability assessments at least every six months, so the scan history is a direct requirement in that case. Record accepted risks with an owner and review date for findings that cannot be fixed on the closed network. Wazuh documents an offline installation path and an offline vulnerability repository option, which is one way to build this evidence, though the fit should be confirmed for your environment. DeployOpen runs security testing and prepares these results, but does not issue attestations.

Can DeployOpen certify our isolated inventory system for an audit?

No. DeployOpen plans, implements, hardens and documents self-hosted systems inside your own infrastructure, and it prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications, and those come from independent auditors or certification bodies. In practice, the engagement produces the configuration baseline, the audit log and backup procedures, the offline transfer record, the retention settings and the security test results that your assessor will review. Ask any partner to put in writing which evidence they will deliver, which items remain your responsibility and which items the assessor must verify. Most engagements are fixed-scope, so the evidence list should be agreed before work begins.

Exporting inventory data under transfer rules

Every export from an air-gapped depot or plant should be treated as a data transfer decision, not a report run. Define up front what leaves the site: stock positions by location and lot, the asset register with custodian and location fields, and movement history such as receipts, transfers, adjustments and count variances. Each dataset carries a different classification. Asset registers can reveal the location of sensitive equipment, and movement history can expose operational patterns. Agree the classification with the data owner and the security team before the first export, and record which fields are excluded by default, such as personal data of staff who handle stock or custodian names.

Approval should sit with a named role, not with whoever happens to have report access. In practice this means a site inventory owner requests the export, a data owner or security officer approves it, and the approval is tied to a file name, date range and destination media. Logging is the control auditors will test. Confirm that the chosen platform records who ran each export and when, and that those logs are themselves kept inside the boundary and written to tamper-resistant storage. Encrypt the export file before it is copied to removable media, and confirm with your security team which encryption tool and key custody model your transfer rules require. Your transfer procedure should also define how media is scanned and how the receiving system verifies the file's integrity.

Bulk reconciliation with the central system needs planning because the ERPNext Data Import tool works from CSV or Excel templates and the documentation advises importing only a few thousand records at a time. A full stock register with tens of thousands of lines will therefore arrive in batches, each needing its own approval and log entry. Test the batch size and reconciliation steps on a copy of the data, and confirm how child table rows such as lot numbers are handled, since an error there can break stock balances. Ask your implementation partner to document the batch procedure, the reconciliation report and the rollback steps, so that a failed batch does not leave the central and site records out of step.

How much does air-gapped inventory implementation cost and how long does it take?

Is open source inventory software free to run on an air-gapped network?

The software license is often free, but the total cost is not. ERPNext is free to self-host according to its pricing page, and Odoo Community is an open source core, while Odoo Enterprise is a paid edition. Barcode apps, multi-company, Studio and external API access are on Odoo's Custom plan, which the pricing page says can be hosted on Odoo.sh or on-premise. Confirm which features your depot or plant needs before comparing edition fees with a SaaS quote, because those features decide the edition. Budget also for hardware, staff time and the offline update process.

Why is Frappe Cloud pricing not relevant to an isolated site?

Frappe Cloud is a hosted service, and an air-gapped facility cannot reach a hosted service by design. The published Frappe Cloud prices, including shared site hosting from 5 US dollars per month and servers from 20 US dollars per month for shared instances or 125 US dollars per month for dedicated servers, apply only to that hosting model. A self-hosted ERPNext site on your own servers replaces those fees with hardware, operations and support costs that you carry. Ask any partner to price the on-premise hardware and the update workflow separately.

What cost components should a quote for air-gapped inventory include?

A complete quote separates several components:

Software edition or subscription fees, if the chosen platform requires them.
Hosting and hardware for application, database and backup servers, plus any local registry or media server.
Offline media handling, covering packaging, transfer, checksum verification and the update procedure.
Data cleanup and migration of item masters, locations and stock balances.
Barcode device, label printer and label template setup.
Testing, staff training and go-live support during the first stock count.

Ask for each line as one-time or recurring, and ask who is paid for each item.

What drives the implementation timeline for an offline inventory system?

Timing depends mostly on data readiness, the number of sites and the device work, not on the software install alone. Item and stock cleanup usually takes longer than expected when master data sits in spreadsheets. Each site needs its own location structure, scanners and printers tested on the closed network. Update delivery adds lead time because each upgrade must be packaged, transferred and tested before it reaches production. Ask any partner to show the written milestones and the dependencies they depend on, including your own staff availability.

Can our internal IT team implement and run this without a partner?

Yes, many teams do, provided they have engineers who can operate a Linux server, database backups, a container or bench-based deployment, and a documented offline update process. Frappe documents installation with Docker Compose and the bench command line tool, and Odoo documents packaged installers and source installation. The harder work is usually the data migration, device configuration and repeatable update cycle. Be honest about staff time, since that cost recurs during upgrades and incident response. A partner can take on fixed-scope parts of the work.

What must our team supply before a DeployOpen engagement can be scoped?

DeployOpen provides a quote from written scope, so the team should prepare the inputs that set that scope. These include the list of sites and warehouses, the item and stock data sources, the required barcode and label workflows, the hardware already on site, the network and approved transfer media rules, and the named owners for sign-off. Also provide the export and retention rules that apply to stock records. Engagements are typically fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

What raises or lowers the cost of exporting data under transfer rules?

Costs rise when every export requires manual review, when data must be classified by record type, or when records are retained under rules that need separate storage. Costs fall when export formats, approval steps and retention periods are defined once and built into reports. Confirm with your compliance lead which records must be kept and for how long before the design starts, because changes after go-live are more costly. For broker-dealer records, the SEC's Rule 17a-4(b) sets a minimum retention period that you should verify with counsel.

Does DeployOpen certify that our air-gapped inventory system is compliant?

No. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue audit reports, attestations and certifications. Ask your assessor which evidence they expect for access logs, change records and backups, and plan the implementation so those artifacts are produced during rollout, not reconstructed later. The cost of that evidence work should appear as its own line in the written scope.

How DeployOpen scopes and supports air-gapped inventory

DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted inventory platforms inside the client's own isolated infrastructure, whether that is a depot network, a plant control zone or a data center with no route to the internet. In practice this means the work covers the platform itself (Odoo, ERPNext or OpenBoxes), the offline package repository and update path, the barcode devices and label printers on the closed network, the backup target that stays inside the boundary, and the administrator runbooks that staff will use when something breaks with no vendor support a phone call away. Each engagement is fixed in scope, with deliverables and timelines agreed in writing before work starts, so the client can see which of these items are included and which are left to their own teams.

DeployOpen also runs security testing against the deployed system, covering the application, its APIs and the network paths that the isolated design relies on. Before scoping, the reader should decide who owns the controls the platform cannot provide alone, such as the media transfer procedure, the approval step for each imported package, and the review of administrator access. DeployOpen can prepare the system configuration, the change records, the access logs and the test results that an assessor will ask for, and it can help map those artifacts to the control set the organization is assessed against. It does not issue audit reports, attestations or certifications. Those come from independent auditors and certification bodies, and the reader should confirm early which body will review the evidence.

Ongoing support is handled through a retainer, separate from the initial fixed-scope project. Retainers typically cover platform patching, offline update cycles, restore tests, user administration and periodic re-testing after changes. Because each update must cross the boundary on media, the retainer should state how many update cycles per year are included, who verifies the integrity of each package, and what response is expected when a security fix arrives between cycles. Ask any partner to put these terms in the written scope, and ask for the exact list of deliverables, not a general description of support.

Self-hosted inventory management for air-gapped facilities