Neste artigo você vai aprender:
- Por que Cloudflare Pages é a melhor opção para hospedar arquivos de verificação de deep links.
- Como registrar um domínio
.deve o que o torna especial para este caso. - Como estruturar o projeto e configurar o
_headerspara controlar oContent-Type. - Como validar que tudo está acessível antes de testar no device.
Este é um conteúdo extra da série completa sobre Deep Links no Flutter. Se você ainda não viu os posts anteriores: Post 1 | Post 2 | Post 3 | Post 4 | Post 5 | Post 6 | Post 7.
Nos posts anteriores configuramos App Links e Universal Links (Post 5) e criamos a página signup.html que serve de ponte entre o link e a loja (Post 7). Faltava um lugar para hospedar tudo isso. Este é esse post.
Por que Cloudflare Pages
Três requisitos técnicos não negociáveis para hospedar assetlinks.json e apple-app-site-association:
-
HTTPS sem redirects — o Android rejeita o
assetlinks.jsonse houver qualquer redirect no caminho. -
Content-Typecontrolável — oapple-app-site-associationnão tem extensão, então o servidor precisa saber qual MIME type servir. - Domínio customizado — os arquivos precisam estar no mesmo domínio declarado no app.
O Cloudflare Pages atende os três com configuração mínima. Deploy direto do GitHub — push = publicado automaticamente.
Por que .dev
O TLD .dev está na lista HSTS Preload do Chrome. Isso significa que HTTPS é obrigatório por especificação — qualquer requisição HTTP é forçada para HTTPS pelo próprio navegador antes de chegar ao servidor. Uma configuração a menos para se preocupar.
Custo médio: R$ 60–80 por ano. Se você já usa Cloudflare, registrar o domínio lá elimina a etapa de apontar os nameservers.
Estrutura do projeto
Crie um repositório no GitHub com esta estrutura:
meudominio/
├── .well-known/
│ ├── assetlinks.json
│ └── apple-app-site-association
├── signup.html
├── index.html
└── _headers
O signup.html é exatamente o arquivo que construímos no Post 7 — copie direto para cá.
O arquivo _headers
/.well-known/apple-app-site-association
Content-Type: application/json
/.well-known/assetlinks.json
Content-Type: application/json
Sem esse arquivo, o apple-app-site-association (sem extensão) seria servido sem Content-Type definido — e o iOS pode rejeitar o arquivo silenciosamente. É a causa mais comum de Universal Links que "funcionam às vezes".
Os arquivos de verificação
assetlinks.json:
[
{
"relation": ["delegate_permission/common.handle_all_urls"],
"target": {
"namespace": "android_app",
"package_name": "com.seuapp",
"sha256_cert_fingerprints": [
"AA:BB:CC:DD:EE:FF:..."
]
}
}
]
apple-app-site-association:
{
"applinks": {
"apps": [],
"details": [
{
"appID": "TEAM_ID.com.seuapp",
"paths": ["/signup", "/signup/*"]
}
]
}
}
Deploy no Cloudflare Pages
1. Crie o repositório no GitHub com a estrutura acima e faça o push.
2. No Cloudflare: Workers & Pages → Create → Pages → Connect to Git → selecione o repositório → Build command: vazio → Output directory: / → Save and Deploy.
3. Em Custom Domains, adicione seu domínio. Se está no Cloudflare Registrar, o certificado é provisionado em minutos.
Validando o deploy
curl -I https://seudominio.dev/.well-known/assetlinks.json
curl -I https://seudominio.dev/.well-known/apple-app-site-association
Confirme content-type: application/json nos dois. Se não aparecer, revise o arquivo _headers — espaçamento ou encoding incorreto são as causas mais comuns.
Para o Android, valide com a ferramenta oficial:
https://developers.google.com/digital-asset-links/tools/generator
O que construímos até aqui
- Um domínio
.devcom HTTPS obrigatório por especificação. - Um repositório estático no GitHub com os arquivos de verificação e o
signup.html. - Deploy automatizado no Cloudflare Pages — push = publicado.
-
Content-Type: application/jsonconfigurado corretamente para os dois arquivos de verificação.
Código completo disponível no repositório: FitConnect no GitHub
Este artigo é um crosspost do Medium — leia lá também e deixa um clap se curtiu.
Você usa outro provedor para hospedar esses arquivos? Vercel, Firebase, S3? Conta nos comentários.
