• Available features
  • Security
    • Authentication and authorization
    • Secure networking
    • Data encryption
    • Email service
  • Compliance
    • View compliance and certification details
    • Access controls
    • Monitoring
    • Audit and observability
  • Bring your own domain
  • Application
    • Advanced search
    • GitLab Pages
    • Hosted runners
    • Self-managed runners
    • OpenID Connect and SCIM
  • Pre-production environments
• Unavailable features
  • Application features
  • Operational features
  • Feature flags
• Migrate to GitLab Dedicated
• Get started

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

You can configure SAML single sign-on (SSO) using any number of SAML 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). SAML request signing, group sync, and SAML groups are supported.

For more information, see how to configure SAML for your instance.

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.
• Restricts access to the AWS organization to select GitLab team members.
• User accounts follow the Access Management Policy.
• 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:

1. Use the Hub account to access customer resources.
2. Request access through an approval process.
3. 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 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.

To add a custom hostname after your instance is created, submit a support ticket.

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.

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.

The following GitLab Pages features are not available for GitLab Dedicated:

• Custom domains
• PrivateLink access
• Namespaces in URL path
• Let’s Encrypt integration
• Reduced authentication scope
• Running Pages behind a proxy

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:

• Enable SCIM provisioning for your IP allowlist
• Enable OpenID Connect for your IP allowlist

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.

Application features

The following GitLab application features are not available:

• LDAP, smart card, or Kerberos authentication
• Multiple login providers
• FortiAuthenticator or FortiToken 2FA
• Reply by email
• Service Desk
• Some GitLab Duo AI capabilities
  • View the list of supported AI features
  • For more information, see the Supporting AI Features on GitLab Dedicated
• Features other than available features that must be configured outside of the GitLab user interface
• Any functionality or feature behind a feature flag that is turned off by default

The following features are not supported:

• Mattermost
• Server-side Git hooks

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

Feature flags

Feature flags are not available for GitLab Dedicated.

Feature flags support the development and rollout of new or experimental features on GitLab.com. Features behind feature flags are not considered ready for production use, are experimental and therefore unsafe for GitLab Dedicated. Stability and SLAs may be affected by changing default settings.

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.