Environment and secrets

Variables go under [services.<name>.env]. A value is one of four kinds:

[services.web.env]
LOG_LEVEL = "info"                                         # literal
STRIPE_KEY = { secret = true }                             # secret
DATABASE_URL = { from_database = "db" }                    # database property
S3_KEY = { from_service = "storage", key = "ACCESS_KEY" }  # another service's variable

Secrets

{ secret = true } declares the key; the value is written separately and is stored encrypted. It is never shown again, in the panel or the CLI.

duploy secret set web STRIPE_KEY=sk_live_… OTHER=…
duploy secret set web - < .env.production    # read a .env file from stdin
duploy secret rm web STRIPE_KEY
duploy env web                               # names and kinds, never values

K= writes an empty value. Removing a value with secret rm keeps the key in the config, so the next deploy fails with missing_secret until a value is set again.

Database references

from_database reads a property of a managed database in the same project:

property	Postgres	MySQL	Redis
url (default)	postgres://app:…@db.shop.internal:5432/db	mysql://app:…@…:3306/db	redis://:…@…:6379/0
host	db.shop.internal	same form	same form
port	5432	3306	6379
user	app	app	empty
password	generated	generated	generated
database	the database name	the database name	0

PGHOST = { from_database = "db", property = "host" }

Service references

from_service copies a variable from another service's resolved environment, secrets included. The usual use is sharing one credential between the service that owns it and the services that call it:

[services.storage.env]
ACCESS_KEY = { secret = true }

[services.web.env]
S3_ACCESS_KEY = { from_service = "storage", key = "ACCESS_KEY" }

The key has to exist in the target's env (or be one of the platform variables below, such as PORT).

Inheriting a whole environment

inherit_env starts a service from another service's resolved environment. Its own env then adds to it and overrides it:

[services.worker]
type = "worker"
source = { image_of = "web" }
inherit_env = "web"
command = ["bin/worker"]

Order of precedence, lowest first: platform variables, the inherited environment, the service's own env. Cycles are rejected.

Platform variables

Every container gets these. Your own env may override them.

Variable	Value
PORT	The service's port
DUPLOY_SERVICE	Service name
DUPLOY_PROJECT	Project name
DUPLOY_DEPLOYMENT	Deploy id (services)
DUPLOY_RUN	Run id (cron jobs)
DUPLOY_CPU	CPU limit in cores
DUPLOY_MEMORY_BYTES, DUPLOY_MEMORY_MB	Memory limit
GOMAXPROCS	CPU limit rounded up

Config files

Small config files can be mounted into the container, read-only, without baking them into the image:

[services.web.files]
"/etc/app/config.yml" = """
listen: 0.0.0.0:${PORT}
log_level: ${LOG_LEVEL}
"""
"/etc/app/ca.pem" = { from = "deploy/ca.pem", mode = "0600" }

• The key is an absolute path in the container.
• The value is the content, or { content = "…" }, or { from = "<repo path>" } to read a file from the repository at the deployed commit.
• mode is an octal string, default "0644".
• ${VAR} is replaced from the service's environment when the container is created; an unknown name is a config error. Write $${ for a literal ${.
• Limits: 64 KiB per file, 16 files and 256 KiB per service. Files may not sit inside a volume path.

Changing a file, including the repository file behind from, starts a new container; nothing is edited in place.