Platform

Secrets

Secrets are encrypted key-value pairs injected into your deployments at runtime. They never appear in logs, container images, or API responses — only the names are visible.

Creating a secret

Secrets are created per project. Navigate to Project → Secrets → New Secret in the console, or use the CLI:

bashbricqs secrets set DATABASE_URL "postgres://user:pass@host:5432/db" \
  --project my-project
Note: Secret values are encrypted at rest using AES-256. Once saved, the value cannot be read back — only overwritten or deleted.

Injecting secrets into deployments

Secrets are injected as environment variables into your deployment's container. Select which secrets a deployment has access to at deploy time:

bashbricqs deploy my-api \
  --model meta-llama/Llama-3-8B-Instruct \
  --secret DATABASE_URL \
  --secret OPENAI_API_KEY

Inside the container, secrets are available as standard environment variables:

pythonimport os

db_url = os.environ["DATABASE_URL"]  # injected at container start
api_key = os.environ["OPENAI_API_KEY"]

Secret scoping

ProjectSecrets belong to a project and can only be injected into deployments within that project.EnvironmentYou can create separate secrets for preview and production environments (e.g. TEST_DB_URL vs PROD_DB_URL).Access controlOnly project members with Owner or Editor roles can create, update, or delete secrets.

Rotating secrets

Updating a secret does not automatically redeploy running containers. To apply a new value, trigger a new deployment or restart the existing one:

bash# Update the secret value
bricqs secrets set DATABASE_URL "postgres://user:newpass@host/db" --project my-project

# Redeploy to pick up the new value
bricqs redeploy <deployment-id>

Listing and deleting secrets

bash# List all secret names (values are never shown)
bricqs secrets list --project my-project

# Delete a secret
bricqs secrets delete DATABASE_URL --project my-project
Note: Deleting a secret while it is injected into a running deployment does not remove it from that running container — the value is already baked into the container environment at start time. The new value takes effect on the next deployment.

Security best practices

  • Rotate secrets regularly — especially after team member offboarding.
  • Use per-environment secrets rather than sharing a production credential with preview deployments.
  • Avoid committing .env files to version control — use BRICQS Secrets instead.
  • Audit secret access in the Governance panel: every create, update, and delete is logged.