Plystra

Stability Levels

Plystra documentation uses three maturity labels:

Stable: implemented behavior you can rely on in the current self-hosted release.
Experimental: preview behavior that may change as real integrations shape it.
Vision: long-term Backend OS direction, not a near-term release promise.

Current stable scope is self-hosted Core: minimal native auth, actor context, API keys, explainable authorization, Resource Registry, AuditLog, templates metadata, plugin metadata, Docker, migrations, and SDK support for the stable HTTP surface.

Expanded authentication is intentionally outside Core. Use the Complete Auth plugin for public password registration, email verification codes, magic links, and email capability integration.

Start Here

Quickstart

Start Plystra with Docker or Go, apply migrations, bootstrap a demo admin explicitly, and protect an invoice approval action.

Implementation Map

See every current repository, runtime surface, and Stable/Preview/Vision boundary in one place.

HTTP API

Review envelopes, Bearer sessions, API keys, Context Mode, and Complete Auth plugin routes.

OpenAPI

Download the generated Core API JSON/YAML artifacts and verify the contract boundary.

SDKs

Use consistent TypeScript, Python, and Go clients for system, auth, actor, authz, audit, and registry calls.

Plugins and Capabilities

Understand plugin metadata, independent capability contracts, Complete Auth, and email provider repo boundaries.

Current Product Shape

Core runtime

The plystra/plystra repository is the runtime entrypoint. It loads privileged system capabilities at startup and exposes /api/v1.

System capabilities

Identity, authorization, resource registry, audit, and admin control are system capabilities, not ordinary optional business plugins.

Context Mode

A trusted backend passes actor, resource, and grants inline to protect one real action without migration.

Strict boundary

Inline context requires a scoped server API key. Bearer user sessions are for human/admin flows and actor context.

Simple Mode

Simple Mode is a single-space application mode. It uses one application-level default Space per deployment:

User -> default UserMember -> default Member -> space_default

It does not create one default Space per User. If an application later introduces multiple explicit Spaces, existing data may need reassignment, but the authorization foundation remains the same.