Engineering analytics for GitLab Self-Managed behind a VPN
A secure pattern for analyzing private GitLab delivery data when a hosted application cannot reach the customer network.
Understand the network constraint
A hosted SaaS backend usually cannot call a GitLab instance that is available only on a company VPN or private network. Adding every customer origin to deployment configuration does not scale, and asking the customer to expose GitLab publicly weakens the security boundary. The user's browser, however, may already have authorized network access while connected to the VPN. That creates a practical route for a manual, browser-direct sync, provided the product treats the browser as an untrusted boundary and minimizes what leaves it.
Let the browser call GitLab directly
In browser-direct mode, the user enters the GitLab origin, group scope, and a read-only token in the page. JavaScript running in the browser calls the GitLab API through the existing VPN connection. It normalizes only the delivery metadata required by the product and sends that normalized payload to the hosted application. The token must never be included in that payload, application logs, error monitoring, or analytics. Optional convenience storage should be tab-scoped session storage, not persistent local storage, and closing the tab should remove the credential.
Use the narrowest practical permissions
Create a token intended for read-only API access and scope the sync to the groups or projects the workspace is authorized to analyze. Validate the GitLab origin as HTTPS, reject credentials embedded in URLs, and prevent calls to arbitrary internal hosts where possible. The hosted ingestion route should independently verify the signed-in workspace manager, accepted provider type, payload schema, maximum size, repository scope, and rate limit. A browser-held token reduces server-side secret exposure, but it does not remove the need to validate everything the browser submits.
Optimize the sync around bounded pages
Fetch projects and recent merge requests with the largest supported page size, honor GitLab pagination headers, and bound the history by a clear time window or record limit. Avoid one request per merge request unless a metric truly needs detailed events. Load expensive review, participant, or iteration data concurrently with a conservative cap and show progress by completed work, not an arbitrary spinner. Cache normalized results in the application so reports do not repeat the VPN fetch. Manual browser-direct mode cannot provide reliable background sync or webhooks after the tab closes, so label freshness honestly.
Verify the security promise
During a pilot, inspect the browser network panel and confirm the token is sent only to the customer's GitLab origin. Check that application requests contain normalized metadata rather than raw secrets or source code. Close the tab and verify the token is gone. Test an invalid origin, an expired token, a user without workspace permissions, an oversized response, and a partial sync. Finally, compare a sample of projects, merge requests, reviewers, labels, milestones, and iterations with GitLab itself. A secure architecture is useful only when users can also trust the resulting evidence.
See your delivery system clearly.
Explore a production-like Troodo workspace and see how delivery evidence becomes a focused management brief.
Explore the live demo