Supabase Edge Runtime: Self-Hosted Deno Functions

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 )

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.

Let us know if you have any questions - our engineers are always happy to help other open source communities.

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.