Mechanics 0.1.57 turns addons from a PostgreSQL feature into a small service catalog. The command shape stays the same, but the catalog now covers the first stateful services most agent-shipped apps need: a database, object storage, a cache, and a message bus.
This note is scoped to addons. PostgreSQL arrived first in 0.1.55; 0.1.57 keeps that database workflow and adds S3-compatible buckets, Valkey caches, and NATS JetStream servers beside it.
The catalog now has four primitives
postgres: a CloudNativePG PostgreSQL database, reachable inside the tenant namespacebucket: a SeaweedFS-backed, S3-compatible object storage bucketvalkey: an authenticated Redis-compatible cache for ephemeral statenats: a single-node NATS server with JetStream file storage
Users and agents discover the catalog through addon type list and
addon type info <type>. Creation uses one verb across service types:
addon create db --type postgres, addon create assets --type bucket,
addon create cache --type valkey, or addon create events --type nats.
PostgreSQL remains the baseline
The PostgreSQL addon is still the durable application database path. Mechanics
renders a CloudNativePG Cluster, bootstraps an app database owned by
an app user, and exposes credentials through the Kubernetes secret
<name>-app. Apps wire it as DATABASE_URL from the secret's
uri key; Mechanics does not print passwords back to the caller.
Its typed parameters are intentionally narrow: PostgreSQL version 17 or 18,
storage from 1Gi to 10Gi, and memory from 256Mi to 1Gi. Version and storage are
create-only; memory can be updated later with addon set. Until backups land,
the connection contract is explicit: treat this as disposable state, with
retained volumes available only for admin recovery.
Bucket covers application objects
The new bucket addon creates a tenant-prefixed S3 bucket, S3 identity,
generated access keys, policy, and policy binding. It is backed by SeaweedFS and
exposed through the in-cluster S3 endpoint with path-style access. The default
quota is 5Gi, and the accepted range is 1Gi to 10Gi.
Apps consume the generated <name>-bucket secret through standard S3-shaped
environment variables: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY,
AWS_REGION, AWS_ENDPOINT_URL_S3, and S3_BUCKET. That makes it a
good fit for uploads, generated assets, exports, and other object-like state.
Valkey covers fast ephemeral state
The new valkey addon provisions a single authenticated Valkey instance
with the Redis protocol on port 6379. It generates a <name>-valkey secret
containing a redis:// URI, intended to be mounted into apps as
REDIS_URL.
Valkey is explicitly ephemeral: it uses in-memory/cache semantics, and cache
data is lost on restart or delete. The tunable knobs are version 8 or 9, memory
from 128Mi to 1Gi, and an eviction policy such as allkeys-lru,
allkeys-lfu, volatile-lru, volatile-ttl, or
noeviction.
NATS covers messages and streams
The new nats addon deploys the official NATS Helm chart with JetStream
enabled. It gives apps an internal NATS host on port 4222 and a generated
<name>-nats secret whose uri key can be mounted as
NATS_URL.
This is a single-node persistent NATS server, not a highly available cluster. It is meant for small app-local messaging, streams, and consumers. Supported version lines are 2.12 and 2.14; storage ranges from 1Gi to 10Gi; memory ranges from 256Mi to 1Gi.
Why this shape matters
Addons are still GitOps objects. Mechanics commits manifests under
addons/<name>/, Argo CD reconciles them, and the SSH command surface reads
status back from Kubernetes. That gives agents a small set of typed verbs while
preserving the human audit trail: parameters, generated resources, readiness,
and connection contracts are visible instead of hidden behind an opaque service
broker.
0.1.57 makes addons a catalog: database, bucket, cache, and messaging, all through the same bounded control-plane verb.