Como fazer backup do projeto feito com IA em 2026

Como fazer backup do seu projeto?

Exporte o código para o GitHub: essa é a cópia de verdade, com histórico e possibilidade de rodar em outro lugar. Depois copie os dados que estão no Supabase e guarde os seus prompts em um arquivo de texto. Ter o projeto publicado não substitui nenhuma dessas três coisas.

O erro clássico é achar que backup é uma coisa só. Um projeto vivo tem pelo menos quatro camadas, cada uma mora em um lugar diferente e cada uma se copia de um jeito. Perder uma delas dá um estrago distinto.

Do que exatamente você precisa fazer backup?

Antes de escolher ferramenta, vale saber o que está em risco. A tabela abaixo é a lista completa de um projeto típico feito em um construtor.

Duas linhas dessa tabela costumam surpreender. A dos prompts, porque ninguém pensa neles como material do projeto até precisar refazer algo. E a das chaves, porque a tentação de deixar uma chave dentro do código é grande e o preço de fazer isso é um vazamento silencioso.

Por que exportar para o GitHub é o backup principal?

Porque é o único formato que sobrevive a qualquer cenário. Um repositório com o código do projeto é um arquivo normal, que um desenvolvedor abre, roda e continua sem depender de nós.

A exportação leva os fontes para uma conta sua. A partir daí você tem histórico de versões, pode criar ramificações e pode implantar em outro lugar. A implantação na sua própria conta da Vercel é o caminho natural quando você quer que o projeto passe a viver fora daqui.

Vale entender o sentido dessa via. Ela é uma saída: o repositório vira um projeto independente. Não trate a cópia como um botão de desfazer dentro do construtor, porque não é isso que ela faz. Se o seu objetivo é voltar atrás em uma alteração, o caminho é outra edição, com a instrução do que restaurar.

Os detalhes do que exatamente vai no pacote estão em dá para exportar o código?, e a configuração da ligação com a sua conta em construtor de apps com IA e GitHub.

Como salvar os dados que ficam no Supabase?

O banco é seu e está na sua conta, então a cópia se faz lá, com as ferramentas do próprio serviço. Isso é uma boa notícia: você não depende de ninguém para acessar os seus dados, e também não pode terceirizar a responsabilidade por eles.

Na prática existem dois níveis. O primeiro é a exportação do banco, que gera um arquivo com estrutura e conteúdo das tabelas. O segundo é a cópia dos arquivos que os usuários enviaram, que ficam no armazenamento e não saem junto com o banco.

Um detalhe que dá dor de cabeça depois: dados não são só as linhas das tabelas. As regras de acesso também são configuração e também se perdem. Ao anotar como o seu banco está organizado, inclua quais tabelas têm restrição de leitura e escrita, porque restaurar dados com as permissões erradas é pior que não restaurar. A conversa mais ampla sobre isso está em meus dados estão seguros?.

O que fazer com os prompts e as decisões do projeto?

Guardar em texto, em um arquivo qualquer que você controle. Parece exagero até o dia em que você precisa recriar uma tela e não lembra como pediu aquilo.

Um arquivo útil tem quatro blocos. O pedido original completo, do jeito que você escreveu. A lista de edições, uma linha por edição, na ordem em que aconteceram. As decisões que você tomou e por quê, incluindo as que você recusou. E os dados fixos do negócio: preços, telefone, endereço, textos aprovados.

Isso vale ainda mais em trabalho para cliente. Quando alguém pergunta em novembro por que a página de preços ficou daquele jeito, a resposta está no arquivo, não na sua memória. É também o material que economiza créditos: refazer um projeto a partir de um pedido bem escrito custa uma construção, enquanto reconstruir por tentativa e erro custa várias edições.

Com que frequência vale fazer a cópia?

Depende de quanto você perde se voltar no tempo. Essa é a única pergunta que importa, e ela tem respostas diferentes para cada camada.

Código muda quando você edita, então a exportação faz sentido depois de cada bloco de mudanças que você considera bom. Não é preciso exportar a cada correção de texto; é preciso exportar antes de mexer em algo grande.

Dados mudam sozinhos, com o uso. Uma loja que recebe pedidos todo dia precisa de uma rotina de cópia frequente, porque um dia perdido é um dia de pedidos perdidos. Um site institucional que só tem formulário de contato aguenta uma frequência bem menor.

Conteúdo e prompts mudam quando você mexe neles, e a cópia é praticamente automática se você mantiver a pasta em uma nuvem pessoal.

O que um backup não protege?

Três coisas, e é melhor saber disso antes de confiar demais.

Erro copiado. Se você apagou uma tabela por engano na terça e a cópia é de quarta, a cópia tem o erro dentro. É por isso que manter mais de uma geração de backup vale mais que manter a mais recente.

Contas de terceiros. O seu domínio está com um registrador, a cobrança com o Stripe, o e-mail com o Resend. Perder acesso a uma dessas contas não se resolve com backup de código: resolve-se com gerenciador de senhas e com verificação em duas etapas ativada.

Conhecimento. Um repositório não explica por que o cálculo do desconto é daquele jeito. Essa parte é o arquivo de decisões, e ela só existe se você escrever.

Quanto isso custa em créditos?

Exportar não é uma ação de geração, então o custo do backup em si não é o problema. O que consome crédito é reconstruir, e é justamente isso que o backup evita.

O plano gratuito traz 2.400 créditos, que dá para quatro construções. O Pro custa $25 por mês com 20.000 créditos, algo em torno de 33 construções ou 66 edições, e o Business custa $50 por mês com 20.000 créditos.

A conta prática é simples: um projeto refeito do zero custa uma construção mais a sequência de ajustes até voltar ao ponto anterior. Com o pedido original salvo em texto, essa sequência encolhe bastante.

Como testar se o seu backup presta?

Restaurando. Um backup que nunca foi restaurado é uma hipótese, não uma garantia, e o dia de descobrir isso não pode ser o dia do acidente.

O teste mínimo tem três passos. Baixe o repositório em uma pasta limpa e veja se ele roda. Suba a cópia do banco em um projeto novo do Supabase e confira se as tabelas chegaram com as linhas certas. Abra o arquivo de prompts e pergunte a si mesmo se alguém que não é você conseguiria refazer o projeto lendo aquilo.

Se os três passos passarem, você tem backup. Se algum falhar, você descobriu isso em um dia tranquilo, que é exatamente o objetivo.

Por onde começar?

Comece pela exportação, porque ela é a que mais protege e a que leva menos tempo. Depois crie o arquivo de texto com o pedido original colado dentro; leva cinco minutos e é o item que ninguém faz.

Se o seu projeto ainda não tem banco nem usuários, essas duas ações já cobrem quase tudo. Dá para conferir o caminho de exportação e publicação em zugo.dev, inclusive em um projeto de teste montado a partir de um dos 38 modelos prontos.