Olá pessoALL, quem me acompanha sabe: sou fã de carteirinha do Azure App Service. Tanto que há alguns meses escrevi um artigo inteiro explicando por que o App Service continua sendo minha aposta #1 para .NET no Azure. Na época, alguns leitores me perguntaram: "Rafael, mas e IA? O App Service não vai ficar pra trás nessa onda de agentes?"

Confesso que fiquei com essa pergunta na cabeça. E a resposta chegou no Build 2026.

O time do App Service publicou o rollup oficial de anúncios do Build 2026, e eu passei os últimos dias fuçando cada link da documentação. Nesse artigo, trago minha síntese com a análise de quem usa esse serviço em produção, com clientes reais, desde a época em que ele ainda se chamava Azure Websites.

O que vamos cobrir:

1. Easy AI: seu web app vira um MCP server sem mudar uma linha de código
2. Isolated v4: GA do hardware de nova geração no ASEv3
3. Managed Instance: o caminho pras aplicações legadas continua evoluindo
4. Platform Release Channel: controle sobre patches de runtime (finalmente!)
5. Azure CLI para a era dos agentes: erros de deploy que se explicam sozinhos
6. Melhorias de plataforma: deploys Python 30% mais rápidos, FastAPI sem configuração, e mais

Vamos lá?

Easy AI: o anúncio que me fez parar tudo

Vou ser direto: esse é o anúncio mais importante do pacote. A Microsoft está introduzindo o Easy AI, um guarda-chuva de funcionalidades pra transformar web apps existentes em aplicações prontas pra agentes de IA. Tudo isso através de um novo blade AI (preview) no portal do Azure.

E a primeira funcionalidade desse guarda-chuva é o Built-in MCP no App Service.

Antes de explicar por que fiquei tão animado, deixa eu contar uma história. Há alguns meses, um cliente aqui da AzureBrasil.cloud queria expor a API do sistema dele pra agentes de IA. A API já existia, rodava no App Service há anos, estável, documentada com OpenAPI. O caminho? Escrever um MCP server — Model Context Protocol, o protocolo que padroniza como agentes de IA descobrem e chamam ferramentas externas.

Fizemos o de sempre: SDK do MCP, mapeamento manual de cada operação da API pra uma tool, tratamento de autenticação, deploy de um serviço novo, monitoramento de um serviço novo. Funciona? Funciona. Mas vamos ser honestos: era puro plumbing. Código que não entrega valor de negócio nenhum, só traduz um protocolo pro outro.

MAS (aqui entra um GRANDE MAS) — com o Built-in MCP, todo esse trabalho simplesmente desaparece. Você fornece a especificação OpenAPI 3.x da sua API, e o App Service gera automaticamente as tools e um endpoint MCP pronto pra qualquer agente consumir. Sem SDK, sem serviço adicional e sem mexer no código da aplicação.

Na prática, funciona assim: a plataforma lê o spec (por padrão em /home/data/.ai/apispec.json), transforma cada operação em uma MCP tool usando o operationId como nome, e serve o endpoint via streamable HTTP no path que você escolher. Se você usa ASP.NET Core com Microsoft.AspNetCore.OpenApi (padrão desde o .NET 9), ou FastAPI que já gera o spec em /openapi.json, você literalmente já tem tudo que precisa.

Quer ver como fica a configuração via Bicep? Simples assim:

resource site 'Microsoft.Web/sites@2025-05-01' = {
  name: appName
  location: location
  properties: {
    serverFarmId: appServicePlanId
    aiIntegration: {
      Mcp: {
        Servers: [
          {
            Name: 'orders'
            Endpoint: '/mcp/orders'
          }
        ]
      }
    }
  }
}

Pronto! Seu endpoint MCP está no ar em https://<app-name>.azurewebsites.net/mcp/orders, e qualquer cliente compatível (GitHub Copilot, Claude Desktop, Cursor) consegue descobrir e chamar suas tools.

