Managed resources export their connection details as variables that an App's environment can reference — ${db.uri}, ${db.password}, ${cache.uri} and so on. This is documented at resources/postgres and resources/valkey, and it is the intended way to wire an app to a database.
None of it is reachable from the CLI. There is no command, schema field, or API response that tells you these variables exist or what they are called.
What I checked (CLI 0.1.0)
| Route |
Result |
brainpod describe resource Postgres |
Only diskRef, instance, version — the input schema. No exports. |
brainpod describe resource App |
spec.env is {name, value} with value: minLength 1. Nothing indicates value may be a reference. |
GET /v1/openapi.json |
18 paths, none for variables. No exports/variables vocabulary anywhere in the document. |
GET /v1/pods/{pod}/resources/{kind}/{namespace}/{name} |
Resource is urn + content, i.e. the spec you submitted, returned back. No status or exports section. |
brainpod blueprint get wordpress |
Body says "Database credentials are wired automatically", but defaults is {} and the resource graph is not returned, so the syntax never appears. |
The only way to discover the syntax through the CLI is to install a blueprint onto a pod and read the resulting App's env back — mutating a draft in order to learn a notation.
Why it matters
Driving the CLI from a coding agent is a documented onboarding path, and describe is explicitly positioned as the authoritative contract for each kind. An agent that reads describe resource Postgres, finds no exports, and reads describe resource App, finding value is a plain string, will reasonably conclude that every value must be literal. It then tries to hand-assemble a connection string using a password that is generated by the platform and never exposed — so it either stalls or ships a broken DATABASE_URL.
Suggestions
- Add an
exports (or variables) section per kind to brainpod describe resource <kind>, and to the OpenAPI document it is derived from, listing the available fields and their meaning.
- Note in
describe resource App that spec.env[].value accepts ${<resource>.<field>} references, with a pointer to where the per-kind fields are listed.
- Consider surfacing the resolved set for a pod, e.g.
brainpod --pod <pod> resource variables, so an agent can confirm a reference before composing a draft.
Related
brainpodnl/skills#6 — the deploy skill currently tells agents that these exports do not exist, partly because describe gives it no reason to think otherwise.
Managed resources export their connection details as variables that an App's environment can reference —
${db.uri},${db.password},${cache.uri}and so on. This is documented at resources/postgres and resources/valkey, and it is the intended way to wire an app to a database.None of it is reachable from the CLI. There is no command, schema field, or API response that tells you these variables exist or what they are called.
What I checked (CLI 0.1.0)
brainpod describe resource PostgresdiskRef,instance,version— the input schema. No exports.brainpod describe resource Appspec.envis{name, value}withvalue: minLength 1. Nothing indicatesvaluemay be a reference.GET /v1/openapi.jsonexports/variablesvocabulary anywhere in the document.GET /v1/pods/{pod}/resources/{kind}/{namespace}/{name}Resourceisurn+content, i.e. the spec you submitted, returned back. No status or exports section.brainpod blueprint get wordpressdefaultsis{}and the resource graph is not returned, so the syntax never appears.The only way to discover the syntax through the CLI is to install a blueprint onto a pod and read the resulting App's env back — mutating a draft in order to learn a notation.
Why it matters
Driving the CLI from a coding agent is a documented onboarding path, and
describeis explicitly positioned as the authoritative contract for each kind. An agent that readsdescribe resource Postgres, finds no exports, and readsdescribe resource App, findingvalueis a plain string, will reasonably conclude that every value must be literal. It then tries to hand-assemble a connection string using a password that is generated by the platform and never exposed — so it either stalls or ships a brokenDATABASE_URL.Suggestions
exports(orvariables) section per kind tobrainpod describe resource <kind>, and to the OpenAPI document it is derived from, listing the available fields and their meaning.describe resource Appthatspec.env[].valueaccepts${<resource>.<field>}references, with a pointer to where the per-kind fields are listed.brainpod --pod <pod> resource variables, so an agent can confirm a reference before composing a draft.Related
brainpodnl/skills#6 — the deploy skill currently tells agents that these exports do not exist, partly because
describegives it no reason to think otherwise.