CloudOps: Cloud Infrastructure on Hardware You Own

A mechanical spine: separate metal vertebrae, graffiti-tagged in red and blue, with cabling threaded along the whole length.
Our own mark, and a reasonable picture of a control plane: segments that stand apart, one cable running through all of them.

Infrastructure decisions still tend to end at the same fork. Rent from a public cloud and you get an API, a console, managed databases and a network you can describe in code — running on somebody else's hardware, at somebody else's margin, in somebody else's jurisdiction. Buy your own machines and you get the hardware, the margin and the physical control, along with all the work the cloud had quietly been doing for you.

The second path is the one most teams walk back from. Not because servers are hard to buy, but because everything around them becomes manual again: someone images the disks, someone remembers which host runs the database, someone writes the VLAN down in a document nobody opens. Hardware is the cheap part. The operating model is what costs.

CloudOps is our answer to that fork, and it is our own product — built and run by this team. It is a self-hosted cloud platform: a control plane you install over your own bare metal that provisions servers, virtual machines, databases, storage and networks in minutes, with the ergonomics you would expect from a public cloud.

Want to see it against your own setup? Tell us what you run and we'll walk you through it.

Request a demo

What it actually does

One multi-tenant control plane, used three ways.

  • MSPs and hosting providers run a fully isolated tenant environment for every client on shared hardware — separate consoles, separate networks, separate billing per organization.
  • Platform and infrastructure teams turn their own racks into self-service IaaS: developers get VMs, databases and storage on demand, while the team keeps the hardware and the audit trail.
  • Hardware owners list idle bare metal and let the platform handle provisioning, isolation and payouts.

The building blocks are the ones you would expect from a cloud, and each is a first-class object in the API rather than a script somebody maintains. The full set is on the products section of the site; the short version:

  • Compute — bare-metal servers and KVM virtual machines, Linux or Windows, each with a browser console attached.
  • Databases — managed instances, with provisioning, backups and monitoring handled by the platform instead of by a runbook.
  • Storage — ZFS-backed block volumes with snapshots and encryption, plus S3-compatible object storage.
  • Networking — private networks and security groups, encrypted overlay networking across sites, and site-to-site VPN gateways.
  • Bare-metal provisioning — network-boot and image physical servers from the platform, unattended or interactive. An empty rack becomes capacity without anyone standing next to it.
  • Identity and access — organizations with role-based access control, SSO, invitation flows and scoped API tokens that can be revoked one at a time.

Every change is a job you can read afterwards

This is the part that matters six months in, and the part that is easiest to skip when you build the same thing yourself. Nothing on the platform happens by hand on a machine. Every change runs as a tracked, auditable Ansible job, recorded with what ran, when, and against what.

There are no snowflake servers, because nothing was ever configured by somebody logging in and typing. That history also answers the question an auditor actually asks — never "is it secure", always "show me what changed".

Three surfaces, one API

The console, the REST API and the official Terraform provider are at full parity. Anything you can click, you can codify; anything you codify shows up in the console afterwards.

In practice that means servers, VMs, keys and security groups get described in main.tf, reviewed in a merge request like any other change, and converged by the platform — with the console left as the place you go to look, rather than the place where state quietly diverges from the code. API tokens are scoped and revocable, so a pipeline gets exactly the reach it needs and loses it in one click.

The marketplace

This is the piece with no real equivalent elsewhere. The marketplace lets you rent verified bare metal — GPU rigs, CPU-heavy boxes, storage nodes — from independent operators, with a 24-hour minimum and an SLA that covers downtime you did not cause. Rentals are billed separately at the price each provider sets and itemized on the invoice: your plan pays for platform capabilities, never for somebody else's hardware.

It runs in the other direction too. If you own racks with capacity sitting idle, you can list them, set your own price, and let the platform handle provisioning, tenant isolation and weekly payouts.

Worth being straight about where this stands: the marketplace is just opening and has no listings yet. If you have spare capacity, being early is the entire opportunity.

What it costs

There is no public rate card, and the reason is practical rather than coy — infrastructure footprints differ too much for one-size pricing. There are four packages, and the pricing page lays out what each one includes:

  • Starter — solo builders and home labs. One organization, bare metal and VMs, console, REST API and Terraform provider.
  • Team — teams on shared infrastructure. Multiple members with role-based access, managed databases, block and object storage, security groups and private networking.
  • Business — production workloads across sites. Multi-site overlay networking, site-to-site VPN gateways, PXE provisioning at fleet scale, full audit trail and job history.
  • Enterprise — custom requirements. Capacity through marketplace providers, dedicated onboarding, custom terms and invoicing.

Tell us what you run — how many servers, how many sites, how many people — and a quote comes back for the package that fits.

Two things worth knowing before you ask. You can bring your own hardware on every package: the tiers differ in team, networking and support capabilities, not in whose metal you run. And changing package tears nothing down — your servers, VMs and data stay exactly where they are, and only the capabilities around them change.

Who this is for

If you are renting cloud capacity you could own, and the bill has stopped looking like a rounding error, CloudOps is the way to move that workload onto your own metal without going back to doing everything by hand. If you already own racks and maintain the automation around them yourself, it replaces a pile of scripts nobody wants to inherit with a control plane that keeps its own records.

And if you have hardware sitting idle, it is a way to have it earn instead.

Want to see it against your own setup?

Tell us what you run — how many servers, how many sites, how many people — and we'll walk you through the platform against it, then come back with a quote for the package that fits.

Request a demo

Related articles

← Back to all articles