Olimpiaseg
Cliente — site institucional + CRM de seguros
Estado-alvo: NÃO PUBLICADO — fora do ar, sem acesso externo
Desligamento total solicitado. Projeto de cliente: exige comunicação formal e entrega dos dados.
O que existe hoje (o que será desligado)
- App publicado (site público + CRM interno)
- Banco Lovable Cloud (leads, oportunidades, apólices, seguradoras, regras, blog)
- Autenticação e usuários do CRM
- Domínio / DNS apontando para o app
- Formulários do site que gravam leads
1. Backup (antes de desligar qualquer coisa)
Sair com cópia completa e restaurável dos dados. Nada é desligado antes desta fase estar concluída e verificada.
- 1Exportar o banco (dump completo)críticoLovable Cloud → Advanced settings → Export data. Guardar o dump .sql com data no nome em pasta segura do grupo (drive interno + cópia offline).
- 2Exportar tabelas críticas em CSVAlém do dump, exportar em CSV as tabelas de negócio (clientes, leads, contratos, pedidos) para leitura sem restaurar o banco.
- 3Baixar arquivos do storagecríticoDocumentos, imagens e anexos do bucket. O dump SQL não inclui arquivos de storage.
- 4Exportar usuários de autenticaçãoLista de usuários (e-mail, criação, último login). Senhas não são exportáveis — se o projeto voltar, será reset de senha.
- 5Salvar o códigocríticoConectar/atualizar o repositório GitHub do projeto ou baixar o ZIP do código. Sem isso o front-end também se perde.
- 6Registrar segredos e integraçõesListar nomes das secrets, webhooks configurados e URLs de callback em documento interno (sem colar valores em texto aberto).
- 7Backup específicoExportar leads, oportunidades e apólices em CSV para entregar ao cliente em formato aberto.
- 8Backup específicoSalvar os posts do blog (conteúdo + imagens) — costuma ser o que mais dá trabalho recriar.
- 9Verificar o backupcríticoRestaurar o dump em um Postgres de teste e conferir contagem de linhas das tabelas principais. Só marcar a fase como concluída após isso.
2. Comunicação e congelamento
Ninguém deve estar usando o sistema no momento do desligamento.
- 1Avisar os usuárioscríticoComunicação formal ao cliente (corretora), por escrito, com data de encerramento, o que será entregue (dump + CSVs + arquivos) e prazo de guarda dos dados.
- 2Definir data e hora de corteEscolher janela de baixo uso e comunicar com pelo menos 7 dias de antecedência.
- 3Modo somente leituraSe possível, bloquear escritas alguns dias antes para o backup final não ficar desatualizado.
- 4Backup final (delta)Repetir o export no dia do corte, já com o sistema congelado.
3. Desligamento técnico
Cortar tráfego e custo, na ordem que evita erro visível ao público.
- 1Remover domínio customizadoTirar o apontamento DNS antes de despublicar, para não deixar domínio do cliente exibindo erro.
- 2Despublicar o appcríticoDesativa a URL pública e para o consumo de compute/egress.
- 3Desligar formulários e integrações de entradaQualquer form, e-mail ou automação que ainda envia lead para este banco precisa ser desativado ou reapontado.
- 4Revogar chaves e secretscríticoInvalidar tokens de integração e chaves de serviço. Se algum token era compartilhado com outro projeto, rotacionar lá também.
- 5Remover acessos de usuáriosDesativar contas do CRM e remover colaboradores do projeto no Lovable.
4. Encerramento e guarda
Fechar o ciclo com rastro documental.
- 1Entregar os dados ao clienteEnviar pacote (dump + CSVs + arquivos) com protocolo de recebimento assinado — cobre a parte de LGPD.
- 2Definir prazo de retençãoCombinar por quanto tempo o grupo mantém a cópia (ex.: 12 meses) e agendar o descarte.
- 3Arquivar o projeto no LovablecríticoSó arquivar/excluir depois do aceite do backup. Exclusão de projeto é irreversível.
- 4Atualizar esta centralMarcar o projeto como desligado para sair das projeções de custo.
Pontos de atenção
- • Dados de seguros e propostas são sensíveis (LGPD): a entrega ao cliente e o descarte precisam estar documentados.
- • Site público e CRM vivem no mesmo app — despublicar derruba os dois ao mesmo tempo.
- • O domínio do cliente deve sair antes da despublicação para não ficar página de erro no ar.
Frank.IA
Grupo RBR — plataforma de gestão de franquias (VZL)
Estado-alvo: PUBLICADO com restrição de IP — acesso interno apenas
Continua no ar, mas fechada: acesso só do ambiente liberado (IP), ninguém de fora entra.
O que existe hoje (o que será desligado)
- App publicado (dashboard, unidades, chamados, expansão, pedidos)
- Banco Lovable Cloud (unidades, franqueados, checklists, chamados, leads, pedidos, logs de agentes)
- Autenticação e papéis de acesso
- Agentes de IA, automações e integrações configuráveis
- Edge functions de orquestração
- Suíte de testes e código no repositório
1. Backup (antes de desligar qualquer coisa)
Sair com cópia completa e restaurável dos dados. Nada é desligado antes desta fase estar concluída e verificada.
- 1Exportar o banco (dump completo)críticoLovable Cloud → Advanced settings → Export data. Guardar o dump .sql com data no nome em pasta segura do grupo (drive interno + cópia offline).
- 2Exportar tabelas críticas em CSVAlém do dump, exportar em CSV as tabelas de negócio (clientes, leads, contratos, pedidos) para leitura sem restaurar o banco.
- 3Baixar arquivos do storagecríticoDocumentos, imagens e anexos do bucket. O dump SQL não inclui arquivos de storage.
- 4Exportar usuários de autenticaçãoLista de usuários (e-mail, criação, último login). Senhas não são exportáveis — se o projeto voltar, será reset de senha.
- 5Salvar o códigocríticoConectar/atualizar o repositório GitHub do projeto ou baixar o ZIP do código. Sem isso o front-end também se perde.
- 6Registrar segredos e integraçõesListar nomes das secrets, webhooks configurados e URLs de callback em documento interno (sem colar valores em texto aberto).
- 7Backup específicoBackup mesmo continuando no ar: se a trava de IP for mal configurada, você quer poder restaurar.
- 8Backup específicoExportar logs dos agentes de IA — podem conter dados sensíveis.
- 9Backup específicoExportar a configuração das integrações antes de mexer em tokens.
- 10Verificar o backupcríticoRestaurar o dump em um Postgres de teste e conferir contagem de linhas das tabelas principais. Só marcar a fase como concluída após isso.
2. Fechar o acesso por IP
Só o ambiente liberado (seu IP fixo / VPN) enxerga o app. Todo o resto recebe bloqueio.
- 1Descobrir o IP liberadocríticoConfirmar o IP público fixo do escritório/VPN. Se for IP dinâmico, a trava quebra sozinha — nesse caso usar Cloudflare Access por e-mail.
- 2Colocar o domínio atrás do CloudflareDomínio no Cloudflare com proxy ligado (nuvem laranja). Sem proxy, o WAF não filtra nada.
- 3Criar regra WAF de bloqueiocríticoCustom rule: (ip.src not in {SEU_IP}) → Block. Testar de fora (4G do celular) e confirmar o bloqueio.
- 4Bloquear também a URL .lovable.appcríticoA regra de IP só protege o domínio no Cloudflare. A URL frank-ia.lovable.app continua aberta — precisa de visibilidade privada no Lovable ou login obrigatório no app.
- 5Exigir login em todas as rotasIP é a camada externa, não substitui auth. Todas as rotas de dados devem continuar atrás de autenticação.
3. Revisão de segurança
Garantir que nada fica exposto mesmo com a trava de IP.
- 1Desligar o Inspect / badge de ediçãocríticoProject Settings → tirar o badge 'Edit with Lovable' e qualquer painel de inspeção no app publicado, para não expor a origem nem atalho de edição.
- 2Desligar remix públicocríticoProject Settings → General → Public remixing OFF. Remix público entrega o código-fonte inteiro, inclusive integrações.
- 3Conferir chaves no frontcríticoSó chave publishable pode aparecer no bundle. Service role, tokens de terceiros e chaves de IA nunca — se houver, rotacionar imediatamente.
- 4Revisar RLS de todas as tabelasRLS ligado e política escopada por usuário/unidade. Nenhuma política aberta a anon em tabela de dados.
- 5Fechar endpoints públicoscríticoRotas /api/public e webhooks precisam validar assinatura ou token — a trava de IP não cobre quem chama a API direto.
- 6Limpar usuários e papéisRemover contas de teste e ex-colaboradores; revisar quem é admin. Papéis em tabela própria, nunca no perfil.
- 7Revisar logs dos agentes de IASe gravam prompts com dados de franqueados, definir retenção e limpar histórico antigo.
- 8Rodar o scan de segurançaExecutar a varredura de segurança do projeto e tratar tudo que for crítico antes de considerar fechado.
4. Manutenção do estado fechado
Não deixar a trava se degradar com o tempo.
- 1Documentar o IP e a regraRegistrar qual IP está liberado e onde a regra vive, para não perder o acesso quando o link mudar.
- 2Revisar mensalmenteConferir se o IP ainda é o mesmo e se a regra continua ativa após mudanças de DNS.
- 3Monitorar custoContinua no ar, então continua consumindo. Acompanhar os ~R$ 33/30d na aba Banco de Dados.
- 4Atualizar esta centralManter o estado 'publicado com restrição de IP' registrado aqui.
Pontos de atenção
- • Trava de IP protege o domínio no Cloudflare — a URL .lovable.app precisa ser fechada separadamente, senão a proteção é ilusória.
- • IP fixo é obrigatório. Com IP dinâmico você se auto-bloqueia; nesse cenário use Cloudflare Access por e-mail.
- • Restrição de IP não substitui autenticação nem RLS: quem entrar no ambiente liberado veria tudo.
- • Como o projeto continua ativo, os agentes de IA e integrações seguem rodando e gastando — revise se todos ainda são necessários.