Deployment Credentials on Varity

Varity TeamCore Contributors

Varity has two distinct environment-variable paths. Keeping them separate prevents the retired shared-credential model from becoming current guidance.

Application-owned Secrets

You create and supply credentials for services your application chooses, such as a payment processor, email provider, or external AI API. Varity does not create those third-party accounts, and it does not provide shared development credentials.

Use Environment Variables for file precedence, reserved names, and secret-handling rules.

Attached-service Connection Variables

When the deployment engine actually provisions a supported attached service, it injects that service’s reserved connection variables into the deployed runtime. Those values are deployment-scoped runtime wiring, not local development credentials and not a general credential-fetch API.

Use Auto-wired Services for the supported detection and variable contract. Bring your own managed database through an application-owned environment variable when you need durability or lifecycle behavior beyond that contract.

Caution

The retired credential-proxy path is not part of the current CLI contract. Do not expect NEXT_PUBLIC_VARITY_APP_ID, an automatically supplied application API key, or a doctor command that retrieves shared credentials.

Verification

After deployment, follow the returned operation to a terminal result and check application logs for connection success. Do not print secret values. A successful local varitykit doctor run proves local prerequisites only; it does not prove attached-service provisioning or runtime health.

Environment VariablesSupply application-owned configuration and secrets.

Auto-wired ServicesRead the attached-service detection and runtime variable contract.