doc/subscriptions/gitlab_dedicated/_index.md
{{< details >}}
{{< /details >}}
GitLab Dedicated is a single-tenant SaaS solution that is:
Each instance provides:
With GitLab Dedicated, you can:
This section lists the key features that are available for GitLab Dedicated.
GitLab Dedicated provides the following security features to protect your data and control access to your instance.
GitLab Dedicated supports SAML and OpenID Connect (OIDC) providers for single sign-on (SSO).
You can configure single sign-on (SSO) using the supported providers for authentication. Your instance acts as the service provider, and you provide the necessary configuration for GitLab to communicate with your Identity Providers (IdPs).
Two connectivity options are available:
For private connections to internal resources using non-public certificates, you can also specify trusted certificates.
If your webhooks and integrations need to connect to services that are not accessible from the public internet, you can use AWS PrivateLink for private connectivity. Because GitLab Dedicated is a SaaS service, it cannot directly connect to local IP addresses in your network.
To set up private connectivity for your internal services:
If you need to connect to more than 10 endpoints, implement a reverse proxy or TLS passthrough on your infrastructure. This approach routes multiple services through fewer private link connections.
Data is encrypted at rest and in transit using the latest encryption standards.
Optionally, you can use your own AWS Key Management Service (KMS) encryption key for data at rest. This option gives you full control over the data you store in GitLab.
For more information, see GitLab Dedicated encryption.
By default, Amazon Simple Email Service (Amazon SES) is used to send emails securely. As an alternative, you can configure your own email service using SMTP.
{{< details >}}
{{< /details >}}
Cloudflare is implemented as a web application firewall (WAF) for distributed denial-of-service (DDoS) protection and related security capabilities. The WAF implementation and configuration is managed by the GitLab SRE team. Direct access to WAF configuration or logs is not available.
GitLab Dedicated adheres to various regulations, certifications, and compliance frameworks to ensure the security, and reliability of your data.
You can view compliance and certification details, and download compliance artifacts from the GitLab Dedicated Trust Center.
GitLab Dedicated implements strict access controls to protect your environment:
In emergency situations, GitLab engineers must:
All actions in the Hub and tenant accounts are logged to CloudTrail.
In tenant accounts, GitLab Dedicated uses:
You can access application logs for auditing and observability purposes. These logs provide insights into system activities and user actions, helping you monitor your instance and maintain compliance requirements.
By default, your GitLab Dedicated instance is accessible at tenant_name.gitlab-dedicated.com.
You can configure a custom domain to use your own domain name instead, such as gitlab.company.com.
Use custom domains to:
You can configure custom domains for:
registry.company.com)kas.company.com)For more information, see custom domains.
[!note] GitLab Pages does not support custom domains. Pages sites are accessible only at
tenant_name.gitlab-dedicated.site, regardless of any custom domain configured for your GitLab Dedicated instance.
By default, GitLab Dedicated enables direct downloads from S3 for optimal performance (proxy_download = false).
Proxied downloads are not supported. The following settings cannot be set to true:
proxy_download in the consolidated object storage configurationdependency_proxy_object_store_proxy_download in the Dependency Proxy object storage configurationThe object types that support direct downloads include:
When you download one of the above object types, your browser or client connects directly to Amazon S3 rather than routing through GitLab infrastructure.
GitLab Dedicated comes with the self-managed Ultimate feature set with a small number of exceptions. For more information, see Unavailable features.
GitLab Dedicated uses the advanced search functionality.
You can access advanced analytical features through the ClickHouse Cloud integration, which is enabled by default for eligible customers. You are eligible if:
You can use GitLab Pages on GitLab Dedicated to host your static website. Pages is enabled by default.
Your website uses the domain tenant_name.gitlab-dedicated.site, where tenant_name matches your instance URL.
[!note] Custom domains are not supported. If you add a custom domain like
gitlab.my-company.com, you still access your website attenant_name.gitlab-dedicated.site.
Control access to your website with:
Your existing IP allowlists are applied to your Pages websites.
If failover occurs during disaster recovery, your site continues to work from the secondary region.
Hosted runners for GitLab Dedicated allow you to scale CI/CD workloads with no maintenance overhead.
As an alternative to using hosted runners, you can use your own runners for your GitLab Dedicated instance.
To use self-managed runners, install GitLab Runner on infrastructure that you own or manage.
You can use SCIM for user management or GitLab as an OpenID Connect identity provider while maintaining IP restrictions to your instance.
To use these features with IP allowlists:
GitLab Dedicated supports pre-production environments that match the configuration of production environments. You can use pre-production environments to:
Pre-production environments must be purchased as an add-on to your GitLab Dedicated subscription, with no additional licenses required.
The following capabilities are available:
Limitations:
While you can modify most settings through the Admin area, GitLab automatically manages certain settings to ensure system stability and security.
GitLab configures rate limits based on your instance size and automatically resets them to these defaults during maintenance windows to ensure optimal performance. These limits prevent any single user or automation from degrading performance for other users on your instance.
For more information about how rate limits work in GitLab Dedicated, see authenticated user rate limits.
This section lists the features that are not available for GitLab Dedicated.
| Feature | Description | Impact |
|---|---|---|
| LDAP authentication | Authentication using corporate LDAP/Active Directory credentials. | Must use GitLab-specific passwords or access tokens instead. |
| Smart card authentication | Authentication using smart cards for enhanced security. | Cannot use existing smart card infrastructure. |
| Kerberos authentication | Single sign-on authentication using Kerberos protocol. | Must authenticate separately to GitLab. |
| FortiAuthenticator/FortiToken 2FA | Two-factor authentication using Fortinet security solutions. | Cannot integrate existing Fortinet 2FA infrastructure. |
| Git clone using HTTPS with username/password | Git operations using username and password authentication over HTTPS. | Must use access tokens for Git operations. |
| SSH certificate authentication | SSH authentication using CA-issued certificates. | Must use another SSH authentication method, such as SSH keys. |
| Sigstore | Keyless signing and verification for software supply chain security. | Must use traditional code signing methods. |
| Port remapping | Remap ports like SSH (22) to different inbound ports. | GitLab Dedicated only uses default communication ports. |
| Feature | Description | Impact |
|---|---|---|
| Reply by email | Respond to GitLab notifications and discussions through email. | Must use GitLab web interface to respond. |
| Service Desk | Ticketing system for external users to create issues through email. | External users must have GitLab accounts to create issues. |
| Feature | Description | Impact |
|---|---|---|
| Some GitLab Duo AI capabilities | AI-powered features for vulnerability detection and productivity. | Limited AI assistance for development tasks. |
| Features behind disabled feature flags | Experiment and beta features under development. | No access to experimental or beta features. |
For more information about AI features, see GitLab Duo.
Feature flags are used to support the development and rollout of new, experiment, and beta features. In GitLab Dedicated:
When a feature becomes generally available, it's available in the same version following the release schedule for deployments.
| Feature | Description | Impact |
|---|---|---|
| Custom domains | Host GitLab Pages sites on custom domain names. | Pages sites accessible only using tenant_name.gitlab-dedicated.site. |
| Namespaces in URL path | Organize Pages sites with namespace-based URL structure. | Limited URL organization options. |
The following operational features are not available:
The following features require direct server access and cannot be configured:
| Feature | Description | Impact |
|---|---|---|
| Mattermost | Integrated team chat and collaboration platform. | Use external chat solutions. |
| Server-side Git hooks | Custom scripts that run on Git events (pre-receive, post-receive). | Use push rules or webhooks. |
[!note] Server-side Git hooks are not supported for security and performance reasons. Instead, use push rules to enforce repository policies or webhooks to trigger external actions on Git events.
GitLab Dedicated maintains a monthly service level objective of 99.9% availability.
Service level availability measures the percentage of time that GitLab Dedicated is available for use during a calendar month. GitLab calculates availability based on the following core services:
| Service area | Included features |
|---|---|
| Web interface | GitLab issues, merge requests, GitLab API, Git operations over HTTPS |
| Container Registry | Registry HTTPS requests |
| Git operations | Git push, pull, and clone operations over SSH |
The following are not included in service level availability calculations:
For more information about disaster recovery, including recovery objectives, see disaster recovery for GitLab Dedicated.
To migrate your data to GitLab Dedicated:
Before your subscription expires, you receive a notification that the end date is approaching.
When your subscription expires, you can access your instance for 30 days.
To preserve your data, contact your account team or email Support within 15 days of expiration to request data preservation.
During this 30-day period, you can:
After 30 days, if your data is not archived or migrated to another instance, your instance is terminated and all Customer Content is deleted. This includes all projects, repositories, issues, merge requests, and other data.
You can request confirmation of account removal 90 days after instance termination. Confirmation is provided as an email from AWS stating that your account is closed.
For more information about GitLab Dedicated or to request a demo, see GitLab Dedicated.
For more information on setting up your GitLab Dedicated instance, see Create your GitLab Dedicated instance.