Vale ressaltar dois pontos importantes antes de você sair habilitando isso em produção:

• Autenticação não é opcional. Depois que um cliente MCP conecta, toda operação exposta na ToolList é chamável. A recomendação é usar o App Service Authentication (Easy Auth), que aplica as mesmas verificações de identidade das outras rotas do app. Nunca exponha um MCP server público sem autenticação.
• Filtre o que você expõe. A propriedade ToolList permite listar exatamente quais operações viram tools. Aquele endpoint DELETE /admin/purge-database? Mantenha fora da lista. O padrão é ["*"] (tudo), então revise antes de habilitar.

E tem um detalhe de engenharia que me agradou: quando você atualiza o spec, a plataforma detecta a mudança, recalcula a lista de tools e notifica os clientes conectados via notifications/tools/list_changed. Sem restart. Hot reload de verdade.

O blade AI (preview) também traz uma aba Agents, que mostra métricas dos agentes hospedados no seu App Service (total de agentes, chamadas, tokens consumidos e taxa de erro), tudo extraído do Application Insights via OpenTelemetry com as convenções semânticas de Generative AI. Ou seja, você monitora o custo e o comportamento dos seus agentes com as ferramentas que já conhece.

Dito isso, a preview tem limites: 1 MCP server por app, apenas transporte streamable HTTP, e planos dedicados (Basic ou superior). Pra cenários com workflows multi-step ou tools sem endpoint HTTP correspondente, um MCP server customizado ainda é o caminho.

Isolated v4: hardware de nova geração pra quem precisa de isolamento

Agora que cobrimos a novidade de IA, vamos pro anúncio de infraestrutura. O Isolated v4 (Iv4) atingiu General Availability no App Service Environment v3 (ASEv3).

Se você não trabalha com ASE, deixa eu contextualizar: o App Service Environment é a versão single-tenant do App Service. Infraestrutura dedicada, isolamento total, pra workloads com requisitos rígidos de compliance e residência de dados. Bancos, seguradoras, governo. Aquele tipo de cliente que pergunta "quem mais roda nesse servidor?" e precisa ouvir "ninguém".

O Iv4 traz pro ASEv3 a mesma geração de hardware v4 que já alimenta o Premium v4, com desempenho bem acima do Isolated v2, sem abrir mão das garantias de isolamento. Você tem workload mission-critical num ASEv3 com Iv2 hoje? O upgrade é escalar pra um plano Iv4, sem rearquitetar nada.

Porém, um aviso honesto que o próprio time da Microsoft fez questão de destacar: a demanda está alta e a capacidade pode ser limitada mesmo nas regiões suportadas. A disponibilidade começa num conjunto restrito de regiões e expande conforme demanda. Se você planeja migrar, verifique a região antes e, se encontrar problemas de capacidade, abra um ticket de suporte. Consulte também a página de pricing: SKUs Isolated não são baratos, e o custo precisa estar na conta do projeto desde o início.

E tem um detalhe estratégico escondido nesse anúncio: o Iv4 no ASEv3 é a fundação pro Managed Instance em infraestrutura dedicada. O que nos leva ao próximo tópico.

Managed Instance: a ponte pras aplicações legadas ficou mais curta

No meu artigo anterior sobre o App Service, eu disse que o Managed Instance tinha me surpreendido positivamente. Ele resolve aquele cenário que todo consultor conhece: a aplicação Windows legada que precisa de acesso ao registry, componentes COM, dependências instaladas no OS, e que por isso "precisava de uma VM".

Quantas migrações você já viu travarem exatamente nesse ponto? Eu perdi a conta.

No Build 2026, o Managed Instance (ainda em preview) ganhou melhorias que mostram maturidade a caminho do GA:

• Restarts em ~30 segundos (antes, mudanças de configuração significavam esperas bem maiores)
• Sem restart pra mudanças de registry e storage adapters
• Tooling de diagnóstico integrado
• Expansão pra novas regiões (Central e South India, com rollout mais amplo em andamento)

