Air-gapped Project Management Software
You deploy air gapped project management software by installing local server packages on offline machines. You then link the app to a local database and an internal directory. Teams often set this up by copying container images across a physical transfer drive. Once the app runs, admins grant broad database and server roles to speed up work. Those wide permissions let anyone on the internal network run risky queries or read private rows. How air gapped project management software works on clos
Software-Defined Perimeter (SDP) + Temporary Project-Based Access: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You deploy air gapped project management software by installing local server packages on offline machines. You then link the app to a local database and an internal directory. Teams often set this up by copying container images across a physical transfer drive. Once the app runs, admins grant broad database and server roles to speed up work. Those wide permissions let anyone on the internal network run risky queries or read private rows.
How air gapped project management software works on closed networks
Closed networks have no route to the public web. Every piece of software must live inside your private data center. You bring in install files on physical media and check their digital signatures first. Then you run the web server, background workers, and relational database on local hosts.
The project app stores tasks, sprint boards, and comments inside that local database. Users log in through a local directory server that sits in the same room. The app checks group memberships and maps each user to a project role. Admins also need direct shell and database permissions to run updates and backups. They log in to the host operating system to fix broken jobs or tune tables. Because external cloud tools cannot reach the network, local admins hold full root keys.
What native offline roles solve and what they miss
Running your project tracker offline stops external attackers from reaching your task boards over the web. Built-in app roles also control which teams can view or edit specific project boards. A developer can move a ticket, while a manager can close a sprint. These native rules work well when people only use the web interface.
Still, the native setup only checks who logs in at the start of a session. It does not check what individual database statements or host commands do in flight. System admins and support engineers still log in straight to the backend database. Once inside, a broad role lets them read every table or drop production data. Ticket comments often hold sensitive data like emails, phone numbers, card numbers, or national IDs. Without statement-level checks and field masking that rewrites matched fields in results, raw data stays exposed. You also lack a clear log that ties every SQL statement to one person.
Software-Defined Perimeter (SDP) + Temporary Project-Based Access: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
How to lock down backend database and host work
Start by separating web app roles from backend database and host roles. The web app itself should use a strict database account that only reads and writes app tables. It should never hold permission to alter schemas or manage other database users. Give schema change rights only to a dedicated migration process during planned maintenance windows.
Next, stop sharing static database passwords or root SSH keys among your support engineers. Shared accounts make it impossible to see who ran a bad query during an outage. Map every backend session to an individual user from your local identity directory. Review which tables hold private fields like phone numbers, emails, or card numbers. Set up rules so routine support queries do not return those sensitive columns in plain text. Finally, store all command and query logs on a separate local host for audits.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
How do we update air gapped project management software without internet?
You download the new release packages and dependencies on a machine with internet access. After you verify the file checksums, you move them inside on approved physical media.
How do users log in when cloud identity providers are unreachable?
Teams connect the project app to a self-hosted directory server running inside the private network. Users log in with their local domain credentials, and the app reads their group roles.
Why do backend databases in offline networks still need query controls?
An air gap only blocks outside traffic, not mistakes or abuse by internal staff. Query controls stop admins from dropping tables or reading raw emails and card numbers during maintenance.