A container starts without its credential

Symptom

The container runs and the application reports an empty password, a missing API key, or an authentication failure against something it depends on. The deployment itself looks healthy.

Diagnose

1. Does the deployment still reference the credential? GET /api/v1/deployments/{name} and read the secrets list. An update that sent a shorter list replaced the stored one — sending a field replaces it outright, and a lost reference removes the credential without failing anything. See sending part of a description.
2. Is the path the one that holds the material? GET /api/v1/secrets/resources lists every path referenced in your tenant, and GET /api/v1/secrets/resources/{name}/consumers shows who reads each one.
3. Are the keys the ones the application expects? Delivery is by environment variable, keyed as the stored document is keyed. A key named differently in the document is a different variable.
4. Was the container created before the material existed? The value is resolved when the container is created, so material written afterwards reaches the next container, not this one.

Resolve

• Reference lost: send the whole secrets list again, including the entry that disappeared.
• Wrong path or wrong key: correct it. Every refusal a path can earn is in rejections and alterations.
• Material added after the container: rotate, or make any change that replaces the container, so the value is resolved again.
• Expecting a file: delivery is env-only and a request to mount is refused. Render the file from the environment in your own entrypoint — see give a deployment a credential.

Prevent

Read the stored list before sending a partial update, and name credentials after what they belong to so two deployments cannot end up reading two copies of one password.