Skip to content
VPSDen
Engineering, not policy

Every promise on this site has a mechanism behind it.

A privacy policy is a document describing what a company intends to do. It survives exactly as long as that intention — through acquisitions, insolvency, a change of management, or a sufficiently determined court. It is not a security control.

Everything below is built so that our intentions stop being the load-bearing part. Each one includes what it does not protect against, because a control whose limits you do not know is a control you will misuse.

Included free on every disk-backed plan

Zero-knowledge LUKS

The problem

A no-logs promise is worth exactly as much as the company making it. Companies get sold, get raided, run out of money, and change management. The promise does not survive any of those.

The mechanism

Your volume is a LUKS2 container using aes-xts-plain64 with a 512-bit key and argon2id key derivation sized to your plan — 512 MiB of memory cost on 2 GB instances, 1 GiB from 4 GB upwards, because the derivation runs inside the initramfs and a machine that cannot afford the memory will not unlock. The passphrase is generated in your browser and never transmitted to us. On every boot the instance halts in an initramfs dropbear shell and waits for you to SSH in on a dedicated pre-boot port and run cryptroot-unlock.

What follows

If we are handed a binding order for your disk, we comply — by handing over ciphertext and a header hardened against offline attack. That is the only honest version of a no-logs claim: one that holds when we are compelled.

What it does not do

The key is in RAM while the machine runs. A hypervisor operator or a live root compromise reaches it. If that is your threat model, use GHOST instead — there is no disk at all.

The full setup, reproducible yourself
Nobody else sells this€2/month

Dead-man switch

The problem

Sometimes the risk is not that someone compels you — it is that you stop being able to act. Detention, illness, a border crossing that goes badly, a country you cannot leave.

The mechanism

You pick a check-in interval between 24 hours and 90 days, and a grace period. Check in from the panel, the API, the onion service, or with an Ed25519-signed heartbeat sent by the instance itself, which means the machine can hold its own switch. Miss both windows and we overwrite the volume key, then wipe and reprovision the node.

What follows

The destruction is genuine and irreversible. There is no archive, no soft-delete, no thirty-day recovery window and no support ticket that undoes it. We cannot restore it for a court and we cannot restore it for you.

What it does not do

People do forget. Set a realistic interval, use a generous grace period, and enable the optional advance warning to your contact address if you have one. Customers do trigger it accidentally, and the pattern is always the same: a 24-hour interval set before travelling.

Built for the worst afternoon of your life€2/month

Duress PIN

The problem

"Just do not log in" is useless advice when somebody is holding your laptop and watching the screen. Refusing is itself information, and in some jurisdictions it is a criminal offence.

The mechanism

You configure a second PIN. Entering it authenticates successfully, renders a complete and entirely normal-looking panel, and spends the next four seconds destroying every volume key on the account and issuing wipe instructions to every node. The panel then behaves as though the instances are rebooting.

What follows

To an observer standing behind you it is indistinguishable from a successful login. You have complied. There is simply nothing left to read.

What it does not do

It destroys everything on the account, not a selection. If you need partial deniability, split across separate accounts — separate access keys are free and unlinked, which is the point of not having identities.

Default onFree, on by default

Metadata-free mode

The problem

The dangerous thing is rarely file contents. It is the pattern: when a machine is busy, how much it transfers, when it reboots, when its operator logs in. Most hosts collect all of that by default because the graphs look good in the panel.

The mechanism

We disable per-instance graphing, bandwidth sampling and console session recording at the hypervisor level. Not "we delete it after 24 hours" — the sampling job does not run, so the samples are never generated. Capacity planning uses a per-region aggregate at 15-minute resolution with no per-customer attribution.

What follows

You lose the pretty graphs in the panel. You gain the certainty that the samples do not exist to be subpoenaed, breached, or sold in a bankruptcy.

What it does not do

You can turn it off if you genuinely want the graphs. Some customers do, for capacity work. It is a switch, not a religion.

We treat a raid as an availability event€7/month · included on VOID and GHOST L

Multi-jurisdiction failover

The problem

Most hosts treat a seizure as the end of the conversation. Your data is gone, your service is down, and you find out from a news article.

The mechanism

You nominate a second country. Your instance replicates to it continuously over an encrypted channel. A health check running from three independent vantage points watches the primary; if it stops responding — seized, raided, cut off by an upstream, or simply dark — the standby is promoted and our anycast DNS follows within about sixty seconds.

What follows

A hostile action against one jurisdiction becomes a failover event rather than an outage. In our one real seizure, in 2019, customers with failover enabled were serving from a second country before we had finished writing the incident notice.

What it does not do

Replication means a second copy exists, in a second legal regime. That is a trade-off, not a free win. It is encrypted with your key, but if you want exactly one copy in exactly one country, do not enable this.

