Skip to content

Knowledgebase

Using environment variables consistently across web and CLI

development

Web requests, SSH commands, cron jobs and workers can start with different environments. A setting present in an interactive shell may be missing from a panel-managed application.

What you need before you begin

List the processes that use the application and how each starts. Identify the approved source of production configuration and secrets.

01 Use environment variables consistently across web and CLI

  1. Record the required variable names and safe defaults in a configuration template. Keep real secret values in the protected runtime mechanism.

  2. Configure the web process, worker and scheduled command to load the intended environment. Use explicit interpreter and project paths where shell defaults differ.

  3. Check the working directory and configuration-file discovery rules. A relative path can load another environment file or none at all.

  4. Refresh cached framework configuration and restart persistent processes after a relevant change.

  5. Test one safe operation from each execution path, comparing non-sensitive configuration identifiers and results.

02 Example: compare required environment names without printing secrets

When a Python task works over SSH but fails under cron, run a small presence check through each approved execution path. This example reports whether required values are available. It deliberately avoids printing the database connection string or mail credentials.

Code or configuration example
import os

required = ('DATABASE_URL', 'MAIL_HOST', 'APP_RELEASE')
for name in required:
    print(f'{name}: {"present" if os.getenv(name) else "missing"}')

A variable present in the interactive shell but missing from cron points to the startup environment or configuration-loading path. Matching presence does not establish that values match, so next compare safe service identifiers through the application’s private diagnostics. Use the same working directory and interpreter as the real scheduled command.

Expected result: The web process, worker and scheduler all receive their required configuration from the intended protected source. The support transcript contains useful yes/no evidence without a full environment dump.

Confirm the expected result

Confirm a database or mail operation uses the intended service from the website and from scheduled work. Avoid full environment dumps when collecting evidence.

Troubleshoot unexpected results

If only cron fails, reproduce its command with a minimal environment and the same account. Interactive shell startup files may supply values that cron never receives.

A common question

Should I put every secret in a command-line argument?

Arguments can appear in process listings, logs or shell history. Use the supported protected configuration mechanism and pass only the information the command actually requires.

Was this answer helpful?

Need a little more help?

Our support team can help you find the next step.

Contact support