We run a completely self-hosted, air-gapped environment and are struggling to bridge project management and development workflows. Our project managers need high-level planning views, Kanban boards, Gantt charts, and simple status tracking, but they do not want to work directly in GitLab. At the same time, developers do not want to leave GitLab to create or update duplicate tasks in another system.
Our experience with OpenProject's GitLab integration has been disappointing because it mainly records Git activity for traceability rather than supporting an interactive day-to-day workflow.
Ideally, we need a self-hosted tool that can:
1. Let project managers create and manage high-level work items in a friendly interface.
2. Create or synchronize those items as GitLab issues so developers can use branches, commits, and merge-request closing keywords normally.
3. Sync developer-created issues, status changes, and progress back to the project management interface automatically.
Has anyone implemented this successfully in an air-gapped environment? I'm especially interested in self-hosted products or practical custom integration approaches that both project managers and developers will actually use.
4 Answers
If you are able to build and maintain an integration, a lightweight bridge may be more realistic than finding a perfect off-the-shelf product. ProjeQtOr is open source and could serve as the planning side, with GitLab webhooks and scheduled jobs translating issue creation, status changes, assignments, and links in both directions. Define one system as authoritative for each field to prevent update loops and conflicting edits.
Plane is worth investigating because it is self-hostable and has a GitLab integration. Check the exact capabilities and licensing of the integration, especially for an isolated deployment. It may provide a better user experience for project managers, but verify whether its synchronization is genuinely bidirectional or mainly issue import and linking.
A deterministic synchronization service is probably safer than using an AI model for this. Webhooks can handle immediate GitLab events, while scheduled reconciliation jobs catch missed events in an air-gapped environment. Map fields explicitly, preserve the GitLab issue ID on the planning item, and limit synchronization to the fields that need to cross systems. That will be easier to audit and operate reliably.
Before adding another system, it may be worth evaluating GitLab’s own planning features. Saved views, issue boards, roadmaps, and configurable work-item statuses can cover high-level planning and reporting without requiring synchronization. That keeps the data in one place and avoids conflicts between two systems.
Those features are useful, but our project managers have already rejected using GitLab as their primary interface. The main challenge is finding something that gives them a separate experience without forcing developers to maintain duplicate data.
An internal automation service could still help with translation and dashboards, but the actual synchronization should remain rule-based. Periodic reconciliation and clear conflict-handling rules matter more than having a model generate updates.