Skip to content
Closed Private Alpha

Our cloud. Your metal.One control plane.

Run workloads on hardware you control. Burst or fail over to ours when needed. The same dashboard, CLI, config, and primitives.

Requests arrive from the internet at the Unisrv edge, which routes them either to instances running on Unisrv cloud hardware or, across a private mTLS tunnel, to instances running on hardware you own.

Your hardware,without the hard part.

Connect your own compute nodes and they plug straight into the Unisrv control plane. It doesn't matter whether you're running on our infrastructure or yours.

Your nodes dial out to the proxy edge, and requests come back down that private mTLS tunnel. Nothing to port forward, and it works behind shared NAT. Fall back to our capacity when you need it, or run entirely on your own metal.

No matter where, we run all containers inside Firecracker microVMs for strong isolation.

Your node and the Unisrv edge are joined by a private link secured with mutual TLS 1.3. Your IP stays private and your nodes stay off the public internet.

Your homelab

Protected networking keeps your IP private. Unisrv handles edge routing and TLS. You deploy.

Your datacenter

Full data sovereignty on your own infrastructure. Run multi-region private clouds on racks you already own.

Declarative by default.

Define your infrastructure in a single unisrv.hcl file. Services, deployments, networks. A few simple primitives that compose into anything.

unisrv.hcl
project = "unisrv-io"

service "unisrv" {
  hosts = ["unisrv.io"]

  location "/" { deployment = "web-ssr" }
}

deployment "web-ssr" {
  port = 8080
  container {
    image = "ghcr.io/unisrv/unisrv-io:latest"
  }
}

Simplified version of this page's declaration. Of course we self-host :)

terminal
unisrv up
  + service    unisrv    unisrv.io
  + deployment web-ssr   ghcr.io/unisrv/unisrv-io:latest

Summary: 2 to add, 0 to change, 0 to destroy.
Apply these changes? yes

   https://unisrv.io

The control plane reads this file, compares it to live state, and acts on the difference.

Simple primitives. Any architecture.

A Service routes external traffic. A Deployment runs instances of your containerized code. Compose them into anything from a single API to a multi-tier application.

Traffic from the internet reaches a service on api.example.com. The service routes the path / to the frontend deployment, which runs one instance, and the path /api to the backend deployment, which runs three. Over an internal private network the backend reaches a redis deployment of one instance and a postgres deployment of two — a primary and a replica, each with a volume.

What you getout of the box.

Declarative-first

The Kubernetes operator model without a cluster to run. Core primitives reconcile desired state against live state and react to changes.

Ephemeral environments

Spin up per-PR preview environments, or per-agent environments for AI development. Every branch gets its own isolated stack that expires on a TTL and scales to zero.

Built-in observability

Logs, HTTP metrics from the edge (response codes, latency), and instance-level resource usage (CPU, memory). All collected automatically.

Automatic TLS

Point your domain at Unisrv and certificates are provisioned automatically via Let's Encrypt. Or grab a .unisrv.dev subdomain instantly.

Private networking

Private networks with built-in service discovery across deployments. Multi-region support included.

Firecracker microVMs

Every instance runs in its own Firecracker microVM. You get container convenience with real VM-level isolation.