v0.83.1

Highlights

Secret variable values are no longer returned by the API — #467

Variables declared as passwords were shown in clear text on the product deployment detail page. This was not a rendering bug: GET .../product-deployments/{id} shipped every stored value verbatim, so the value was in the HTTP response regardless of what the UI drew. Masking in the frontend would have been cosmetic.

Values of Password variables and of every connection-string type are now withheld. The API returns the variable's name, whether it is secret, and whether a value is stored — never the value itself. The detail page shows •••••••• for a stored secret and "not stored" when there is none. There is deliberately no reveal affordance: the value is not present in the response at all.

Connection strings count as secrets even though their type is not Password — they embed Password=….

The "save value" opt-out now actually works for product deployments — #467

The deploy form has always offered a per-variable Save value toggle, and the client has always sent the opt-out list. But the product deployment endpoint had no field to receive it: the list was discarded during binding and every variable was persisted anyway, including passwords the user explicitly opted out of saving. The toggle was decorative; the filter that existed was only reachable through the single-stack deploy path.

The opt-out now flows through the product deploy and upgrade paths and filters both the product-level shared variables and the per-stack variables before they are persisted. Docker still receives the full set — the container needs the value to run.

The upgrade form carries the choice forward and handles stored secrets properly: the field starts empty, leaving it empty keeps the stored value, typing replaces it. Untouched stored secrets are omitted from the request rather than sent as empty strings, which would previously have won during the variable merge and wiped the password.

Notes for operators

• A stored password is no longer readable in the UI by anyone, administrators included. This is intentional. Where a password is needed, it comes from its source of truth, not from a deployment view.
• A password that was not saved has to be entered again on upgrade. Also intentional — it only appeared otherwise because it was being stored against the user's choice.
• Deployments created before this release have no recorded classification and fall back to judging by variable name (*PASSWORD*, *SECRET*, *TOKEN*, *CONNECTIONSTRING*, …), erring towards withholding. Their next deploy or upgrade records the exact set from the product manifest.
• A database migration (AddSecretVariableNames) runs automatically on startup. No manual step, no manifest change.

API contract change

Despite being a patch release, this changes the shape of two response fields. Anyone consuming the API directly needs to adapt:

sharedVariables:  Dictionary<string, string>  →  DeploymentVariableDto[]
stacks[].variables: Dictionary<string, string>  →  DeploymentVariableDto[]

DeploymentVariableDto { name, value (null when secret), isSecret, hasValue }

Distributions built on @rsgo/core need the same adjustment where they render these fields.

Documentation: Variable types → Password

Full changelog: v0.83.0...v0.83.1