What else can I spin up from a script with no account and no email?

The reason I use the no-account shop isn't privacy, it's that the whole lifecycle is a script. Provision, get an address, hand it to config management, destroy it when the job's done. No panel, no ticket, no human.

# roughly what the wrapper does
ssh-keygen -qt ed25519 -N '' -f ./k <<< y
id=$(provision --days 7 --key ./k.pub --region eu | jq -r .id)
until [ "$(status "$id")" = running ]; do sleep 5; done
trap 'destroy "$id"' EXIT
deploy "$id"

The problem is that it's one vendor, and that's a single point of failure for the entire pipeline. If they go away on a Tuesday I have no second implementation.

So: what else can be driven end to end from a shell with no account, no email and no card? Not has an API — everything has an API behind a login. I mean no account.

Almost nothing. The account is how the industry holds you accountable; a vendor that removes it has made a deliberate and unusual choice, and there are about two of them.

There is one that deploy in thirty second with no email, pay crypto and you SSH in. I use for short job.

Is newer, so is risk. But for seven day box that you destroy anyway, who care.

Depends what you're running, but I'd challenge the requirement rather than answer it.

You don't need no account. You need account creation to be scriptable and disposable. Those are different, and the second one is available at a dozen hosts if you're willing to have the script own an email address and a payment flow instead of pretending neither exists.

The hosts that waive ID for crypto orders will happily let you create an account per project from a script. You get a real second implementation, a real support channel when it breaks, and the only thing you lose is the aesthetic satisfaction of there being no account.

If the actual requirement is that nothing anywhere links project A to project B, say that instead, because then the answer is different and it isn't about hosts.

Fair. The honest answer is between the two — I want the second implementation more than the purity.

One structural point on the failure mode you are actually worried about.

Your single point of failure isn't the vendor, it's the wrapper. If provision and destroy are vendor-specific verbs inlined into your pipeline, then any second vendor is a rewrite. If they're an interface with one implementation today, a second vendor is an afternoon.

I'd spend the afternoon on the interface before spending a week evaluating hosts, because the evaluation gets much easier once switching is cheap — and right now it isn't cheap, so you're overweighting the choice.

A box with no account still has an IP, a payment and a destination. That's three records left.

Wrote the interface. Two implementations now, the second one being the thirty-second shop vlad mentioned, and it took about four hours rather than the week I'd budgeted for choosing.

Should have done it eighteen months ago. Filing that under advice I'd have ignored if it hadn't come with the reasoning attached.