Closed beta

Kubernetes-grade deploys. None of the Kubernetes.

CheesyServe is a deployment platform on Talos Kubernetes, with self-hosting on the roadmap. Push an image to any registry, define a workload, and the operator handles HA, isolation, and routing — public or strictly internal.

HTTP · gRPC · WebSockets
cheesyserve — deploy
$ docker push ghcr.io/acme/api:1.4.0
pushed · sha256:9f1c…a20e
$ cheesy workload apply api.yaml
project payments · env production
exposure internal · replicas 3 · pdb enabled
✓ reconciled in 11s — 3/3 healthy
AvailabilityMulti-node
ReachTailnet
TenancyIsolated
The ceiling
Docker-based platforms are simple until they aren't.

No real multi-tenancy, limited high-availability guarantees, and no native path to Kubernetes-grade resilience once your team outgrows a single box.

The floor we set
A pod in a cluster is not automatically highly available.

Spread constraints, disruption budgets, probes, graceful draining — CheesyServe encodes those defaults so a hardware failure doesn't become dropped requests or lost data.

How it works

Four steps, no cluster surgery

01
Push your image

Build however you like, then push to any registry — Docker Hub, GHCR, or your own.

02
Define a workload

Image, scaling, exposure method. Grouped into projects and environments.

03
The operator reconciles

Desired state becomes the right K8s resources, with resilience defaults applied.

04
It's running

Publicly over HTTPS, or internally with AWS VPC and Tailnet bridges.

Features

Built for teams that outgrew Compose

Self-hosted
Planned

Run it on your own infrastructure and own your data end to end. Packaging for self-hosting hasn't started yet.

K8s-native, Talos-based

An immutable, minimal OS purpose-built for Kubernetes — not Docker Swarm.

Bring your own image

CheesyServe never builds your app. Push to any registry — Docker Hub, GHCR, or your own — and deploy.

Multi-tenant clusters

Several teams share one cluster with proper isolation and lower overhead.

Internal services first-class

Deploy workloads that are never exposed to the public internet.

Private network bridges
Cloud Planned

Reach internal workloads from an AWS VPC or your Tailnet — no public endpoint. Planned for a later iteration.

Architecture

Seven parts, one control plane

Kubernetes clusterTalos-based cluster running platform and workloads
Web UIManage projects, workloads, environments
Web APIREST API behind the UI and CLI
OperatorReconciles desired state with the cluster
CLITerminal control of the whole platform
Terraform providerPlanned — infrastructure as code
Concepts
WorkloadThe minimum deployable unit — a web API, a frontend, a background worker.
ProjectA logical group of workloads belonging to one team or application.
EnvironmentA deployment target — staging, production — scoped to a cluster namespace.
Scope: HTTP/HTTPS, gRPC and WebSockets. Other protocols are out of scope.
Tiers

Self-hosted and cloud, on the roadmap

Self-hosted packaging hasn't started yet. The cloud tier's core is what we're building first; the AWS and Tailnet bridges are planned for a later iteration.

Feature
Self-hosted · planned
Cloud
Core deployment
Planned
Included
Internal services
Planned
Included
Multi-tenant clusters
Planned
Included
AWS private network bridge
—
Planned
Tailnet access bridge
—
Planned