What this means
What this means
An environment variable only does something if your code reads it. CM Cloud injects whatever names and values you enter, but a variable your app never references is simply ignored — it does not switch your database, connect a backend, or change behaviour. The correct list comes from your app and its framework, not from CM Cloud. Examples: an app using Prisma reads DATABASE_URL (declared in prisma/schema.prisma as env("DATABASE_URL")); Django and Rails also read DATABASE_URL plus a secret key; an app that talks to a PocketBase backend reads whatever URL variable its own code names (commonly POCKETBASE_URL); and browser-exposed values in Next.js must start with NEXT_PUBLIC_. Setting POCKETBASE_URL on an app whose data layer is actually Prisma does nothing — the app still looks for DATABASE_URL. Changing which backend an app uses (for example moving a Prisma/SQLite app onto managed PocketBase) is a code change, not an environment-variable change.
Before you start
Before you start
Know your stack — language, framework, and ORM. The authoritative list of variables is inside your own repository, so you can find it instead of guessing.
Step-by-step guidance
Step-by-step guidance
- Find every variable your code reads: search the repo for process.env. (Node), os.environ / os.getenv (Python), env( (Laravel/Rails), or import.meta.env (Vite). Each unique name is a variable your app expects.
- Look for a .env.example, .env.sample, or .env.template file in the repo — projects usually list every required variable there with placeholder values.
- Check your framework/ORM's required names: Prisma and most SQL ORMs read DATABASE_URL; Django needs SECRET_KEY (and often DATABASE_URL); a PocketBase client reads the URL variable your code names (often POCKETBASE_URL); Next.js browser variables must start with NEXT_PUBLIC_.
- In the portal Environment Variables section, add exactly those names. They are case-sensitive and must match your code character for character — DATABASE_URL is not the same as database_url.
- Do not add variables your app does not read. An unused variable is ignored; it will not point your app at a different database or backend.
- Redeploy so the variables are injected, then read the runtime logs. An error like 'DATABASE_URL is not defined' or 'undefined' names the exact variable your code expected but did not find — add that one.
- If you actually want to change which database or backend your app uses (for example, move onto managed PocketBase), update your application code to read from and connect to it first. Setting a new URL variable alone will not migrate the app.
What CM Cloud support will review
What CM Cloud support will review
Support can confirm which variables your app expects (by reading the names your code references), whether they are set in the portal, and whether a redeploy ran after you changed them. Support does not edit your application code or choose your database for you.
What is not automated yet
What is not automated yet
CM Cloud does not guess, generate, or inject variables for you, does not rename them to match your framework, and never changes which database or backend your app uses — only your code decides that. Setting a variable your app does not read has no effect.
Safety note
Safety note
Reading this article does not capture payment, provision infrastructure, register or transfer domains, change DNS, write Cloudflare or WHMCS, call providers, or enable live execution.
Safe next action
Safe next action
Search your repository for the variables your code reads (process.env, os.environ, env(...)), set those exact names in the portal Environment Variables section, then redeploy.