Environment variables and export

An environment variable set with a plain assignment like NAME=value only exists inside your current shell. Running export NAME=value instead makes it part of the environment that gets copied to every child process your shell starts, like scripts, PHP-CLI, or Node. If a program can't see a variable you just set, the fix is almost always: you forgot export, or you set it in a shell that already exited.

Setting variables the right way

There are three common scopes, from narrowest to widest:

• One command only: NAME=value some_command sets the variable just for that one process, then it's gone.
• Current shell session: export NAME=value makes it available to this shell and anything it launches, until you log out or close the terminal.
• Every future session: add the export line to a shell startup file, like ~/.bashrc or ~/.bash_profile, so it's set automatically every time you log in.

Check what's currently set with printenv or env. Check a single variable with echo $NAME. Remove one from the current session with unset NAME.

A common mix-up: shell variables vs. environment variables

Every variable you assign becomes a shell variable, visible to that shell. Only exported variables become environment variables, visible to child processes too. This trips people up when a script calls another script or program and the second one can't see a variable the first one set without exporting it. If you're troubleshooting why a cron job or a script run over SSH behaves differently than the same command typed interactively, this is usually why: non-interactive shells often don't read the same startup files, so exports you only put in ~/.bashrc never get loaded.

Where this matters on shared and WordPress hosting

On shared hosting you get SSH access without root, so you can export variables for your own session and cron jobs, but you can't set anything system-wide for the whole server. If a cron job needs an environment variable, don't rely on it inheriting your interactive shell's exports. Instead, set the variable directly in the Cron Jobs tile's command line, or source a small file at the top of the script that defines and exports what it needs before running the rest of the job.

PHP applications generally don't read shell environment variables the way command-line scripts do. If you need to change how PHP itself behaves (upload limits, memory limits, and similar settings), that's not an environment variable problem: those live in cPanel under Software → MultiPHP INI Editor, not in a shell profile.

Node.js apps run through Setup Node.js App in cPanel. For application-specific variables (database URLs, API keys, and so on), keep them defined and exported in a script your app loads on startup rather than depending on a shell session that isn't always running.

Where this matters on a VPS

With root access on a VPS, standard Linux gives you more room to set variables system-wide, such as /etc/environment for simple key-value pairs read at login, or a file in /etc/profile.d/ ending in .sh for anything that needs real shell logic. This is general root-admin territory rather than a Flashcloud-specific tool, and both locations apply to every user on the server, so use them for values that genuinely belong to the whole machine, like a shared API endpoint, not secrets that should stay scoped to one application or one user's account.

Services managed by systemd don't inherit your shell's exported variables at all, since they aren't started from an interactive login. If a systemd-managed application needs an environment variable, set it in the service's unit file with an Environment= line, or point it at an EnvironmentFile=, and reload the daemon afterward.

Making variables persist correctly

A variable exported only at the prompt disappears the moment that shell closes. For anything you want available every time you log in, put the export line in your shell's startup file and reload it with source ~/.bashrc (or log out and back in) to confirm it takes effect. If you're not sure which startup file your shell reads, check what shell you're running with echo $SHELL, since bash and zsh use different filenames.

Nameserver changes are a separate system entirely from shell environment variables and are handled through the domain's DNS settings, not through export - see our nameservers and DNS provider.