GitLab Dedicated
- Tier: Ultimate
- Offering: GitLab Dedicated
GitLab Dedicated is a single-tenant SaaS solution that is:
- Fully isolated.
- Deployed in your preferred AWS cloud region.
- Hosted and maintained by GitLab.
Each instance provides:
- High availability with disaster recovery.
- Regular updates with the latest features.
- Enterprise-grade security measures.
With GitLab Dedicated, you can:
- Increase operational efficiency.
- Reduce infrastructure management overhead.
- Improve organizational agility.
- Meet strict compliance requirements.
Available features
This section lists the key features that are available for GitLab Dedicated.
Security
GitLab Dedicated provides the following security features to protect your data and control access to your instance.
Authentication and authorization
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).
Secure networking
Two connectivity options are available:
- Public connectivity with IP allowlists: By default, your instance is publicly accessible. You can configure an IP allowlist to restrict access to specified IP addresses.
- Private connectivity with AWS PrivateLink: You can configure AWS PrivateLink for inbound and outbound connections.
For private connections to internal resources using non-public certificates, you can also specify trusted certificates.
Data encryption
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 encrypted data at rest (BYOK).
Email service
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.
Compliance
GitLab Dedicated adheres to various regulations, certifications, and compliance frameworks to ensure the security, and reliability of your data.
View compliance and certification details
You can view compliance and certification details, and download compliance artifacts from the GitLab Dedicated Trust Center.
Access controls
GitLab Dedicated implements strict access controls to protect your environment:
- Follows the principle of least privilege, which grants only the minimum permissions necessary.
- Restricts access to the AWS organization to select GitLab team members.
- Implements comprehensive security policies and access requests for user accounts.
- Uses a single Hub account for automated actions and emergency access.
- GitLab Dedicated engineers do not have direct access to customer environments.
In emergency situations, GitLab engineers must:
- Use the Hub account to access customer resources.
- Request access through an approval process.
- Assume a temporary IAM role through the Hub account.
All actions in the Hub and tenant accounts are logged to CloudTrail.
Monitoring
In tenant accounts, GitLab Dedicated uses:
- AWS GuardDuty for intrusion detection and malware scanning.
- Infrastructure log monitoring by the GitLab Security Incident Response Team to detect anomalous events.
Audit and observability
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.
Bring your own domain
You can use your own hostname to access your GitLab Dedicated instance. Instead of tenant_name.gitlab-dedicated.com, you can use a hostname for a domain that you own, like gitlab.my-company.com. Optionally, you can also provide a custom hostname for the bundled container registry and KAS services for your GitLab Dedicated instance. For example, gitlab-registry.my-company.com and gitlab-kas.my-company.com.
Add a custom hostname to:
- Increase control over branding
- Avoid having to migrate away from an existing domain already configured for a GitLab Self-Managed instance
When you add a custom hostname:
- The hostname is included in the external URL used to access your instance.
- Any connections to your instance using the previous domain names are no longer available.
For more information about using a custom hostname for your GitLab Dedicated instance, see bring your own domain (BYOD).
Custom hostnames for GitLab Pages are not supported. If you use GitLab Pages, the URL to access the Pages site for your GitLab Dedicated instance would be tenant_name.gitlab-dedicated.site.
Application
GitLab Dedicated comes with the self-managed Ultimate feature set with a small number of exceptions. For more information, see Unavailable features.
Advanced search
GitLab Dedicated uses the advanced search functionality.
GitLab Pages
You can use GitLab Pages on GitLab Dedicated to host your static website. The domain name is tenant_name.gitlab-dedicated.site, where tenant_name is the same as your instance URL.
Custom domains for GitLab Pages are not supported. For example, if you added a custom domain named gitlab.my-company.com, the URL to access the Pages site for your GitLab Dedicated instance would still be tenant_name.gitlab-dedicated.site.
You can control access to your Pages website with:
- GitLab Pages access control.
- IP allowlists. Any existing IP allowlists for your GitLab Dedicated instances are applied.
GitLab Pages for Dedicated:
- Is enabled by default.
- Only works in the primary site if Geo is enabled.
- Is not included as part of instance migrations to GitLab Dedicated.
Hosted runners
Hosted runners for GitLab Dedicated allow you to scale CI/CD workloads with no maintenance overhead.
Self-managed runners
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.
OpenID Connect and SCIM
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:
Pre-production environments
GitLab Dedicated supports pre-production environments that match the configuration of production environments. You can use pre-production environments to:
- Test new features before implementing them in production.
- Test configuration changes before applying them in production.
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:
- Flexible sizing: Match the size of your production environment or use a smaller reference architecture.
- Version consistency: Runs the same GitLab version as your production environment.
Limitations:
- Single-region deployment only.
- No SLA commitment.
- Cannot run newer versions than production.
Unavailable features
This section lists the features that are not available for GitLab Dedicated.
Authentication and security
| 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. |
| Multiple login providers | Configuration of multiple OAuth/SAML providers (Google, GitHub). | Limited to a single identity provider. |
| 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. |
| Sigstore | Keyless signing and verification for software supply chain security. | Must use traditional code signing methods. |
Communication and collaboration
| 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. |
Development and AI features
| Feature | Description | Impact |
|---|---|---|
| Some GitLab Duo AI capabilities | AI-powered features for code suggestions, vulnerability detection, and productivity. | Limited AI assistance for development tasks. |
| Features behind disabled feature flags | Experimental or unreleased features disabled by default. | Cannot access features in development. |
For more information about AI features, see GitLab Duo.
Feature flags
GitLab uses feature flags to support the development and rollout of new or experimental features. In GitLab Dedicated:
- Features behind feature flags that are enabled by default are available.
- Features behind feature flags that are disabled by default are not available and cannot be enabled by administrators.
Features behind flags that are disabled by default are not ready for production use and therefore unsafe for GitLab Dedicated.
When a feature becomes generally available and the flag is enabled or removed, the feature becomes available in GitLab Dedicated in the same GitLab version. GitLab Dedicated follows its own release schedule for version deployments.
GitLab Pages
| Feature | Description | Impact |
|---|---|---|
| Custom domains | Host GitLab Pages sites on custom domain names. | Pages sites accessible only using tenant_name.gitlab-dedicated.site. |
| PrivateLink access | Private network access to GitLab Pages through AWS PrivateLink. | Pages sites must be accessed over public internet. |
| Namespaces in URL path | Organize Pages sites with namespace-based URL structure. | Limited URL organization options. |
| Let’s Encrypt integration | Automatic SSL certificate provisioning for Pages sites. | Must manage SSL certificates manually. |
| Reduced authentication scope | Fine-grained access controls for Pages sites. | Less flexible authentication options. |
| Running Pages behind a proxy | Deploy Pages sites behind reverse proxy configurations. | Limited deployment architecture options. |
Operational features
The following operational features are not available:
- Multiple Geo secondaries (Geo replicas) beyond the secondary site included by default
- Geo proxying and using a unified URL
- Self-serve purchasing and configuration
- Support for deploying to non-AWS cloud providers, such as GCP or Azure
- Observability dashboard in Switchboard
Features that require server access
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. |
Access to the underlying infrastructure is only available to GitLab team members. Due to the server-side configuration, there is a security concern with running arbitrary code on services, and the possible impact on the service SLA. As an alternative, use push rules or webhooks instead.
Service level availability
GitLab Dedicated maintains a monthly service level objective of 99.5% 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, CI job logs, GitLab API, Git operations over HTTPS |
| Container Registry | Registry HTTPS requests |
| Git operations | Git push, pull, and clone operations over SSH |
Service level exclusions
The following are not included in service level availability calculations:
- Service interruptions caused by customer misconfigurations
- Issues with customer or cloud provider infrastructure outside of GitLab control
- Scheduled maintenance windows
- Emergency maintenance for critical security or data issues
- Service disruptions caused by natural disasters, widespread internet outages, datacenter failures, or other events outside of GitLab control.
Migrate to GitLab Dedicated
To migrate your data to GitLab Dedicated:
- From another GitLab instance:
- Use direct transfer.
- Use the direct transfer API.
- From third-party services:
- Use the import sources.
- For complex migrations:
- Engage Professional Services.
Get started
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.