Supabase Edge Runtime: Self-Hosted Deno Functions

hey hn, supabase ceo here

This is a webserver for Deno. It is MIT licensed, written in Rust, and based on the latest Deno Runtime (1.32+). It can serve TypeScript, JavaScript, and WASM functions.

This one is important for local development and self-hosting. For local development, it ensures there is parity between development and production. For self-hosting, it means you can deploy and manage your Deno Functions on your own hardware. We have provided a Demo repository for deploying to Fly.io [1]. The runtime is not production-ready, but it is in a usable state. Note that we still use Deno Deploy at Supabase, and strongly recommend it for your own Deno functions.

In the medium-term, this will reduce our tech-stack by 1 service. We'll remove Kong (a reverse proxy) and replace it with the Deno runtime. I'm excited about some other possibilities that this provides for self-hosting - one that we talked about was the ability to bundle a SQLite file with your functions, for a fully-contained and globally deployed webserver.

The team will be around if you have any questions

[1] Deploy on Fly: https://github.com/supabase/self-hosted-edge-functions-demo

HIPAA support this week? :)

We got SOC2 Type 2 last week, HIPAA is next.

We won't do much of an announcement about SOC2, so you can consider this comment the "official announcement" :)

Thank you for open-sourcing especially under MIT license. I am digging through the codebase and finding a lot of interesting things.

I am building another open-source project that is also a self-hosted deno runtime written in Rust, Windmill [1], where we enable to build all of your internal tool and infra (endpoints, workflows, apps) based on scripts (deno, but also python, go, bash). Instead of running one http server continuously for your function, we run it on demand which has its own set of challenges.

We are doing something pretty naive right now: we create a fork and call deno run [2]. It's decently efficient (25ms for a naive script e2e). We are familiar with deno_core and use it in other places to run javascript directly, but for typescript, deno didn't expose directly the root entrypoint as a lib so we had to fork it [3] and are now gonna be able to do the transpiling to js AOT and save the fork for sub 5ms script execution.

We also want to make some functions togglable as high-performance endpoints and for those we would want them to be spawned as http servers to save the cold start. I'm gonna investigate thoroughly the codebase, and thank you very much for having shared it.

[1]: https://github.com/windmill-labs/windmill

[2]: https://github.com/windmill-labs/windmill/blob/main/backend/...

[3]: https://crates.io/crates/deno_cli_lib_windmill

Usually the teams know what they need to build based on user feedback (which we get a lot of).

We don't have Product Managers, the developers are expected to be very product-focused and user-facing. After every launch week we ask them what they want to build and then they get to work.