Migrar do Netlify

Conferido com o código em 2026-10-30 (versão 0.1.0) · versão em Markdown

O SeeDropHost não roda o seu comando de build. Se o site precisa de build, faça como faz hoje; depois aponte o sdh deploy para a raiz do repositório (ele lê o netlify.toml e publica a pasta publish) ou direto para a pasta pronta.

O que é lido sozinho

No seu projeto	O que o SeeDropHost faz
`netlify.toml` ou `seedrop.toml`	`[build] publish`: só essa pasta vai para o ar. `[[redirects]]` (from, to, status, force, condições Language/Country, inclusive `from = "https://www.exemplo.com/*"`) e `[[headers]]` (`for` + `[headers.values]`). O `seedrop.toml` vence se os dois existirem. O arquivo nunca é servido.
`_redirects`	lido como está: 200/301/302/303/307/308/404/410, `*` e `:splat`, `:marcadores`, `!` para forçar, `Language=` e `Country=`, proxy para endereços públicos. Detalhes, em inglês
`_headers`	lido como está: blocos por caminho com curingas e linhas `Nome: valor` (o `Set-Cookie` é descartado)
`<form data-netlify="true" name="…">`	encontrado no deploy; os envios vão para a caixa de leads. `netlify-honeypot="campo"` é respeitado; o campo `form-name` é colocado para você. Detalhes, em inglês
Funções em `[functions] directory` (padrão `netlify/functions`)	vão junto com o deploy e só rodam se o servidor tiver `SDH_FUNCTIONS=1` — veja abaixo
`404.html`	servida com status 404 para endereços que não existem
URLs limpas	`/sobre` serve `sobre.html` ou `sobre/index.html`; a outra forma responde 301 para a que existe

O mesmo vale para um .zip da raiz do repositório e para uma pasta solta no painel.

Funções: desligadas por padrão, para dono único

Formatos aceitos, um arquivo por função (.js, .mjs ou .cjs):

// clássico
exports.handler = async (event, context) => ({ statusCode: 200, body: "ok" });
// moderno
export default async (req) => new Response("ok");

Elas respondem em /.netlify/functions/<nome> e /.sdh/functions/<nome>, e por regras 200 como /api/* /.netlify/functions/:splat 200. Limites: 10 segundos, 128 MB de memória, 6 MB de envio e 6 MB de resposta. O process.env tem só as variáveis do site com escopo functions.

Atenção: as funções vêm desligadas. Ligue (SDH_FUNCTIONS=1) só se você for dono de todos os sites do servidor. A função roda num worker do mesmo processo, com limite de tempo e memória, mas isso não é isolamento: ela consegue ler o banco, os arquivos de todos os sites e as credenciais do servidor. Quem publica uma função tem acesso total ao servidor. Com as funções desligadas, esses endereços respondem 404.

O que ainda não é lido

Não há build a partir do Git nem deploy a cada push. [build] command, plugins e [context.*] não rodam. Faça o build no seu computador ou na CI e rode sdh deploy.
Edge functions, funções agendadas e funções em segundo plano.
Funções que fazem require de arquivos vizinhos ou de node_modules (cada função é um arquivo só) e funções em TypeScript (aparecem como aviso).
Em [[redirects]]: query, signed, headers e a condição Role aparecem como aviso e são ignorados. Condições do _redirects além de Language e Country nunca casam.
Formulários: sem aviso por e-mail, sem envio de arquivo, sem reCAPTCHA. O spam é barrado por honeypot, contagem de links e limite por IP.
Não há CDN global própria: coloque a Cloudflare na frente (guia de VPS, em inglês).

Tudo isso aparece no relatório do deploy; nada é pulado em silêncio.

Passo a passo

Faça o build como hoje, por exemplo npm run build.
Crie o site e envie como rascunho. O rascunho ganha um endereço de prévia próprio e não vai para o ar; o seu domínio continua apontando para o Netlify, então o visitante não vê nada mudar.

npx sdh create meu-site
npx sdh deploy ~/meu-repo --site meu-site --draft

Leia o relatório que o comando mostra: o arquivo de configuração lido, a pasta publicada, as funções encontradas, a nota de SEO/GEO, os formulários e qualquer regra que não foi entendida.
Compare o site no Netlify com a prévia do rascunho, página por página, inclusive os endereços antigos do seu _redirects e do netlify.toml:

npx sdh comparar https://www.seu-site.com.br https://<deploy>--meu-site.seu-servidor.exemplo --projeto ~/meu-repo --json relatorio.json

Ele bloqueia (código de saída 1) quando mudam status, redirecionamentos, canonical, noindex, hreflang, formulários ou quando um novo Disallow do robots.txt cobre páginas que existem, e avisa sobre título, descrição, h1, JSON-LD, texto e endereços que saíram do sitemap. Endereço de prévia (<deploy>--<site>.) é reconhecido sozinho: o noindex que toda prévia tem não conta, mas o noindex que o próprio site declara continua bloqueando. Use --previa para forçar isso em outro endereço. Se a página inicial do site antigo redireciona para outro host (domínio sem www ↔ www), a comparação segue uma vez e avisa.

Corrija, envie de novo e compare de novo até nada bloquear. Depois publique: npx sdh publish meu-site <id-do-deploy>.
Ligue o domínio: npx sdh domain:add meu-site www.seu-site.com.br. Crie o registro TXT que ele mostra (a prova de que o domínio é seu) e o CNAME (ou registros A, para o domínio sem www). Confira com npx sdh domain:check www.seu-site.com.br. O domínio só é servido depois que o TXT é verificado.
Mantenha o site no Netlify até o DNS virar e os leads chegarem na caixa nova (npx sdh leads meu-site).

Desfazer

Aponte o DNS de volta para o Netlify. No SeeDropHost todo deploy continua guardado; sdh publish com um id anterior volta a versão na hora.