> For the complete documentation index, see [llms.txt](https://docs.adapta.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.adapta.org/skip/comece-aqui/dominando-o-skip-cloud-banco-de-dados-e-autenticacao.md). # Dominando o Skip Cloud: Banco de Dados e Autenticação {% embed url="" %} O **Skip Cloud** é o backend gerenciado que vem junto com a plataforma Skip — **sem necessidade de criar conta em outro serviço**. Ele cuida de banco de dados, autenticação, APIs customizadas, eventos automáticos, uploads de arquivo, realtime, busca semântica e tarefas agendadas para o seu projeto. **Foco principal: ferramentas internas e apps de uso corporativo.** O Skip Cloud foi desenhado pensando nos casos mais comuns construídos no Skip — CRMs, ERPs leves, sistemas de gestão, dashboards, intranets, portais de cliente, ferramentas de operação, automações de processo. Para esse perfil, ele é mais que suficiente. Para apps públicos de altíssimo volume (redes sociais, marketplaces, plataformas de mídia), avalie o comparativo com Supabase mais abaixo. ### Como ativar 1. No editor do Skip, clique no ícone do **Skip Cloud** na barra superior. 2. Confirme a ativação. O backend do projeto é provisionado automaticamente no primeiro build após a ativação — você não precisa se cadastrar em nenhum outro lugar. 3. Pronto: peça ao Skip para criar tabelas, autenticação ou APIs no próximo prompt. {% hint style="info" %} **Primeiro prompt depois de ativar:** "O Skip Cloud foi integrado. Crie autenticação por e-mail/senha e as tabelas necessárias. Substitua os dados mockados por dados reais." {% endhint %} {% hint style="warning" %} **Skip Cloud e Supabase são exclusivos por projeto.** Cada projeto Skip usa um backend nativo: ou Skip Cloud, ou Supabase — nunca os dois ao mesmo tempo. Quando você ativa o Skip Cloud, a opção de Supabase fica desabilitada na barra de ferramentas (tooltip "Desative o Skip Cloud para usar") e vice-versa. Se quiser trocar de backend num projeto que já tem dados, será preciso migrar manualmente — não há ferramenta automática hoje. Por isso, a escolha vale a pena ser feita cedo. {% endhint %} ### O que está incluído | Recurso | Disponível? | Como funciona | | ------------------------------ | :---------: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Banco de dados | ✅ | Banco SQLite dedicado por projeto, com migrations gerenciadas pelo Skip. | | Autenticação | ✅ | Email/senha nativo, com regras de acesso (RLS) por collection. | | APIs customizadas (backend) | ✅ | Endpoints HTTP escritos em JavaScript, expostos em `/backend/v1/...`. | | Eventos automáticos no banco | ✅ | Rode código no servidor automaticamente quando um registro é criado, atualizado, validado ou deletado (ex: enviar email no cadastro, validar regra de negócio antes de salvar). | | Upload de arquivos (Storage) | ✅ | Campos do tipo `file` em qualquer tabela, com tipo MIME e tamanho máximo configuráveis. | | Realtime | ✅ | Atualizações ao vivo da UI quando registros mudam (Server-Sent Events). | | Tarefas agendadas (Cron) | ✅ | Crons em JavaScript com expressão cron (`0 3 * * *`, etc.). | | Busca semântica / vetores | ✅ | Campos `vector` para KNN. Veja Busca Semântica e RAG. | | Domínio customizado no backend | ❌ | Apenas a app pública suporta domínio próprio. A URL do backend é gerada pela Skip e aparece no painel do projeto. | | Edge Functions independentes | ❌ | Toda lógica de servidor roda dentro do próprio backend do projeto, não como serviço separado. | ### Capacidade — o Skip Cloud aguenta o meu app? Para o caso de uso típico do Skip — **ferramentas internas e apps corporativos** — sim, com folga. Pensa em CRMs, sistemas de gestão, dashboards executivos, portais de cliente, intranets, ferramentas de operação: esse perfil tipicamente envolve **dezenas a alguns milhares de usuários autenticados**, padrões de uso previsíveis e tráfego concentrado em horário comercial. O Skip Cloud foi dimensionado exatamente para isso. Cada projeto recebe um backend dedicado, isolado dos demais, com capacidades de referência: | Métrica | Capacidade típica | Observações | | -------------------- | -------------------------------------------- | -------------------------------------------------------------------------- | | Registros no banco | Dezenas a centenas de milhões | Bem acima do que ferramentas internas costumam acumular. | | Leituras/segundo | Centenas a alguns milhares | Indexes adequados (que o Skip cria por padrão) mantêm performance estável. | | Escritas/segundo | Centenas sustentadas | Suficiente para CRUD de formulário, lançamentos, registros de operação. | | Usuários simultâneos | Centenas a baixos milhares | Cobre o perfil de uma equipe inteira ou base de clientes B2B com folga. | | Conexões realtime | Centenas concorrentes | Dashboards e listas que atualizam ao vivo sem configuração extra. | | Storage de arquivos | Volumes generosos por projeto, S3-compatível | CDN ainda não disponível (no roadmap). | Esses são valores de referência baseados em testes da Skip e na arquitetura usada, **não compromissos contratuais**. Se você está planejando algo bem fora desse perfil (ex: app público de altíssimo tráfego), fale com o suporte antes de escalar. #### Quando o Skip Cloud não é a escolha certa Se o seu projeto se encaixa em pelo menos um destes padrões — geralmente apps públicos de grande escala ou requisitos enterprise específicos — vale começar direto em Supabase: * **Apps públicos de altíssimo tráfego** com centenas de escritas/segundo sustentadas (marketplaces de grande porte, redes sociais, telemetria IoT). * **Necessidade de PostgreSQL puro** (queries SQL complexas, extensões específicas, JOINs em grande escala). * **Tráfego de mídia intenso ao público externo** que se beneficia de CDN (enquanto a CDN não chega ao Skip Cloud). * **Domínio customizado obrigatório no backend** (webhooks que exigem `https://api.minhaempresa.com.br`). * **Compliance regional** que exige dados em região específica fora dos EUA. ### SLA e disponibilidade #### A garantia que o Skip Cloud oferece O backend do seu projeto estará disponível para processar requisições sempre que houver tráfego, **exceto nas janelas curtas e bem definidas** descritas neste documento — basicamente, durante uma atualização de backend disparada por uma mensagem sua no chat, ou no primeiro acesso depois de inatividade prolongada. Fora dessas janelas, o Skip Cloud monitora e recupera automaticamente qualquer degradação — você não precisa configurar health checks, restart ou failover. **O que conta como "atualização de backend"?** Quando você manda uma mensagem no chat do Skip e ele faz um build que cria/altera tabelas, regras de acesso, APIs customizadas, hooks ou crons, isso vai para o Skip Cloud e causa uma janela curta de indisponibilidade naquele momento. Mensagens que mexem só no front-end (mudar layout, cores, textos, componentes React) **não afetam** a disponibilidade do backend — o projeto segue respondendo normalmente. A Skip ainda **não publica um SLA contratual** (ex: "99,9% garantido com créditos em caso de descumprimento") para o Skip Cloud — esse é um item de roadmap. O que oferecemos operacionalmente hoje: * **Monitoramento contínuo** (24/7) com alertas para a equipe Skip em caso de degradação. * **Recuperação automática** quando algo dá errado, sem intervenção manual. * **Persistência durável** dos dados com backups operacionais (restauração via suporte). * **Tráfego HTTPS ponta-a-ponta** e isolamento por projeto. #### Como projetar a disponibilidade que você pode esperar Sendo honestos sobre o que você vai sentir como usuário: * **Janelas curtas de erro durante atualizações de backend** (tipicamente 0,5 a 2 segundos cada vez que um build seu altera tabelas, regras, APIs ou crons) são a fonte mais comum de "instabilidade percebida". Detalhes no FAQ abaixo. * Para projetos em **produção estabilizada** (poucos builds com alteração de backend por dia), a indisponibilidade efetiva no mês fica tipicamente abaixo de poucos minutos — comparável, na prática, a uma faixa de **99,9%**. * Apps em **desenvolvimento ativo** (muitos prompts/builds por dia mexendo no backend) verão mais janelas curtas de erro durante essas atualizações — isso é parte normal do ciclo de iteração e não representa uma falha de plataforma. Se o seu caso de uso exige **SLA formal escrito** (ex: contrato com cliente corporativo que cobra disponibilidade auditada), Skip Cloud ainda não atende — o caminho atual é Supabase no plano com SLA, ou conversar com a equipe Skip sobre opções enterprise. #### Mitigações que você mesmo pode aplicar Para reduzir o impacto das janelas curtas de erro: * **Evite mandar muitas mudanças de backend em horários de pico** do seu app — agrupe alterações em poucos builds quando puder. * **Implemente retry no front-end** para chamadas críticas (já é boa prática independente de plataforma). * Para tarefas críticas que precisam de execução garantida, **prefira disparar via cron externo** (GitHub Actions, EventBridge) batendo num endpoint `/backend/v1/...`, em vez de depender exclusivamente do cron interno. ### Skip Cloud x Supabase — qual escolher? Como cada projeto Skip usa **apenas um dos dois** (eles são exclusivos por projeto), vale entender a diferença antes de ativar. Os dois entregam um backend isolado por projeto — não é "single-tenant vs multi-tenant", e sim **quem opera, onde fica a conta, e qual a maturidade de cada feature**: | Eixo | Skip Cloud | Supabase | | ---------------------------- | --------------------------------------------------------------------------- | --------------------------------------------------------------- | | Conta separada? | Não. Já vem com o Skip. | Sim — você cria conta em supabase.com e autoriza o Skip. | | Quem opera a infra | A equipe Skip. | Você gerencia o projeto Supabase (billing, quotas, regiões). | | Onde os dados ficam | Servidores Skip na AWS (Norte da Virgínia, EUA). | Região que você escolheu ao criar o projeto Supabase. | | Banco | SQLite dedicado por projeto. | PostgreSQL dedicado por projeto. | | Autenticação | Email/senha + OAuth básico. | Email, vários OAuth providers, SAML, MFA, anônima. | | Storage de arquivos | S3-compatível; CDN no roadmap. | S3-compatível, com CDN e transformações de imagem. | | Realtime | Sim (SSE nativo). | Sim (mais maduro, baseado em PostgreSQL). | | APIs customizadas | Endpoints em JavaScript dentro do próprio projeto. | Edge Functions Deno deployadas separadamente. | | Eventos automáticos no banco | Sim — código JS reage a create/update/delete (antes ou depois da operação). | Sim — via triggers SQL ou webhooks que disparam Edge Functions. | | Domínio próprio no backend | Não. | Sim. | | Provisionamento | Automático no primeiro build. | Manual (criar projeto Supabase, conectar). | | SLA formal | Não publicado. | Sim, em planos pagos do Supabase. | #### Escolha Skip Cloud se: * Você está construindo uma **ferramenta interna ou app corporativo** (CRM, ERP leve, sistema de gestão, dashboard, portal, intranet, automação de processo) — o sweet spot do Skip Cloud. * Você quer começar **sem se cadastrar em outro serviço**. * A capacidade descrita acima na seção **Capacidade** atende seu projeto (caso da grande maioria dos projetos Skip). * Você **não precisa** de domínio próprio no backend, CDN para mídia ou OAuth com vários provedores. #### Escolha Supabase se: * Você está construindo um **app público de larga escala** (marketplace, rede social, plataforma de mídia) com tráfego que justifica CDN e Postgres dedicado. * Você precisa de **PostgreSQL** (relacional puro com JOINs complexos, extensões, queries SQL). * Você precisa de **OAuth com vários providers, MFA, SAML, ou domínio customizado no backend**. * Seu app exige **SLA contratual escrito**. * Você quer **Edge Functions com event loop completo**. * Você precisa que os dados fiquem em uma **região específica fora dos EUA** (ex: São Paulo para LGPD com dados sensíveis). ### FAQ #### Há SLA / taxa de disponibilidade garantida? Não há SLA contratual publicado hoje. A operação é monitorada 24/7 e, na prática, projetos em produção estabilizada (poucos builds com alteração de backend por dia) costumam ficar em uma faixa comparável a **99,9% de uptime** — ver seção **SLA e disponibilidade** acima para os detalhes do raciocínio. #### Onde os dados são armazenados? * **Região:** AWS, Norte da Virgínia (EUA) — `us-east-1`. * **Operação:** infraestrutura própria da Skip, com criptografia em disco. * **Isolamento:** cada projeto tem seu próprio banco e diretório de dados, sem mistura entre projetos. * **Backups:** backups operacionais com restauração via suporte (não há exportação self-service no painel ainda). Se você precisa que os dados fiquem em uma região específica (ex: Brasil para LGPD com dados sensíveis), a opção atual é **Supabase com região São Paulo**. #### Posso usar Skip Cloud e Supabase no mesmo projeto? **Não.** A integração nativa é exclusiva: cada projeto Skip usa um dos dois. Se você ativar o Skip Cloud, a opção de Supabase fica desabilitada na barra superior, e vice-versa. A razão é evitar duplicação de schema, autenticação dividida e ambiguidade no agente sobre qual backend usar para cada tabela. Se quiser trocar depois, será preciso **migrar dados manualmente** — por isso recomendamos escolher cedo. #### Quando o Skip Cloud fica indisponível? Quanto tempo dura? **Curto, mas real.** A indisponibilidade do backend é disparada por builds que mexem no backend (tabelas, regras de acesso, APIs customizadas, hooks, crons). Cada vez que você manda uma mensagem no chat e o Skip aplica uma alteração dessas, o backend do seu projeto passa por uma janela curta de atualização: | Tipo de alteração no build | Duração típica | Limite | | -------------------------------------------------- | ----------------- | ------- | | Apenas mudanças no banco (tabelas, campos, regras) | 0,5 – 1 segundo | 15s | | 1 API/hook sem dependências externas | 0,3 – 0,7 segundo | 15s | | 1 API/hook com pacotes npm | 1 – 3 segundos | 15s | | Mudanças no banco + N APIs/hooks no mesmo build | \~1s + N × \~0,7s | N × 15s | Builds que **só mexem no front-end** (componentes, layout, textos, estilos) não causam essa janela — o backend continua respondendo normalmente. Durante a janela, requisições em voo podem retornar erro de conexão. Para apps com alto tráfego, **prefira agrupar várias mudanças num build único** em vez de pedir em mensagens separadas. #### O que acontece com tarefas agendadas (cron) durante uma atualização de backend? Os crons ficam registrados dentro do próprio projeto. Quando o backend passa pela janela curta de atualização, o agendamento é recriado automaticamente assim que ele volta. * **Não há catch-up:** se o horário de um cron passou exatamente durante essa janela, ele não é re-executado. * Se um cron estava executando no momento da atualização, ele é interrompido sem retry automático. * Para tarefas críticas que precisam de garantia "exactly-once", recomendamos disparar a partir de um cron externo (ex: GitHub Actions) batendo num endpoint `/backend/v1/...` da sua app. #### Tem limite de quantos projetos eu posso criar no Skip Cloud? Não há limite por usuário no painel. A capacidade da plataforma é monitorada continuamente pela equipe e expandida conforme necessário, então você pode criar projetos à vontade. #### Posso conectar meu próprio domínio ao backend? **Não para o Skip Cloud.** O backend é sempre acessado pela URL gerada pela Skip e exibida no painel do projeto. O domínio customizado que o plano Premium oferece se aplica à **app pública** (a interface que seus usuários acessam), não ao endpoint do banco/API. Se você precisa de domínio próprio para chamadas de API (ex: webhooks que exigem `https://api.minhaempresa.com.br`), use **Supabase** ou implemente um proxy próprio. #### Tem como eu acessar o banco diretamente, fora do Skip? **Sim.** O Skip Cloud expõe uma API REST acessível pela URL do seu projeto (mostrada no painel do Skip Cloud dentro do editor, junto com o token de superusuário). Com isso você consegue: * Listar, criar e atualizar registros via HTTP. * Autenticar como usuário ou superusuário e receber um token JWT. * Consumir realtime via Server-Sent Events. #### Posso exportar meus dados? * **Pelo painel:** ainda não há botão "Exportar tudo". Você consegue listar registros via API e exportar manualmente. * **Por API:** use a API REST do Skip Cloud para baixar tabelas em JSON. * **Migração para Supabase:** ainda não temos ferramenta automatizada. O caminho atual é exportar via API e re-importar via SQL no Supabase. #### Posso criar APIs customizadas (endpoints HTTP) no Skip Cloud? **Sim.** Peça ao Skip: > Crie um endpoint `POST /backend/v1/checkout` que recebe um carrinho e chama a API do Stripe. **Limitações importantes:** * O endpoint deve começar com **`/backend/v1/`** — o prefixo `/api/` é reservado para uso interno. * **Um endpoint por arquivo:** se você precisa de 3 endpoints relacionados, o Skip cria 3 arquivos. * A linguagem é **JavaScript** executado num runtime restrito: sem `setTimeout(fn, ms>0)`, sem `setInterval`, sem pacotes nativos (`bcrypt`, `sharp`). Bibliotecas pure-JS funcionam normalmente até **5 MiB de bundle**. * O `fetch` interno tem **timeout de 30 segundos**. #### Posso reagir automaticamente quando dados mudam? (eventos / hooks) **Sim — esse é um dos recursos mais usados do Skip Cloud.** Você pode pedir ao Skip para criar um evento (ou "hook") que executa código no servidor automaticamente toda vez que um registro é criado, atualizado, validado ou deletado em uma tabela. **Casos de uso comuns:** * Enviar e-mail de boas-vindas quando alguém se cadastra. * Validar uma regra de negócio antes de salvar (ex: "estoque não pode ficar negativo"). * Notificar um webhook externo após um pedido ser confirmado. * Calcular um campo derivado automaticamente (ex: `total = quantidade × preço`). * Manter contadores em outra tabela em sincronia. **Você pode escolher quando o código roda:** * **Antes da operação** — para validar ou modificar os dados que vão ser salvos. * **Após sucesso** — para disparar e-mails, chamar APIs externas, atualizar caches. * **Em chamadas HTTP específicas** — para interceptar e modificar a resposta da API antes de chegar ao cliente. > Quando um pedido for criado e o pagamento confirmado, envie um e-mail para o cliente com o resumo da compra e notifique nosso webhook do Slack. Limitações são as mesmas das APIs customizadas (sem `setTimeout > 0`, sem `setInterval`, sem pacotes nativos, bundle até 5 MiB, timeout de fetch de 30s). Como cada evento roda dentro do seu projeto, ele compartilha capacidade com as outras requisições — eventos muito pesados podem aumentar a latência geral. #### Posso fazer upload de arquivos (imagens, PDFs)? **Sim.** Crie uma tabela com um campo do tipo `file` e o Skip já suporta upload, validação de MIME e tamanho. Detalhes: * O storage é **S3-compatível** sob o capô. CDN para entrega acelerada está no roadmap; hoje os arquivos são servidos direto pelo backend do projeto. * O tamanho máximo é configurado por campo (ex: 5 MiB para avatares, 25 MiB para PDFs). * Os arquivos são acessados via URL `/api/files///`. * Para a grande maioria das ferramentas internas (anexos em CRMs, comprovantes em sistemas de gestão, fotos de produto em catálogos), o storage do Skip Cloud atende com folga. Para apps públicos com tráfego de mídia muito alto (rede social com fotos, plataforma de vídeo), enquanto a CDN não chega no Skip Cloud, vale avaliar Supabase. #### Realtime funciona? **Sim, via Server-Sent Events (SSE).** O Skip já cria um hook React `useRealtime` que mantém a UI sincronizada quando registros mudam — em outras abas, por outros usuários, ou por hooks de servidor. Peça: > Mantenha a lista de mensagens em tempo real. #### Como é a segurança / privacidade? * **Isolamento por projeto:** cada projeto tem dados, autenticação e segredos próprios — projetos diferentes nunca enxergam dados uns dos outros. * **Segredos** (API keys, tokens) são guardados separadamente do código e só são acessíveis pelo próprio projeto. * **Autenticação obrigatória** em todas as chamadas (Bearer token de usuário ou superusuário). * **HTTPS ponta-a-ponta** em todo o tráfego. * Para dados sensíveis sob LGPD/HIPAA, recomendamos avaliação caso-a-caso com o suporte. #### O que acontece se eu não usar o projeto por muito tempo? Após alguns minutos sem requisições, o backend do seu projeto pode entrar em modo **idle** para economizar recursos. Quando uma nova requisição chega, ele é acordado automaticamente em \~1–3 segundos no primeiro hit. Os dados nunca são apagados por inatividade — o despertar é transparente e não exige nenhuma ação sua. ### Limitações conhecidas (resumo) {% hint style="warning" %} **Sem SLA contratual publicado hoje** (disponibilidade na prática comparável a uma faixa de \~99,9% para projetos em produção estabilizada). {% endhint %} {% hint style="warning" %} **Janela curta de indisponibilidade** quando um build mexe no backend (\~0,5 – 2s típico, até 15s no pior caso). Builds que só alteram o front-end não causam. {% endhint %} {% hint style="warning" %} **Exclusivo com Supabase:** um backend nativo por projeto. {% endhint %} {% hint style="warning" %} **Domínio customizado** não disponível para o backend (só para a app pública). {% endhint %} {% hint style="warning" %} **Storage S3-compatível sem CDN ainda** (no roadmap) — para tráfego de mídia altíssimo a usuários externos, hoje considere Supabase. {% endhint %} {% hint style="warning" %} **Crons sem catch-up** e sem garantia exactly-once. {% endhint %} {% hint style="warning" %} **Sem export/restore self-service** pelo painel; restauração via suporte. {% endhint %} {% hint style="warning" %} **Backend em JavaScript com limitações** (sem `setTimeout > 0`, sem packages nativos, sem event loop). {% endhint %}