AppRafter

An opinionated, vertically integrated Platform-as-a-Service on Kubernetes.

One Application manifest, designed to run unchanged from a €5 VDS to multi-node production — an open-source core, with an optional managed cloud on top.

---

Status: pre-1.0, under active development. The single-node Tier 1 MVP (milestone M1, the v0.1.x series) has shipped; multi-node tiers, the platform services, and the managed cloud are in active development. spec.md (its Revision line) and plan.md are the source of truth — this README states what runs today versus what is on the roadmap.

What it is

AppRafter fills the gap between a hosted PaaS and vanilla Kubernetes:

• Hosted PaaS — easy to start, but tied to one vendor, costly at scale, and not self-hostable.
• Vanilla Kubernetes — portable and scalable, but the cognitive load is high and the ecosystem is fragmented.
• AppRafter — one Application manifest, four hardware tiers, GitOps as the only control surface, and no vendor lock-in at any layer. Deploy via Argo CD and the apprafter CLI, with destructive operations gated by a MigrationPlan CRD rather than an unguarded kubectl delete. (An MCP interface — letting an AI agent drive deploys through the same gate — is on the roadmap.)

The platform is deliberately opinionated — one proven component per slot (e.g. Cilium for networking, Argo CD for GitOps) — so there is a single, well-trodden path instead of an assembly project.

Two products, one platform

AppRafter is an open-source platform first, with a managed cloud as a second product built on top of the same core — not a premium fork of it.

1. Open-source core — self-host

Everything required to run the platform is open source and free to run on your own hardware or in your own cloud: the Rust operator and its CRDs, the apprafter CLI, the developer portal, the platform services, and observability. The managed cloud adds only a thin convenience layer on top — a self-hosted cluster is fully functional without it.

Shipped today is the single-node Tier 1 control plane: apprafter provisions a Hetzner VDS, bootstraps the cluster (Cilium, upstream Gateway API, the AppRafter operator, Argo CD, cert-manager), and the operator reconciles your Applications through GitOps. Multi-node tiers and the needs-based platform services (Postgres, Redis, and more) are landing per plan.md.

Licensed under FSL-1.1-Apache-2.0 (see License).

2. Managed cloud — on top (in development)

For teams who would rather not run the ops themselves, a managed cloud is in development. Its defining design choice: your cluster, control plane, operator, and all your data always stay on your own infrastructure. The managed side hosts only a thin layer on top — the Backstage portal, an account UI, and a hosted MCP endpoint.

Two properties follow directly from that architecture:

• Anti-vendor-lock by design. Because the cluster will be a standalone open-source install on your own infrastructure, canceling the subscription leaves it running by design — you lose only the hosted convenience layer, with no migration required.
• Minimal Data Exposure. The managed services are designed to see only metadata — manifests applied, status and audit events — never the data in your databases or your secret values.

The managed cloud is planned at three levels of increasing scope — Hosted Services (the launch plan) → Managed Operations → Turnkey Cloud — billed per cluster. A waitlist opens at launch.

A hardware tier (the compute substrate, T1–T4) and a managed plan (how much of the operations we run for you) are two independent axes — any tier can run self-hosted or under a managed plan.

Tier model

The dev-facing API is identical across tiers; moving between tiers is a platform operation, not a manifest rewrite. Tier names denote the compute substrate only.

Tier	Substrate	Typical use	Status
1 · Solo	Single VDS (Hetzner CX/CPX-class)	Side-projects, solo founders	Implemented
2 · Small team	3+ heterogeneous nodes (HA)	Growing teams, production	In development
3 · Production	Bare metal (dedicated EPYC, Talos)	Established products	Roadmap (Phase 5)
4 · Regulated	External hyperscalers (AWS / GCP / Azure)	Regulatory / sovereignty needs	Roadmap (Phase 6)

Confidential containers (Kata-CC on TDX / SEV-SNP hardware) are a planned orthogonal opt-in capability — available on any tier whose hardware supports it, not a tier of their own.

Under the hood

Boring, proven components, plus a thin layer of our own code only where no ready solution exists.

• Components the platform standardizes on (one per slot): Talos Linux, k3s + Cilium (eBPF networking), Argo CD (GitOps), CloudNativePG, Dragonfly (Redis-compatible), ClickHouse, NATS JetStream, Backstage, cert-manager, external-dns, KEDA. Secrets use SealedSecrets on Tier 1 and OpenBao on Tier 2+; control-plane storage is kine (SQLite on Tier 1), with a NATS JetStream backend and a replayable audit log as the Tier 2+ target.
• Written here, shipping today: the Rust operator on kube-rs (reconciling Application, MigrationPlan, PlatformStack, and SourceCredential), a Rust admission webhook enforcing cross-field invariants the CRD schema can't express, the apprafter CLI (provisioning, bootstrap, lifecycle), the MigrationPlan reconciler that gates destructive changes behind explicit approval, and the ResourceClaim / ServiceProvider primitives with the provisioner behind needs.pg, needs.redis and needs.disk. CUE is the design-time schema layer (schemas/), checked with cue vet.
• Designed, landing per the roadmap: the MCP server with its agentic-safety gate (managed track), and the AccessGrant access model, which is understood but not scheduled — see Feature status for what is built and what each phase carries.

Repository layout

Directory	Contents
cli/	apprafter — Rust CLI for provisioning, bootstrap, lifecycle
operator/	In-cluster Rust operator and admission webhook (kube-rs)
schemas/	CUE schemas for every CRD
providers/	Built-in ServiceProviders (Postgres, JetStream, ClickHouse, Redis, S3)
backstage-plugins/	TypeScript plugins for the developer portal
platform-stack/	Platform Helm / CUE charts distributed to clusters
argocd-cue-cmp/	Argo CD config-management plugin for CUE app repositories
manifests/	Base platform manifests (Tier 1 today)
landing/	Project website (Astro + Payload CMS)
docs/	TechDocs sources, ADRs, visual assets
examples/	Reference Applications and golden-path templates

Quick start

Get the apprafter CLI onto your PATH — the release binary is the normal path, no repository checkout required:

curl -fsSL https://apprafter.dev/install.sh | sh

The installer picks the build for your platform, verifies the release checksum before installing anything, and refuses rather than installing something it could not verify. Read it first if you prefer — curl -fsSL https://apprafter.dev/install.sh -o install.sh, then sh install.sh. Archives, checksums and the target list are at apprafter.dev/download.

With a cluster running, shipping an application is three commands and one manifest:

apprafter app scaffold     # writes apprafter/Application.cue for the repo you are in
apprafter app validate     # checks it against the platform schema, locally
apprafter app add          # registers it; Argo CD deploys it and keeps it synced from Git

Standing up the cluster itself (provision a Hetzner VDS, bootstrap the platform) is covered end-to-end in the operator quickstart.

Full operator and developer documentation:

• Operator quickstart — provision and bootstrap a Tier-1 cluster.
• Platform management — PlatformStack lifecycle, channels, upgrade and freeze.
• Migration plans — approve and reject destructive-change gates.
• Private repos & registries — registering the credential Argo CD clones with and the node pulls with.
• Writing Application.cue — the CUE manifest format, CMP, and multi-environment patterns.
• Feature status — every user-facing feature, its status, and the phase it lands in.

Development

Working on AppRafter itself (not just deploying to it) starts from a checkout:

git clone https://github.com/AppRafter/apprafter
cd apprafter
nix develop          # or open in the VS Code Dev Container
just bootstrap       # install local Git hooks
just lint            # CUE + SPDX + cargo + bun checks
just e2e-up          # local k3d cluster

Three setup paths (Nix flake, Dev Container, manual via mise) are documented in the contributing setup guide.

License

AppRafter is open core:

• Platform core (cli/, operator/, schemas/, manifests/) — FSL-1.1-Apache-2.0: the Functional Source License, which auto-converts to Apache 2.0 two years after each release. It permits any use — personal, internal business, and commercial workloads — except offering AppRafter itself as a managed service to third parties. Once a release reaches its two-year conversion date, that restriction lifts.
• Plugins (providers/*, backstage-plugins/*, community SDKs) — MIT from day one.
• Documentation (docs/) — CC-BY-4.0 for prose, Apache-2.0 for code samples in guides. See Licensing.

See LICENSE, LICENSE-APACHE, LICENSE-MIT, LICENSE-CC-BY-4.0, NOTICE, and ADRs 0001 (original FSL choice) and 0032 (current core license) for the rationale.