Everything, not just the websiteFree · managed onion endpoint for your instance €1/month

Onion-native infrastructure

The problem

A privacy host whose control panel logs your IP address on every login has given you a nicely encrypted server and a complete access log of who administers it.

The mechanism

The panel, the API, the support desk, the status page and SSH bastion access are all reachable over v3 onion services with Vanguards hardening. We publish the Onion-Location header, so Tor Browser offers you the onion version automatically. Your instance can be given its own managed onion endpoint with optional client authorisation.

What follows

There is no meaningful IP address for us to record for your administrative sessions, because the request arrives from a Tor circuit. The field is not empty as a matter of policy — it is empty as a matter of routing.

What it does not do

Onion routing costs latency. The panel is noticeably slower over Tor. Both paths are available and both are equally supported.

Our threat model, stated explicitly

Any security claim is meaningless without saying who the adversary is. Here is ours, in descending order of how well we handle it.

1. Physical seizure of hardware — handled well

LUKS with a key we never hold means a seized drive yields ciphertext. GHOST means a seized chassis yields nothing at all. Failover means the workload keeps running elsewhere. This is the scenario we are engineered for and the one that actually occurs.

2. Compelled disclosure by a court — handled well

We comply with binding orders from courts in the jurisdiction where the hardware sits, and we produce exactly what is compelled and nothing more. That is a salted hash, a payment amount, an instance specification, and encrypted blocks. In 12 years we have received 412 requests, of which 23 were valid local court orders and 23 were complied with. Those disclosures produced 0 customer records — not because the orders were resisted or were unenforceable, but because a customer record in the sense of a name, an address, a payment instrument or an identity document has never existed in our systems to hand over.

3. Our own insolvency or acquisition — handled structurally

The most under-discussed risk in this industry. A customer database is an asset in a bankruptcy and it gets sold. Our answer is that the database does not contain anything worth buying: no names, no addresses, no payment instruments, no IP addresses. An acquirer gets a list of hashes.

4. A hostile insider — partially handled

Hypervisor access is limited to four people, every privileged action is logged to an append-only store in a separate jurisdiction, and console access requires two-person authorisation. But an operator with hypervisor access can read guest memory, and no hosting provider can honestly claim otherwise. If your threat model includes us, you want genuinely dedicated hardware with your own disk encryption, treating the host as a landlord — and we do not sell that. VOID is bare-metal-class but still virtualised. Buy physical isolation from a provider that actually offers it.

5. A state-level adversary specifically targeting you — not handled

We will say this plainly because the rest of the industry will not: if a well-resourced state actor is specifically interested in you, a €7.90 VPS is not your answer. Traffic correlation, endpoint compromise, and legal process against every intermediary are all available to them. What we can offer is that the hosting layer is not the weak link, and that we will not be the ones who hand you over. That is the honest boundary of what a hosting company can do.

What we ask of you

Almost every real-world deanonymisation we have seen came from the customer's side, not ours. In descending order of how often it happens:

  • Administering an anonymous server from a home IP address with no tunnel.
  • Registering the domain with real WHOIS data.
  • Paying with cryptocurrency withdrawn directly from a KYC exchange to the invoice.
  • Reusing an SSH key, a PGP key, or a username that appears elsewhere under a real name.
  • Running an application that leaks an identifier — an analytics tag, a support widget, a default error page with a hostname in it.

We have written up the boring layers in the hardening checklist and the Monero payment guide. Get those right before you spend money on the exotic ones.

Questions

Mechanism questions

How does a dead-man switch for a server work?

You choose a check-in interval between 24 hours and 90 days plus a grace period. Check in from the panel, the API, the onion service, or with a signed heartbeat from the instance itself. If the interval and the grace period both elapse without a check-in, the volume key is destroyed and the node is wiped and reprovisioned. The destruction is irreversible, including for the provider, because the key material is overwritten rather than archived.

What is a duress PIN?

A second account PIN that logs in normally and renders a plausible panel for a few seconds while silently destroying every volume key on the account. It exists for the situation where someone is compelling you to log in while watching. To an observer it is indistinguishable from a successful login.

Can a hosting provider really not read my disk?

Yes, if the disk is encrypted with a key the provider never receives. With zero-knowledge LUKS the volume is encrypted using LUKS2 with argon2id and a passphrase generated in your browser. Every boot halts in an initramfs dropbear shell until you SSH in and supply it. The provider holds ciphertext and a hardened header, so a compelled disclosure produces unreadable blocks. The limitation is that the key is in memory while the machine runs.

Mechanisms, not promises. From €4.40 a month.

Zero-knowledge LUKS and metadata-free mode are on by default and cost nothing.

No email · No KYC · Pay in Monero · Deployed in under a minute