Skip Cloud
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
- No editor do Skip, clique no ícone do Skip Cloud na barra superior.
- 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.
- Pronto: peça ao Skip para criar tabelas, autenticação ou APIs no próximo prompt.
:::tip 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."
:::
:::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, conforme as necessidades do projeto. (Ver seção Skip Cloud x Supabase — qual escolher? abaixo.)
:::
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/checkoutque 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), semsetInterval, sem pacotes nativos (bcrypt, sharp). Bibliotecas pure-JS funcionam normalmente até 5 MiB de bundle. - O
fetchinterno 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.
Exemplo de prompt:
"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/<collection>/<recordId>/<filename>. - 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)
- ⚠️ Sem SLA contratual publicado hoje (disponibilidade na prática comparável a uma faixa de ~99,9% para projetos em produção estabilizada).
- ⚠️ 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.
- ⚠️ Exclusivo com Supabase: um backend nativo por projeto.
- ⚠️ Domínio customizado não disponível para o backend (só para a app pública).
- ⚠️ Storage S3-compatível sem CDN ainda (no roadmap) — para tráfego de mídia altíssimo a usuários externos, hoje considere Supabase.
- ⚠️ Crons sem catch-up e sem garantia exactly-once.
- ⚠️ Sem export/restore self-service pelo painel; restauração via suporte.
- ⚠️ Backend em JavaScript com limitações (sem
setTimeout > 0, sem packages nativos, sem event loop).
Ainda com dúvidas?
- Aulas em Vídeo: Trilha de capacitação.
- Bug Scanner: botão dentro do editor, ao lado do ícone de celular.
- Grupo de Suporte: WhatsApp.
- Email: support@usecurling.com