Environment variables

Each project's Environment page holds its variables. They're encrypted in the panel's database, and on the server they exist only in a root-only file that systemd hands to the app's process.

#Edit them

• Rows: a name and a value per row. Add variable adds a row, and Show values reveals the values, which stay hidden until then.
• Raw .env: all of them as one .env file, to edit as text or paste a whole file into. Switching back to Rows turns each KEY=value line into a row. Comments and export are fine; lines that aren't KEY=value are pointed out before they're left out.

The browser never fills these fields in with a saved password.

#Apply them

• Save stores them for the next deploy.
• Save and restart loads them into the running app right away, without a rebuild and without downtime.

Variables read at build time, like NEXT_PUBLIC_* in Next.js, are baked into the build, so they need a redeploy. A static site reads every variable at build time, so saving redeploys it.

#Set for you

Below your variables, Set for you lists what the server provides:

• DATA_DIR: the folder that survives deploys, /srv/apps/<app>/data.
• PORT and HOST: the live color's port, and 127.0.0.1.
• DATABASE_URL, MONGODB_URI and REDIS_URL: when you add a database.

#On the server

On deploy, your variables are written to /etc/layer/apps/<app>/app.env, owned by root and readable by nobody else. systemd reads it and hands the variables to the app's process, so the app gets its environment but has no file it could read or rewrite. Values never appear in build logs.

ls -l /etc/layer/apps/<app>/    # app.env, services.env, blue.env, green.env