O que é o SeeDropHost?

Uma hospedagem de sites estáticos que roda no seu próprio servidor (Node.js 24). Você publica um site já pronto — um HTML, um .zip ou uma pasta — pela API HTTP, pela linha de comando sdh, por MCP (para agentes de IA) ou pelo painel. Versão 0.1.0; ainda não existe uma instância pública hospedada.

Dá para publicar um único arquivo HTML?

Sim. Envie o arquivo como corpo de POST /v1/sites/{site}/deploys/html ou rode sdh deploy pagina.html --site meu-site. Se quem opera o servidor ligou a publicação sem conta, POST /v1/drop publica sem token por 24 horas.

Serve como alternativa ao Netlify?

Para site já construído (HTML, CSS, JS, imagens), sim: lê o netlify.toml (pasta publicada, redirecionamentos, cabeçalhos), _redirects, _headers e formulários data-netlify. Não roda o seu comando de build e não tem CDN global própria. Funções de um arquivo só rodam se quem opera o servidor ligar, e só em servidor de dono único, porque não são isoladas.

Três planos: Grátis (R$ 0, 3 sites, uso comercial liberado), Pro (R$ 29/mês) e Agência (R$ 149/mês), todos com deploys ilimitados. A cobrança abre junto com o primeiro servidor público; até lá não há nada a pagar. Rodando no seu servidor, o custo é o do servidor.

Um agente de IA pode derrubar meu site?

Não pelas ferramentas de deploy do MCP: todo deploy feito por agente nasce rascunho, com endereço de prévia. Colocar no ar (publish_deploy) e trocar ou apagar variável (set_env_var, delete_env_var) são marcados como destrutivos, então o cliente MCP pede confirmação a uma pessoa, e toda escrita fica na auditoria com o autor.

Hospedagem de sites para pessoas e agentes de IA

Publique um site pronto em um passo

O SeeDropHost é uma hospedagem de sites estáticos que roda no seu próprio servidor. Você envia um HTML, um .zip ou uma pasta — com um único comando curl, com a linha de comando sdh, por MCP ou pelo painel — e recebe o endereço no ar. Deploy feito por agente de IA nasce como rascunho, e todo deploy vem com um relatório de SEO/GEO.

# um .zip, para um site que já existe (precisa do token do servidor)
curl --data-binary @site.zip -H "content-type: application/zip" \
  -H "Authorization: Bearer $SDH_TOKEN" \
  "$SDH_API_URL/v1/sites/meu-site/deploys/zip"
# uma pasta, pela linha de comando: só sobe o que mudou
npx sdh deploy ./dist --site meu-site

Começar Migrar do Netlify Comparação (em inglês)

Como está hoje

Versão 0.1.0. Roda no seu computador ou na sua VPS (guia, em inglês). Ainda não existe instância pública hospedada; o primeiro servidor público está em preparação.
Preços: Grátis, Pro (R$ 29/mês) e Agência (R$ 149/mês). A cobrança por Pix e boleto já está no código; os planos hospedados abrem junto com o primeiro servidor público, e até lá nada é vendido.
A linha de comando roda a partir de uma cópia do repositório (npx sdh ou npm run sdh --); ela não está publicada no npm.

Feito para agentes, com uma pessoa no botão de publicar

O SeeDropHost tem um servidor MCP com as mesmas ferramentas em duas formas: local (stdio, lê só as pastas que você liberar) e remoto em /mcp (Streamable HTTP, token Bearer, nunca lê o disco do servidor).

O agente publica. deploy_files (ou deploy_directory / deploy_zip no MCP local) sempre cria um rascunho: nada muda para quem visita. O agente recebe o endereço de prévia, a nota de SEO/GEO e os formulários encontrados.
Uma pessoa confere a prévia. Rascunhos e versões antigas saem com X-Robots-Tag: noindex, para não entrarem no Google.
Uma pessoa aprova. publish_deploy é marcada como destrutiva (destructiveHint: true), então o cliente MCP pergunta antes. A mesma ferramenta volta para qualquer versão anterior.

# Claude Code com o MCP remoto (seu servidor)
claude mcp add --transport http seedrophost https://seu-servidor.exemplo/mcp \
  --header "Authorization: Bearer seu-token"

Ferramentas do MCP e quais são destrutivas (em inglês) →

O que ele faz e vale saber

