Como Publicar WordPress no Azure em 2026: Guia Completo com MySQL e App Service

Passo a passo atualizado para publicar WordPress no Microsoft Azure com arquitetura moderna: App Service (Linux + PHP 8.3) e MySQL Flexible Server. Inclui checklist de produção, segurança (hardening), monitoramento e otimização de performance.

Visão geral da arquitetura (o que funciona em 2026)

Se você quer WordPress no Azure sem gambiarra e com caminho de escala, a combinação mais limpa é:
Azure App Service (aplicação) + Azure Database for MySQL (Flexible Server) (banco).
O segredo é não tratar WordPress como “sitezinho”, e sim como aplicação web com dependências reais: banco, TLS, cache, logs e custo.
Arquitetura de WordPress no Azure com MySQL Flexible Server

App Service (Linux + PHP 8.3): execução gerenciada, escala, deploy e logs. Em 2026, o PHP 8.3 é o padrão de estabilidade.
MySQL Flexible Server: banco gerenciado, backups, manutenção e opções de rede/segurança.
DNS + HTTPS: domínio próprio e TLS obrigatório.
Observabilidade: logs e alertas desde o dia 1.

Links de referência (externos):
Quickstart WordPress no App Service (Microsoft Learn)
·
MySQL Flexible Server (Microsoft Learn)

Quando faz sentido usar Azure (e quando é overkill)

Azure faz sentido quando você precisa de governança, observabilidade, escala e integração com ecossistema corporativo.
Se a necessidade é “site institucional simples”, você consegue mais barato e mais fácil em hospedagem gerenciada de WordPress.

Faz sentido: ambiente controlado, integrações, alta disponibilidade, padrões corporativos.
Overkill: site simples sem exigência de monitoramento, SLO, ou controle de rede.

Pré-requisitos

Conta Azure com permissão para criar recursos (Resource Group, App Service, MySQL).
Domínio e acesso ao DNS (Cloudflare, Registro.br, etc.).
Política mínima de acesso: senha forte, MFA e usuários nomeados (nada de “admin”).

Download oficial do WordPress (externo):
wordpress.org/download

Passo a passo completo (portal do Azure)

Aqui estão dois caminhos. O Caminho A é o mais rápido e com menos erro humano.
O Caminho B é manual, para quem quer controle absoluto do deploy.

Caminho A (recomendado): Marketplace/Quickstart

Crie um Resource Group
- Portal Azure → Resource groups → Create
- Nome sugerido: rg-wp-tiespecialistas-prod
- Região: escolha a mais próxima do público
Crie WordPress pelo Azure App Service (Marketplace)
- Portal Azure → Create a resource → procure por WordPress / App Service WordPress
- Selecione assinatura, Resource Group e região
Configure o App Service
- Preferir App Service em Linux
- Escolher plano inicial compatível com produção pequena/média (evite Free para produção)
Configure o banco como MySQL Flexible Server
- Região do banco = região do App Service (latência importa)
- Defina usuário admin e senha forte
- Crie um banco lógico (ex.: wordpress)
Finalize o deploy
- Aguarde “deployment succeeded”
- Acesse a URL e complete o wizard do WordPress

Caminho B (manual): App Service + Deploy do WordPress + Banco separado

Crie MySQL Flexible Server e o banco wordpress.
Crie o App Service Linux com PHP compatível com seus plugins (PHP 8.3 recomendado).
Faça o deploy do WordPress (ZIP deploy, GitHub Actions, ou pipeline que você já usa).
Configure variáveis de ambiente do banco no App Service (host/user/pass/dbname).
Ajuste o wp-config.php para ler do ambiente (evite segredo hardcoded).

Este caminho é melhor para quem já tem CI/CD e quer controle de versão do WordPress, tema e plugins como código.

Persistência de Dados (Azure Files)

Um ponto crítico em 2026: o sistema de arquivos do App Service Linux é efêmero. Se o container reiniciar, seus uploads somem. Para evitar isso:

Crie uma Storage Account e um File Share.
Mapeie esse compartilhamento no App Service em Configuration > Path Mappings para o diretório /var/www/html/wp-content/uploads.

Domínio, DNS e HTTPS

DNS: apontando o domínio

Crie um CNAME (ex.: www) → seuapp.azurewebsites.net.
No App Service, adicione o domínio em Custom domains.
Valide e aguarde propagação.

Dica: se estiver usando Cloudflare, comece com proxy desligado até validar domínio e HTTPS, depois ligue.

HTTPS: obrigatório

Habilite TLS/HTTPS para o domínio no App Service.
Ative HTTPS Only.
Teste redirecionamento: http:// deve virar https://.

Produção mínima vs Produção séria (escolha consciente)

Produção mínima (publicar sem passar vergonha)

App Service em plano não-free
MySQL Flexible Server com backup ativo
Domínio próprio + HTTPS forçado
MFA para contas administrativas
Backups testados (restore de verdade, não fé)

Produção séria (quando o site vira ativo de negócio)

WAF/CDN (Cloudflare ou Azure Front Door conforme estratégia)
Limite de login e proteção contra brute force
Rotina de atualização e janela de manutenção
Alertas de disponibilidade, latência e erros 5xx
Plano de rollback (deploy versionado)
VNET Integration: Conexão privada entre App e Banco.

Hardening: segurança sem paranoia (mas com vergonha na cara)

Conta admin: não use “admin”. Crie usuário nomeado e privilégio mínimo.
MFA: obrigatório para Azure e recomendado para wp-admin.
Plugins: menos é mais. Cada plugin é uma potencial superfície de ataque.
XML-RPC: se não usa, desative.
wp-config: não coloque segredo fixo em repositório. Use App Settings/Key Vault se aplicável.
Banco: restrinja rede; evite acesso público quando possível.

Referências externas úteis:
Hardening WordPress (WordPress.org)

Performance: o que realmente move o ponteiro

Performance em WordPress geralmente morre por três tiros: tema pesado, plugins demais e imagem mal tratada.
No Azure, você também precisa olhar para CPU, memória e conexões com o banco.

Cache: use cache de página/objeto. Em 2026, integrar com Azure Cache for Redis é o diferencial para painéis administrativos rápidos.
Imagens: comprimir e servir formatos modernos (WEBP) e tamanhos responsivos.
Banco: monitore consultas lentas e conexões simultâneas.
CDN: assets estáticos via CDN reduzem latência e carga.