1. Find out what is underneath
Almost every crypto-friendly host is either a reseller of a large cloud or somebody with rented hardware in a cabinet. Neither is bad. Not telling you which is.
The check takes thirty seconds: find an IP the host advertises, or deploy the cheapest thing they sell, and run a whois on the address. You will see either a recognisable network — Vultr, DigitalOcean, Hetzner, Linode, OVH — or something you have never heard of.
A reseller of a top-tier cloud inherits that cloud's network, hardware and DDoS posture. Mystery hardware inherits whatever the operator felt like buying, and its IP ranges often carry the reputation of whoever used them last.
2. Read the abuse policy before you need it
Every host has an abuse process. The question is whether it is written down and whether it reads like something a person actually follows.
What you want to see: where reports go, what happens first, how long you get to respond, when suspension happens, and whether you can appeal. What you do not want is silence, or a single line saying accounts may be terminated at the provider's discretion. The second one is not a policy, it is a reservation of the right to do anything.
This matters more on a no-KYC host than anywhere else, because you have no relationship manager and no paper trail. The policy is the relationship.
3. Find out what happens to your money before you send it
Prepaid balance is the normal model in this corner of hosting, and it is fine. What varies enormously is what the host will tell you about it in advance.
Look for a clear answer to: is the balance refundable, does it expire, and what happens to it if you stop using the service. If you cannot find that answer before paying, that is the answer.
We are a reasonable example to hold to this standard. Our top-ups are final — balance is prepayment for hosting here, it does not expire, and it cannot be paid back out. You may dislike that policy; the point is that it is written in the terms and on the FAQ before you fund anything, rather than discovered afterwards.
4. Check how billing is measured
Hourly billing is not just a convenience. It is a structural protection, because it caps how much of your money is at risk at any moment.
If a host only sells in monthly or annual blocks, your first purchase is a bet on a company you have not tested. If they bill hourly from a balance, you can put in a small amount, run a server for an evening, destroy it, and know exactly what you bought before committing anything real.
Annual-only pricing at an implausible discount is the specific pattern to distrust. It is how a host maximises what it collects before anyone notices a problem.
5. Ask a question before you pay
Send support something specific that requires a real answer — a question about their abuse stance on your use case, or which provider backs a particular region. Not "do you accept Bitcoin".
You are measuring two things: whether a human answers, and whether the answer is specific. A host that cannot answer a pre-sales question in a day will not be faster when your server is down.
6. Do the arithmetic on the price
You can look up what the underlying clouds charge. If a host is reselling a $5 instance for $2 a month, one of a few things is true: they are not reselling what they claim, the resources are oversold to the point of uselessness, or the business is funded by new deposits rather than by hosting. None of those ends well.
Cheap is fine. Cheaper than the wholesale cost of what is being sold is a warning, and it is the most reliable single signal on this list.
7. Look at how the payment itself works
There is a real difference between a host that gives you a payment page with an invoice, an amount, a timer and a status you can refresh, and one that posts a raw wallet address and asks you to send funds and then email them.
The second is not automatically dishonest, but it has no mechanism for the ordinary failure — you paid, the amount was off by a fee, and now the credit depends on somebody reading their email. A processor-backed invoice makes that case handleable. A wallet address in a support ticket does not.
The checks we would fail
Worth naming, because a page like this from a host is self-serving unless it names its own weak spots.
We are new. The domain was registered in mid-2026. Age is a legitimate signal and we do not have it. The honest mitigation is the one we would recommend against any young host: start with a small top-up, run something real for a day, and scale up only after it behaves.
No status page. If something breaks you find out by looking at your server, not by looking at ours. That is a gap and it is on the list to fix.
No dedicated hardware, no bare metal, no managed services. If those are your requirements we are the wrong shop, and it is better to know now.
What we do offer against this checklist: real instances on four named clouds you can verify with a whois, a published abuse process with actual deadlines, hourly billing from a prepaid balance so your exposure is hours rather than months, a refund policy stated before payment rather than after, and processor-issued invoices rather than a wallet address in a ticket.