> 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 %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.adapta.org/skip/comece-aqui/dominando-o-skip-cloud-banco-de-dados-e-autenticacao.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.