The CLI: Run ‘ocel deploy’ in your existing apps, and deploy to a configured target, no separate IaC files required.
The SDK: Declare infra your app needs as code within the app itself, the CLI builds and provisions with no extra steps when deploying. Rust, Go, Python and Typescript supported.
The Console: Optional self-hostable UI for an otherwise CLI-first product. The neat part is that the console itself is an app built with the sdk and deployed with the CLI !
You can try it out to deploy your apps to your own infra. VPS is well tested, and AWS+Cloudflare is also quite well covered. I’ve been dogfooding this myself for things I’m building. Please expect bugs, as it’s still early days.
Why ?
I’ve been a big fan and user of SST for a long time (personal and professional projects). The DX is genuinely unmatched and the high-level components make things quite easy. I think they proved that most apps don’t need complex IaC code, and abstracting things behind high level components/primitives, with some customization levers, actually works quite well.
Ocel builds on that by taking it a bit further, no infra code, have a similar ‘high level components’ approach, but directly in the app. And support deploying existing apps or frameworks from day one in the CLI. You should be able to cd into an existing app and just deploy! (Of course theres a bit more like providing credentials to the platform you are deploying to, domains, one-time setup, etc). Everything else is the gripes I had after deploying tons of apps with SST:
- Preview and production separation built in, so previews can share heavy resources and be considerably faster - First class support for separating the origin and edge, so composing AWS and cloudflare (common setup I had) becomes a breeze - CLI-first product, but with a UI console that can also be self hosted for things like team management, setting env vars, etc. - More SDK primitives (Realtime, Tasks, Pubsub topics, etc) that give a BaaS-like experience no matter where you deploy