Introduction
High is a deploy-anywhere platform. Point it at a repository and it builds an image, runs it wherever you choose, and stitches every running piece into one private network — no matter where each piece physically lives.
What High does
Most platforms make you pick a home: one cloud, one cluster, one region. High doesn't. You give it a repo; it builds a multi-arch image and runs it on the target you name — managed cloud Kubernetes (EKS, GKE, AKS), a plain VPS, a homeserver, or a Raspberry Pi on your desk.
The headline is what happens after things are running. High joins every component into a single, per-tenant private overlay network. Your API on EKS, your database on a Pi at home, and a worker on a VPS all talk to each other privately — as if they shared one LAN.
Everything you deploy is a release — a specific build, run with a specific config, on a specific stage. Read Core concepts once and the rest of these docs will click.
The two surfaces
You only ever touch two things. Everything else — building images, rendering the internal manifest, reconciling, wiring the network — is derived for you.
- The web console. A dark control surface: a catalog of projects on the left, live deployment status in the middle, and an integrated chat dock on the right.
- Your own MCP client. The same operations exposed as tools, so an agent — or you, from your editor — can drive High directly. See MCP & chat.
How a deploy flows
A deploy is a short pipeline. You rarely run these steps by hand — the console and MCP do it for you — but knowing the shape helps when something needs attention.
- Project — a name and a git URL.
- Build — an immutable image rendered from a commit.
- Config — the reusable, versioned settings a workload runs with.
- Release — build × config × stage, rendered to a manifest and reconciled onto your outposts.
When a release converges, its stage reports ready. When it can't, you get a specific, actionable reason — not a stack trace.