feat(items): deploy litellm with its own postgres and redis

[amiralis1365]

Closes #16.

litellm deploys one stateless container. Virtual keys, teams, budgets, rate
limits and the per-key spend ledger are Prisma rows, so with no DATABASE_URL
the tables are never created and the only credential a deployment has is
LITELLM_MASTER_KEY — one shared secret, no per-client attribution, nothing to
invoice from. The existing listing says as much and leaves it there. This adds
litellm-stack: the same proxy with the database that makes it accountable, and
Redis beside it for the state a second replica needs.

It is also the first item in the corpus that is a graph. All 13 others are
single-node with connections: {}, so fromRole/fromOutput resolution and
the two compatibility axes were exercised only by tests/rules.test.ts against
synthetic items.

What this adds

node	image	size	wires in
db	postgres:17.10-alpine	general.standard.small	—
cache	redis:8.8.1-alpine	general.standard.small	—
web	ghcr.io/berriai/litellm:v1.83.14-stable.patch.3	general.standard.small	databaseUrl ← db.dsn, redisUrl ← cache.url

Producers first, because map order is graph order and the two nodes the wires
come from should read before the node they arrive at. parameters stays empty:
the merged USER inputs are already the form this item wants — database
password, user and name, plus two generated LiteLLM keys — and an authored block
would have to restate all five to add nothing. Neither wired input appears
there, which is the point.

The two new outputs

items/postgres and items/redis publish only address, a mesh-internal
host:port. LiteLLM reads one DSN and one URL, so this item's copies add:

output	schema	why
db.dsn	STRING / CONNECTION_STRING / POSTGRES, sensitive	DATABASE_URL is the whole of the database configuration this container needs
cache.url	STRING / CONNECTION_STRING / REDIS	url is the one redis-py argument carrying host and port together

Both are DERIVED: the host and port are not knowable until the platform places
the node, so no value can be written. Component §6.2 forbids an output that
depends on a value received over an inbound connection, and neither does —
the credentials dsn carries are that node's own USER inputs. Blueprint
§4.2's worked example wires a Postgres node's connectionString, so a composed
DSN is the shape the contract was written for.

address stays beside both. dsn embeds POSTGRES_PASSWORD and is marked
sensitive; a consumer that only needs to reach the server should keep taking the
address rather than a copy of the password. cache.url is not sensitive and the
component says why: the server runs with no requirepass on a PRIVATE
endpoint, so there is no password for the URI to carry.

What the database changes about the proxy

Four differences from the single-container item, each caused by the database:

	why
LITELLM_SALT_KEY added, generated	encrypts provider credentials at rest; there is nothing to encrypt without a database. Rotating it after a credential is saved makes every saved credential unreadable — upstream's guidance is "set once, never change it"
STORE_MODEL_IN_DB=True	model definitions live in Postgres rather than a config file this container has no way to receive
DISABLE_SCHEMA_UPDATE deliberately unset	upstream sets it on proxy replicas because their Helm chart runs migrations in a separate job. This blueprint has no such job, so the proxy applying its own schema is the only thing that creates the tables
readiness initialDelaySeconds 30 → 120	with DATABASE_URL set, proxy_cli.run_server runs the Prisma schema setup before uvicorn binds 4000, so on a first deploy nothing answers until the migration chain finishes against an empty database

The probe stays on /health/liveliness even though the database is what would
make /health/readiness meaningful. That route is declared with
dependencies=[Depends(user_api_key_auth)], so once LITELLM_MASTER_KEY is set
it answers 401 to a probe carrying no key and the deployment would never come
up. /health/liveliness carries no such dependency.

LITELLM_MODE=PRODUCTION is set because the default, DEV, is the one value
that makes the CLI call load_dotenv() on startup, reading a stray .env out
of the working directory.

Redis is wired and does not switch itself on

Stated here rather than found in review. redis_usage_cache — the client the
proxy shares tpm/rpm counters, spend and router state through — is assigned in
exactly one place, ProxyConfig._init_cache, reachable only from the
litellm_settings.cache is True branch of load_config. No environment
variable reaches that flag in v1.83.14-stable.patch.3 or in v1.99.1, the
current release, which was read to check whether the gap had closed.

A config.yaml cannot be shipped either. The published image config is
Entrypoint: ["docker/prod_entrypoint.sh"], Cmd: ["--port","4000"], and that
script ends in exec litellm "$@"; per spec ADR-0010 a Musher command
overrides the image's CMD while inheriting its ENTRYPOINT, so every word this
component can pass arrives as a litellm CLI argument and there is nowhere to
write a file for --config to name.

What closes it is the other wire. With STORE_MODEL_IN_DB set,
ProxyConfig.save_config writes litellm_settings to the config table and
_update_config_from_db merges it back at every start, so enabling the cache
once — from the Admin UI or a single POST /config/update — is durable and
applies to every replica. cache_params is left empty on purpose: an empty
block is what sends LiteLLM to the environment, _redis_kwargs_from_environment()
maps every REDIS_<ARG> variable onto a redis-py argument, and RedisCache
drops a null host, port and password before connecting — so REDIS_URL alone is
the whole connection. The listing says this in plain words and the component
carries the reasoning.

Rejected

A newer LiteLLM tag. v1.97.1 added general_settings.coordination_redis
and an admin API that persists it, which is a nicer switch than
litellm_settings.cache. It is still not zero-touch — it is also read from
config or the database — so it buys no automation, and it would take this item
off the stable track for nothing. v1.83.14-stable.patch.3 is the highest
vX.Y.Z-stable tag the project publishes, which is why the existing item pins it.

A JOB node seeding the config row. It would have to insert into
LiteLLM_Config before the proxy has migrated the schema that creates it, and
the contract orders no nodes.

Adding dsn and url to items/postgres and items/redis. The README asks
for one item per pull request, and the item model requires per-item component
copies regardless, so the divergence is inherent rather than introduced here.

Validation

npm test — 400 tests, 0 failures, against the tip of musher-dev/spec fetched
at run time. npm run typecheck clean. The per-item suite covers the new
surface: every connection resolves at both ends and the two fit — §4.2 and
the install form covers what a deploying user must supply — §5.2, §5.3.

The capability phase is out of reach here as always: whether
general.standard.small is offered and whether the slug is free are decided at
sync.

Noted, not fixed here

items/litellm/components/litellm.yaml tells the deploying user that "LiteLLM
prefixes it with sk-". It does not — the master key is compared verbatim with
secrets.compare_digest, and the sk- assertion in user_api_key_auth applies
only to virtual keys. Harmless in practice, wrong in the description, and its
own one-item change.

🤖 Generated with Claude Code

https://claude.ai/code/session_01AAbh92nGTa3XKBQh2r1jUU