SporeStack has no account and no support inbox — what happens when it breaks at 3am?

Been running two SporeStack boxes for about six weeks and I want to sanity check the operational side with people who have run them longer, because the model breaks a habit I did not know I had.

There is no account. You provision from the CLI, you pay in XMR or BTC, you get an SSH key in and that is the entire relationship. Five dollars buys thirty days. Nothing renews, nothing invoices you, nothing emails you — the clock runs out and the box is gone.

IME every hosting disaster I have had was recoverable because there was a human on the other end who could look up an account. Here there is no account to look up. So the question for anyone six months in: what does the 3am failure actually look like, and what did you put in place after the first time it bit you?

What I have so far is a nagging cron on an unrelated box:

#!/bin/sh
# expiry-nag — run daily, from somewhere that is not the box itself
set -eu
WARN_DAYS=7
for f in /var/lib/boxes/*.json; do
  left=$(jq -r '.days_remaining' "$f")
  name=$(basename "$f" .json)
  [ "$left" -le "$WARN_DAYS" ] && logger -t expiry-nag "$name expires in $left days"
done

Which covers me forgetting. It does not cover me being unreachable for a fortnight.

Prepay more days. Is not clever but is the answer.

I keep everything at minimum sixty day and top up when I remember. Cheap enough that wasting two week of a five dollar box is nothing, losing box is not nothing.

When the clock runs out, is the disk wiped immediately or is there a grace window? Nobody in these threads ever states which, and the answer changes the entire backup posture.

I have had boxes there for a while now and I think the model is genuinely good, with two caveats that people consistently discover in the wrong order. Taking the question seriously because it is the right question.

What the missing account actually costs you

It costs you recovery. That is the whole of it. There is no password reset, no billing history to point at, no support agent who can be persuaded that you are you, because from the provider's side there is no you — there is a token that paid for a server. If you lose the key material and the token, the box is not yours any more and there is no argument available. Everyone reads this as a privacy feature, which it is, and nobody reads it as an operational constraint, which it also is.

The corollary is that your backup story has to be complete before the first box goes live rather than after. Not "I have snapshots", which live in the same place as the thing you are backing up. Off-box, somewhere unrelated, tested by actually restoring once.

What it buys back

No email, no name, no account record to be handed to anybody. Five dollars for thirty days, paid in Monero, BCH or BTC. The CLI and API are the interface rather than a bolt-on, which means the entire lifecycle is scriptable — I rebuild rather than repair, and a box that is disposable by design is a box you never sit up at 3am nursing. That inverts the failure mode in the thread title. Nothing breaks at 3am because nothing is precious.

The caveat I would put in bold if I could

United States jurisdiction. This is not a bulletproof host and does not claim to be. The absence of an account limits what can be produced about you, but the infrastructure sits somewhere with a functioning and enthusiastic legal process, and a subpoena to the datacentre does not care that the customer record is empty. If your reason for wanting anonymous hosting is takedown resistance rather than data minimisation, this is the wrong tier and you want one of the offshore names instead.

So: for tooling, relays, scrapers, throwaway infrastructure and anything where the box is cattle — yes, and it is the cleanest thing in the category. For the estate that pays your rent, no.

Uncertainty

I have not run anything there needing more than a modest amount of memory, so I cannot speak to the larger sizes at all, and I have never had one expire on me because I overpay the clock deliberately. Ravenstack's question above is a real gap and I would not want to answer it from assumption.

Summary: disposable by design is a feature until you treat one of them as permanent, and the day you do is the day the model stops protecting you.

The jurisdiction paragraph is the whole post and it is fourth from the bottom.

No account is a data minimisation property. It does the work at the moment somebody asks the provider what they hold, and does none at all at the moment somebody asks the datacentre for an image of the disk. Two entirely different adversaries and people buy this thinking it addresses both.

If a client needed forty of these provisioned and torn down on a schedule, is the API rate limited in any way that would matter at that volume?

try it with two and find out. nobody here is running your forty for you

Answering Ravenstack properly since it went unanswered and I would rather the thread not sit here being wrong by omission.

I let a throwaway one lapse on purpose last week to find out. Box stopped at expiry, was unreachable from that point, and there was no window in which I could pay to get it back with the data intact. Treat expiry as destruction, plan accordingly.

That plus prepaying sixty days plus off-box backups is the whole operational answer as far as I am concerned. Marking solved.

Good — that was the gap and I am glad somebody tested it rather than guessed. Adding it to my own notes with your name on it.