Referência de implantação, configuração e administração do AI Reality Check.
O AI Reality Check é implantado no Railway com um serviço web Next.js e um banco de dados PostgreSQL. O app é construído com `npm run build` e iniciado com `npm start`.
Como o auto-deploy do Railway via GitHub pode parar silenciosamente de funcionar, sempre implante manualmente: `cd ai-reality-check && railway up`. Isso constrói e implanta em um único passo.
O domínio de produção é airealitycheck.ai, configurado nas definições de domínio personalizado do Railway. O SSL é gerenciado automaticamente via Let's Encrypt (TLS 1.3).
DATABASE_URL — string de conexão PostgreSQL (fornecida pelo Railway). ENCRYPTION_KEY — chave hex de 32 bytes para criptografia AES-256-GCM. ANTHROPIC_API_KEY — chave de API para Claude (Verificação de Confiança + Chatbot). NEXT_PUBLIC_APP_URL — https://airealitycheck.ai. RESEND_API_KEY — chave de API para emails de link mágico.
GOOGLE_CLIENT_ID, GOOGLE_CLIENT_SECRET — credenciais OAuth do Google. GITHUB_CLIENT_ID, GITHUB_CLIENT_SECRET — credenciais OAuth do GitHub. Todas as URIs de redirecionamento OAuth devem apontar para /api/auth/callback/google e /api/auth/callback/github respectivamente.
Nunca faça commit de variáveis de ambiente no git. Todos os segredos são gerenciados pelas configurações de variáveis de ambiente do Railway. A ENCRYPTION_KEY deve ter exatamente 64 caracteres hexadecimais (32 bytes). Gere uma com: openssl rand -hex 32
Prisma 6 é usado para acesso ao banco de dados. O schema está em prisma/schema.prisma. Execute `npx prisma db push` para sincronizar alterações no schema (sem necessidade de migrações para desenvolvimento).
User, AuthToken, Session, Result, AuditLog, WaitlistEntry, ChatConversation, ChatMessage. Todos os dados voltados ao usuário são criptografados em repouso usando AES-256-GCM antes do armazenamento.
Use Docker para PostgreSQL local: `docker run -d -p 5432:5432 -e POSTGRES_PASSWORD=postgres -e POSTGRES_DB=airealitycheck postgres:16`. Defina DATABASE_URL=postgresql://postgres:postgres@localhost:5432/airealitycheck no .env.
Todos os dados de resultados e mensagens de chat são criptografados com AES-256-GCM antes do armazenamento no banco de dados. As chaves são gerenciadas via variáveis de ambiente e nunca expostas ao cliente. O texto original da verificação de confiança nunca é armazenado.
Cabeçalhos de segurança são aplicados via middleware: CSP, X-Frame-Options DENY, HSTS, X-Content-Type-Options nosniff, Referrer-Policy, Permissions-Policy. O CSP permite 'self' para scripts, estilos, imagens, fontes e conexões.
Todas as rotas de API que alteram estado validam um token CSRF. O token é gerado no servidor e atualizado automaticamente pelo componente CsrfRefresh. Os tokens expiram após 24 horas.
Limitador de taxa em memória com limites por endpoint: Verificação de Confiança 10/hora, Verificação de Prontidão/Gastos 20/hora, Link Mágico 5/15min, Chatbot 30/hora. Adequado para implantação de instância única.
Autenticação por email via Resend. O usuário insere o email, recebe um link mágico e clica para verificar. O token é hasheado com bcrypt e expira em 15 minutos. O cookie de sessão é definido na verificação.
OAuth do Google e GitHub são suportados. Os cookies de sessão usam SameSite=Lax (necessário para redirecionamentos OAuth de origem cruzada). Os cookies são definidos diretamente nos objetos de resposta para respostas de redirecionamento.
As sessões duram 24 horas. Configurações de cookie: HttpOnly, Secure (produção), SameSite=Lax, Path=/. Os registros de sessão são armazenados no banco de dados com userId e expiração.
Navegue até /admin/marketing (requer variável ADMIN_EMAIL + autenticação). Selecione uma plataforma (X, LinkedIn, Facebook) e um tópico, então o Claude gera conteúdo de mídia social pronto para publicar com ganchos, hashtags e CTAs.
POST para /api/marketing/waitlist-blast envia emails de lançamento para todos os assinantes do waitlist que ainda não foram notificados. Envia em lotes de 50, rastreia notifiedAt para evitar envios duplicados. Protegido por autenticação admin + CSRF.
Configure a variável de ambiente ADMIN_EMAIL no Railway com seu endereço de email. Apenas usuários autenticados que correspondam a este email podem acessar as ferramentas de marketing. Todas as ações são protegidas por CSRF e registradas em auditoria.
Crie um novo arquivo .ts em src/data/blog-content/ com campos de título, slug, descrição, conteúdo e relatedCheck. Adicione a importação no arquivo index.ts. O sitemap e o feed RSS atualizam automaticamente.
Os artigos usam dados estáticos TypeScript (sem CMS, sem banco de dados). Cada artigo vincula a uma verificação relacionada via CTA. O conteúdo suporta títulos, parágrafos, listas e texto em negrito. Os artigos são apenas em inglês (não traduzidos).
O sitemap em /sitemap.xml e o feed RSS em /feed.xml incluem automaticamente novos artigos. Nenhuma atualização manual necessária — ambos leem o array de conteúdo do blog no momento da compilação.
Quatro modelos de email em src/lib/emails.ts: email de boas-vindas (no cadastro), resumo de resultados (após verificação), reengajamento (para usuários incompletos) e envio em massa para waitlist (anúncio de lançamento). Todos usam HTML com marca no tema escuro do app.
Acione via /api/marketing/waitlist-blast. Envia para todos os registros WaitlistEntry onde notifiedAt é nulo. Lotes de 50 com atrasos para evitar limites de taxa. Cada envio bem-sucedido atualiza notifiedAt para evitar reenvios.
Sem RESEND_API_KEY configurada, todos os emails são registrados no console em vez de enviados. Use isso para desenvolvimento local para verificar o conteúdo e os gatilhos de email sem enviar mensagens realmente.
Os esquemas JSON-LD de FAQ, Breadcrumb e Product são aplicados nas páginas de verificações e preços. Teste com a ferramenta de teste de resultados enriquecidos do Google (search.google.com/test/rich-results) para verificar se os dados estruturados renderizam corretamente.
Imagens OG dinâmicas geradas via /api/og/result?type={check}&score={score}. Imagens OG baseadas em arquivos nos diretórios de layout para páginas estáticas. Teste com depuradores de mídia social (Twitter Card Validator, LinkedIn Post Inspector).
Adicione airealitycheck.ai ao Google Search Console, verifique via DNS e envie o sitemap. Monitore o status de indexação, erros de cobertura e desempenho de busca. Verifique problemas de dados estruturados na aba Melhorias.
Todas as ações significativas são registradas na tabela audit_logs: login, envio de verificações, visualizações de resultados, uso do chatbot. Cada registro inclui userId, ação, endpoint, hash de IP e metadados.
Visualize os logs da aplicação com `railway logs -n 50`. Verifique o painel do Railway para status de implantação, uso de recursos e rastreamento de erros.
Verifique se o app está funcionando acessando a página inicial. Acesse /sitemap.xml e /robots.txt para verificar se a geração estática está funcionando.
Verifique se SameSite está definido como Lax (não Strict). Confirme que as URIs de redirecionamento OAuth correspondem exatamente. Verifique se o CSP form-action inclui os domínios dos provedores OAuth. Veja docs/issues/google-oauth-login-broken.md para o relato completo.
O auto-deploy do Railway via GitHub pode parar silenciosamente de funcionar. Sempre use `railway up` no diretório ai-reality-check como alternativa confiável. Verifique `railway logs` para confirmar que a nova versão está rodando.
Verifique se DATABASE_URL está configurada corretamente no ambiente do Railway. Para desenvolvimento local, certifique-se de que o contêiner Docker PostgreSQL está rodando. Execute `npx prisma db push` para sincronizar o schema.
Verifique se ANTHROPIC_API_KEY está definida e é válida. Verifique os limites de taxa (10/hora por usuário). Certifique-se de que o texto de entrada tem menos de 5.000 caracteres. Verifique os logs do Railway para erros específicos de API.