Secrets and variables

A service gets its database's address and credentials from the database's outputs. Other values, such as API keys, come from project variables and secrets. Secret values stay out of Git, and release logs hide your project's secrets.

How a service gets its database's address and credentials

The database's module publishes its address and credentials as outputs. The service refers to them, and each release fills in that environment's values. In this spec.env, each line becomes an environment variable:

"POSTGRES_URL": "jdbc:postgresql://${postgres.default-db.out.interfaces.writer.host}/postgres",
"POSTGRES_USER": "${postgres.default-db.out.interfaces.writer.username}",
"POSTGRES_PASS": "${postgres.default-db.out.interfaces.writer.password}"

Where secrets are kept, and using your own secrets manager

Secret values aren't stored in Git. The control plane keeps them per environment, and its cloud decides where: AWS Secrets Manager on AWS, OpenBao (Vault-compatible) on Azure, and Google Cloud Secret Manager or its own database on GCP. Self-hosted, that's the cloud account your control plane runs in.

On Facets hosted, you can keep an environment's secrets in your own AWS Secrets Manager instead. Facets support turns on this early-access setting; you can't undo the move or change the account or region later (Where your data lives).

Secrets in logs

Release logs hide your project's secrets and module outputs marked sensitive.