Output references

Many resources depend on credentials from other resources. A Postgres client needs a connection string. A Kubernetes plugin needs a kubeconfig. You could copy those values by hand every time they change — or you can reference them.

The idea

A field that holds a credential (API token, connection string, kubeconfig, password) can be filled in two ways:

• Literal — you paste the actual value.
• Output reference — the field points at another resource’s output field.

Output references re-resolve automatically. If the upstream resource’s value changes (say, a managed database rotates its password), the dependent resource picks up the new value the next time it connects.

Where the references come from

Credential forms are plain fields — there is no link icon on Connection string or Kubeconfig that opens a picker. References are wired from the resource that produces the value, or from a field that already holds one:

• From the upstream resource’s own page. A managed database or cluster carries a tab for the plugin that consumes it — a DigitalOcean Postgres database gets a PostgreSQL tab, a DOKS or EKS cluster gets a Kubernetes tab — and opening that tab passes the connection string, CA certificate or kubeconfig straight through as a reference. Nothing is typed and no second account is created. That is what a credential field’s help text means when it says you can “link this to a DigitalOcean Managed Database after adding”.
• From a picker the plugin declares. DNS record content is the one create form with a reference control today: a Value source select offering Pick a resource or Use custom value — see DNS records below.
• From a field that already holds a secret or a reference. Those render with a Reroll link that opens a dialog for pointing them somewhere else — see Secret rerolls.

Example

You have a DigitalOcean managed Postgres database and you want the SQL editor pointed at it.

1. Open the managed database resource.
2. Switch to its PostgreSQL tab.
3. That’s it — the connection string and CA certificate flow through from the database’s outputs.

The Postgres side now follows whatever DigitalOcean returns.

Which plugins expose outputs

Any resource that produces a credential-ish value. Common ones:

• DigitalOcean managed databases — connectionString, privateConnectionString
• Neon branches — connectionString
• EKS / AKS / GKE clusters — kubeconfig
• PlanetScale branches — connectionString
• Turso databases — url, authToken

DNS records

DNS record content uses the same machinery. When you create an A, AAAA, or CNAME record, a Value source select appears above the value, offering Pick a resource (the default) or Use custom value. Leave it on Pick a resource and the value field becomes a picker that searches across your accounts for IP- or hostname-producing resources; picking one stores a live reference, so the record tracks the source’s address and is re-applied at the provider when it changes. Other record types (MX, TXT, SRV, NS) have no such select — their value is plain text. See DNS records.

When to use a literal instead

• The upstream resource is not managed by infrawrench.
• You want to pin a specific credential regardless of upstream changes.

See Secret rerolls for changing a reference after you set it.

Seeing the wiring

Every reference is also a dependency edge, and the dependency graph draws them all at once — including the blast radius of any resource other things depend on.