How to set environment variables on your hosting
Without root access, environment variables come from a control panel screen where one exists, or from a .env file your app loads itself.
On shared hosting without root access, environment variables come from one of two places: a dedicated environment variable screen if your control panel offers one, or a .env file your application reads itself. True server-level environment variables — the kind set for the whole system, available before PHP even starts — normally need access to the server's own configuration, which is one of the things root access controls.
Option 1: your control panel's own screen
Some hosting platforms provide an environment variable setting per site, letting you define name and value pairs that PHP can then read with getenv():
<?php
$key = getenv('API_KEY');
If your control panel has this, it is generally the tidiest option, since the values live outside any file that might accidentally end up somewhere it should not — copied into a backup, committed to a repository, or left readable in a folder a browser can request.
Option 2: a .env file the application loads itself
Where no panel-level option exists, applications built with Composer commonly load a .env file at startup using a package such as vlucas/phpdotenv. Frameworks like Laravel do this automatically — see deploying a Laravel application for how its own .env file is structured. A plain PHP project can do the same with a few lines:
<?php
$lines = file('.env', FILE_IGNORE_NEW_LINES | FILE_SKIP_EMPTY_LINES);
foreach ($lines as $line) {
[$name, $value] = explode('=', $line, 2);
putenv(trim($name) . '=' . trim($value));
}
A .env file placed inside a browser-reachable folder can be requested directly by URL unless something specifically blocks it — see using .htaccess for a rule that denies requests to files matching that pattern. It should also never be committed to a Git repository; list it in .gitignore and create the real file directly on each server instead.
What this is actually protecting
Environment variables exist to keep secrets — database passwords, API keys, encryption keys — out of the application's own code, so the same codebase can run with different credentials in different places without editing a single PHP file between them. That separation is one of the basic habits covered in securing a PHP application, and it matters regardless of which of the two methods above you end up using.
Related reading
Point the document root at Laravel's public folder, set up .env, run migrations, and cache the config — what a Laravel deploy needs.
How to use .htaccess on your hosting accountOne file that controls redirects, rewrites and access rules for a whole folder — and one typo in it that can take the site offline.
How to secure a PHP applicationThe handful of defences that stop almost every real attack on a PHP application, and the reasoning behind each one.
How to call an external API from PHPcURL, an authentication header and a decoded JSON response — the three parts of calling any external API from a PHP script.