Deploy por conteúdo

Cada arquivo é guardado pelo seu SHA-256. O deploy manda a lista e só sobe o que falta; publicar a mesma pasta duas vezes sobe 0 arquivos. Todo deploy é imutável e tem endereço próprio.

Comparador de migração, endereço por endereço

sdh comparar <site-atual> <prévia-do-rascunho> lê os dois sites, inclusive os endereços antigos do seu _redirects e do netlify.toml, e bloqueia a troca se status, redirecionamento, canonical, noindex, hreflang, formulários ou o robots.txt quebrarem. Sai com código 1 quando algo bloqueia.

Relatório de SEO/GEO a cada deploy

Título, description, canonical, lang, um h1, JSON-LD válido, robots, robots.txt, sitemap.xml, llms.txt, página 404 e títulos repetidos, com nota de 0 a 100 e a lista de páginas que mudaram.

Formulários com caixa de leads

Marque o formulário com data-sdh-form ou com o data-netlify que você já usa. Os envios caem numa caixa que você lê pela API, linha de comando, MCP ou painel, com honeypot, regra de links e limite por IP.

Auditoria com o autor

Toda ação de escrita registra quem fez (cli, mcp-remoto, dashboard ou o cabeçalho x-sdh-actor), o quê e quando. Variáveis secretas ficam criptografadas (AES-256-GCM) e sempre mascaradas.

No seu servidor

Um instalador prepara Node 24, serviço systemd endurecido, Caddy com um certificado curinga para os seus sites e HTTPS sob demanda só para domínios de clientes já verificados, firewall e backup diário. Pensado para ficar atrás da Cloudflare no plano grátis.

O que ainda não faz

Não tem CDN global própria. O site sai do seu servidor; o guia coloca a Cloudflare na frente.
Não faz build a partir do Git nem deploy a cada push: você publica arquivos já prontos.
Não tem funções isoladas. O netlify.toml é lido (pasta publicada, redirecionamentos, cabeçalhos) e funções de um arquivo só rodam se quem opera o servidor ligar, mas só para servidor de um dono único: a função consegue ler o servidor inteiro. Mesmo assim, só rodam nos sites da conta principal. Sem edge functions, funções agendadas ou em segundo plano.
OAuth no MCP remoto: Em construção (hoje: token Bearer).
Página de status pública e histórico de disponibilidade: chegam com o primeiro servidor público.
Cada conta tem os próprios tokens (até 20, e cada conta vê só os próprios sites), mas ainda não há pessoas nem papéis: são vários tokens com rótulo, não usuários.

Perguntas

O que é o SeeDropHost?: Uma hospedagem de sites estáticos que roda no seu próprio servidor (Node.js 24). Você publica um site já pronto — um HTML, um .zip ou uma pasta — pela API HTTP, pela linha de comando sdh, por MCP (para agentes de IA) ou pelo painel. Versão 0.1.0; ainda não existe uma instância pública hospedada.
Dá para publicar um único arquivo HTML?: Sim. Envie o arquivo como corpo de POST /v1/sites/{site}/deploys/html ou rode sdh deploy pagina.html --site meu-site. Se quem opera o servidor ligou a publicação sem conta, POST /v1/drop publica sem token por 24 horas.
Serve como alternativa ao Netlify?: Para site já construído (HTML, CSS, JS, imagens), sim: lê o netlify.toml (pasta publicada, redirecionamentos, cabeçalhos), _redirects, _headers e formulários data-netlify. Não roda o seu comando de build e não tem CDN global própria. Funções de um arquivo só rodam se quem opera o servidor ligar, e só em servidor de dono único, porque não são isoladas.
Quanto custa?: Três planos: Grátis (R$ 0, 3 sites, uso comercial liberado), Pro (R$ 29/mês) e Agência (R$ 149/mês), todos com deploys ilimitados. A cobrança abre junto com o primeiro servidor público; até lá não há nada a pagar. Rodando no seu servidor, o custo é o do servidor.
Um agente de IA pode derrubar meu site?: Não pelas ferramentas de deploy do MCP: todo deploy feito por agente nasce rascunho, com endereço de prévia. Colocar no ar (publish_deploy) e trocar ou apagar variável (set_env_var, delete_env_var) são marcados como destrutivos, então o cliente MCP pede confirmação a uma pessoa, e toda escrita fica na auditoria com o autor.