A governed runtime for coded apps. You write an app (or an agent writes it for you), you describe it in a
short telperion.yaml, and Telperion gives it a host, single sign-on, a database, and, when you ask for
it, a bounded identity in Laurelin so the app can read and act on
Laurelin's ontology as the viewer, and only within what the contract declared.
Telperion never requires Laurelin. An app with no backends block runs on Telperion alone.
Pre-alpha. Milestone 1 (the proof plus the security core) is being built. The design that governs the
build is docs/designs/telperion.md; durable decisions are in docs/adr/; the module map is in
ARCHITECTURE.md. Installing it, on one host or on Kubernetes, and how to supply and rotate every
credential, is docs/OPERATIONS.md, which opens with the two topologies and what each costs to run; setting up the identity provider it signs people in with is
docs/idp/keycloak.md or docs/idp/authentik.md.
telperion.yaml ──► POST /apps ──► [registering] ──► provision ──► client ──► start ──► mount ──► probe ──► [live]
└────► [failed] (FailureCode, Phase)
- One host per app under an apps domain (
fleet.apps.example.org); the control plane on its own domain. - Viewer identity by forward-auth: every request carries a short-lived
X-Telperion-UserJWT the app verifies against Telperion's JWKS. - A Laurelin-linked app is its own OAuth2 public client in Laurelin with scopes derived from the contract; Laurelin issues the tokens, Telperion never holds a Laurelin credential.
- Postgres per app, provisioned by a role that can create databases and nothing else.
See ARCHITECTURE.md. Short version: telperion/core (models, failures, carried auth), telperion/api
(routes for the two entry points, telperion-auth and telperion-control), telperion/registry
(store, lifecycle, bundles), telperion/adapters (storage, backends), telperion/proxy (Caddy and
Ingress renderers), telperion/runtime (compose and Kubernetes), telperion/sdk, telperion/cli.py.
SECURITY.md states what Telperion enforces, what is deliberately not a boundary
(registering an app is running code on your infrastructure; the compose stack is a development stack),
which versions get fixes, and how to report a vulnerability privately. Four modules are carried from
Laurelin, so some reports belong upstream; SECURITY.md says how to tell.
Do not open a public issue for a security bug. Use GitHub's private vulnerability reporting (Security → Report a vulnerability).
Versions come from git tags (ADR-0015); telperion --version reports the version with the commit and
build date of the build in front of you. CHANGELOG.md records every release, and CONTRIBUTING.md
("Releases") has the tag ritual.
Telperion is used by its author's employer and is not owned by it. Design
decisions are made in the open, in docs/adr/, on the same terms for everyone;
no deployment, including that one, gets a decision the tree does not record and
the public cannot read. Where an employer's need and the project's design
disagree, the disagreement is argued in an ADR like any other, and the employer
carries a fork or a configuration rather than the project carrying an
unexplained special case.
MAINTAINERS.md names the maintainer, says how a durable
decision is made and recorded, and states the release cadence.
CONTRIBUTING.md has the rules a PR has to meet: an ADR for
anything that changes the design, a changelog line for anything an operator can
see. CODE_OF_CONDUCT.md applies everywhere the project
happens.
Apache-2.0. Four modules are copied from Laurelin under the same licence; docs/CARRY-OVER.md lists
them with the commits they came from.