osFoundry / Platform
Funções serverless
Funções estilo Lambda por app — cold start em 40ms, sem provisionamento, cobrança por milissegundo.
O que é
As funções serverless do osFoundry são handlers de backend no estilo Lambda que pertencem a um único app. Ao construir um app no workspace, você pode anexar funções que rodam lógica no lado do servidor: tratar o envio de um formulário, chamar uma API externa com uma chave armazenada, transformar dados antes de chegarem ao cliente, tudo sem subir nem administrar servidor algum por conta própria. Não há nada para provisionar: você escreve o handler, publica o app e o backend da função sobe junto. O cold start fica em torno de 40 ms, então a primeira requisição depois de um período ocioso se comporta quase como uma requisição quente, e a cobrança é por milissegundo de execução, e não por capacidade reservada, o que significa que uma função ociosa não custa nada.\n\nDentro do osFoundry, as funções são provisionadas por instalação de app, e não como um único pool compartilhado, de modo que cada app ganha seu próprio ambiente de execução isolado, restrito aos dados e segredos daquele app. Como cada app também já vem com um schema de Postgres por instância (CRUD, um armazenamento de documentos JSONB, chave-valor e pgvector), uma função pode ler e escrever o estado do seu app diretamente, em vez de atravessar uma fronteira de rede até um serviço de banco de dados separado. Assim, o frontend do app, sua lógica de backend e seus dados ficam como uma única unidade implantável dentro do mesmo workspace em que você roda chat, agentes, código e conhecimento.\n\nIsso importa porque, num app pequeno, a maioria dos momentos de \"adicionar um backend\" é justamente a parte cara: escolher um host, ligar um runtime, manter algo aquecido e pagar por isso, chegando tráfego ou não. As funções serverless por app resumem tudo isso à publicação do app. Você mantém a postura BYOK do osFoundry (suas próprias chaves de API, sem sobretaxa de revenda nos modelos que suas funções chamam) e paga apenas pela computação que a função realmente usa, medida ao milissegundo.
Principais recursos
- Cold start de cerca de 40 ms: as requisições alcançam latência quase quente sem que você precise pré-aquecer ou manter instâncias vivas
- Sem provisionamento: você escreve a função contra o seu app, publica e o osFoundry sobe o backend na implantação
- Cobrança por milissegundo de execução real, com custo zero quando a função fica ociosa
- Um ambiente de função isolado por app, restrito aos dados e segredos daquele app em vez de um pool compartilhado
- Combina com o schema de Postgres por instância que cada app já traz, então a função lê e escreve o estado diretamente
Casos de uso
- Criador de apps: adiciona um handler de envio de formulário e uma limpeza de dados agendada a um room app sem subir nenhum backend à parte
- Desenvolvedor solo: chama uma API de terceiros a partir de uma função usando uma chave armazenada, de modo que o segredo nunca vai para o bundle do cliente
- Time focado em dados: roda uma função que lê e escreve o schema de Postgres do app para agregar registros antes de devolvê-los à UI
Perguntas frequentes
Qual é a latência de cold start de uma função serverless do osFoundry?
O cold start fica em torno de 40 ms, então a primeira requisição a uma função ociosa responde com latência próxima à do caminho quente. Você não precisa pré-aquecer funções nem manter um número mínimo de instâncias rodando para chegar a esse número.
Como sou cobrado pelas funções serverless?
A cobrança é por milissegundo de tempo de execução real. Não há taxa mensal fixa por função nem cobrança enquanto ela fica ociosa: você paga só pela computação que uma requisição consome. As chamadas de modelo que uma função fizer continuam rodando com suas próprias chaves BYOK, então não há sobretaxa de revenda desse lado.
Preciso provisionar ou administrar um servidor?
Não. Não há nada para provisionar, escalar ou manter vivo. Você escreve a função contra o seu app e publica o app; o osFoundry sobe o backend isolado por app para você. Cada app ganha seu próprio ambiente de função restrito aos dados e segredos daquele app, e pode ler e escrever diretamente o schema de Postgres que já vem com o app.