SMLL Docs

Secrets

Securely store and manage sensitive configuration values.

Secrets store sensitive values like API keys, passwords, and tokens. They are encrypted at rest in Kubernetes and can be referenced by your services as environment variables.

Secret types

TypeCreated byDescription
CustomYouUser-defined key-value pairs
Database credentialsAutoGenerated when a database is created
Registry credentialsAutoGenerated when a VPC is created

Creating a secret

  1. Go to your VPC's Secrets section
  2. Click Create Secret
  3. Enter a name and add key-value pairs:
API_KEY = sk-abc123def456
WEBHOOK_SECRET = whsec_xyz789
  1. Click Create

Secret values are write-only — once saved, they cannot be viewed in the dashboard. You can update or delete individual keys.

Referencing secrets in services

To use a secret in a service, link it as an environment variable:

  1. Go to your service's Environment Variables tab
  2. Add a variable and choose Link from secret
  3. Select the secret and the key you want
  4. Save and redeploy

The secret value is injected into your container at startup via Kubernetes secretKeyRef.

Auto-generated secrets

Database credentials

When you create a database, SMLL creates a secret with:

KeyDescription
POSTGRES_USERDatabase username
POSTGRES_PASSWORDDatabase password
POSTGRES_HOSTInternal hostname
POSTGRES_PORTPort number
POSTGRES_DBDatabase name
DATABASE_URLFull connection string

Registry credentials

Each VPC gets a registry secret with:

KeyDescription
REGISTRY_URLRegistry hostname
REGISTRY_USERRegistry username
REGISTRY_PASSWORDRegistry password

Updating secrets

You can update individual keys within a secret:

  1. Go to the secret detail page
  2. Click Edit
  3. Modify or add keys
  4. Save

Services referencing the updated secret need to be redeployed to pick up the new values.

Deleting secrets

Secrets that are currently referenced by a service's environment variables cannot be deleted. Remove the references first, then delete the secret.

Best practices

  • Never commit secrets to source control — use SMLL secrets instead of .env files in your repository
  • Scope secrets per service — don't share a single secret across all services if they don't all need the same keys
  • Rotate credentials regularly — update secret values and redeploy services to pick up new values
  • Use auto-generated database credentials — they're created securely and scoped to the specific database
  • Use descriptive key names — STRIPE_SECRET_KEY is clearer than KEY_1

On this page

Secret typesCreating a secretReferencing secrets in servicesAuto-generated secretsDatabase credentialsRegistry credentialsUpdating secretsDeleting secretsBest practicesRelated