Managed Kubernetes on bare metal · now in New York

Kubernetes on servers of your own, without babysitting the control plane

You bring the workloads and choose the machines. We keep the cluster's brain running: the control plane, its database and its backups. Every node underneath is a whole physical server with nothing virtual in the way, and the bill for it is the same every month.

The trade

What you stop worrying about, and what you never give up

You stop

  • Running the control plane. Its servers, its database and its backups are our job, on one node for testing or three for a cluster that must stay up.
  • Paying for a virtual layer. Your containers run on the server's own hardware, so none of it is spent on a hypervisor or shared with a stranger.
  • Watching an egress bill. Nodes are flat monthly servers; nothing charges you per gigabyte that leaves.

You keep

  • The keys to every node. Root SSH, the console and rescue mode stay on each server, which many managed Kubernetes offers take away.
  • Your own public addresses. When an app asks for a load balancer, it is given one of the extra IPv4 addresses on your own node servers.
  • The freedom to leave. It is standard, open-source Kubernetes, so what you build here runs anywhere else Kubernetes does.

From order to running apps

A cluster's life, in five steps

  1. Order it online

    Name your cluster and pick its servers on the order page, then pay the first invoices. Unsure about something? Our AI in the chat replies in seconds, and a person from our team takes over whenever you ask.

  2. Pick the size of the brain

    One control-plane node for development, or three for high availability. Either way its database is copied to a snapshot every six hours.

  3. Pick the servers that do the work

    Tick between one and ten of the New York servers ready today. They arrive just as they sit on the shelf, already running Ubuntu, so nothing is reinstalled, there is no setup fee, and you can add more later, up to ten. They all land in one group tagged pool=general. Want GPU machines to take only GPU jobs? You are the cluster's admin: tag and fence them off yourself with kubectl.

  4. Download the kubeconfig and deploy

    Use kubectl, Helm or whatever you already use. Cilium enforces your network policies, a firewall on each node lets in only your own cluster's machines, and MetalLB puts public addresses in front of your services. Need traffic between services encrypted? Add TLS to your apps or run a service mesh.

  5. Upgrade when it suits you

    You press the button. The control plane moves to the new version first, then each node in turn, one at a time.

Straight talk

Who this suits today, and who should wait

A good fit

  • Teams whose apps run all month and would rather pay a steady bill than an hourly meter
  • AI inference or rendering that wants GPU servers beside ordinary ones in the same cluster
  • Anyone who wants Kubernetes but also wants to log in to the machines underneath
  • Workloads with users near New York

Better to wait

  • You need clusters in several cities now: we are starting in New York only
  • You need published uptime figures before you sign: we will not quote any until our clusters have earned them
  • You need a private, encrypted network between the nodes: there is none, so node traffic crosses public addresses and your apps bring their own TLS
  • You want one small machine rather than a cluster: a Cloud VPS is the simpler answer
  • You want to run Kubernetes entirely yourself: our bare metal for containers is ready for that today

FAQ

Questions about Kubernetes on bare metal at Primcast

What does "managed" mean here?

We look after the part of Kubernetes that makes the decisions: the API server, the scheduler and the etcd database, including a snapshot of that database every six hours. You look after your apps, and the worker servers stay under your control.

Is it real Kubernetes or a lookalike?

Real, upstream Kubernetes, packaged by the RKE2 distribution, which conforms to the CNCF's Kubernetes standard. Kubernetes itself is open source under the Apache 2.0 licence, so nothing you build ties you to us.

Can I still log in to my servers?

Yes. Each node is one of your dedicated servers, and you keep root SSH, the console and rescue mode on it while it serves the cluster.

Will my apps get public IP addresses?

Yes. MetalLB hands a Service of type LoadBalancer one of the extra IPv4 addresses on your own node servers. Between the nodes there is no private network: they talk over their public addresses on our network, and each one's firewall lets in only your cluster's own machines. The cluster does not encrypt that traffic, so if your services must talk privately, give them TLS or mTLS, or run a service mesh.

Can I put GPU servers in my cluster?

Yes, when one is in New York stock as you order: you choose every server yourself. All nodes start in the same group, tagged pool=general. Put your own label and taint on the GPU machines with kubectl and ordinary workloads stay off them, while the jobs that need a GPU ask for it.

When can I start, and where will it run?

Today, in New York. Order on the website, pay the first invoices, and the cluster puts itself together; you download the kubeconfig from your dashboard when it is ready. Each node is billed as the dedicated server it is, with no setup fee: it comes from stock already running Ubuntu 24.04 or 26.04.

Ready to build your first cluster in New York?

Ordering takes a few minutes: pick the brain, name the cluster, tick the servers you want as nodes and pay. Rather talk it through first? The chat answers straight away, and the contact page lists every other way to reach us.

Order your cluster

Curious about the machines first? Browse the servers nodes are made of.