Além disso, os scripts PowerShell do App Service Migration Assistant agora suportam Managed Instance: com o switch -UseManagedInstance, a ferramenta gera automaticamente as configurações de migração (plano, adapters, scripts de instalação) e captura tudo num arquivo de settings. Menos setup manual pra workloads complexas.

E pra quem gosta de ver o futuro chegando: a Microsoft publicou um piloto de migração agêntica de IIS pro Managed Instance, usando um workflow multi-agente com MCP pra descoberta, assessment e deployment. É experimental, e o próprio time recomenda adaptar à sua realidade. Mas a direção é clara: agentes de IA participando ativamente das migrações. Lembra do Built-in MCP lá do começo? As peças se conectam.

Platform Release Channel: o controle que faltava sobre patches

Esse anúncio é menos glamouroso que IA, mas resolve uma dor real que eu já vivi na pele.

Manter runtimes atualizados é uma das grandes promessas de uma plataforma gerenciada. Mas essa faca corta dos dois lados: o mesmo patch que corrige um CVE pode introduzir uma mudança de comportamento no framework ou quebrar uma premissa hardcoded em algum canto da sua aplicação. E até agora, a resposta era "confie no rollout". Pra quem não podia confiar, o plano B era migrar pra containers e assumir a gestão da imagem base. Trocando um problema por outro.

Sim, aprendemos na marra. Já vi patch de runtime causar comportamento inesperado em produção numa segunda-feira de manhã, sem nenhum deploy recente pra culpar. Se você já passou por isso, sabe o desespero.

O Platform Release Channel pro App Service on Linux resolve isso com uma configuração por app, com três canais:

Canal	Comportamento	Quando usar
Latest	Recebe patches assim que disponíveis	Dev e teste, pra validação antecipada
Standard	Cadência padrão de release (default)	Maioria dos apps de produção
Extended	Fica um release atrás do Standard	Workloads sensíveis que precisam de mais tempo de validação

A estratégia que recomendo: aponte seus ambientes de dev/teste pro Latest e valide os patches antes que eles cheguem à produção no Standard. Você transforma o rollout da Microsoft no seu próprio pipeline de validação, de graça.

Configurar é uma linha de CLI:

az webapp update \
  --resource-group meu-rg \
  --name meu-app \
  --platform-release-channel Extended

Mesmos runtimes gerenciados, mesmo patching automático, agora com controle sobre o ritmo. Era o que faltava.

Azure CLI pra era dos agentes: erros que se explicam

O anúncio traz um dado que me chamou atenção: agentes de IA estão usando o Azure CLI como porta de entrada principal pra gerenciar recursos no Azure. E a Microsoft está investindo pesado pra que tanto agentes quanto humanos "acertem de primeira".

Duas melhorias já disponíveis merecem destaque:

Erros de deploy enriquecidos. O novo switch --enriched-errors true no az webapp deploy (App Service on Linux) transforma aquelas falhas opacas de deployment em diagnósticos estruturados: código de erro, contexto do deployment, erro bruto, sugestões de correção e até um prompt pronto pra colar no GitHub Copilot. Quantas horas você já perdeu interpretando um erro genérico de deploy? Pois é.

az webapp list-runtimes repaginado. A lista flat antiga virou uma tabela estruturada com OS, runtime, versão, status de lifecycle e datas de end-of-life, com filtros --runtime e --support. Perguntas como "quais dos meus runtimes estão chegando no EOL?" agora têm resposta em um comando.

Além disso, o time queimou uma parte significativa do backlog do CLI nos últimos releases. Recomendo atualizar o CLI nos seus scripts e pipelines de CI pra pegar tudo isso.

Melhorias de plataforma: os detalhes que somam

Nenhum desses itens é manchete sozinho, mas juntos eles removem fricção real do dia a dia. E aqui os números são concretos:

