I think this sounds easy, but it’s actually quite nontrivial in practice. You need special handling of such a limit for each kind of resource.

E.g. when my limit is reached to they remove the database, along with all backups, and all objects on S3? Since storage is billed, it should also be stopped when the limit is reached, right?

I think in practice among companies paying most of their revenue, there’d be zero interest in this, while it would be a lot of effort to implement.

This is really something specific to hobby projects, which just shouldn’t be using those “unlimited potential cost” services.

I don't think any of these requirements are necessary. A basic "if I reach my bill limit, turn off things that are billing" toggle would suffice for 80%+ of users, especially with better billing controls/per-team billing accounts. I think you run into more problems/user frustrations with a tenuous conditional-shut-off approach.

My tinfoil hat is that a lot of cloud billing is accidental, probably from "lab environments", and they don't want to provide a way to budget/limit these.

What if my bug was saving, like, way more data to the cloud than I expected, and suddenly having a big bill for the hard drive space my data is using up just sitting there? It would be a pretty dumb bug, but hey, you never know, right? In that case they have to choose to either delete my data or keep charging me, so I guess there isn’t an easy zero-cost “stop” option.

The whole post is about this accidental billing situation.

I mean, those S3 objects, those backups, those databases, are billing.

“Turning them off” means deleting them.

It doesn't have to be though?

The provider could reject further access to them (reads / writes) once the limit is reached. The cost of actually keeping objects as "cold" storage has a natural cap per billing cycle since those are billed based on time.

Sounds good to me, that's what offsite backups are for (if the data is even necessary)

It there was a law about this companies would find a way. Where there's any uncertainty they can simply eat those edge costs, the extremely fat profit margins cover it easily.

Would you be interested in a cloud provider that did not charge for inbound or responding (outbound in response) bandwidth?

Yes. Very much so. Or at least one that charged SANE rates. I get 100 mb outbound on my resident ISP, and that is unmetered, but clouds that sit almost directly on the backbone somehow charge a nontrivial amount of dollars per GB of bandwidth.

I only know of Hertzner.

You might be happier with a fixed-size VPS, instead of a cloud provider,

I started writing this comment by saying:

Exactly - the whole point of a cloud provider is scalability. If you're doing a personal hobby project, get off big scalable clouds and get yourself one (or multiple!) fixed-price VPS or dedicated servers.

But as I think of it, I think what people really want, for hobby projects, is not so much the scalability, but the managed offerings. They want zero-ops, zero-maintenance, zero-server-updates hosting, with a fixed price and hard limits. It won't be infinitely scalable, but it doesn't need to be - it's a hobby project.

They just don't wanna sysadmin a server of their own. Which is completely understandable.

There's room in the market for something like this.

An important part of hobby projects is the scaling to zero part too. I wager a lot of hobby projects use cloud simply because it's free or almost free (e.g. 2 cents a month), which isn't the case if you rent a VPS.

We tried this. I was tasked with automating popular software installs into fresh VMs. I think some of my scripts for doing so are on my github - wordpress and some dashboard software, at least.

offerings were published on the main page and afaik no takers. We migrated off whatever hypervisor we were using onto wok/kimchi and finally to proxmox, so my scripts still work, but proxmox has turnkey linux "quickstart" servers now as well as lxd, so there's less reason to use my scripts.

If you want a server that's fixed cost and zero maintenance, I recommend replit.

Thats a good point, however I might want to set limits higher than my normal usage, just not astronomically high.