Environment Variables — Clouderized Docs

How it works

Env vars are never baked into your image. You manage them in the portal; on every deploy the workflow writes them to an app.env file on the VPS and passes it to your container. Your app reads them as normal environment variables — no special handling needed.

Set vars in the portal

Add or edit env vars one row at a time in your app's Env tab. Values are masked by default and synced to Gitea automatically.

Deploy writes app.env

On every push, the workflow writes your vars to app.env on the VPS before starting the container.

Container reads env vars

Your app reads them from os.environ, process.env, etc. — no .env loading needed.

Managing env vars in the portal

The Env tab in your app is the primary place to manage environment variables. Each variable gets its own row — no need to paste a wall of text.

Open the Env tab

Go to dash.clouderized.com → select your app → click Env.

Add or edit variables

Each row shows a key and a masked value. Use Reveal to show the value, Copy to copy it to clipboard, or edit the row directly. Click Add variable to add a new one.

Save Changes

Click Save Changes — this writes your vars to app.env on the VPS and syncs the Gitea secret in one step.

Redeploy to apply

Push to git push clouderized main or click Redeploy in the portal. The new vars take effect when the container restarts.

Save Changes vs Redeploy: Save Changes writes the vars immediately but the running container still has the old values. A redeploy (or push) restarts the container with the new vars.

How it works under the hood

When you click Save Changes, the portal stores your vars in two places: it writes them to app.env on the VPS immediately, and syncs them as a Gitea Actions secret named APP_ENV. On every deploy, the workflow rewrites app.env from the APP_ENV secret, keeping the two in sync.

app.env on the VPS — written at deploy time, never in your repo

DB_HOST=acme-backend-db
DB_PORT=3306
DB_NAME=acme_db
DB_USER=acme_user
DB_PASS=••••••••
STRIPE_SECRET_KEY=sk_live_••••••••••••••••
RESEND_API_KEY=re_••••••••••
APP_BASE_URL=https://app.example.com
LOG_LEVEL=info

Never put secrets in your source code or Dockerfile. APP_ENV is encrypted at rest in Gitea and only exposed to the deploy workflow at runtime.

Editing APP_ENV directly in Gitea (advanced)

You can also edit the APP_ENV secret directly in Gitea: go to your repo on git.clouderized.com → Settings → Secrets and Variables → Actions. The value is a block of KEY=VALUE lines, one per line.

Important: If you edit APP_ENV directly in Gitea without using the portal, the portal's Env tab will show the previous values until you deploy again (the portal reads from app.env, which is only rewritten on push). Use the portal to avoid this mismatch.

Reading env vars in your app

Python
import os

stripe_key = os.environ["STRIPE_SECRET_KEY"]
log_level  = os.environ.get("LOG_LEVEL", "info")  # with default

Local development

Use a local .env file for development. Add it to .gitignore — never commit it.

.env (local only — git-ignored)

DB_HOST=localhost
DB_PORT=3306
DB_NAME=acme_db
DB_USER=acme_user
DB_PASS=devpassword
STRIPE_SECRET_KEY=sk_test_••••••••
RESEND_API_KEY=re_••••••••••
APP_BASE_URL=http://localhost:8080
LOG_LEVEL=debug

Load it in your framework (python-dotenv, dotenv for Node, etc.) during local runs only. On Clouderized the same vars are already in the environment — your app code doesn't need to change between environments.

What not to do

Don't hardcode secrets in source code

Even in a private repo — commits are permanent. Use os.environ["KEY"] and set the value in the portal.

Don't commit .env files

Add .env to your .gitignore. On Clouderized the env file is written by the deploy workflow, not sourced from your repo.

Don't use ENV in your Dockerfile

ENV SECRET=value in a Dockerfile bakes the value into the image layer — it's visible in docker history and every push. Use the portal instead.