Running integrations on an air-gapped network
Some agencies keep key systems on networks with no internet access. Integration still has to happen there. What to look for in a platform that runs fully inside a closed network.
Some public agencies run critical systems on networks that don't reach the internet at all: utility control environments, some public-safety support systems, finance networks kept apart by policy. Those systems still need to share data with each other.
Most integration products assume the opposite. They run in the vendor's cloud and expect every system to be reachable from it. On a closed network, that's a non-starter.
What "air-gapped" actually demands
Running an integration platform inside a closed network is more than installing it on a local server. It has to work with nothing outside:
- No calls home. No license checks, telemetry or updates that need the internet.
- No content networks. The web interface can't load scripts, fonts or styles from outside servers, or it simply won't render.
- No outside services in the data path. No cloud queue, cloud log or hosted AI in the middle of a flow.
- Updates you can carry in. New versions delivered as images or packages your team moves across on approved media.
Ask a vendor to show the product running with the network cable pulled. That's the real test.
Containers make this practical
Packaging the platform as containers helps a lot. The whole thing (web interface, application, worker, scheduler, database) arrives as a set of images. Your team loads them on an internal host, sets a few environment values, and starts them. Moving to a new version means loading new images, not running an installer that fetches dependencies.
- 01Bring images inOn approved media
- 02Load on a hostInside the network
- 03Set keysYour own app key
- 04Connect systemsInternal addresses
- 05Run flowsNo outside calls
Inside the network: guard the inside too
On a closed network, the integration platform can reach systems that matter. That's the point, but it also means a mistyped address could send a flow somewhere it shouldn't go.
A good platform refuses private and internal addresses by default, and lets an administrator allow specific servers. That way the GIS server and the finance database are reachable because someone deliberately added them, not because everything internal is open.
Credentials stay with you
When you host it, the keys stay in your environment. Passwords, tokens and keys for connections should be encrypted with an application key that your team generates and holds. No one outside your network needs it, and backups of the platform hold settings and history, not records or readable secrets.
Files and databases are the usual workhorses
Closed networks lean on the systems that don't need the internet:
- Databases: SQL Server, PostgreSQL/PostGIS and MySQL as sources and destinations.
- SFTP: file drops between internal systems, with host keys pinned.
- Internal REST APIs: many line-of-business systems have one, even on a closed network.
- Email: an internal mail relay for alerts and summaries.
A flow that reads changed work orders from one database and upserts them into another, with a summary emailed to the supervisor, needs nothing from outside.
What you give up, honestly
Some things genuinely need the internet:
- Connectors to cloud services, such as hosted permitting or CRM systems, can't be reached from inside.
- Public data sources like weather alerts or geocoders aren't available.
- A hosted AI model isn't reachable, so plan on building flows by hand; the AI flow builder is optional.
None of these block the core job: moving records between internal systems on a schedule or as they change.
Testing before you go live
On a closed network, you can't point a flow at a cloud sandbox to try it out. Use the real internal systems, carefully:
- Build the flow against a test database or a test folder first.
- Use preview to read a few real records and see what each step would send. Preview writes nothing.
- Turn the flow on only after the checks pass, then watch the first few runs.
Operating it
Self-hosting means your team runs it. Plan for:
- Who loads updates, and how often.
- Where the platform's own database is backed up.
- Who receives failure alert emails.
- How you'll monitor runs, failure rates and slow steps from the dashboard.
In SentraBridge
SentraBridge runs as containers and can be self-hosted on your own servers, including networks with no internet access. The web interface ships with no CDNs or outside fonts, so it works on a closed network. Internal addresses are refused unless an admin allows that server. Records still pass through in memory only. See hosting options and security.