---
id: w1/m24/t002
title: fromDatabase env references — resolved via secretRef, never plaintext
worker: worker1
status: todo
estimate: 30m
depends_on: [w1/m24/t001]
---

## Objective

Implement render.yaml's `fromDatabase` env form: a service env entry referencing a database declared in the same file (`fromDatabase: {name, property}`) resolves to working connection env — **via secretRef into the CNPG connection Secret**, not a plaintext copy (survives credential rotation; nothing sensitive in `bex.yml` or the App spec). Match render.yaml's property names (`connectionString`, `host`, `port`, `user`, `password`, `database`). Check whether the operator's env plumbing already supports secretRef entries (w4/m6's `<svc>-env` injection); extend minimally if not. Also check the spec's `fromService` form — include if it's a trivial sibling, else record as a documented omission.

## Context

- Connection-info source: the CNPG `<name>-app` Secret the postgres feature reads (`lego/backend/internal/postgres/`) — reuse the accessor, don't duplicate.
- Same-file-only references (Render's rule too); unknown names → validation error naming the offender (t001's all-or-nothing gate).

## Files

- `lego/backend/internal/apps/deploy.go` (resolution)
- `lego/types/` + `lego/operator/` (only if secretRef env entries need plumbing)

## Acceptance criteria

- [ ] A referencing service gets working connection env with no plaintext credential in bex.yml, the App spec, or the store; unknown database name rejects the whole apply with a named error.

## Out of scope

- Cross-file/pre-existing-database references; Key Value linkage beyond what the spec's `fromService` check decides.
