GitLab lets self-hosted teams choose their AI models through Microsoft Foundry

GitLab is expanding Duo Self-Hosted so organisations can run its AI development features against models deployed in their own Microsoft Foundry environment. The practical shift is control: teams can choose the model provider, deployment location and data path instead of sending requests to GitLab-managed infrastructure.

Watch Desk analysis

What happened

According to InfoQ, the integration connects a self-managed GitLab instance and its self-hosted AI Gateway to model endpoints hosted through Microsoft Foundry. Supported model families include OpenAI GPT, Anthropic Claude, Meta Llama and Mistral.

The setup also allows organisations to select different models for different Duo features. A code-focused model could handle Code Suggestions, another could support agentic work, and a smaller model could take higher-volume tasks. Model deployments can be changed without rebuilding the wider GitLab workflow.

The architecture is aimed at organisations with data-residency, sovereignty, regulatory or network-isolation requirements. The relevant detail is not merely that GitLab has added more model names to a menu. It is that the model layer can sit inside an organisation's chosen Azure environment, with the AI Gateway acting as the intermediary.

Why it matters

Enterprise AI is edging away from the tidy fantasy that one vendor supplies the model, the development tools, the hosting and the policy answer. GitLab's approach separates those jobs. That gives platform teams more choice over where source code, prompts and responses travel, and which jurisdiction processes them.

It also hands those teams a larger bill in responsibility. They must manage deployments, capacity, networking, credentials, availability and model lifecycles, while checking that a model listed in Microsoft's catalogue is actually compatible with GitLab Duo. Freedom is useful. So is someone being awake when the endpoint changes.

Our read

This is a meaningful enterprise-AI infrastructure move, not a decorative model-picker update. Organisations that cannot send development data to a centrally managed service now have a clearer route to using AI inside their existing GitLab workflows.

But the trade-off is plain: self-hosting shifts control and operational risk towards the customer. Teams should treat Microsoft Foundry availability and GitLab compatibility as separate checks, then test the full data path, permissions and failure behaviour before rolling the arrangement into production.

What to watch

• Supported-model matrix:
  whether GitLab keeps pace with changes in Foundry's catalogue.
• Operational burden:
  how much work customers need to run, secure and monitor the gateway and model endpoints.
• Data controls:
  whether deployments deliver the promised residency and network-isolation benefits in practice.
• Feature coverage:
  which Duo capabilities support model choice first, particularly agentic workflows.

Discussion spark: Does giving enterprises control over their own AI models justify the extra platform burden, or should development-tool vendors hide that complexity behind a managed service?

Watch Desk is operated by WittyWires as an independent cross-cutting AI news tracker. It does not speak for the organisations or people it covers.