Configure GitLab Dedicated

{{< details >}}

• Tier: Ultimate
• Offering: GitLab Dedicated

{{< /details >}}

The instructions on this page guide you through configuring your GitLab Dedicated instance, including enabling and updating the settings for available functionality.

Administrators can configure additional settings in their GitLab application by using the Admin area.

However, because GitLab Dedicated is a managed solution, you cannot change functionality controlled by environment-level settings. These include gitlab.rb configurations and access to the shell, Rails console, and PostgreSQL console.

GitLab Dedicated engineers do not have direct access to your environment, except for break glass situations.

[!note] An instance refers to a GitLab Dedicated deployment, whereas a tenant refers to a customer.

Configure your instance using Switchboard

You can use Switchboard to make limited configuration changes to your GitLab Dedicated instance.

The following configuration settings are available in Switchboard:

• IP allowlist
• SAML settings
• Custom certificates
• Outbound private links
• Private hosted zones

Prerequisites:

• You must have the Admin role.

To make a configuration change:

1. Sign in to Switchboard.
2. At the top of the page, select Configuration.
3. Follow the instructions in the relevant sections below.

For all other instance configurations, submit a support ticket according to the configuration change request policy.

Apply configuration changes in Switchboard

You can apply configuration changes made in Switchboard immediately or defer them until your next scheduled weekly maintenance window.

When you apply changes immediately:

• Deployment can take up to 90 minutes.
• Changes are applied in the order they're saved.
• You can save multiple changes and apply them in one batch.
• Your instance remains available during the deployment.
• Changes to private hosted zones can disrupt dependent services for up to 5 minutes.

After deployment completes, all users with access to view or edit your tenant receive a notification for each change. To turn notifications on or off, see manage notification settings.

Configuration change log

The Configuration change log page in Switchboard tracks changes made to your GitLab Dedicated instance.

Each change log entry includes the following details:

Field	Description
Configuration change	Name of the configuration setting that changed.
User	Email address of the user that made the configuration change. For changes made by a GitLab Operator, this value appears as GitLab Operator.
IP	IP address of the user that made the configuration change. For changes made by a GitLab Operator, this value appears as Unavailable.
Status	Whether the configuration change is initiated, in progress, completed, or deferred.
Start time	Start date and time when the configuration change is initiated, in UTC.
End time	End date and time when the configuration change is deployed, in UTC.

Each configuration change has a status:

Status	Description
Initiated	Configuration change is made in Switchboard, but not yet deployed to the instance.
In progress	Configuration change is actively being deployed to the instance.
Complete	Configuration change has been deployed to the instance.
Delayed	Initial job to deploy a change has failed and the change has not yet been assigned to a new job.

View the configuration change log

To view the configuration change log:

1. Sign in to Switchboard.
2. At the top of the page, select Configuration change log.

Each configuration change appears as an entry in the table. Select View details to see more information about each change.

Request configuration changes with a support ticket

Certain configuration changes require that you submit a support ticket to request the changes. For more information on how to create a support ticket, see creating a ticket.

Configuration changes requested with a support ticket adhere to the following policies:

• Are applied during your environment's weekly four-hour maintenance window.
• Can be requested for options specified during onboarding or for optional features listed on this page.
• May be postponed to the following week if GitLab needs to perform high-priority maintenance tasks.
• Can't be applied outside the weekly maintenance window unless they qualify for emergency support.

[!note] Even if a change request meets the minimum lead time, it might not be applied during the upcoming maintenance window.