- OpenWorkers é um runtime open source que executa JavaScript com base em V8, permitindo implementar computação de borda em infraestrutura própria
- Suporta armazenamento KV, PostgreSQL, armazenamento compatível com S3/R2, service bindings, variáveis de ambiente e segredos
- Mantém alta compatibilidade com Cloudflare Workers, incluindo principais Web APIs como fetch, ReadableStream e crypto.subtle
- Permite self-hosting simples com sandbox V8 Isolate, agendamento cron e deploy baseado em Docker Compose
- É um projeto desenvolvido ao longo de cerca de 7 anos, com o objetivo de ser um ambiente de execução JavaScript sem dependência de fornecedor
Visão geral do OpenWorkers
- OpenWorkers é um runtime compatível com Cloudflare Workers escrito em Rust, que executa JavaScript usando V8 Isolate
- Permite aproveitar as vantagens da computação de borda também em ambientes de servidor próprios
- É disponibilizado como open source, podendo ser distribuído e modificado livremente
Principais recursos
- Integração com diversos recursos externos por meio do recurso de bindings
- Armazenamento KV: suporte a get, put, delete e list
- Integração com banco de dados PostgreSQL
- Suporte a armazenamento compatível com S3/R2
- Inclui service bindings, variáveis de ambiente e gerenciamento de segredos
- Suporte a Web APIs
- Fornece APIs padrão como fetch, Request, Response e ReadableStream
- Inclui crypto.subtle, TextEncoder/Decoder, Blob, setTimeout e AbortController
Arquitetura
- O sistema é composto por proxy nginx, dashboard, API, serviço de logs, runner, PostgreSQL, NATS e scheduler, entre outros
- Cada runner executa código dentro de um V8 Isolate, com limites de CPU de 100 ms e memória de 128 MB
- Inclui scheduler embutido com suporte à sintaxe cron de 5 a 6 campos
- Mantém compatibilidade de sintaxe com Cloudflare Workers
Self-hosting
- O deploy pode ser feito apenas com um único banco de dados PostgreSQL e um arquivo Docker Compose
- Pode ser executado facilmente com os comandos
git clone, configuração de .env e docker compose up
- Inclui o processo de migração e geração de token
Contexto de desenvolvimento
- Projeto concluído após cerca de 7 anos de desenvolvimento
- No início, experimentou sandboxing de JS com vm2 e depois evoluiu inspirado no modelo do Cloudflare Workers
- Passou por Deno-core e atualmente foi reescrito com base em rusty_v8
- O objetivo é oferecer uma experiência de desenvolvimento (DX) no nível do Cloudflare Workers enquanto constrói um ambiente de execução em servidor próprio sem dependência de fornecedor
- No futuro, está prevista a adição de debug determinístico (deterministic debugging) por meio de registro e reprodução de execução
1 comentários
Comentários no Hacker News
O conceito de trazer o poder da edge computing para a própria infraestrutura é interessante
Mas tenho a sensação de que self-hosting entra um pouco em conflito com a essência da edge computing
É um modelo viável porque grandes vendors como a Cloudflare têm mais de 300 PoPs (Points of Presence) espalhados pelo mundo
Claro, dá para montar uma estrutura parecida combinando vendors menores e mais éticos, mas isso traz muito mais esforço e risco
Talvez uns 10 nas regiões principais já não sejam suficientes?
Ao mesmo tempo, preocupa se isso não seria difícil demais de coordenar de forma segura e confiável
O problema das soluções de sandbox é que elas precisam dar uma garantia forte de que o código não consegue escapar da sandbox
Para provar isso, são necessários resultados de testes contra vários cenários de ataque e documentação detalhada
Mas documentação nesse nível é muito rara, e é difícil encontrar exemplos realmente confiáveis
Por isso, eu costumo verificar se há casos de uso em produção em grandes empresas, com equipes de segurança fazendo a manutenção
Em alguns casos, eles até aplicam releases do V8 antes do próprio Chrome
Cada worker roda como um isolate, e não como um processo separado, de forma semelhante ao modelo da Cloudflare
Mas, ao lidar com código de terceiros totalmente não confiável, é melhor adicionar mais uma camada de isolamento com containers ou VMs
Esse sandboxing é mais focado em isolamento de recursos do que em segurança
Uma auditoria de segurança no nível de “nós verificamos e é seguro, pode confiar” não é suficiente
mas em um ambiente self-hosted já existe acesso ao sistema, então há menos motivo para se preocupar com escape da sandbox
Acho que é um projeto excelente
Se o workerd é open source, fico curioso se o diferencial do OpenWorkers é oferecer um ambiente completo
Também queria entender as diferenças no runtime em si e se há planos para um serviço gerenciado no futuro
1️⃣ o workerd oferece apenas o runtime, enquanto o OpenWorkers é uma plataforma completa com dashboard, API, scheduler, logs e bindings (KV, S3/R2, Postgres)
2️⃣ o workerd é baseado em C++, enquanto o OpenWorkers usa Rust + rusty_v8, sendo mais simples e mais fácil de hackear
3️⃣ já existe uma versão gerenciada em dash.openworkers.com, com tier gratuito
mas o self-hosting foi projetado como cidadão de primeira classe
O ponto central do Cloudflare Workers é a cobrança por função, mas, se for self-hosted, no fim é preciso garantir o hardware antecipadamente
Nem tudo precisa ser terceirizado, e é bom existirem opções parecidas
Isso ajuda a reduzir a barreira de adoção
No passado trabalhei bastante separando o deno_core, então entendo a mudança para raw rusty_v8
O deno_core tem bastante código legado, e os testes quebravam com frequência quando algo era alterado
Mas migramos para rusty_v8 para ter um controle mais refinado sobre o runtime,
e depois pretendemos readicionar os recursos que estão faltando também ao runtime do deno
Se é um projeto que ajuda a reduzir lock-in de vendor, eu apoio sem pensar duas vezes
Espero que os serviços de nuvem sejam pressionados a praticar preços mais realistas
Hoje cobram caro demais até por recursos básicos como NAT
Claro, a nuvem é conveniente, mas o problema é o custo alto em comparação com fazer você mesmo
Se as grandes empresas monopolizarem os recursos, pode ficar complicado para pessoas físicas hospedarem por conta própria
Mas, na prática, em muitos países o custo de operar por conta própria é ainda maior
Não é só instalar e pronto; o custo com manutenção e monitoramento é significativo
Seria bom documentar quais recursos ainda não funcionam e o roadmap
A próxima prioridade é um recurso de gravação/reprodução de execução para depuração, e vamos adicionar uma seção de roadmap na documentação
O diagrama de arquitetura em ASCII aparece quebrado no Pixel + Firefox
Diagramas baseados em texto têm seu charme, mas, na prática, é mais útil publicar uma versão compilada em imagem
É uma ideia de produto excelente, tanto tecnicamente quanto estruturalmente
Gosto especialmente do modelo de retribuir em open source um projeto open source de um grande vendor
Ou seja, em vez de eles pegarem open source e comercializarem, nós devolvemos o modelo deles em open source — acho exatamente esse tipo de abordagem correta
Parece que a ideia de “e se hospedássemos a nuvem diretamente nos nossos computadores?” está voltando
Tenho visto essa tendência de self-hosting em vários lugares recentemente
Este vídeo de apresentação também é interessante
O ponto central da nuvem é a elasticidade (elasticity)
Você aumenta ou reduz instâncias conforme a necessidade e paga só pelo que usa
Self-hosting até pode ter ferramentas de deploy convenientes, mas no fim você precisa arcar com o custo total dos servidores
Se a carga for constante ou previsível, tudo bem, mas fora disso tende a ser ineficiente
(É como a diferença entre andar de ônibus e ter uma van própria)
O desenvolvedor pode focar em implementar handlers de eventos, e isso fica ainda mais poderoso com filas e execução durável
No fim, FaaS é uma ferramenta de alto nível para abstrair código boilerplate