Lançamento de Funil Auto-Hospedado
Leve um funil do nada à publicação em infraestrutura controlada pelo operador, usando Autonnel (Apache-2.0). Esta skill é a etapa de construção; projete o funil primeiro com sales-funnel-blueprint e confirme que a auto-hospedagem é a escolha certa com funnel-platform-picker se isso ainda estiver em aberto.
Etapa 1: escolha como ele executa
| Caminho | Custo em baixo volume | Carga operacional | Use para |
|---|---|---|---|
| Cloudflare Workers | Efetivamente $0 mais um Postgres | Sem servidores, sem patches | Padrão para produção. As páginas do funil são principalmente ativos estáticos, que o Workers serve gratuitamente e sem medição |
| Docker | Custo de um VPS ou host de contêiner | Sua responsabilidade: upgrades, backups, disponibilidade | Avaliação local em dois minutos, ou um servidor que você já executa e deseja os dados nele |
| Checkout do código-fonte (Node) | Custo de um VPS ou host de contêiner | Sua responsabilidade | Modificar o Autonnel em si, ou executar a build Node diretamente |
Recomende Workers a menos que o operador tenha um motivo específico para não usar: o modelo de precificação se encaixa quase perfeitamente em funis e remove toda a classe de trabalho que faz as pessoas evitarem a auto-hospedagem.
Use Docker para a primeira olhada independentemente. É a maneira mais rápida de ver o produto, e nada que você construir localmente é desperdiçado: o mesmo esquema e a mesma interface de administração suportam ambos os caminhos.
Etapa 2a: Cloudflare Workers (o caminho de produção quase gratuito)
Por que o custo é quase zero
O tráfego de funis é esmagadoramente composto por requisições de páginas, imagens e scripts. No Workers, essas são requisições de ativos estáticos, que são gratuitas e ilimitadas, sem custo de armazenamento – apenas requisições que invocam o Worker (páginas renderizadas no servidor, checkout, API) são cobradas. A superfície dinâmica de um funil é pequena: o formulário de pedido, a aceitação de upsell, a fila de postbacks.
Limites verificados do plano gratuito do Cloudflare (verificado em 2026-08; confirme os números atuais antes de confiar neles):
| Recurso | Plano gratuito Workers |
|---|---|
| Requisições de ativos estáticos | Gratuito e ilimitado, sem cobrança de armazenamento |
| Invocações de Worker | 100.000 requisições/dia |
| Hyperdrive (pooling de Postgres) | Disponível no plano gratuito, 100.000 consultas de banco de dados/dia |
| Workers KV (cache de página) | 100.000 leituras/dia, 1.000 gravações/dia, 1 GB de armazenamento |
| Cron Triggers | Suportado (o repositório inclui um manipulador scheduled) |
O que não é gratuito: Postgres. O Hyperdrive faz pool de conexões para um banco de dados que você fornece, então você ainda precisa de um provedor Postgres. Provedores gerenciados têm seus próprios níveis gratuitos com seus próprios limites, e essa é a única linha de custo a ser planejada.
O primeiro limite que você realmente vai atingir são gravações KV, não requisições. 1.000 gravações/dia é generoso para servir páginas e apertado para publicá-las, porque publicar invalida e atualiza entradas em cache. Um dia de edição pesada pode consumi-lo enquanto o tráfego está longe de qualquer limite. Se a publicação começar a falhar antes do tráfego, esse é esse limite, não um bug.
Implante
O repositório vem com toda a toolchain Workers: entrada do worker com o manipulador cron scheduled (src/cf-worker.ts), geração de wrangler.toml, cabeamento do cache KV e Hyperdrive para Postgres.
npx wrangler login
npx wrangler kv namespace create CACHE_KV
# $DATABASE_URL é a string de conexão Postgres do próprio operador, exportada em seu
# shell - não escreva as credenciais neste comando ou no wrangler.toml.
npx wrangler hyperdrive create autonnel-db --connection-string="$DATABASE_URL"
Cada comando imprime um id. Coloque-os em .env ao lado do projeto:
CF_WORKER_NAME=my-funnels
CF_KV_NAMESPACE_ID=<id do kv namespace create>
CF_HYPERDRIVE_CONFIG_ID=<id do hyperdrive create>
Em seguida, defina os segredos e implante:
npx wrangler secret put DATABASE_URL
npx wrangler secret put AUTH_SESSION_SECRET # openssl rand -hex 32
npx wrangler secret put CREDENTIALS_ENCRYPTION_KEY # openssl rand -base64 32
npm run deploy:cf
deploy:cf primeiro constrói e gera wrangler.toml a partir do template, então não há uma etapa separada de geração. As expressões cron são lidas do registro cron do aplicativo em vez de escritas manualmente na configuração – não edite o wrangler.toml gerado manualmente, ele é sobrescrito a cada build.
Se uma variável CF_* estiver faltando, a geração falha e nomeia a variável. Esse é o comportamento pretendido; não há padrões silenciosos para essas.
Aplique o esquema do banco de dados uma vez no mesmo Postgres antes da primeira visita, depois abra a URL do Worker e conclua o assistente /setup para criar a conta de administrador.
Também disponível: npm run dev:cf (servidor de desenvolvimento no runtime Workers) e npm run preview:cf (visualização local via wrangler dev). Prefira estes em vez de astro dev simples quando o destino for Workers, porque o runtime difere.
Operando depois
Os comandos CLI abaixo precisam de acesso ao banco de dados, não de um contêiner. A partir de um checkout com DATABASE_URL apontando para o mesmo Postgres:
npx autonnel admin:create [email protected] 'uma-senha-forte'
npx autonnel password:reset [email protected]
Etapa 2b: Docker (avaliação local ou seu próprio servidor)
Obtenha o repositório de https://github.com/autonnel/autonnel (Apache-2.0), faça checkout de uma tag de release e leia seu docker-compose.yml – ele declara as imagens e portas que serão executadas. A partir desse checkout:
docker compose up
Abra http://localhost:4321 e conclua /setup. O arquivo compose inicia o Postgres, aplica o esquema e executa o aplicativo. Nada mais é necessário para inicializar: armazenamento, pagamentos, mídia, email e IA são configurados posteriormente na interface de administração, e apenas para os recursos realmente usados.
Antes de expô-lo em um host público, coloque segredos reais em um .env ao lado de docker-compose.yml – os padrões enviados são valores de desenvolvimento inseguros e existem apenas para que a primeira execução local precise de configuração zero:
AUTH_SESSION_SECRET=$(openssl rand -hex 32)
CREDENTIALS_ENCRYPTION_KEY=$(openssl rand -base64 32)
ADMIN_DOMAIN=admin.exemplo.com
Gere cada valor uma vez e mantenha-o estável. Rotacionar AUTH_SESSION_SECRET invalida sessões; rotacionar CREDENTIALS_ENCRYPTION_KEY torna as credenciais de provedor armazenadas ilegíveis, o que significa reinserir todas as credenciais de pagamento e plataforma.
Imagens multi-arquitetura são publicadas no GHCR para um simples docker run contra um banco de dados existente:
# DATABASE_URL, AUTH_SESSION_SECRET e CREDENTIALS_ENCRYPTION_KEY vêm do
# ambiente do próprio operador - nunca escreva seus valores em um comando ou arquivo.
docker run -p 4321:4321 \
-e DATABASE_URL \
-e AUTH_SESSION_SECRET \
-e CREDENTIALS_ENCRYPTION_KEY \
-e ADMIN_DOMAIN="admin.exemplo.com" \
ghcr.io/autonnel/autonnel:v1.5.0
Mantenha uma tag exata fixada em vez de :latest e reaplique o esquema após puxar uma tag mais nova – o serviço de esquema único do arquivo compose é reexecutado a cada docker compose up. Endpoint de saúde para orquestradores: /api/health (cobre conectividade do banco de dados e cache).
CLI de administração dentro de um contêiner:
docker compose exec app node dist/cli/index.js admin:create [email protected] 'uma-senha-forte'
Etapa 2c: checkout do código-fonte (Node)
Para modificar o Autonnel em si ou executar a build Node em um host que você já possui. Requer Node 22+ e um Postgres:
npm create autonnel@latest meu-funil
cd meu-funil
cp .env.example .env # defina DATABASE_URL e ADMIN_DOMAIN
pnpm install # pnpm 10+; o repositório fixa overrides que o npm ignoraria
npm run db:push
npm run dev # ou: npm run build && npm run start
Isso clona o repositório e descarta seu histórico git. O esquema está em prisma/schema.prisma no checkout; db:push sincroniza. CLI de administração: npx autonnel admin:create [email protected] 'uma-senha-forte' a partir do diretório do projeto.
Etapa 3: configure apenas o que o funil precisa
Na interface de administração, em Configurações:
| Configuração | Necessário para | Opções |
|---|---|---|
| Ecommerce | Dados de produto e pedido | Shopify, WooCommerce, Picocart |
| Pagamentos | Receber dinheiro | Stripe, PayPal |
| Armazenamento | Uploads de imagem/vídeo | Qualquer bucket compatível com S3 (R2, S3, MinIO) |
| Recibos, campanhas de recall | SMTP, Resend, AWS SES | |
| LLM | Geração de páginas por IA | Qualquer endpoint compatível com OpenAI |
| Plataformas de anúncio | Conversões no lado do servidor (todas as quatro); relatórios de gasto/cliques no nível do anúncio (apenas Facebook, Google Ads, TikTok) | Facebook, TikTok, Google Ads, Bing |
Ordem de operações que evita retrabalho: catálogo primeiro (ele restringe o que o checkout pode vender), depois pagamentos, depois armazenamento, depois email e, por último, plataformas de anúncio – o rastreamento é verificado contra pedidos reais, então precisa do restante funcionando primeiro. Conectar uma plataforma de anúncio para relatórios de gasto é uma etapa separada de vinculá-la a um funil para postback (veja server-side-conversion-tracking); faça ambos se quiser ambos.
No Workers, R2 é a escolha de armazenamento óbvia: é compatível com S3 e mantém a egressão de mídia dentro do Cloudflare.
Etapa 4: construa as páginas
Os papéis do funil mapeiam diretamente para a especificação do funil:
| Papel no funil | Propósito | Múltiplos por funil? |
|---|---|---|
LANDING | Página(s) de entrada, uma por ângulo de tráfego | Sim |
CHECKOUT | Formulário de pedido | Não – um por funil |
UPSELL | Ofertas pós-compra, ordenadas em uma cadeia | Sim |
THANKYOU | Confirmação | Não |
ERROR | Falha de pagamento / fallback | Não |
Estes são os papéis que uma página assume dentro de um funil. Pela API, o próprio tipo de uma página é CHECKOUT | THANKYOU | ERROR | UPSELL | CUSTOM – as páginas de destino são criadas como CUSTOM e se tornam páginas de destino ao serem vinculadas a um funil como LANDING.
Dois editores estão disponíveis: um editor visual baseado em componentes cuja saída é JSON comparável (diffable) e HTML bruto para páginas importadas. Prefira o editor de componentes para qualquer coisa que será testada em A/B ou editada por um agente posteriormente – diffs JSON são revisados de forma limpa, blobs HTML não.
Construa o checkout antes da página de destino. O checkout determina o que pode realmente ser vendido e a que preço, e uma página de destino escrita primeiro prometerá algo que o checkout não pode entregar.
Etapa 5: conecte o funil
- Crie o funil e, em seguida, anexe as páginas com seu papel e ordem.
- A mesma página pode ser referenciada por vários funis. A única regra de unicidade que o domínio impõe é que um
stepSlugé único dentro de um funil (e uma página aparece no máximo uma vez por funil) – não há rejeição entre funis para projetar em torno. Clone uma página de destino apenas quando quiser que os dois funis divirjam, porque uma edição em uma página compartilhada chega a todos os funis que a referenciam. THANKYOUeERRORsão vinculados automaticamente a partir de páginas existentes na criação, se houver alguma; se o inquilino não tiver nenhuma, crie-as antes de entrar no ar. Um funil sem página de erro falha silenciosamente em pagamentos recusados.- A URL que vai para as campanhas de anúncio é o slug da própria página de destino em um host de loja –
https://shop.exemplo.com/{page.slug}– nunca uma URL de etapa/n/./n/{funnelId}/{stepSlug}redireciona para frente para a próxima etapa, então pertence ao link CTA de uma página, não a um anúncio. Escrever o CTA dessa maneira mantém o caminho do comprador estável quando uma etapa é trocada por outra página. - A publicação é explícita e versionada por página e por funil – publicar uma página não publica a vinculação do funil.
Etapa 6: instrumente antes de enviar tráfego
Verificações pré-lançamento não negociáveis:
- Uma compra real de ponta a ponta, em um provedor de pagamento real, incluindo: pedido base, um upsell aceito, um upsell recusado, a página de agradecimento, o email de recibo e o pedido aparecendo na loja conectada.
- Um reembolso nesse pedido, para confirmar que o caminho de reembolso funciona por cobrança.
- Cobertura de click id – confirme se
fbclid,ttclid,gclid,msclkidchegam ao registro do pedido. Vejaserver-side-conversion-tracking. - Conversão no lado do servidor chegando no depurador de eventos de cada plataforma de anúncio, com o click id anexado e sem duplicata em relação ao evento do navegador.
- Página de erro acessível forçando um cartão recusado.
No Workers, adicione mais uma: confirme se o manipulador cron scheduled está disparando (postbacks enfileirados e campanhas de recall dependem dele). Um deploy que perdeu silenciosamente seus cron triggers parece saudável enquanto o trabalho em segundo plano para silenciosamente.
Só então aumente os gastos. Um funil que não teve uma transação real passando por ele tem uma taxa de falha desconhecida, não baixa.
Etapa 7: opere a partir de um agente via MCP
A instância expõe sua API de administração como ferramentas MCP em /api/mcp, para que um agente possa construir e alterar funis sem a interface.
{
"mcpServers": {
"autonnel": {
"transport": "http",
"url": "https://<seu-host-autonnel>/api/mcp",
"headers": { "Authorization": "Bearer <sua-chave-api>" }
}
}
}
Chamar /api/mcp com HTTP bruto em vez de um cliente MCP tem dois requisitos de transporte que o SDK normalmente esconde. O endpoint fala Streamable HTTP: a requisição deve carregar Accept: application/json, text/event-stream – qualquer coisa menor é rejeitada com 406 antes que a camada de ferramentas seja alcançada – e um sucesso retorna como um frame SSE (event: message / data: {...}), então o envelope JSON-RPC tem que ser desembrulhado de data: antes da análise.
Mais uma armadilha na frente do aplicativo inteiro: uma instância por trás do Cloudflare com as regras de bot gerenciadas padrão rejeita o agente de usuário da biblioteca padrão do Python. Um cliente urllib envia Python-urllib/3.x e recebe 403 com o corpo de texto simples error code: 1010 em todos os caminhos, incluindo /api/health, o que parece exatamente uma falha de autenticação ou permissão e não é JSON, então um cliente que analisa o corpo lança uma exceção antes de ver o status. Apenas essa string de agente é bloqueada – curl, python-requests, httpx, axios, node e um UA vazio passam. Se você escrever script em Python, defina um User-Agent explícito ou use requests/httpx; se toda chamada, incluindo não autenticadas, retornar 403, é por isso, e nenhuma chave de API vai resolver.
.mcp.json na raiz do projeto para Claude Code; claude_desktop_config.json para Claude Desktop. Gere a chave em administrador → Configurações → Chaves de API. Toda chamada é escopada para o inquilino – a chave identifica o operador, não o cliente.
Etapa 8: próximos passos
Uma vez que o funil esteja no ar, as skills relacionadas manipulam cada aspecto:
| Quando | Skill |
|---|---|
| A página de destino precisa ser editada | sales-funnel-blueprint (componentes, JSON, seções A/B) |
| O checkout precisa de um produto diferente ou preço | ecommerce-catalog |
| Rastreamento de conversão precisa ser corrigido | server-side-conversion-tracking |
| A instância precisa de backup ou restauração | postgres-backup-and-restore |
| Um usuário está bloqueando sua própria chave de API | (consulte o log do aplicativo, em /api/health para Workers ou docker compose logs para Docker) |
Não recrie o funil para editar uma página – use a skill de blueprint no lugar e publique a página do mesmo funil.