What you keep,
and how you show us out
Access, secrets and reversibility, written down. Here, taking back control is not negotiated: you remove a key.
Contents
1. You keep full control
You keep full root access to your machines. We lock nothing down. That is not an oversight, it follows directly from our model: you buy the infrastructure directly from the provider, we bill only the operations. The machine is yours, the provider account is yours, and so is the access.
| What you have access to | Level |
|---|---|
| Your servers | root, permanently |
| Proxmox VE | interface and API, if the hypervisor is dedicated to you |
| Your virtual machines | console and export |
| Your backups | browse and restore |
| Your member area | console, start and stop, ISO mounting, backups |
| Your provider account | it never stopped being yours, where you subscribed to it directly |
At many managed-service providers, “how do I get my things back?” opens a months-long project and a reversibility invoice. Here the question has a one-line answer — and it is further down this page.
2. What we recommend, without imposing it
The distinction matters, so let us write it down: what follows are recommendations. We argue for them and we hold to them on our side. But the access policy on your servers is yours.
SSH keys, not Unix passwords
This is our firmest recommendation. A password can be guessed, replayed, written on a pad and shared without a trace. A key is revoked individually: removing one line from one file removes one access, and only that one.
Individual accounts
One account per person, so that who did what is knowable. Group accounts remain possible if you ask — some organisations prefer them, and that is your call. We will simply tell you what you lose in traceability.
What we do not impose
No bastion, no second factor on your machines, no mandatory access review. We could turn that into a checklist and present it as a mark of seriousness: it would mostly be a way of making ourselves indispensable. A provider holding the only keys to your infrastructure is a provider you do not leave easily. We made the opposite choice, and this page exists so that it can be verified.
That is a default, not a ceiling. If your security policy calls for a bastion, an administration VPN, a second factor, time-bound privileges or session logging, we put it in place and we work within it — it is your infrastructure and your constraints. The difference is that it comes from you, not from us.
And it is often the right call: past a certain level of criticality, or as soon as a regulatory framework applies, those measures belong there — in the contract, not merely in practice.
3. Secrets: who holds what
The credentials, keys and passwords created at commissioning are handed to you at that moment. Each side keeps its own copy afterwards. So there is no single vault that only we hold, and you never have to ask us for access to your own infrastructure.
For on-call clients and full-infrastructure engagements, the reverse is possible too: access to our own vault, so that your team is not stuck if we do not answer. Dependency has to cut both ways, otherwise it is not redundancy.
4. The quarterly restore, and its report
A backup nobody has ever restored is not a backup, it is a hypothesis. So we verify it — and above all we give you the proof.
Two proofs of a different nature
Taken separately, each looks thin. Together they cover the question — and the distinction is real: a valid checksum does not tell you a machine boots.
| Proof | What it attests | Scope |
|---|---|---|
| Integrity | The archive has not rotted and matches what was written. Every chunk carries a checksum, and the good practice documented by Proxmox is a recurring job over recent backups plus a periodic one that “will reverify everything”. | Automatic, permanent, exhaustive |
| Restore | The full chain works, and here is how long it takes. It is the only one of the two that produces a duration. | Manual, periodic, sampled |
Our commitment, with its condition
For Proxmox infrastructures whose backups sit on our Nimbus platform, we restore a randomly picked virtual machine, at a cadence that follows the size of the estate:
| Estate size | Restore tested |
|---|---|
| Up to 5 machines | one random VM every six months |
| More than 5 machines | one random VM every quarter |
Randomly, and that is the point: if we picked the machine, we would only ever test the ones we already know come back.
What this test proves, and what it does not. A random draw verifies that the restore chain works, not that each of your machines has been restored recently — the larger the estate, the further apart any given machine comes round. It is the integrity verification that covers the whole estate, continuously. Together the two answer the question; either one alone does not.
The report handed to you carries:
- • the date of the test;
- • the machine drawn and restored;
- • the volume brought back;
- • the measured restore duration;
- • the outcome.
The condition is not commercial small print: it marks out what we can actually honour. We do not test restores of a backup we do not operate, nor of a workload that is not virtualised with us.
Why that figure beats a guarantee
The measured restore duration is the only figure that lets you estimate a realistic time to restore. Nobody gives it to you. It is also what makes our position on deadlines tenable: we do not guarantee a time to restore, we measure yours and we tell you what it is.
A provider selling you a 4-hour MTTR without ever having timed a restore on your data volume is selling you a number, not a deadline.
The mechanism — how backups are taken, retention, immutability, how the test is run — is described on Nimbus, our backup platform. What you are reading here is the other half: the operational commitment, namely that someone actually uses it regularly and proves it to you.
5. How you show us out
This is the question everyone asks at the end of a contract, and rarely at the start. Here is the full answer, in all three cases.
In every case: you remove our key
Our access is a public key in an authorized_keys
file. You delete it and the access ceases to exist — immediately, without telling us,
without our help. There is no concealed service account and no proprietary agent to uninstall.
Your infrastructure sits at a provider
OVHcloud, Scaleway, Hetzner, IONOS: there is nothing to migrate. The hardware, the contract and the account have been in your name since day one. Cutting our access is enough, and you are out.
Your virtual machine is hosted with us
You take its export in .vma.zst format, Proxmox's
native format, and reinstall it wherever you like. That is the only step involving real work
— and it is on your side, not ours.
No reversibility notice period to negotiate, no exit invoice, no proprietary format. We would rather be kept because the service suits you than because leaving is expensive.
6. What stays with us
Two exceptions, and they are better said plainly.
The physical backup server
When your backups are hosted on our Nimbus platform. That is a managed service — you do not have hands on that machine, and that is precisely what you are buying.
A shared hypervisor
Access to the Proxmox VE interface and API assumes the hypervisor is dedicated to you. If it also hosts other clients, we cannot open its administration console to you without giving them access to your machines, and the other way round.
You are not left empty-handed, though. You keep root on your machines, and your member area gives you hands-on control of what matters day to day, without going through us:
- • the console of your machines;
- • start and stop;
- • mounting a CD, from the pre-loaded ISO images;
- • browsing your backups;
- • restoring a backup.
What stays on our side is administration of the host itself — the part that also touches the others. On a hypervisor you own or that is reserved for you, the question does not arise.
What it does not change: your backups remain browsable and restorable by you, at any time. The hardware and its operation are ours; your data is not.
We are based in Pontoise, Val-d'Oise, France, and the bulk of our work is done remotely.
Frequently asked questions
Do you keep access to our servers after the contract ends?
No, and you do not need to ask us for that. Our access is one SSH key in your authorized_keys file: remove it and the access ceases to exist. There is no hidden service account, no operational back door, no deactivation delay to negotiate.
Do you impose a bastion, MFA or an access policy?
Not by default. We strongly recommend SSH keys over Unix passwords, and individual accounts over shared ones, but the access policy stays yours: it is your server and you keep root on it. If, however, you require a bastion, an administration VPN, a second factor or session logging, we put it in place and we adapt to your security constraints. What we refuse is to make it a condition of the service: a provider who locks down its client's access makes itself indispensable.
What if I want to move a VM hosted with you?
You take its export in .vma.zst format and reinstall it wherever you want. If your infrastructure already sits at a provider — OVHcloud, Scaleway, Hetzner, IONOS — there is no migration at all: the hardware and the account are yours, you simply cut our access.
Who holds the passwords and secrets?
We hand them to you at commissioning, and each side keeps its own copy afterwards. There is no single vault that only we hold, and you never have to ask us for access to your own infrastructure. On-call and full-infrastructure clients can additionally be granted access to our own vault.
Do you actually test restores?
Yes, for Proxmox infrastructures whose backups sit on our Nimbus platform: we restore a randomly picked virtual machine — one every six months up to five machines, one per quarter beyond that — and hand you the report: date, machine, volume, measured restore duration and outcome. That measured duration is the only figure that lets you estimate a realistic time to restore.
A question about the contract rather than the technology?
Scope, access, exit: we answer in writing, before you sign.
Request a quote