Environment variables

1ssh cd.pico.sh vars set web DATABASE_URL=postgres://db/app LOG_LEVEL=debug
2ssh cd.pico.sh vars unset web LOG_LEVEL

vars set stores variables in picd, never in your repository. vars and status list their names, never their values, and so do shared projects. They're in compose's environment when the project deploys, so ${KEY} in your compose files is replaced with them. Pass them on to services with environment: [KEY] or KEY: ${KEY}:

1services:
2  web:
3    image: example/app
4    environment:
5      DATABASE_URL: ${DATABASE_URL}
6      LOG_LEVEL: ${LOG_LEVEL:-info}

They apply on the next deploy; run redeploy to apply them now. They take precedence over the same variables in a committed .env.

vars set on a project that doesn't exist yet creates it, so its first push deploys with them:

1ssh cd.pico.sh vars set api DATABASE_URL=postgres://db/app
2git push ssh://cd.pico.sh/api.git main

COMPOSE_FILE, COMPOSE_PROFILES, and the other COMPOSE_* variables are passed to compose as usual, so they pick a project's compose files and profiles.

In shells #

Shells and commands in a project get its variables too:

1ssh web@cd.pico.sh
2ssh web@cd.pico.sh docker compose ps

A shell in your projects directory doesn't, even after cd web, so docker compose there runs without them. Running docker compose yourself also leaves out picd's compose files such as compose.picd.yaml, unless COMPOSE_FILE names them. compose runs it with both, from anywhere:

1ssh cd.pico.sh compose web up -d

A shell that resumes keeps the variables it started with, and its new tmux windows may too. Exit the shell and connect again to start one with the current variables.