Introducing Triton Cloud

Triton Cloud is a new cloud platform built on illumos: zones, ZFS, and bhyve. It has been built from the ground up for operator and developer experience. It installs with one command. It provisions guests with private networking and public IPs, brings up its own DNS and TLS from first boot, and clusters S3-compatible object storage across nodes. Block and global filesystems are next.

It can also run on your own hardware, in your datacenter, as Triton Private Cloud.

This has been in progress for some time. The first commit was on March 27, 2026, but we've been experimenting with our eventual direction over the last two years. Today, we are introducing it to everyone.

If Triton is new to you

Triton is an open-source cloud platform. It has run production workloads for more than a decade, first at Joyent, then acquired by Samsung, and now Sovren Technologies (Edgecast), who took over Triton DataCenter, Manta, and SmartOS along with the customers running them.

It is opinionated in a way most platforms are not. The host operating system is illumos, which brings ZFS, DTrace, and zones. Virtual machines run on bhyve. Storage is ZFS all the way down.

Triton Cloud is the next generation of that platform. Same substrate, new codebase.

Triton Cloud is not Triton DataCenter with a new coat of paint. We've taken the experience of operating Triton—what worked well and what didn't—and applied that to the next generation, Triton Cloud.

Before we wrote it, we spent some time on what we now refer to as useful experiments. We designed a Rust rewrite. We planned a data-layer migration off Moray and Manatee. We ported individual services from Node.js to Rust. We built an S3 tier on the legacy Manta architecture, which is how we found where its ceiling was.

The most useful result was a negative one. A faster Moray is still Moray. Translating Triton service by service, even into a better language, produced a newer implementation of the same operating model. The operator's day did not change.

So we stopped translating and asked a different question: What does the person running this thing need to be able to install, understand, recover, upgrade, and trust? Designed backward from that, the answers looked nothing like a port.

Triton Cloud today

The control plane. One HTTP service, tritond, owns every piece of state and the entire API. One agent, tritonagent, is the only thing that touches a compute node. Everything else is a client of those two: the operator CLI, the tenant CLI, the admin console, and the tenant portal. State lives in FoundationDB, with ClickHouse for metrics.

Proteus. An illumos kernel module, written in Rust, built on Oxide's OPTE packet engine with our own driver and VPC plugin. It provides per-port flow tables, a distributed firewall, routing, NAT and floating IPs, a Geneve overlay, DHCP, and IMDSv2.

Manta. The storage substrate, rebuilt on FoundationDB and ZFS. S3-compatible object storage runs end to end and clusters across nodes. A POSIX filesystem ships as a Triton zone with alerts and a dashboard. Block storage is designed on the same foundation and is what the storage team starts next.

The whole thing installs with one command and updates with the same command. Every change we make ships to ourselves through the same signed release channel a customer would use, because an upgrade path is only trustworthy if we are on it.

What happens to Triton DataCenter

Nothing sudden. It is in production, we support it, and we keep shipping it for now. We will provide ample time for customers and will have a migration path for existing Triton DataCenter customers.

Triton Cloud is the next generation of Triton DataCenter. It runs on illumos and bhyve, on open hardware, with no per-socket licensing. We're here.