Privacy field guide

What does "no-logs" hosting actually mean?

By the HushVPS team · Updated 2026 · 7 min read

Ask ten hosting companies whether they keep logs and ten of them will say no. That tells you almost nothing. The interesting question — the one that decides whether "no-logs" protects you or just decorates a landing page — is what does no-logs mean for a VPS in practice: which data a server physically has to touch to run, which of that a provider chooses to write down, and how long anything survives on disk. This piece takes the slogan apart and rebuilds it as a checklist you can actually verify.

The problem with the slogan

"No-logs" is a marketing phrase before it is a technical one. It sounds absolute, and absolutes sell. But a virtual private server is a computer sitting in a rack, and computers do not run on nothing. Every host, without exception, handles some data in the moment it serves you. A provider that claims to keep literally zero while still delivering a working box is either being loose with language or hoping you will not ask the follow-up question. The honest framing is not "we touch no data" — that is impossible — but "here is exactly what we touch, what we discard, and what we keep."

What a host technically has to handle

Before we get to what a good provider avoids, it helps to be clear-eyed about what none of them can avoid. These are the unavoidable contact points between you and the machine.

Connection metadata

For a packet to reach your VPS, the network has to know where to send it. That means your IP address, and the server's, are visible to the routing layer for as long as the connection is live. This is just how IP works; it is not a policy choice. The policy choice is what happens next. A logging host writes that connection to a durable, searchable record — a line per session, retained for weeks. A no-logs host lets the routing state exist for the microseconds it is needed and never commits it to a log file. Same physics, opposite outcome.

Billing and provisioning

To hand you a server the host has to confirm you paid for it and then provision the box against some record of your order. With a card processor, that record is heavy: a name, a billing address, a transaction ID that ties you to the purchase forever. With Monero, the confirmation is a payment that clears without a processor writing your identity into a ledger — which is why the payment model and the privacy model are linked, not separate concerns. Either way some order token has to exist long enough to deliver and support the service. The question is whether it is bound to a real-world identity or to nothing more than a random string.

Keeping the platform alive

Hosts also handle transient operational signals: abuse detection to stop a single tenant taking down a node, crash diagnostics when a hypervisor misbehaves, capacity metrics to know when to add hardware. This data is real and it is necessary. The distinction that matters is whether those signals are scoped to platform health and short-lived, or whether they quietly double as a surveillance record of what each customer is doing.

What a host can genuinely avoid keeping

Now the other side of the ledger. A great deal of what people fear in "logs" is entirely avoidable, and avoiding it is a design decision made long before any request arrives:

  • Traffic and access logs. A host does not need a per-request record of what you served to keep your VPS running. Not writing them is a choice, and it is the single most meaningful one.
  • The contents of your disk. On a root VPS, what you install and store is yours. A privacy-minded host does not inspect it, copy it, or run an agent that phones home about it.
  • A KYC identity. You cannot log a name you never collected. Skipping identity verification at signup removes an entire category of retainable data before it is ever created.
  • A payment trail tied to you. No card, no processor record, no bank statement line linking your legal name to a specific server.

The pattern is minimisation: collect the least at the door, keep the least afterward, and design so that the sensitive records simply never come into existence. Data that was never collected cannot leak, cannot be subpoenaed, and cannot be sold.

Retention windows: the number that actually matters

Here is the detail most "no-logs" pages skip. For every piece of data a host does keep, there is a lifetime — a retention window — after which it is deleted. "We keep your order token" means something completely different at 24 hours versus 24 months. A serious policy names the window for each data type. A slogan gives you a single word ("no") and leaves you guessing. When you evaluate a provider, look past the headline claim and hunt for the retention schedule. If it does not exist, the "no-logs" promise has no shape, and a promise with no shape cannot be checked.

Why "zero logs" is usually marketing

The phrase "zero logs" persists because it is easy to print and hard to disprove at a glance. But it collapses two very different things — data handled transiently and data retained durably — into one confident absolute. Privacy educators have made this point for years: the value is in the specifics, not the superlative. Independent guides such as Privacy Guides consistently steer readers toward providers whose claims are documented and testable rather than those with the boldest tagline, and the Electronic Frontier Foundation has long argued that data minimisation — not maximal promises — is what actually protects users. Treat any "we log nothing, ever" banner as an invitation to read the fine print, not a substitute for it.

How to verify a no-logs claim

A claim you cannot check is just a vibe. Three concrete artefacts turn "trust us" into "verify us," and none of them require an account.

Read the written policy

A real policy states, in plain language, what is collected, what is kept, and for how long — and it matches whatever the marketing page says. If the privacy document is vaguer than the homepage, believe the homepage less. Our own privacy policy is written to line up with the retention table on the product page, not to bury the answer in legalese.

Check the warrant canary

A signed canary that refreshes on a schedule is a passive tripwire: if it stops updating or its wording quietly shifts, that change is itself a signal. It cannot prove a negative, but a maintained canary paired with a transparency page shows the provider has thought about compulsion, not just about advertising.

Walk the signup flow yourself

The most convincing test is the one you run. Start an order, leave the email field blank, pay in Monero, and notice the moment you were never asked for an identity. Data that is never requested cannot be logged — and you can confirm that by watching what the checkout actually demands, not by trusting a badge. This is exactly the design behind our verifiable no-logs VPS: the retention list is published, the sensitive fields are absent by construction, and the claim is meant to be inspected before you spend a coin.

No-logs is not the same as anonymous

One last distinction worth holding onto. Anonymous hosting is about the front door — not collecting an identity when you sign up. No-logs is about the timeline — not retaining a record of your activity as it runs. They reinforce each other but they are not synonyms. A host can be anonymous at signup and still log your traffic, or collect your identity and keep no activity logs. The strongest privacy posture does both at once: minimise what is asked for, and minimise what is kept. When you read "no-logs," read it as one half of that pair, and check whether the other half is there too.

See the policy behind the slogan

HushVPS publishes a plain-language retention table, keeps only what running the service requires, and gives you three ways to check. No KYC, Monero billing, full root.