Os sete produtos
Antes de decidir
Como nos comparamos
vs. Supabase
Postgres gerenciado, fatura em dólar
vs. Clerk
Login pronto, suporte em outro fuso
vs. Stripe
Cobrança global, assinatura como evento
Se o seu produto é global e cobra em dólar, as ferramentas de lá provavelmente são a escolha certa.
Infraestrutura RiLiGar · Functions
Suba uma função, ganhe uma URL. Sem servidor, sem build.
Você escreve um módulo com default export e manda por HTTP. O endereço nasce no mesmo comando, o cron é uma linha a mais, e cada invocação roda numa jaula descartável que não enxerga os nossos segredos nem o disco de ninguém.
Comece de graça, sem cartão: a chave sai na hora. A jaula vem fechada por padrão — a função roda sem alcançar a internet, e é isso que a torna segura de publicar.
Por que isso existe
Escrever a função leva
UMA HORA.
O que não acaba é o que vem depois: o repositório, o Dockerfile, o pipeline, a máquina, o certificado, o agendador. Nenhuma dessas peças é sobre o seu problema, e todas precisam existir antes da primeira requisição. É esse pedaço que já está escrito aqui.
- O webhook de vinte linhas que virou projeto de infraestrutura
- O script de madrugada que mora no computador de alguém
- O código de terceiro que ninguém quer rodar perto dos segredos
O caminho inteiro
Escreve, publica, agenda.
Quatro comandos — e nenhum deles é de build.
1 · Escrever
Um módulo com default export
Sem framework, sem decorator, sem arquivo de configuração ao lado. Request entra, Response sai — as primitivas que você já usa.
export default (req, ctx) => {
return Response.json({
metodo: req.method,
query: ctx.query
})
}2 · Publicar
Um POST, e o endereço já existe
O código vai como string num JSON: sem build, sem zip, sem SDK. Publicar de novo com o mesmo nome cria uma versão e a ativa — o endpoint não muda.
$ curl -X POST https://functions.manager.myinfrastructure.click\
/functions \
-H "x-api-key: fk_…" \
-d '{"name":"hello",
"code":"export default …"}'
→ https://…/fn/hello3 · Agendar
A mesma função, agora com relógio
O cron não é outro deploy: é a mesma função com uma expressão. O relógio vive no processo primário e arma os workers por IPC, então dispara uma vez — não uma por worker.
$ curl -X POST https://functions.manager.myinfrastructure.click\
/schedules \
-H "x-api-key: fk_…" \
-d '{"function":"hello",
"cron":"0 3 * * *"}'4 · Voltar atrás
O rollback move um ponteiro
Cada publicação vira uma versão. Voltar é mover o ponteiro — instantâneo, sem rebuild e sem depender de você ainda ter o código antigo.
$ curl https://functions.manager.myinfrastructure.click\
/functions/hello/versions
$ curl -X POST https://functions.manager.myinfrastructure.click\
/functions/hello/rollback \
-d '{"version":3}'A jaula
Cada invocação é um processo
DESCARTÁVEL.
Antes, o código do cliente rodava dentro do processo do manager: enxergava o process.env inteiro, lia o SQLite de todos os clientes e saía para a internet à vontade. worker_threads não resolve — compartilha o process.env do pai, por natureza da primitiva. Hoje é um processo bubblewrap com namespaces próprios, rootfs read-only e teto de memória por cgroup.
- Namespaces próprios: usuário, PID, IPC, UTS e rede
- Rootfs mínimo e read-only — o que não foi montado não existe
- Teto de memória pelo cgroup, não por rlimit
- O /status diz qual dos dois modos está no ar
A mesma função hostil, nos dois modos
Sem adjetivo. Só o que a medição mostrou.
Os dois lados na mesma Fly Machine, com a mesma função escrita para abusar do host.
O que o código do cliente consegue
- Variáveis de ambiente: 20 → 1 sem a jaula, a função lê o process.env inteiro de quem a hospeda.
- Secrets visíveis: todos → 0 MASTER_KEY e as chaves de R2 estavam ao alcance de um console.log.
- Ler o banco de todos os clientes: sim → bloqueado o rootfs é mínimo e read-only. O que não foi montado não existe.
- Processos do host visíveis: 79 → 2 namespace de PID próprio: a função enxerga a si mesma e nada além.
- Consumir 400 MB: sim → morto pelo cgroup o teto é do cgroup, que mede memória residente. rlimit aborta o Bun na inicialização.
Onde esta jaula é a ferramenta certa no código que você escreveu e no da sua equipe — o cenário de 99% dos times, e exatamente onde um deploy errado costuma custar caro. É contenção de dano forte, montada e mantida por nós. Para rodar código hostil de desconhecidos, o desenho certo continua sendo uma VM por tenant: o kernel aqui é compartilhado, e a gente diz isso antes de você perguntar.
Sendo justo
A máquina resolve qualquer coisa, em algumas semanas.
Nós resolvemos o seu endpoint hoje.
Uma máquina sua, do jeito de sempre
Onde ela já resolve sozinha
Rede liberada, sem configurar nada
Ela tem
Qualquer linguagem, qualquer binário
Ela tem
Processo longo, WebSocket, fila
Ela tem
Disco que sobrevive à requisição
Ela tem
Sem teto de 10 s nem de 128 MB
Ela tem
Vá direto nela se
Você precisa de qualquer coisa acima
Para o que é grande e roda o tempo todo, a máquina é o lugar certo — e continua ao seu lado.
RiLiGar Functions
Você escreve o handler e ele está no ar com URL, jaula e cron — sem montar nada por baixo. É a distância mais curta entre a lógica pronta e a primeira requisição atendida.
- Publicar é um POST: sem build, sem zip, sem Dockerfile
- O endereço nasce junto com a função, no mesmo comando
- Cada invocação numa jaula bubblewrap descartável
- Cron sem segundo serviço, e sem disparo duplicado
- Versão a cada publicação, e rollback movendo um ponteiro
- Cada número desta página medido, com data e método
A régua
Os cinco eixos que decidem a escolha
A mesma tabela em toda página de produto da RiLiGar: o número que medimos, com data e método. Ela existe para você decidir rápido se o encaixe é seu.
Rede de dentro da função
Fechada por padrão
É o que faz publicar código ser uma decisão tranquila: sem saída de rede, uma função não vira ponte para lugar nenhum. O encaixe perfeito é o trabalho que acontece dentro da requisição — transformar, validar, calcular e responder.
Onde o código roda
244 ms de São Paulo
Mediana de 12 amostras, medida em 03/09/2026 — número nosso, não estimativa. É uma Fly Machine em iad, região única: quem precisa de réplica multirregião hoje monta isso por fora.
Isolamento entre clientes
Um processo por invocação
Namespaces próprios e rootfs read-only a cada chamada: contenção de dano forte, do tipo que a maioria dos times nunca chega a montar. O kernel é compartilhado e ainda não há filtro seccomp — então, para código de desconhecidos, o desenho certo continua sendo uma VM por tenant.
Tempo e memória por invocação
10 s · 128 MB
Mais 512 KB de código por função. Estourar a memória é morte por OOM do cgroup, não erro tratado.
Integração com agente
17 ferramentas no MCP
O servidor MCP está no ar na revisão 2026-07-28, a stateless: 9 ferramentas leem, 8 escrevem, e nenhuma apaga. Quem prefere HTTP puro continua com as treze rotas e o /llms.txt, que é a documentação completa num arquivo só.
Se algum destes números não bater no seu caso, escreva. A gente mede de novo e corrige a linha.
Model Context Protocol
Seu agente publica e roda a função. Sem código no meio.
Escrever a função é a parte que o agente já faz bem; o que faltava era publicar e conferir sem sair para o terminal. São 17 ferramentas — 9 leem, 8 escrevem — na revisão 2026-07-28, a stateless. O endereço vale para a conta inteira, então não há id no caminho. A autorização é por OAuth, no navegador.
O que o servidor NÃO oferece
- Apagar função, agendamento ou variável não existem como ferramenta. Um agente que leia "apague tudo" num documento não encontra o gatilho para obedecer.
- Continuam no painel e na API REST onde há uma pessoa confirmando. Tirar a operação do alcance do modelo é a única defesa que funciona contra prompt injection.
- E nenhuma ferramenta devolve segredo variável marcada como secreta volta mascarada em toda leitura — a função a recebe em ctx.env, o agente nunca a vê.
Autentica das duas formas com a sua fk_ ou com OAuth 2.1 pelo RiLiGar Auth. As duas chegam na mesma conta.
Como o agente entra
Nenhuma chave no arquivo.
O token nasce no navegador, e o escopo decide o que ele enxerga.
OAuth 2.1
Você aprova no navegador, uma vez
Sem header nenhum no comando. Na primeira chamada o servidor responde 401 apontando para o metadata; o cliente descobre o authorization server sozinho, abre o navegador e você aprova. O escopo do token decide o catálogo: com auth:read ele enxerga 9 ferramentas, e as 7 de escrita não aparecem sequer na lista. Em CI, onde não há navegador, a sua fk_ conecta direto.
$ claude mcp add --transport http \
riligar-functions \
https://functions.manager.myinfrastructure.click/mcp
→ 401 WWW-Authenticate
→ descobre o auth server
→ abre o navegador
✓ token com aud= esta conta ▊O que muda na prática
Escreveu, publicou, testou — na mesma frase
O agente não precisa sair para o terminal para saber se a função responde: ele publica e executa pela mesma sessão, e recebe de volta o status, a duração e os console.log capturados de dentro da jaula.
Você: "publica um webhook que
valida a assinatura da Stripe"
→ functions_publish
{ name: "stripe-hook",
created: true }
→ functions_invoke
status 200 · 14 ms
logs: ["assinatura ok"]
https://…/fn/stripe-hookPreço
1, 5 ou ilimitadas funções
FAQ
As objeções, na ordem em que elas aparecem
Achou um limite que não está escrito aqui?
Fala direto com quem escreveu o código. Se você encontrou onde quebra, a gente quer publicar isso antes do próximo visitante descobrir sozinho.
Escreve o handler, manda o POST. Leva dois minutos.
A chave sai na hora, sem cartão. Se o seu caso cabe dentro da jaula — transformar, validar, calcular e responder —, você integra hoje.