NEXUS

One console, however many data centres

Your primary site, your DR site and whatever comes after them: each added from a form, all run from one place, with the same compute, storage and networking in every one. All of it on infrastructure you own, and none of it dependent on anybody else’s.

A multi-region private cloud platform, for teams who would rather own than rent.

The economics and the control of your own hardware, without asking your team to live in an administrator’s console built for somebody else. Nexus runs on infrastructure you own, in your own racks, and puts every region you run behind one sign-in — with the failover, the access model and the day-to-day console that a bare infrastructure layer leaves you to build for yourself. Deploy, manage and scale from one place, with nothing leaving your building.

Everything in one place

Compute
Block storage
Object storage
Networking
Images
Identity

See it before you talk to us

Nine chapters, no sign-up

A guided tour of the real console, running in your browser. It plays on its own, or you can drive it — jump to a chapter, and it stops and waits.

Signing in, and the console your teams land in
Adding a second region from a form
A seven-step DR failover, step by step
The AI assistant turning a sentence into a checked plan
IAM, compute, storage and networking

Open the console tour

Sample data — every name, address and figure on those screens is invented for the demonstration. Nothing to install, nothing to sign into.

The additions

Five things set Nexus apart

Everything underneath behaves the way your team already expects it to. These five are what sits on top.

Clusters

Add a region from a form

A label and an identity endpoint, validated against a live handshake before it saves — so a typo fails in front of the person who made it, not at somebody’s next login. A second site is live in under a minute, and a third is the same form again.

DR migration

Seven auditable steps

A failover that keeps the machine’s MAC and private IP, adopts the already-mirrored volumes instead of copying them, and flags the one step that cannot simply be run again — before you start it.

AI assistant

Plain English to a checked plan

Describe the machines you want. It matches the size to the CPU and memory you asked for, resolves the image and network by name in your own catalogue, writes the first-boot setup, and shows your quota headroom before and after. Nothing is created until you confirm.

IAM policies

Allow-list, AWS vocabulary

A policy grants a principal an action on a resource, and anything not granted is implicitly denied — the AWS vocabulary most people already know. A shared platform accumulates forty instance sizes; each team sees the two it uses.

The console itself

Light, dark and ⌘K

A command palette that searches instances, volumes, security groups and panels at once. Light and dark are a per-user setting, not a deployment-wide one.

Standard foundations

Nothing core is modified

Compute, storage, networking, images and identity work the way engineers already expect, on standard APIs your existing tooling speaks. Skills, runbooks and API clients carry over unchanged.

The hard part

Disaster recovery a person can follow

Most DR plans are a document nobody has rehearsed. This one is seven named steps on a single screen, and the console is candid about the one you cannot simply run again.

Because the volumes are already mirroring, a 540 GB database moves in the time it takes to demote one image and promote another — and the primary is stopped, never deleted, so fail-back is a supported path rather than an act of faith.

Where the custom work sits

The reason this does not become a fork you have to maintain

What building this yourself usually costs

A patched dashboard, and a merge conflict at every release you try to take
A second region is a config edit on every node, then a restart
Failover is a runbook, and it is only as good as whoever is awake
You drift further from the mainstream every release, and wait on one vendor for a security fix

Where Nexus puts the work instead

New console panels on top of unmodified services, so upgrades stay routine
A form, validated against a live identity handshake before it saves
Seven ordered steps, timestamped, with the irreversible one flagged
You stay on the mainstream, and a security fix reaches you when the project ships it

How it arrives

Standard foundations, and no lock-in

Nexus is a NubeStack product, installed and run alongside the private and hybrid cloud work we already do — and built so that leaving is a decision you keep the right to make.

Self-hosted
Your hardware, your data centres
It runs on your hardware, in your own racks, behind your own sign-in. Nothing leaves your building, and nothing about it depends on reaching us.
Standard
Nothing core is modified
Everything Nexus adds sits on top of unmodified services, so an upgrade stays an upgrade rather than a merge — and a security fix reaches you when the project ships it, not when a single vendor gets round to it.
Supported
The people who built the platform run it
The engineers who stand your cloud up are the ones who maintain the console on top of it. Your existing runbooks, skills and API clients keep working throughout.

Common questions

Worth asking early

What is it built on, and are we locked in?

Nexus is built on mature, widely used open infrastructure — OpenStack — rather than a proprietary stack of our own invention, and none of it is forked. Compute, storage, networking, images and identity are the standard components, unmodified, and the APIs are the standard ones your existing tooling already speaks. Everything Nexus adds sits above them as additional console panels. That is why an upgrade is something you take rather than something you merge, why a security fix reaches you when the project ships it, and why your engineers’ skills and runbooks keep working.

How many regions can one console manage?

Regions are added from the console rather than compiled in, so the third is the same piece of work as the second: give it a label, point it at its identity endpoint, and the console validates the handshake before it saves. The tour shows two, because two is where disaster recovery starts to mean something.

What can the AI assistant actually do?

You type a sentence — three web servers, 4 GB RAM and 2 vCPU each, Ubuntu, on the private network, install nginx — and it returns a plan: a matched instance size, an image and network resolved by name against your own catalogue, the first-boot setup written out, and your quota headroom before and after. It creates nothing. Because every name is resolved against the real catalogue first, a typo comes back as a message rather than a half-built stack you have to unpick.

Does the IAM layer replace the platform's own access control?

No — it sits alongside them. Policies shape the catalogue: what each team is shown and can pick from, expressed in AWS IAM’s vocabulary of a principal, an action and a resource, with an implicit deny for anything not granted. The access controls that govern the API underneath stay exactly where they are, so the two reinforce each other rather than one standing in for the other.

Can we see it against our own environment?

Yes. The tour is sample data by design, so the next step after it is a walkthrough against something real — either a lab we stand up or the infrastructure you already run. That conversation is the right place for the specifics of your estate.

Take the tour, then tell us what your estate looks like

Nine chapters will tell you whether the console is the shape you want. After that the useful conversation is about your regions, your hardware and what your DR position actually is today.

Book a call Open the console tour