GitLab has announced a path for organizations to bring their own models to GitLab Duo Self-Hosted using Microsoft Foundry. The setup lets admins connect GitLab Duo Self-Hosted to GPT, Claude, Llama, and Mistral models hosted in Foundry and choose between them for different features.
- Connect GitLab Duo Self-Hosted to Foundry-hosted models (GPT, Claude, Llama, Mistral)
- Assign a specific model per GitLab Duo feature
- Deploy and manage models within a single Azure subscription
HOW GITLAB DUO SELF-HOSTED CONNECTS TO FOUNDRY
The solution comprises three core components: a self-managed GitLab instance, an AI Gateway, and model endpoints exposed through Microsoft Foundry. A single AI Gateway routes requests to the appropriate Foundry deployment based on the triggering GitLab Duo feature. TechStaged has also covered GitLab Credits Bring Usage-Based Pricing to Duo Agent Platform.
- Self-hosted GitLab instance
- AI Gateway for routing requests
- Foundry model endpoints for deployments
DATA RESIDENCY AND SECURITY CONSIDERATIONS
In a fully self-hosted configuration, inference data — including code inputs, prompts, and model responses — does not leave your network. Billing metadata, such as an instance ID, a de-identified user ID, a call count, and a timestamp, can leave only when using an online license. Data at rest stays in the Azure geography you select; where inference runs depends on deployment type (global, data zone, or regional).
- Inference stays within customer control in self-hosted setups
- Billing metadata may exit with online licensing
- Azure-region deployment options affect data residency
DEPLOYMENT OPTIONS AND MODEL CATALOG
Foundry’s catalog includes GPT, Claude, Llama, and Mistral, with GitLab noting overlaps between Foundry offerings and GitLab’s supported-model matrix. Availability varies by region and deployment type, so organizations should verify both Foundry and GitLab documentation before committing.
- Choose a region and deployment type in Foundry (global, regional, data-zone)
- Deploy one or more models under a single Azure subscription
- Assign different model families to individual features (e.g., agentic chat vs. code completion)
GETTING STARTED AND WORKFLOW NOTES
Deployment steps are outlined in the accompanying guidance: deploy the chosen models in Foundry, name each deployment for auditability, obtain an API key for each deployment, configure the AI Gateway, and wire GitLab Duo to the Foundry deployments. GitLab’s UI expects a deployment name, model family, endpoint, API key, and a model identifier prefix (such as azure/YOUR-DEPLOYMENT-NAME).
- Deploy models in Microsoft Foundry
- Create traceable deployment names (suggesting role-based names like duo-chat)
- Configure the AI Gateway and GitLab Duo per deployment
- Assign deployments to specific GitLab Duo features
LICENSING, PREFIXES, AND MODEL-PREFIX GUIDANCE
The integration supports both on-premises and Azure-hosted deployments and notes that when Foundry exposes non-OpenAI models through the Azure OpenAI endpoint, the azure/ prefix still applies. If a feature is routed to a GitLab-managed model, requests go through the GitLab-hosted AI Gateway and the deployment is hybrid rather than fully self-hosted.
- azure/ prefix usage when going through Azure OpenAI endpoint
- Hybrid deployment if using GitLab-managed models
- Check that the deployment prefix matches the actual endpoint in Foundry
RELATED COVERAGE
SOURCES
- GitLab: Bring your own model to GitLab Duo Self-Hosted with Microsoft Foundry Published · Primary source