• Pipeline de deploy Python ~30% mais rápido. O time perfilou o remote build de ponta a ponta e reconstruiu as partes lentas: Zstandard substituiu gzip nos artefatos de build (compressão ~6x mais rápida, descompressão ~2.6x, o que também acelera cold starts), uv substituiu o pip como instalador primário (com fallback automático), e uma cópia redundante de staging foi eliminada. O maior ganho é em apps de IA/ML com árvores de dependência gigantes. Detalhes no post oficial.
• FastAPI sem startup command. O App Service agora escaneia os entry-points comuns (main.py, app.py, api.py), detecta o import do FastAPI e inicia com o worker Gunicorn/Uvicorn correto automaticamente. Disponível pra Python 3.14+, com mais versões a caminho.
• Deferred Kudu Recycle. Atualizar um app setting não-crítico durante um deploy assíncrono não interrompe mais o deploy: o Kudu adia o recycle por até 40 minutos. Settings críticos de deployment (como WEBSITE_RUN_FROM_PACKAGE) continuam reciclando na hora, e você pode marcar seus próprios settings como críticos com WEBSITE_DEPLOYMENT_CRITICAL_APPSETTINGS. Quantos deploys quebrados por alguém mexendo em connection string na hora errada isso vai evitar?
• Site Status. O portal agora mostra o estado de lifecycle da plataforma (Starting / Started / Stopping / Stopped / Updating / Blocked), o último erro conhecido e detalhes por instância, com ações de reparo direto no blade, como restart ou substituição da instância.
• Aliases SSH pra Python. Atalhos dentro do container pra ativar o virtual environment, navegar pros paths comuns e inspecionar o processo. Menos tempo lembrando caminhos, mais tempo debugando.

Minha leitura: a aposta continua de pé

Lá no começo, mencionei a pergunta que os leitores me fizeram: "o App Service não vai ficar pra trás na onda de agentes?"

Depois desse Build, minha resposta é um sonoro não. E o que mais me agrada é o como: em vez de criar um produto novo e pedir pra você rearquitetar tudo, a Microsoft está trazendo a era dos agentes pra dentro da plataforma que você já usa. Seu web app de anos vira um MCP server com um spec OpenAPI. Sua aplicação legada Windows ganha um caminho de migração assistido por agentes. Seu CLI devolve erros que um agente (ou você) consegue agir em cima.

Lição aprendida ao longo desses anos acompanhando o App Service: a plataforma que evolui sem quebrar o que já funciona é a plataforma que ganha no longo prazo. De Azure Websites a MCP servers nativos, a história se repete.

E você? Já abriu o blade AI (preview) no seu App Service? Qual desses anúncios resolve uma dor real do seu dia a dia: o Built-in MCP, o Release Channel, ou os deploys Python mais rápidos? Deixe nos comentários, quero muito saber como vocês estão levando IA pras aplicações existentes.

Links Úteis

Anúncio principal

• App Service Build 2026 Updates — O rollup oficial com todos os anúncios

Easy AI

• Configure App Service built-in MCP (Preview) — Documentação completa do Built-in MCP
• Register and discover remote MCP servers in Azure API Center — Governança de MCP servers

Infraestrutura

• Isolated v4 docs — Documentação do Iv4 no ASEv3
• Managed Instance on Azure App Service — Visão geral do Managed Instance
• App Service Migration Assistant PowerShell Scripts — Scripts com suporte a -UseManagedInstance

Plataforma e CLI

• Platform Release Channel — Controle de patches de runtime
• Better Deployment Errors in az webapp deploy — Erros enriquecidos no CLI
• Platform Improvements for Python AI Apps — Deploys Python 30% mais rápidos
• Simplifying FastAPI Deployments — FastAPI sem startup command
• Deferred Kudu Recycle — Deploys resilientes a mudanças de config

Espero que tenham curtido! []s e até a próxima.