Registry

The registry is Wippy's central configuration store. All definitions—entry points, services, resources—live here, and changes propagate reactively through the system.

Entries

The registry holds entries—typed definitions with unique IDs:

app.api:get_user          → HTTP handler
app.workers:email_sender  → Background process
app:database              → Database connection
app:templates             → Template set

Each entry has an ID (namespace:name format), a kind that determines its handler, arbitrary meta fields, and kind-specific data.

Alongside that authored content the registry keeps its own provenance for each entry: the owner, meaning the deployment source the entry came from, and root, marking a dependency declaration the deployment selected. This state is assigned by the registry, not written by the entry author, and it is kept separate from meta so the two can never be confused. It is read through the snapshot state API rather than the ordinary entry APIs—see Registry module.

For how the registry functions as an authorization layer, see the Security Model.

Kind Handlers

When an entry is submitted, its kind determines which handler processes it. The handler validates the configuration and creates runtime resources—an http.service entry starts an HTTP server, a function.lua entry creates a function pool, a db.sql.postgres entry establishes a connection pool. See Entry Kinds Guide for available kinds and Custom Entry Kinds for implementing handlers.

Live Updates

The registry supports runtime changes—add, update, or remove entries while the system runs. Changes flow through the event bus where listeners can validate or reject them, and transactions ensure atomicity. Version history enables rollback.

YAML definition files are serialized registry snapshots loaded at startup. See Registry module for programmatic access.

See Also