GitLab Duo Self-Hosted now runs models via Microsoft Foundry in customer-owned environments

GitLab announced on September 22, 2026 the expansion of GitLab Duo Self-Hosted to support models deployed through Microsoft Foundry, according to a report by InfoQ. In practice, this means organizations can now run GitLab Duo's AI features (Code Suggestions, chat, agentic flows) against models hosted within the customer's own chosen Azure environment, instead of relying on the model infrastructure managed by GitLab.

The integration covers model families such as GPT (OpenAI), Claude (Anthropic), Llama (Meta), and Mistral, all accessible through the Microsoft Foundry catalog. The central point is not just "one more supported model": it's the ability to choose provider, deployment location, and data path independently of the development tool.

What the architecture looks like

According to InfoQ, the technical design has three pieces: a self-managed GitLab instance, a self-hosted GitLab AI Gateway, and one or more model endpoints hosted via Microsoft Foundry. The Gateway acts as an intermediary between GitLab Duo and the selected models, instead of tying each Duo feature to a specific AI provider.

A relevant detail for those architecting this type of environment is model selection per feature. It's possible to use, for example, a code-oriented model for Code Suggestions, another model for agentic workloads, and a smaller (and cheaper) model for high-volume tasks. Swapping the model behind one of these functions doesn't require reworking the GitLab workflow itself.

The trade-off InfoQ points out

The report highlights a point that tends to be left out of self-hosted AI marketing discourse: giving the organization control over models and infrastructure shifts responsibility onto engineering and platform teams. It becomes internal work to manage model deployment, capacity, network, credentials, availability, and model lifecycle, in addition to maintaining the GitLab environment itself.

There's also a specific operational risk cited by InfoQ: a model's availability in the Microsoft Foundry catalog doesn't automatically equate to compatibility with GitLab Duo. The Foundry catalog can change faster than GitLab's supported model matrix, which forces teams to check compatibility on both ends before switching models in production.

Where this fits compared to GitHub Copilot and Bedrock

InfoQ draws a direct comparison with other market platforms. GitHub Copilot has also been expanding support for multiple underlying models, but its default experience remains strongly integrated with GitHub's managed service. Platforms like Amazon Bedrock and Microsoft Foundry itself offer multi-model infrastructure, but they don't replace an integrated DevSecOps platform like GitLab: they solve the model layer, not the layer of development flow, code review, and pipeline.

GitLab's move, according to the report, fits into a broader market trend of no longer treating AI-powered development tools and foundation models as a single, bundled service. GitLab positions itself as a model-agnostic control layer: it handles the developer workflow and the AI features, while the organization decides which model runs underneath.

What changes for those handling sensitive data in Brazil

For Brazilian teams under the LGPD (Brazil's data protection law), or operating in regulated sectors such as finance, healthcare, and public agencies, the discussion of where the model runs and through which paths prompts and code snippets travel has stopped being secondary. Teams that today avoid adopting Copilot or Duo in their managed form because they can't guarantee that source code and prompts won't leave the country, or won't leave the corporate network, gain from this expansion a concrete route: keep GitLab self-managed, stand up the AI Gateway internally, and point it to models running inside an Azure region under the company's own direct control.

In practice, this alone doesn't resolve the question of data sovereignty: Azure is still public cloud infrastructure, and the organization needs to negotiate datacenter region, contracts, and network configuration with Microsoft. What the architecture described by InfoQ does resolve is that the decision point over credentials, network path, and model lifecycle moves into the hands of the company's own platform team, not GitLab's.

This also changes the cost and operational calculus for architects and technical leaders: adopting this path means adding to the team the responsibility of managing availability and capacity for the models on Foundry, on top of what's already spent maintaining a self-managed GitLab instance. For small organizations or those without a dedicated platform team, this is a real entry cost that the managed version of GitLab Duo (or standard Copilot) doesn't require.

What still remains open

InfoQ doesn't detail specific regional availability timelines for Brazil, nor does it list which Azure regions already support this configuration combined with the GitLab AI Gateway. The report also doesn't include a latency or cost benchmark comparing this self-hosted route with using GitLab's own managed model infrastructure. For teams evaluating the migration, checking compatibility between the Foundry catalog and GitLab Duo's supported model matrix remains, according to the report itself, a manual step that needs to be repeated with every update on either side.