Provider longevity
Longevity and guarantees: what truly protects your infrastructure
"You are a young company" is the first objection we hear from public buyers. The real question is less the provider's age than what happens to your infrastructure if it disappears. With Bunker, the answer is structural: an open-source, reversible platform you can take back without our approval, a published subprocessor chain, an exposed ISMS. Here, continuity rests on a verifiable technical property rather than a promise.
Updated on October 2, 2026
For a public buyer or a director entrusting their information system to a provider, longevity is a real question, and a fair one. But a provider's age or size is a poor indicator of it: large vendors close products, force migrations or get acquired, and their size does not give you your freedom back the day it happens. This page explains what actually protects your infrastructure, and how to check a host's resilience before you buy, with evidence rather than on trust.
"Young company": the real question is continuity
When a CIO says "you are a young company", they are not expressing a preference for large providers. They are asking a continuity question: if you disappear, what becomes of my infrastructure? It is a fair question, and it deserves a verifiable answer rather than commercial reassurance.
The honest answer is not to promise we will always be here. It is to make sure your continuity does not depend on us. That is the whole point of reversibility: an infrastructure you can take back at any time, without our approval, stays usable whatever happens to us.
Why a provider's size does not guarantee your longevity
The intuition that "a large player is safer" holds up poorly in the field. Hyperscalers and large vendors regularly pull services from the catalogue, impose version upgrades, or change their pricing terms. Broadcom acquiring VMware is the most telling recent example for infrastructure teams.
The blind spot is the same in every case: the more you are locked in, the less a provider's size protects you. It even becomes a trap, because a proprietary service with no equivalent elsewhere turns every change of course into a rewrite you did not choose. What protects you, in the end, is your ability to leave, far more than the size of whoever hosts you.
Reversibility neutralises provider risk
With Bunker, continuity is first a technical property, before being a contractual clause. The platform is reversible by design: open-source end to end, built on open standards (Kubernetes, S3 object storage, PostgreSQL), with no proprietary layer to hold you.
Concretely, leaving comes down to three steps you perform alone, without our green light: you recover your data through exports and database dumps, you redeploy the platform wherever you want since it rests on open standards, then you point your DNS at the new hosting. There is no switch we keep on our side. That is what overturns the "young company" objection: the day a provider becomes a risk, the only safeguard that counts is being able to do without it.
What Bunker exposes publicly
A young company cannot lean on a long track record. It can, however, be more transparent than a large player. So we expose what is verifiable today:
- A public ISMS and trust center: our security posture, vulnerability handling and commitments are documented on the security and trust center page.
- A published subprocessor chain: every subprocessor is listed in the contract (GDPR art. 28) and exposed on our subprocessors page, with the law each answers to.
- An open-source stack: no proprietary black box disappears with us; the code and standards stay available.
- Supervision relies on automated monitoring backed by a real SRE on-call rota.
Verifiable transparency is the best substitute for seniority: it can be checked, where a promise of longevity can only be verified after the fact.
Contractual guarantees: escrow and launch pricing
Beyond technical reversibility, two contractual guarantees directly address the continuity concern. They are stated here conditionally, because their exact wording is still being framed legally. [À VALIDER /legal]
- Escrow clause: placing the elements needed for reclaim into escrow, triggered by events defined in the contract, adds a further safety net to reversibility. [À VALIDER /legal]
- Launch pricing named as such: the launch price is contracted as a launch price, so you know what to expect, with no abrupt unanticipated increase. [À VALIDER /legal]
These guarantees complement the technical property; they do not replace it. Reversibility stays the foundation, because it can be exercised without depending on anyone.
How to assess a host's longevity before you buy
Rather than judging a provider by its age, ask the questions that measure your real exposure:
- Can I recover my data and redeploy the platform elsewhere, without a rewrite and without the provider's approval?
- Is the stack open-source and open-standards, or does it depend on proprietary services with no equivalent?
- Are the security posture and subprocessor chain published and verifiable?
- Does the contract provide for an escrow clause and clear pricing over time?
- What happens, precisely, to my infrastructure the day the provider stops?
A host that answers these five points in writing gives you a sturdier continuity than a big name that locks you in. To put it into practice, our cloud repatriation guide details the reclaim process, and the CLOUD Act and sovereignty page covers the jurisdictional side.
Frequently asked questions
Bunker is a young company: is that a risk for my infrastructure?
The real risk is not the provider's age, it is dependency. Bunker neutralises it through reversibility: the platform is open-source, open-standards and reversible, you can take it back onto your servers or another host without our approval. Your continuity therefore does not depend on our longevity. Add a public ISMS and subprocessor chain, verifiable today.
What happens to my infrastructure if Bunker stops operating?
It keeps running, because you can take it back without us. Leaving comes in three steps: you export your data and databases, you redeploy the platform wherever you want since it rests on open standards, then you repoint your DNS. No approval or action on our part is required and there is no switch on our side. It is a technical property of the platform, detailed on our reversible cloud page.
Is a host's size a guarantee of longevity?
Not really. Large players pull services, impose migrations or change their pricing, and their size does not give you your freedom back the day it happens. Worse, the more a proprietary service is locked, the more a change of course becomes a project you did not choose. For the buyer, what makes longevity is the ability to leave, far more than the size of whoever hosts you.
What is an escrow clause and do you offer one?
An escrow clause places the elements needed to reclaim the platform into the custody of a trusted third party, who releases them to you if events defined in the contract occur. It is a safety net that complements technical reversibility. We are working to include it in our contracts; its exact wording is still being framed legally.
Will the launch price increase abruptly?
The launch price is named as such in the contract, so you know what to expect over time. And whatever happens to the price, reversibility leaves you the last word: being able to take your infrastructure back without a rewrite is the best negotiating leverage against an increase. The exact terms are still being framed legally.
How do I check a cloud provider's resilience before buying?
Ask five verifiable questions. Can I recover my data and redeploy elsewhere without a rewrite and without the provider's approval? Is the stack open-source and open-standards? Are security and the subprocessor chain published? Does the contract provide for escrow and clear pricing over time? What happens to my infrastructure if the provider stops? Written answers are worth more than a reputation.
Go further
Continuity that does not depend on us
The best longevity guarantee is being able to do without your provider. Let's talk through your continuity and compliance constraints.