Deployment & Production Config

From localhost to live

Everything you have built runs on localhost — only you can see it. To show employers or clients, the site must be deployed to a server on the public internet with a real web address. Every paid course ends here, because a project nobody can visit is hard to put on a CV. The good news: PHP is the easiest language to host — cheap shared hosting runs it everywhere.

The simplest path for a beginner: a shared host with cPanel. You upload your files to the public_html folder (by FTP or the web file manager), create a MySQL database in the control panel, and the site is live at your domain.

Keep secrets out of your code

Your database password and API keys must never be hard-coded in files you commit to Git — anyone who sees the code would have them. Instead you use environment variables: secret values stored *on the server*, outside your code. A common approach is a .env file (loaded by a Composer package like vlucas/phpdotenv) that you keep off Git.

# .env  (NEVER committed to Git)
DB_HOST=localhost
DB_NAME=myapp
DB_USER=appuser
DB_PASS=super-secret-password

The .env file lists each secret as NAME=value. You add .env to your .gitignore so it is never uploaded to a public repository. A library reads these into PHP, where you access them with getenv() or $_ENV — so the code refers to $_ENV["DB_PASS"] instead of containing the actual password.

<?php
  // config.php reads secrets from the environment
  $host = $_ENV["DB_HOST"];
  $db   = $_ENV["DB_NAME"];
  $user = $_ENV["DB_USER"];
  $pass = $_ENV["DB_PASS"];

  $pdo = new PDO("mysql:host=$host;dbname=$db", $user, $pass);
?>

Now config.php pulls each value from $_ENV — the secrets live only in the .env on the server, never in the code itself. The same code runs on your laptop and on the live server; only the .env differs. Share the code freely; the secrets stay private.

Production php.ini settings

A live server must behave differently from your development machine. The most important change: stop showing errors to visitors (they leak information and look broken) while still logging them for you.

; php.ini on the LIVE server
display_errors = Off      ; never show errors to visitors
log_errors = On           ; but record them for you
error_log = /var/log/php_errors.log

; on your LOCAL machine you want the opposite:
; display_errors = On      ; so you can see and fix problems

On the live server, display_errors = Off ensures a visitor never sees a raw PHP warning (which could reveal file paths or query details). log_errors = On with an error_log path means those problems are quietly written to a file you can read. On your own machine you flip display_errors back On, because there you *want* to see errors immediately to fix them.