How we build

Open standards — a platform you can leave

Standard x86, open hypervisors, storage with published formats and a published API, configuration you can read. Leaving is possible, so staying is a choice. The argument, the trades it carries, and what we do so the option stays open.

• Standard x86 — Replaceable parts
• Open hypervisors — Proxmox VE, XCP-ng
• Open storage — SMB, NFS, iSCSI, S3
• No per-socket licence — On the open stacks
• Documented baseline — Firmware written down

The argument

A platform you can leave is a platform you can negotiate with

Most infrastructure decisions are made once and lived with for five to seven years. The question that matters at signature is not which platform is best today — it is what your position looks like in year four, when the renewal quote arrives and the alternative is a migration you have not budgeted for.

Open standards are how that position stays yours. Standard x86 servers, open hypervisors, storage whose on-disk formats and APIs are published, and configuration that is text rather than an appliance's internal state. None of it is exotic, and all of it means the same thing: leaving is possible, so staying is a choice.

This is not an argument that the global OEMs build bad machines. They build very good ones. It is an argument that a large part of what you pay them for is not the machine — it is the design decisions around it that make the next purchase, the next drive and the next renewal theirs as well. That is a commercial model, not an engineering one, and it is worth recognising as a choice you are making rather than a fact of the industry.

Where it shows up

What being open actually buys, layer by layer

• The hardware — Standard x86 with parts that are sourced rather than allocated — drives, PSUs, NICs and RAID controllers you can buy from more than one place, in a chassis that takes them.
• The hypervisor — Proxmox VE and XCP-ng carry no per-socket or per-core licence and no edition ladder. A support subscription is available and priced per node, and it gates no features.
• The storage — Published on-disk formats and standard services — SMB, NFS and iSCSI — so a pool is readable and mountable by software you did not buy from us. Object storage speaks the S3 API, which every archival tool already targets.
• The network — Ethernet and standard protocols, not a fabric that only one vendor's switches complete. The cable you buy next year fits the port you bought this year.
• The spares — A machine built from catalogue parts can be repaired from catalogue parts, in year six, when the original line has been discontinued twice.
• The data — Disk images in qcow2 or raw, configuration in text, backups in formats with more than one reader. Exit is an afternoon of copying rather than a project.

The other model

The global OEMs did not arrive at proprietary design by accident

A tier-one server is a standard x86 machine surrounded by decisions that make it theirs. The drive carrier is a shape you cannot buy elsewhere. The drive inside it may refuse to report health unless it carries their firmware. The RAID controller writes a layout their tools read. The management processor is capable, and the features you actually wanted — remote console, virtual media, the API — sit behind a licence tier bought per server. Memory, risers and power supplies are keyed or qualified so that the catalogue part will not do.

None of that is required to build a reliable server. It is required to make the server the beginning of a relationship rather than the end of a purchase. The engineering is real and often excellent; the design around it is commercial.

The cost shows up later, which is the point of it. It shows up when a drive fails in year four and the only source is the vendor at the vendor's price. When the support renewal is quoted against an estate that cannot be maintained any other way. When firmware you need to close a security advisory is behind an entitlement that has lapsed. And when end-of-support arrives on the vendor's calendar rather than on the machine's, and a fleet that still works becomes a fleet that must be replaced.

Where the money goes

The same machine, two commercial models

Not a claim that one is always right. A claim that the difference is decided at specification and paid for over five years.

• Drives — On a proprietary platform: Vendor carrier, often vendor firmware; replacement is sole-source. On an open one: Catalogue drives from more than one supplier, chosen for the duty cycle
• Management — On a proprietary platform: Capable controller, with the useful features on a paid licence tier. On an open one: Baseboard management standard on the platform, not sold back per server
• RAID and storage layout — On a proprietary platform: Proprietary on-disk format that the vendor's tools read. On an open one: Published formats and standard services, readable by software you did not buy from us
• Hypervisor — On a proprietary platform: Per-socket or per-core licence with an edition ladder above it. On an open one: Open hypervisors with per-node support and no feature gating
• Firmware and security fixes — On a proprietary platform: Commonly behind an active support entitlement. On an open one: Baseline recorded and shipped with the build
• End of life — On a proprietary platform: Announced on the vendor's calendar. On an open one: Decided by the workload and the spares you can still buy

• Where lock-in actually comes from Rarely from the hardware. It comes from the licence that counts sockets, so a CPU refresh is a commercial event. From a disk format only one product can read, so the data cannot move even though the servers could. From a management plane that owns the configuration, so rebuilding elsewhere means rediscovering decisions nobody wrote down. And from support terms: an entitlement that lapses and takes firmware access with it, or a contract that is void if a third-party part is fitted. None of those are technical barriers. They are commercial ones, engineered in, and they are why the renewal quote arrives with confidence behind it.
• What makes an estate movable A published on-disk format. Configuration that is text, in version control, readable a year after the person who wrote it left. Hardware whose parts have more than one source. Licences that do not count the things you are about to change. None of that is exotic and none of it costs extra at purchase. It is decided at specification and it is almost impossible to add afterwards, which is the entire reason it belongs in the conversation before the order rather than at the renewal.

