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.
I've been dabbling with deno for a couple years now, one of the most powerful features I'm excited about is BroadcastChannel[1] support, which works with --unstable in Deno Deploy.
One of the challenges I've run into is debugging timeouts in deno deploy, so I'm curious--
1. is BroadcastChannel supported in supabase self-hosted edge functions?
2. is there more tooling available to supabase edge functions to debug than currently in deno deploy?
---
if curious of specifics, this is my work in progress proof of concept, exploring using pathnames for channels, to get anyone on the same url path connected across regions through sockets and broadcast channel: https://github.com/tylerchilds/kickstart/blob/869506c9dae1e1...
[Supabase engineer & author of the blog post here.]
Thanks! Good Questions
1. We haven't enabled BroadcastChannel in the Edge Runtime. Mainly because we haven't found good use cases for it within Edge Functions (it does make sense as a way to subscribe within a browser client, but not sure how it fits with async/short-lived nature of Edge Functions). Curious about how you plan to use BroadcastChannel in Edge Functions?
2. As I've mentioned in the blog post Edge Runtime allows you to tweak the duration and memory available for an Edge Function (check the examples/main/index.ts in the repo too). Personally, I use this option to debug timeouts and memory issues on Edge Functions. We also plan to introduce better ways to profile your Edge Functions in the future.
Congrats on the launch! I’ve been so underwhelmed with Lambda’s lack of forward progress lately and have been wanting to play around a bit with V8 isolates. This looks like a super-easy way to get a runtime spun up and handling requests on AWS.
One of the biggest annoyances with Deno deploy/functions is that there is no way to store any data. This would be very useful to e.g. cache an auth token, store a key/value pair, etc. See also: https://github.com/denoland/deploy_feedback/issues/110
Is any work being done to fix this? Or is this out of scope currently?
Yes, this is something we are exploring for Edge Runtime. One cool development is AsyncLocalStorage now works on Deno via a polyfill [0]. We may enable a single node store on Edge Runtime using this. Also, there are some interesting development in Supabase platform to enable Edge Databases, which could also be an answer to this.
Is Supabase targeted towards webdev "apps" or mobile "apps"? As a mobile dev I got excited to check out a Firebase + serverless alternative, but the docs seem very targeted towards webdevs and non-native apps.
I see there's a 1.0 Swift library that's available, would love if someone can chime in with their experience using that in an iOS app.
Hey!
I wonder, why CEO, not even CTO or other Principal Engineer come here in person. Is it cuz company doing so great that CEO has so much free time to spend it on activity of that sort or HN is consider so serious resource to spend time on it even for C level person..
We use Kong as our API Gateway, so it is responsible for authentication, rate limiting, routing, etc. By moving that to edge runtime, we simplify our stack since we already run a edge runtime container to run user functions.
The other motivation for doing this is that it makes our API Gateway programmable with user defined functions. For example, you could implement custom transformations for storage or augment the Authorization header with custom claims before calling Postgrest.
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.
This is a webserver built on the Deno runtime. Deno makes it easy to build a custom JavaScript runtime [1]. I am excited about extending this runtime to integrate it better with the rest of the Supabase stack. For example, we can modify the Deno filesystem API to read and write files to Supabase Storage instead.
just use a regular server for mid/larger sized apps.
i started my web dev journey with JAMStack, Vercel, the "edge". everything is easy as long as one only deploys a full-stack NextJS app. the moment other apps come in, just use a server deployed as VPS and avoid "edge runtime hell". edge runtime hell refers to "you can't do this (function with over 2MB payload), you can't do that (because not supported by X)".
EDIT: I implicitly meant with "deploy as VPS" -> deploy your server via Render/Heroku/CI-CD instead of serverless functions running on the "edge".
I'm coming around to building everything for a VPS from the outset. There's a lot of upside to VPSes, such as:
1. Can be purchased as a fixed cost, usually at a rate that's much cheaper than on-demand pricing, and especially serverless--this tends to only get better with time as competition keeps prices low
2. It's "just" a Unix/Windows/Mac box, so the issues with runtime constraints you mention are bounded differently (and often more favorably); serverless is also just a box, but the constraints tend to be more onerous and limiting and it's not usually accessible in the same way
3. With containers, it's trivial to move between providers, so the hardware itself becomes fungible
4. On containers, I'm having a great time shipping Docker Compose configs--this works really well for the scale of application I'm targeting while avoiding the dreaded complexity of e.g. k8s
5. There's decades of high quality tooling already built and battle tested which makes operating VPSes much easier; the fact you can SSH into the machine, for instance, has huge leverage as an solo person working on independent products
Going forward, I'm planning to skip edge compute altogether unless there's a really compelling reason to want it. I should also mention that when a VPS is paired with a CDN, you can layer on bits of "edge compute" where it's warranted; or, you know, use it to cache static assets close to your users. :)
All-in-all it's kind of a funny return to where I started ~20 years or so ago with web development.
> it's kind of a funny return to where I started ~20 years or so ago with web development
It's a journey I've been going on too.
All the new platforms and paradigms that have emerged have had an initial shallow aura of helpfulness that has drawn me in, but almost exclusively when digging in I've realised that they create more issues than they solve, and/or introduce limitations that aren't worth it and force me to write janky, overly complicated code to work around that isn't comprehensible even a few weeks hence.
Maybe the most notable exception to this is containers. But in a sense they're an abstraction over the very same VPS paradigm. So that makes sense. It's not something new or different, just the same thing but with some advantages (and disadvantages too, obviously).
If VPSs had the same marketing and maybe a bit more polished standard tooling I have a feeling it would quickly gain traction and simplify life for most people. As well as prevent vendor lock-in, of course.
It’s in the SaaS business model. The incentives, even for fully open source like supabase, is misaligned with self-hosting. Even if they’re super honest and trying to be helpful, their fully managed globally available offering is going to have very different needs than self-hosters.
I actually more like the model of having FOSS where the company behind it offers consulting instead, to build, deploy and operate the product for customers who lack the in-house expertise. It’s not perfect, but it helps align the incentives towards simplicity.
> usually at a rate that's much cheaper than on-demand pricing
This is an area that is legitimate swindling/inflation by hosted app providers (e.g. DO Apps, Heroku, Render, Fly, etc). Oftentimes the per-vCPU/memory price is inflated over the underlying cost, even relative to a rather expensive underlying provider like AWS; which they'll reasonably justify by saying that this is the value-add, yeah you pay more but its more managed. But: when you have underlying access to the VPS, you can host more than one process! Which, of course, they're oftentimes doing on their end to cut costs.
Serverless functions can legitimately fall into the "always cheaper" category. If you've got twenty apps that each get request volume in the range of dozens-to-thousands per month; you could host that on a $5/mo VPS, or you could pay a few cents for a FaaS (Lambda, GCP, Cloudflare Workers, etc, all priced in the same magnitude). But the price-to-scale chart of serverless functions is really weird; they do hit a point where they're more expensive than just, you know, running a web server on a VPS. That point isn't at a super low volume, but its not far off from where its something to think about for a typical software organization. If I had a personal project that hit that point, I'd classify it as a good problem to have.
I also feel endless frustration in how there legit isn't a single cloud provider out there that (1) offers a serverless functions runtime, and (2) gives you the ability to set a non-zero budget which turns off the world when you go over budget. Many offer free tiers with no credit card, and some are even generous (Vercel and Firebase are two good examples), but I won't build on a free tier. I want to pay you. So, you upgrade and give a credit card, and now you're liable for one fuck-up bankrupting you, or throwing you on your knees at the mercy of their customer support. The severity of this fuck-up ranges from "my GCP account does just use a VPS, but egress is unlimited, so the bill was a bit high this month" to "the new dev changed a lambda function to call another which called the first one, and our bill is now the GDP of a developing nation-state".
The vast majority of the managed infrastructure world is, unfortunately, B2B swindlers just trying to out-swindle each other, only possible because they're all buying from each other, constantly raising prices, finding new ways to bill their customers, and losing any grip on the true (extremely low) reality of their costs. Supabase is better than most. I really do appreciate releases like this one. I'd also add Cloudflare to my list of "good ones"; they've taken a hard stance against charging for bandwidth, and I think that single decision had controlled a ton of the incremental costs we see from their newer higher-level product offerings like Workers.
I have stuck with cheap VPS servers for as long as I can remember. It takes 5 minutes to deploy a full stack node.js app, along with a database - and I've yet to exhaust the resources on my VPS, even with all my side projects (production grade and hobby stuff).
Have always found it weird how so many heroku-style hosting providers charge _per app_, things get costly, quickly, when you have lots of small apps like I do.
Just yesterday I realised I'll need a database to store job queues for https://chatbling.net - ChatGPT helped me figure out how to install it, have it persist to disk, ensure it starts up with the system etc. It's nice to not be fearful of unexpected charges hitting my card.
To anyone reading, even if it's just for learning, every now and then, skip the vercel/fly.io/netlify/planetscale/upstash/render/railway whatever cool hosting provider is out, and give a $5 VPS a try.
I think I want to do the same. Can you describe your stack please? How much downtime do you get and how do you deal with app updates and system updates to the vps machine itself? What about monitoring?
I’ve been using Cloudflare workers for a while now and I have to disagree.
There are entire classes of problems I no longer worry about with Workers and can just focus on building. My search history is a reflection of that. I’m no longer looking up “how do I put this thing in a Jails or container to limit exposure?” “how do I properly secure an SSH server?” “what is the magic incantation in my NGinx configuration to get an A+ SSL rating?”
I also spend less time thinking about ongoing maintenance, automating rotation of SSL certs, keeping system packages up to date, doing a dist-upgrade every few years, maintaining Terraform files to rebootstrap a server from scratch, thinking about hot/cold redundancy, etc.
With (some) serverless providers an absolutely massive slice of the responsibility of building a web application is pushed across the API and vendor boundary and is someone else’s responsibility.
For me at least, this is huge. I have a handful of clients that don’t have any full time engineering staff, and being able to push the cost of ongoing maintenance down is the only thing that allows them to afford building a custom application.
I'm afraid you're trying to make system administration look much harder than it actually is. As an example, adding good defaults to your nginx config is automated by certbot, or you could use caddy. You could run your apps statelessly by containerizing your applications or by simply writing Ansible playbooks and then not have to worry about upgrades - you simply deploy the application on the new server and spin down the old one.
I updated my post. I meant with "deploy as VPS" "deploy as a (virtual private) server with a service like render, heroku".
I agree the sys admin stuff, no thanks. the appeal of "serverless edge", at least to me, is ease of deployment. but, that ease of deployment is tooling / git integration rather than the underlying architecture.
the benefit of "your functions are globally distributed" has yet to appeal to me. for large ecommerce maybe. but then again, just deploy your servers in a distributed fashion which is "easy" if no state persistent is involved and tooling like fly.io is emerging.
Is there something about Deno that makes Edge functions good to be based on it - Netlify also has its Edge functions in Deno https://docs.netlify.com/edge-functions/overview/ maybe just coincidence, but seen two edge functions in Deno implementations in the last hour so makes me wonder.
One reason is that Deno can run on v8 isolates which start up really quickly. This makes the deploys near instantaneous and helps with cold start time too. The DX with Deno is pretty neat since it comes in bundled with a test runner, doc generator, linter, bundler, etc.
does any one have good practical experience running Supabase locally? Its against their business model to have this run well so I'm a bit scared of the growing lock-in.
(P.S. if Supabase is listening some customers like myself would be willing to pay a significant amount for support in a kubernetes/docker deployment running on our servers. We currently pay $50k - $100k simply for enterprise support contracts for each Cloudera, kafka, Kong, Flink... Not your target customer group so would be silly to add thoughts out laud )
Yes! `supabase init` and `supabase start` gets most of the way there! Customizing the ports in `supabase/config.toml` makes having multiple supabase instances running easy. This works great for all the Postgres, auth, and storage things, as well as real-time functionality. My engineers have a single package.json script to get everything up and running.
I work at an agency, and the dev teams run supabase locally. We use Prisma for migrations and maintaining our SQL functions and storage configurations. `supabase stop --backup` is our friend.
Not being able to run multiple edge functions at a time kept us leaning into Cloud Run and Cloudflare. I'm excited about today's announcement.
I have run self hosted Supabase for awhile in Kubernetes. One of the main gotchas I will warn against is becoming too attached to the CLI, as it’s currently quite tied to assumptions that you’re using hosted Supabase.
Also be prepared to do your own infra work if you want something scalable and production ready. The HA guarantees are kind of “bring your own” eg not really there out of the box and IMO the default docker compose setup provided, while thorough and working, serves as more of a proof of concept of the system than something you should actually be running in production.
Self-hosting is easier said than done. You can do it, but maintaining the infra, scaling, performance, security, updates, downtime, all of that is a _giant_ overhead. It's not against our business model for self-hosting to not work well. Everything we do is open-source and we don't "supplement" it with features from closed source code.
Hey there - Tim here from Supabase!
We have some options to explore here so probably best to connect on a call to get a better understanding of your project and how we can best align to help!
Can you send me an email on tim@supabase.io and we can tee up a time?
Cheers,
Tim
If I need to do more than one query to the database in series, my intuition is that it would be faster to make those calls in the same region as the database, rather than at the edge. It seems to be true using Vercel's playground[1] (towards Supabase).
Any guidance for Supabase based apps? Is it possible to run my functions close to the database?
for when it really matters, then you should just use a Postgres Function. That will be an order of magnitude faster than anything you do to match the region.
Supabase has auto-generated APIs (using PostgREST), so you can execute a Postgres Functions like this:
How is the real world WASM story for typical server side languages like python, ruby, etc. these days? Last I looked at it WASM seemed to have a lot of warts and complications (and limited real world language support) vs. just spinning up a native process in a container. Can you go from for example python flask API source file to serving requests in WASM with minimal fuss or loss of functionality vs. native CPython?
Readit News
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
I've been dabbling with deno for a couple years now, one of the most powerful features I'm excited about is BroadcastChannel[1] support, which works with --unstable in Deno Deploy.
One of the challenges I've run into is debugging timeouts in deno deploy, so I'm curious--
1. is BroadcastChannel supported in supabase self-hosted edge functions? 2. is there more tooling available to supabase edge functions to debug than currently in deno deploy?
[1]: https://deno.com/deploy/docs/runtime-broadcast-channel
--- if curious of specifics, this is my work in progress proof of concept, exploring using pathnames for channels, to get anyone on the same url path connected across regions through sockets and broadcast channel: https://github.com/tylerchilds/kickstart/blob/869506c9dae1e1...
Thanks! Good Questions
1. We haven't enabled BroadcastChannel in the Edge Runtime. Mainly because we haven't found good use cases for it within Edge Functions (it does make sense as a way to subscribe within a browser client, but not sure how it fits with async/short-lived nature of Edge Functions). Curious about how you plan to use BroadcastChannel in Edge Functions?
2. As I've mentioned in the blog post Edge Runtime allows you to tweak the duration and memory available for an Edge Function (check the examples/main/index.ts in the repo too). Personally, I use this option to debug timeouts and memory issues on Edge Functions. We also plan to introduce better ways to profile your Edge Functions in the future.
Our Lambdas are currently written in Typescript and built with esbuild. We zip them and push to AWS.
Is any work being done to fix this? Or is this out of scope currently?
[0] https://github.com/denoland/deno/issues/7010#issuecomment-14...
I see there's a 1.0 Swift library that's available, would love if someone can chime in with their experience using that in an iOS app.
2. We encourage all of our developers to participate in the discussions, I just am usually just faster to respond.
3. Personally: I love HN and the community. I read it every day and learn a lot from it. I'm a developer like most other readers
The other motivation for doing this is that it makes our API Gateway programmable with user defined functions. For example, you could implement custom transformations for storage or augment the Authorization header with custom claims before calling Postgrest.
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
This is a webserver built on the Deno runtime. Deno makes it easy to build a custom JavaScript runtime [1]. I am excited about extending this runtime to integrate it better with the rest of the Supabase stack. For example, we can modify the Deno filesystem API to read and write files to Supabase Storage instead.
[1] https://deno.com/blog/roll-your-own-javascript-runtime
i started my web dev journey with JAMStack, Vercel, the "edge". everything is easy as long as one only deploys a full-stack NextJS app. the moment other apps come in, just use a server deployed as VPS and avoid "edge runtime hell". edge runtime hell refers to "you can't do this (function with over 2MB payload), you can't do that (because not supported by X)".
EDIT: I implicitly meant with "deploy as VPS" -> deploy your server via Render/Heroku/CI-CD instead of serverless functions running on the "edge".
1. Can be purchased as a fixed cost, usually at a rate that's much cheaper than on-demand pricing, and especially serverless--this tends to only get better with time as competition keeps prices low
2. It's "just" a Unix/Windows/Mac box, so the issues with runtime constraints you mention are bounded differently (and often more favorably); serverless is also just a box, but the constraints tend to be more onerous and limiting and it's not usually accessible in the same way
3. With containers, it's trivial to move between providers, so the hardware itself becomes fungible
4. On containers, I'm having a great time shipping Docker Compose configs--this works really well for the scale of application I'm targeting while avoiding the dreaded complexity of e.g. k8s
5. There's decades of high quality tooling already built and battle tested which makes operating VPSes much easier; the fact you can SSH into the machine, for instance, has huge leverage as an solo person working on independent products
Going forward, I'm planning to skip edge compute altogether unless there's a really compelling reason to want it. I should also mention that when a VPS is paired with a CDN, you can layer on bits of "edge compute" where it's warranted; or, you know, use it to cache static assets close to your users. :)
All-in-all it's kind of a funny return to where I started ~20 years or so ago with web development.
It's a journey I've been going on too.
All the new platforms and paradigms that have emerged have had an initial shallow aura of helpfulness that has drawn me in, but almost exclusively when digging in I've realised that they create more issues than they solve, and/or introduce limitations that aren't worth it and force me to write janky, overly complicated code to work around that isn't comprehensible even a few weeks hence.
Maybe the most notable exception to this is containers. But in a sense they're an abstraction over the very same VPS paradigm. So that makes sense. It's not something new or different, just the same thing but with some advantages (and disadvantages too, obviously).
It’s in the SaaS business model. The incentives, even for fully open source like supabase, is misaligned with self-hosting. Even if they’re super honest and trying to be helpful, their fully managed globally available offering is going to have very different needs than self-hosters.
I actually more like the model of having FOSS where the company behind it offers consulting instead, to build, deploy and operate the product for customers who lack the in-house expertise. It’s not perfect, but it helps align the incentives towards simplicity.
This is an area that is legitimate swindling/inflation by hosted app providers (e.g. DO Apps, Heroku, Render, Fly, etc). Oftentimes the per-vCPU/memory price is inflated over the underlying cost, even relative to a rather expensive underlying provider like AWS; which they'll reasonably justify by saying that this is the value-add, yeah you pay more but its more managed. But: when you have underlying access to the VPS, you can host more than one process! Which, of course, they're oftentimes doing on their end to cut costs.
Serverless functions can legitimately fall into the "always cheaper" category. If you've got twenty apps that each get request volume in the range of dozens-to-thousands per month; you could host that on a $5/mo VPS, or you could pay a few cents for a FaaS (Lambda, GCP, Cloudflare Workers, etc, all priced in the same magnitude). But the price-to-scale chart of serverless functions is really weird; they do hit a point where they're more expensive than just, you know, running a web server on a VPS. That point isn't at a super low volume, but its not far off from where its something to think about for a typical software organization. If I had a personal project that hit that point, I'd classify it as a good problem to have.
I also feel endless frustration in how there legit isn't a single cloud provider out there that (1) offers a serverless functions runtime, and (2) gives you the ability to set a non-zero budget which turns off the world when you go over budget. Many offer free tiers with no credit card, and some are even generous (Vercel and Firebase are two good examples), but I won't build on a free tier. I want to pay you. So, you upgrade and give a credit card, and now you're liable for one fuck-up bankrupting you, or throwing you on your knees at the mercy of their customer support. The severity of this fuck-up ranges from "my GCP account does just use a VPS, but egress is unlimited, so the bill was a bit high this month" to "the new dev changed a lambda function to call another which called the first one, and our bill is now the GDP of a developing nation-state".
The vast majority of the managed infrastructure world is, unfortunately, B2B swindlers just trying to out-swindle each other, only possible because they're all buying from each other, constantly raising prices, finding new ways to bill their customers, and losing any grip on the true (extremely low) reality of their costs. Supabase is better than most. I really do appreciate releases like this one. I'd also add Cloudflare to my list of "good ones"; they've taken a hard stance against charging for bandwidth, and I think that single decision had controlled a ton of the incremental costs we see from their newer higher-level product offerings like Workers.
Have always found it weird how so many heroku-style hosting providers charge _per app_, things get costly, quickly, when you have lots of small apps like I do.
Just yesterday I realised I'll need a database to store job queues for https://chatbling.net - ChatGPT helped me figure out how to install it, have it persist to disk, ensure it starts up with the system etc. It's nice to not be fearful of unexpected charges hitting my card.
To anyone reading, even if it's just for learning, every now and then, skip the vercel/fly.io/netlify/planetscale/upstash/render/railway whatever cool hosting provider is out, and give a $5 VPS a try.
Easiest is to just provision ur own vps and run a docker-compose or k8s
There are entire classes of problems I no longer worry about with Workers and can just focus on building. My search history is a reflection of that. I’m no longer looking up “how do I put this thing in a Jails or container to limit exposure?” “how do I properly secure an SSH server?” “what is the magic incantation in my NGinx configuration to get an A+ SSL rating?”
I also spend less time thinking about ongoing maintenance, automating rotation of SSL certs, keeping system packages up to date, doing a dist-upgrade every few years, maintaining Terraform files to rebootstrap a server from scratch, thinking about hot/cold redundancy, etc.
With (some) serverless providers an absolutely massive slice of the responsibility of building a web application is pushed across the API and vendor boundary and is someone else’s responsibility.
For me at least, this is huge. I have a handful of clients that don’t have any full time engineering staff, and being able to push the cost of ongoing maintenance down is the only thing that allows them to afford building a custom application.
I agree the sys admin stuff, no thanks. the appeal of "serverless edge", at least to me, is ease of deployment. but, that ease of deployment is tooling / git integration rather than the underlying architecture.
the benefit of "your functions are globally distributed" has yet to appeal to me. for large ecommerce maybe. but then again, just deploy your servers in a distributed fashion which is "easy" if no state persistent is involved and tooling like fly.io is emerging.
The developer tooling is just not mature yet, and buggy in lots of ways.
Edge technologies are nice until they get into your way of work.
(P.S. if Supabase is listening some customers like myself would be willing to pay a significant amount for support in a kubernetes/docker deployment running on our servers. We currently pay $50k - $100k simply for enterprise support contracts for each Cloudera, kafka, Kong, Flink... Not your target customer group so would be silly to add thoughts out laud )
I work at an agency, and the dev teams run supabase locally. We use Prisma for migrations and maintaining our SQL functions and storage configurations. `supabase stop --backup` is our friend.
Not being able to run multiple edge functions at a time kept us leaning into Cloud Run and Cloudflare. I'm excited about today's announcement.
Also be prepared to do your own infra work if you want something scalable and production ready. The HA guarantees are kind of “bring your own” eg not really there out of the box and IMO the default docker compose setup provided, while thorough and working, serves as more of a proof of concept of the system than something you should actually be running in production.
Self-hosting is easier said than done. You can do it, but maintaining the infra, scaling, performance, security, updates, downtime, all of that is a _giant_ overhead. It's not against our business model for self-hosting to not work well. Everything we do is open-source and we don't "supplement" it with features from closed source code.
If I need to do more than one query to the database in series, my intuition is that it would be faster to make those calls in the same region as the database, rather than at the edge. It seems to be true using Vercel's playground[1] (towards Supabase).
Any guidance for Supabase based apps? Is it possible to run my functions close to the database?
[1] https://edge-data-latency.vercel.app/
Supabase has auto-generated APIs (using PostgREST), so you can execute a Postgres Functions like this: