What you actually rent when you rent a machine

The destroy button is the most trusted control in hosting and it does very little of what people think it does.

You stop paying for a box. You click destroy, the panel says destroyed, the entry leaves the list. Nothing was wiped. Wiping is a physical event on hardware you have never touched and never will. What happened is that you asked a company to mark some storage available again, and what they do with it next is their business and invisible to you.

That is the last mile of a problem that starts on the day you sign up.

Where I am writing from

I run mobile proxy lines on Singapore carrier SIMs and a rack of Android phones that customers rent by the month. I also rent servers from other companies, because some things need to sit in a place I have no rack in.

So I have been at both ends of this. I know exactly what I can see as the provider. I assume the people I rent from can see the same about me, and I have never taken that as an insult. It is the arrangement.

The reasons people move onto rented hardware are good ones. The machine is awake at four in the morning, it is in Frankfurt if the account is supposed to look like it lives in Frankfurt, and a second person can reach it without credentials travelling through a chat window. Real problems, properly solved. The question is what comes attached.

The disk is readable and the key is not yours

A hosting provider can mount your volume. A remote desktop provider can see the screen. I can pull anything off a handset in my rack in about a minute, because it is my rack and I wrote the controller config myself.

So everything cached on that machine is readable by somebody who is not you. Session cookies. Saved passwords in a browser profile. An API key in a shell history file nobody has opened since March. Backup codes somebody screenshotted during a rushed setup and never deleted.

None of that requires a dishonest provider. It requires a provider.

Which brings up the phrase printed on every hosting page in the world. Encrypted at rest usually means the volume is encrypted with a key the provider holds and applies on your behalf, so a drive carried out of a building is useless to whoever carried it. Genuine control, and it works.

It is a much narrower claim than people hear. It says nothing about the party holding the key, and that party is the company you rent from, which can be served a legal request, can employ someone with too much access, and can be breached itself. Encryption that means what people assume it means keeps the key somewhere the provider cannot reach. That setup exists, it costs you an unlock step on every reboot, and almost nobody running a fleet lives with it.

The address block came with a history

The IP on a rented machine has a past and none of it is yours. Datacenter ranges get recycled constantly, so the address handed to you this morning belonged to a stranger last month, and whatever reputation they built on it arrived before you did.

The subnet is shared as well, and platforms score subnets rather than only individual addresses. You can be entirely clean and still sit inside a range that three platforms already distrust because of neighbours you will never meet or be told about.

This catches people coming off a home connection, where there was a history too but at least it was theirs. On a rented block the history belongs to a rotating cast who moved on and left the score behind.

Snapshots outlive your deletion

Every serious provider takes snapshots, and you almost certainly ticked the box, because the feature is good and has rescued plenty of people.

A snapshot is a copy of the machine’s state at a moment: session cookies, browser profile, whatever sat in memory if the image was taken live. It lives on storage you do not administer, under a retention policy you did not write.

Deletion is therefore partial by design. The file leaves the running system and stays inside however many images exist, for however long the policy says, and neither number is yours to set.

I take snapshots on my own servers too. The point is narrow: each one is a second copy of your session state, sitting outside the boundary you picture.

The provider account is the single point of failure

Everyone rehearses a machine dying. It is the wrong rehearsal. A dead machine is loud, obvious, and rebuilt by Tuesday.

The failure that costs is the provider account being suspended, and the causes are dull. A card that expired while you were travelling. An abuse complaint about a shared address, handled bluntly by someone clearing a queue. An automated fraud check that decided your signup pattern looked wrong.

When that lands, every machine on the account goes together. There is no degradation to watch. Forty sessions across eleven boxes end in the same minute because of a billing relationship none of the platforms involved have ever heard of.

The simultaneity is a second problem living inside the first. Accounts with no visible connection go quiet inside the same ten minutes, then reappear three days later from a new range at roughly the same time of day. Nothing about any individual account changed. What they shared was an event on your invoice, and from outside, a shared event across a set of accounts is the exact shape of a link.

That risk never appears in the monthly price. The dull fix is to keep the fleet off one billing account: two companies, and more than one account inside each where the terms allow it, so a suspension takes a slice instead of the lot. Mine sit across two providers and it costs about fifteen dollars a month more than consolidating would. There is a ceiling on it, though. I have watched people spread across six providers and lose track of which machine does what, and a fleet you cannot describe is a fleet you cannot repair at two in the morning.

The line I draw

What goes on rented hardware is work. Running sessions, browser profiles I could rebuild in an afternoon, scheduled jobs, anything that has to be in a specific country or awake at a specific hour.

The test is one question asked twice. If this disk went to a stranger tomorrow, what does that cost me. If the account were suspended tomorrow, what does that cost me. When both answers are a bad week, it goes on the rented machine and I stop thinking about it.

What never leaves hardware I hold has not changed in two years. The password vault, including the export made during a migration and left in a downloads folder. Recovery material: backup codes, 2FA seeds, and the recovery mailbox every reset link on earth eventually lands in. Credentials that never expire, meaning long lived API keys, SSH private keys and saved payment methods. And the ledger of which account uses which line and which identity, because losing one account is a bad day and handing over the map is another thing entirely.

Short lived credentials are the working compromise

The obvious objection is that a machine needs credentials to do anything useful, and it does.

What belongs there is the kind that dies on its own. A token with an expiry. A key scoped to one job. A session that ends in a week whether or not anybody remembers to end it.

The question to ask about any credential is how long it stays useful after it leaks. A token with six days left, sitting in a snapshot, is six days of exposure. A permanent API key in that same snapshot is exposure until you happen to notice, and nobody happens to notice.

The end of the term

Back to the destroy button.

On a good provider the block is zeroed, or the volume key is dropped and the data becomes unreachable. On a cheap one it goes to the next customer and the outcome depends on how their storage layer behaves. You will not be told which kind you were on, and asking produces a paragraph rather than an answer.

So the only control that matters is the one exercised at the start. If the material that would hurt you never touched that disk, its destruction is not something anybody needs to be honest with you about.

A rented phone or a remote desktop ends the same way. Log out through the platform’s own session list rather than through the device, because the device is going to somebody else and the only logout you can verify is the one recorded on the account side.

The thing I will get argued with about

I will not put a recovery mailbox on rented hardware. People who do are one billing dispute away from an interesting week.

The answer I get is that this is paranoid and that reputable providers do not read customer disks. Mostly true, and beside the point. A mailbox receiving every password reset for an entire fleet should not be protected by an internal policy I cannot read and will not be told has changed. I would rather run that one mailbox at home on a box that reboots when the power flickers, and eat the downtime.

What I cannot verify

My own hardware is not automatically safer and implying otherwise would be dishonest. My rack depends on aircon I pay for and power my building supplies. I have lost modems to a bus powered hub that could not carry the load, a failure no datacenter would ever have handed me. A machine I own has a single point of failure and it is me.

And I cannot verify most of what I have just told you to worry about. I do not know whether my provider zeroes storage. I have never watched it happen. I have read the page where they say they do, and a page is not evidence.

Which is why the rule is about what I put there instead of who I trust. I cannot audit these companies and neither can you, so the only question worth building around is what still stands if I turn out to be wrong about them.

The stack we run and the guides behind it are at Multi Account Ops.

Get new guides and videos first — join the Telegram channel.