The five-year view

How the position changes between signature and renewal

The arithmetic that decides whether a renewal is a negotiation or a formality.

• Year one — the platform is chosen — Everything is possible and nothing is committed. This is the only point at which exit cost is cheap to influence, and the only point at which nobody is thinking about it.
• Year two — the data settles — Formats, integrations and habits form around the platform. Exit cost stops being about the servers and starts being about everything wired into them.
• Year three — the estate grows on the same terms — Expansion goes to the incumbent because mixing is awkward. Each addition is rational on its own and the aggregate is a position.
• Year four — the renewal arrives — The quote reflects what moving would cost you, not what the service costs to provide. That is not cynicism; it is how any supplier prices a captive estate.
• Year five — the decision is made twice — Either the alternative is credible and the renewal is negotiated, or it is not and the renewal is signed. Open standards are what make the first sentence true.

Due diligence

Questions worth asking any vendor, including us

We answer these about ourselves further down the page. They are here because they are the questions we would ask, and because a page arguing for open standards should be willing to be measured by them.

• What is the on-disk format, and what else can read it?
• If we stop paying for support, what stops working — and does firmware access stop with it?
• Is the licence counted per socket, per core or per node, and what happens when we change CPUs?
• Can we fit a drive, NIC or PSU we sourced ourselves without voiding the contract?
• Where does the configuration live, and can we export it as text?
• Which parts of this system are you the only possible supplier for?
• What does moving away look like in practice — and has anyone done it?
• If your company were acquired next year, which of these answers would change?

Procurement

Why open stacks are easier to evidence in a tender

A public-sector tender asks what a system is made of, where it was made, and who can support it. Every one of those questions is easier to answer about a machine built from catalogue parts running published software than about an appliance whose bill of materials is a trade secret.

It matters after the award too. Component-level traceability is a documentation exercise when the components are nameable, and an impossibility when they are not. The same is true of the support question: an estate that more than one organisation could maintain is an estate a buyer can keep maintained, which is the thing the clause is actually for.

This is not an argument that open always wins a tender. Where a specification names a product, it names a product. It is an argument that the open answer is the one you can evidence quickly, and in procurement the speed of evidence is often the difference.

The honest version

What open standards cost you

A page that only lists advantages is marketing. These are the trades, and they are real — we run an estate on this stack and pay them.

• More decisions land on you — What it means in practice: A proprietary appliance makes choices its maker has tested. Open stacks hand those choices back — node counts, network sizing, drive selection — and an unconsidered choice is a real risk.
• Support is assembled, not single-throat — What it means in practice: Hardware from us, software from the project or its sponsor. It works when the boundaries are agreed in advance and it is worse when they are not.
• The ecosystem assumes competence — What it means in practice: The documentation is excellent and assumes you will read it. Teams without that appetite are better served by an appliance, and we will say so.
• Certification checklists sometimes name products — What it means in practice: Some tenders and audit regimes name specific proprietary platforms. Where that is the requirement, it is the requirement — we build for those too.

How we work

What we do so the option stays open

• Validated across five hypervisors — Every platform is validated for Proxmox VE, VMware ESXi, XCP-ng, Hyper-V and Nutanix AHV, so a hypervisor decision taken later is not also a hardware decision.
• Firmware baseline recorded — The BIOS and controller revisions a build was validated on are written down and shipped with it — the difference between an estate and a collection of similar machines.
• Build-to-order, not fixed SKUs — Configured to the workload rather than to a catalogue tier, so you are not buying a bundle to reach the one component you needed.
• Documented, not locked — Nothing we ship requires our software to run, and nothing about the way it is built prevents someone else from supporting it. That is deliberate.
• Built, tested and supported here — Integrated and manufactured in India, burn-in tested before dispatch, and covered by the warranty and response terms set out on the services page — the same for every machine we build.
• We run it ourselves — SpectraCloud, our own production cloud, runs on Proxmox VE across more than 800 physical servers. The argument on this page is one we have already bet our own infrastructure on.

Where to look next

The open stack, page by page

The argument, made concrete.

• Proxmox VE platforms — The cluster shapes we build, from the 800+ hosts we run on it.
• Software-defined storage — What SDS moves into software, and what it moves onto your nodes.
• Spectra Object Storage — S3 to 4PB, erasure coded, hardware and software both made in India.