Everlock modular self-hosting in one binary
Search RSS feed

Browse

OCI backend

OCI backend

Everlock now has a working backend-oci-http implementation.

Current state

  • mounted through frontend-http
  • implemented as an adapter over apimeister-registry
  • selected by vhost, similar to the site backend
  • backed by one Everlock store per configured registry
  • authenticated through Everlock HTTP Basic auth and Everlock grants

Current implementation model

The OCI backend is not one global registry. It is a host-dispatched backend:

  • each configured OCI registry has its own vhost list
  • each configured OCI registry has its own store
  • the backend selects the registry by Host header

This makes the current OCI implementation closer to site hosting than to a single monolithic registry service.

Storage

Each configured OCI registry is backed by its own Everlock versioned-storage store.

That means:

  • one logical OCI registry maps to one Everlock store
  • OCI data is persisted through Everlock storage rather than a separate filesystem blob directory
  • current OCI writes are auditable in the same general way as the other versioned-storage-backed backends

The store-backed implementation is the source of truth for OCI persistence.

Admin CLI

Current OCI registries are managed through the admin SSH console:

  • /oci list
  • /oci create <name> [store=<name>] vhost=<host>
  • /oci set <name> store=<name> | vhost=<host>
  • /oci unset <name> vhost=<host>
  • /oci delete <name>

Changes currently apply on restart rather than live reload.

Getting started

Authorization

Current authorization uses normal Everlock identity and grant checks:

  • HTTP Basic auth validates against the Everlock user registry
  • pull maps to Everlock read access
  • push maps to Everlock write access
  • delete maps to Everlock delete access
  • anonymous pull works by granting Reader on the OCI instance to the built-in anon user

The current path shape is coarse-grained at OCI instance level, so this should be treated as the first working authorization layer rather than the final OCI ACL model.

Internal reference

The precise implementation notes live in: