• Prerequisites
• Allow outbound connections from the GitLab instance
• Allow inbound connections from clients to the GitLab instance
• Run a health check for GitLab Duo

Configure GitLab Duo on a self-managed instance

GitLab Duo is powered by large language models (LLMs), with data sent through an AI gateway. To use GitLab Duo on a self-managed instance, you can:

1. Use the LLMs and the cloud-based AI gateway that’s hosted by GitLab. This option is the default.
2. Use LLMs from the supported list and self-host the AI gateway and LLMs. This option provides full control over your data and security.

This page focuses on how to configure a self-managed instance if you’re using the default, GitLab-hosted option.

Prerequisites

• You must ensure both outbound and inbound connectivity exists. Network firewalls can cause lag or delay.
• Silent Mode must not be turned on.
• You must activate your instance with an activation code.
• GitLab Duo requires GitLab 17.2 and later for the best user experience and results. Earlier versions may continue to work, however the experience may be degraded.

GitLab Duo features that are experimental or beta are turned off by default and must be turned on.

Allow outbound connections from the GitLab instance

Check both your outbound and inbound settings:

• Your firewalls and HTTP/S proxy servers must allow outbound connections to cloud.gitlab.com and customers.gitlab.com on port 443 both with https://. These hosts are protected by Cloudflare. Update your firewall settings to allow traffic to all IP addresses in the list of IP ranges Cloudflare publishes.
• To use an HTTP/S proxy, both gitLab_workhorse and gitLab_rails must have the necessary web proxy environment variables set.
• In multi-node GitLab installations, configure the HTTP/S proxy on all Rails and Sidekiq nodes.

Allow inbound connections from clients to the GitLab instance

• GitLab instances must allow inbound connections from Duo clients (IDEs, Code Editors, and GitLab Web Frontend) on port 443 with https:// and wss://.
• Both HTTP2 and the 'upgrade' header must be allowed, because GitLab Duo uses both REST and WebSockets.
• Check for restrictions on WebSocket (wss://) traffic to wss://gitlab.example.com/-/cable and other .com domains. Network policy restrictions on wss:// traffic can cause issues with some GitLab Duo Chat services. Consider policy updates to allow these services.
• If you use reverse proxies, such as Apache, you might see GitLab Duo Chat connection issues in your logs, like WebSocket connection to …. failures.

To resolve this problem, try editing your Apache proxy settings:

# Enable WebSocket reverse Proxy
# Needs proxy_wstunnel enabled
  RewriteCond %{HTTP:Upgrade} websocket [NC]
  RewriteCond %{HTTP:Connection} upgrade [NC]
  RewriteRule ^/?(.*) "ws://127.0.0.1:8181/$1" [P,L]

Run a health check for GitLab Duo

You can determine if your instance meets the requirements to use GitLab Duo. When the health check completes, it displays a pass or fail result and the types of issues. If the health check fails any of the tests, users might not be able to use GitLab Duo features in your instance.

This is a beta feature.

Prerequisites:

• You must be an administrator.

To run a health check:

1. On the left sidebar, at the bottom, select Admin.
2. Select GitLab Duo.
3. On the upper-right corner, select Run health check.
4. Optional. In GitLab 17.5 and later, after the health check is complete, you can select Download report to save a detailed report of the health check results.

These tests are performed: