Greffon: an open-source, self-hosted deployment platform

Deploying applications today usually means choosing between two poles. On one side, managed platforms — Heroku, Railway, Render — that democratized deployment at the price of metered bills, vendor terms, and zero say over where your data lives. On the other, Kubernetes: the industry standard for good reasons, and a multi-year operational commitment for teams that should be shipping features, not staffing a platform group.
Greffon sits in the rational middle. It is an open-source platform for deploying containerized applications — greffons, French for grafts — onto infrastructure nodes you own — greffers, the rootstock they graft onto. One control plane, any number of workers, no vendor in the loop.
Think of it as a self-hosted Heroku: publish a Docker Compose template, configure an instance, and let the platform handle orchestration, TLS and lifecycle on your own machines.
What Greffon solves
The managed-platform trap. PaaS pricing scales with your success, and sovereignty is not on the menu. Acceptable for a prototype; untenable for organizations with data-residency, compliance or budget constraints.
The Kubernetes mountain. “Run Kubernetes” is not an answer for most teams. It is an API surface to learn, networking to debug, upgrades to manage, and a dedicated team to staff.
The gap between them is where most organizations actually live: teams that want push-button deployment without hosted dependencies, and infrastructure that already exists — on-premises, or at European providers like Scaleway, OVH or Clever Cloud — waiting to be put to work.
Greffon is built for that gap: deployment for people who own their infrastructure and intend to keep it that way.
Architecture: boring by design
Your browser
│
Manager frontend (React)
│
Manager backend (Django) ── built-in certificate authority
│ mTLS
Greffer nodes (FastAPI) ── Docker Engine · Nginx per-instance TLS
│
Your applications (Docker Compose)
The manager backend is the control plane. It holds the catalog of deployable applications, authenticates users, orchestrates instance lifecycle, and issues certificates through a built-in certificate authority — no external secrets manager to bootstrap first.
The manager frontend is the dashboard: browse the catalog, configure an instance, start it, stop it, read its status.
The greffer is a lightweight agent on each of your nodes. It registers with the manager over a secure handshake and installs mTLS certificates for every exchange that follows. When told to start an instance, it fetches the Docker Compose template, renders the configuration into it (Jinja2), creates volumes and networks, brings the stack up, fronts it with a per-instance TLS reverse proxy (Nginx), and reports health back asynchronously. One greffer can host many instances side by side.
The design is deliberately boring. Each component does one thing; each can be upgraded or replaced alone. Greffers are cattle, not pets — if a node dies, the instance restarts elsewhere, because the manager holds the configuration and the worker is just a runtime. And the asynchronous status reporting tells you the real story of a partially failed fleet instead of the false confidence of a synchronous API.
A deployment, in practice
- Curate a catalog. Docker Compose templates live in a Git repository, each with a declarative schema of what the user may configure — domain name, credentials, sizing.
- Register a greffer. Provision any Linux box — bare metal, VM, cloud instance — and install the agent. It registers itself with the manager.
- Deploy. A user picks an application from the catalog, fills in the configuration, clicks deploy. Certificate issued, command sent, template fetched and rendered, containers up, HTTPS on.
- Operate. Start, stop, status — from the dashboard, with the greffer pushing state changes back as they happen.
No Helm charts, no admission controllers, no ingress DSL. Docker Compose and a config schema.
Open source, precisely
Two components are public today:
- greffer — the worker agent (Python, FastAPI), licensed AGPL-3.0: the network-copyleft license that keeps hosted derivatives open while leaving self-hosted use unrestricted.
- greffon-catalog — example application templates (TypeScript), licensed Apache-2.0, so catalog templates can be reused anywhere without friction.
The licensing split is intentional: strong copyleft where the platform’s value lives, permissive where adoption should be effortless.
Who this serves
Hosting providers. Today you sell VPS or managed Kubernetes. Greffon suggests a third product: a white-labeled control plane and pre-configured greffer images, so customers deploy applications without leaving your ecosystem — PaaS revenue without building a PaaS.
Organizations with constraints. Data residency, auditability, compliance. Greffon runs on your hardware under your control, and certificate issuance is transparent and deterministic — handled by your own CA, not a third-party service.
Small teams. Deploy like a managed platform, own like self-hosted — without hiring a platform group first.
Roadmap
- M1 — reliability of the core: Django control plane, built-in CA, stable orchestration API. This is where the beta stands.
- M2 — production hardening: the greffer’s recent migration to FastAPI unlocks async operation and WebSocket support; next come step-ca and Let’s Encrypt integration for the CA, reverse tunneling for greffers behind NAT, and structured observability (metrics, logging).
- M3 — scale: PostgreSQL for the control plane, generated OpenAPI schemas, capacity testing, multi-worker scheduling.
Each milestone closes real operational gaps before the next opens.
Where it stands
Greffon is in beta and live at greffon.io. The worker and the catalog are open today; the platform matures in the open as the beta hardens. If you deploy applications, run infrastructure, or build hosting products, it is worth your attention now — and if you want to talk integration, distribution or contribution, write to contact@greffon.io.
Greffon is built at Samouraï Coop, where the engineering studio ships the platforms and the film crew documents the work. Self-hosting is not nostalgia here; it is the position that organizations should own their deployment pipeline the way they own their code.