Copiar um projeto Supabase é diferente de transferir
Você já montou uma base que funciona. Agora precisa de uma demonstração, de uma versão independente ou de um ponto de partida para outro projeto. Refazer cada tabela, política e bucket pode significar repetir trabalho que já está pronto.
Prepare um backup da origem, crie um projeto de destino vazio, restaure os componentes incluídos e valide as configurações e os acessos antes de conectar a aplicação. A origem continua existindo; a cópia não fica sincronizada automaticamente com ela.
Se o objetivo for apenas mudar a organização responsável pelo mesmo projeto, o Supabase já oferece transferência entre organizações. Para criar outra base, também existe a opção nativa de restaurar um backup em um novo projeto, com requisitos próprios e escopo de banco de dados. Arquivos do Storage e outras configurações exigem trabalho adicional.
O Smoonb entra como uma forma de organizar o caminho de backup e restauração, reunindo os artefatos disponíveis para levar uma base a outro destino. A escolha depende do que você precisa copiar e de como quer conferir essa cópia.
Quando uma cópia independente faz sentido
Reaproveitar uma base
Começar outro projeto com uma estrutura conhecida, revisando regras e dados para o novo contexto.
Preparar uma demonstração
Criar uma base separada com dados de teste, sem depender da base usada pela aplicação original.
Explorar uma nova versão
Avaliar mudanças em um projeto independente, com suas próprias credenciais e integrações.
Para ambientes de desenvolvimento integrados ao seu fluxo de migrations, avalie também o Supabase Branching. Uma cópia via backup é um retrato do momento capturado, não um mecanismo de sincronização contínua.
O que precisa acompanhar a cópia
“Copiar o projeto” parece uma única ação, mas envolve partes diferentes. O banco pode estar correto enquanto a aplicação ainda aponta para arquivos, serviços ou redirects da origem. Por isso, defina o escopo antes de restaurar.
| Componente | O que conferir no backup | No novo projeto |
|---|---|---|
| Banco de dados | Esquema, dados e papéis, conforme as etapas concluídas no backup. | Confira tabelas, contagens, funções, extensões e políticas de acesso. |
| Supabase Storage | Arquivos e metadados presentes no pacote de Storage. | Confira buckets, objetos, permissões e downloads. Um dump do banco sozinho não contém os arquivos. |
| Edge Functions e migrations | Código exportado nas etapas selecionadas. | Revise o código, publique as funções necessárias e configure secrets separadamente. |
| Auth e Realtime | Exportações de configuração, quando disponíveis. | Use os arquivos como referência e aplique os ajustes manualmente no Dashboard. |
| Aplicação e serviços externos | Não são copiados automaticamente por um backup do Supabase. | Atualize URLs, chaves, redirects, webhooks, e-mails e variáveis do ambiente de destino. |
O conteúdo depende das opções selecionadas e das etapas que terminaram sem erros. Consulte nosso checklist de backup Supabase para conferir os artefatos antes de avançar.
Como preparar a cópia com o Smoonb
01Defina a origem e o que você quer reaproveitar
Anote a referência do projeto de origem e escolha os componentes necessários. Para uma demo ou uma nova aplicação, prefira dados de teste. Dados pessoais, usuários reais e secrets não devem ser levados para outro contexto por conveniência.
Se a origem recebe gravações, planeje uma janela adequada para obter uma base consistente, inclusive entre banco e Storage. Este roteiro não promete cópia sem interrupção ou captura simultânea de todos os componentes.
02Gere e confira o backup
Com o Smoonb instalado, a licença configurada e as credenciais apontando para a origem, execute o backup. Revise as opções e acompanhe os resultados de cada etapa.
npx smoonb backupConfira o projeto, a data, os logs e os arquivos gerados. Verifique se o pacote de Storage contém os objetos esperados e guarde uma cópia dos artefatos antes de usar qualquer comando de restauração.
03Crie um destino vazio e independente
Crie o novo projeto no Supabase e configure o destino no Smoonb com as credenciais correspondentes. Confira a referência duas vezes: a restauração escreve no destino selecionado. Não aponte esse processo para a origem ou para um projeto com dados que você precisa preservar.
Prepare Docker e Supabase CLI para a restauração e confira compatibilidade de versões e extensões. Mantenha os arquivos de configuração da origem e do destino claramente separados.
04Restaure e complete as configurações
Com o destino já confirmado, inicie a restauração e selecione os artefatos e as etapas compatíveis com o seu backup. Leia os resultados antes de prosseguir.
npx smoonb restoreUse as exportações de Auth e Realtime como referência para os ajustes manuais. Revise as Edge Functions e seus secrets. Redirects, provedores de login, endpoints externos e variáveis da aplicação precisam corresponder ao novo ambiente.
Antes de liberar a cópia, revise jobs agendados, triggers, webhooks e serviços de e-mail ou cobrança. Um destino novo ainda pode acionar sistemas reais se carregar configurações antigas. Use credenciais e destinatários de teste para validar.
05Valide antes de conectar a aplicação
Um comando concluído é apenas uma parte da conferência. Compare o que foi restaurado, teste os acessos e só então atualize a aplicação para a URL e as chaves do novo projeto. A aplicação original deve continuar apontando para a origem.
A cópia está pronta? Confira estes pontos
- Tabelas, contagens e registros de teste correspondem ao escopo escolhido.
- RLS e permissões isolam usuários comuns e preservam os acessos administrativos legítimos.
- Arquivos do Storage abrem no destino com as permissões esperadas.
- Login, recuperação de senha e redirects usam os endereços corretos.
- Funções, secrets e integrações apontam para serviços apropriados ao novo contexto.
- Jobs e webhooks foram revisados antes de produzir qualquer efeito externo.
- A aplicação usa a referência e as chaves do novo projeto, sem depender da origem.
Se você quer aproveitar a preparação para organizar os arquivos, veja também como limpar o Supabase Storage com backup e retenção. Limpeza e cópia são operações diferentes: preserve os arquivos necessários antes de excluir qualquer coisa.
Perguntas frequentes sobre copiar projetos Supabase
Posso copiar para outra conta Supabase?
O destino pode estar em outra organização ou conta à qual você tenha acesso autorizado. Você precisa das permissões e credenciais adequadas dos dois lados. Se a necessidade for apenas trocar a organização do mesmo projeto, confira primeiro a transferência nativa.
A cópia inclui os arquivos dos buckets?
Somente se esses arquivos foram incluídos no backup e restaurados com sucesso. O dump do banco não substitui o backup dos objetos do Storage. Confira o pacote de arquivos e teste downloads no destino.
Preciso excluir ou transferir o original?
Não. Este fluxo usa backup e um novo destino. Ele não exige excluir nem transferir a origem. Ainda assim, é essencial conferir as referências antes de restaurar: escolher o destino errado muda o risco da operação.
Serve para recuperar um projeto pausado?
A situação é diferente quando você só tem os arquivos disponibilizados pelo Supabase. Nesse caso, siga o guia de recuperação de um projeto Supabase pausado, que explica a preparação desses arquivos para um novo destino.
Como funciona o teste do Smoonb?
O teste dura cinco dias a partir da criação da primeira licença, sem cartão de crédito. Crie sua conta, configure o CLI e use um projeto de teste para conhecer o fluxo antes de trabalhar com uma base importante.