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, and 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, while 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, and 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.