GitLab Self-Managed

Overview

GitLab Self-Managed is a customer-operated GitLab deployment. GitLab Enterprise Edition and GitLab EE remain useful search terms, but the Pomerium guide also applies to other self-managed editions.

GitLab Self-Managed can expose sensitive application data or administrative functions. A Pomerium route adds identity-aware policy before a user reaches the selected endpoint while the service keeps its own detailed permissions.

Pomerium controls who can establish the selected route to GitLab Self-Managed. GitLab Self-Managed remains responsible for its application, protocol, data, and service-level permissions.

How it works

Create a Pomerium HTTPS route for the selected private HTTP endpoint. Configure the application public URL, trusted proxy settings, WebSocket forwarding, and suitable timeouts.

Keep application authentication and granular authorization active. Test interactive terminals, streaming views, agents, and other long-lived connections separately.

Route the public host to http://gitlab:80 and preserve the Host header. Set GitLab external_url to the public HTTPS host. When Pomerium terminates TLS, keep GitLab's internal NGINX on HTTP, disable GitLab Let's Encrypt, and do not publish the upstream port.

Example

A team keeps GitLab Self-Managed on a private network. Pomerium policy controls the public HTTPS route. GitLab then handles its own login, project roles, repositories, and application permissions.

Considerations

• GitLab keeps its own login and project authorization.
• Git over SSH needs a separate native access or TCP design.
• Test runners, webhooks, registries, APIs, and command-line Git separately.
• Do not use the same protected GitLab deployment as the Pomerium identity provider.
• Pomerium checks TCP and WebSocket policy when the connection starts. A later policy change does not terminate an established connection.