A PHP site can work on your laptop and still fail the moment it reaches a server. Most small teams host PHP website code on shared hosting first, then discover the server uses a different PHP version, folder structure, or database setting.
The fix is a controlled setup. Pick the right hosting model, upload only the public files, connect the database, then test the live path before you send traffic.
Start by choosing the amount of server control your site actually needs.
CHOOSE THE RIGHT WAY TO HOST A PHP WEBSITE
Your hosting plan controls what you can change. It also controls who handles patches, backups, server errors, and PHP upgrades.
Don’t buy a VPS because it sounds more professional. A poorly maintained VPS creates more risk than a well-managed shared plan.
Shared hosting with cPanel works for simple sites
Shared hosting is the lowest-cost option for a brochure site, small custom portal, WordPress plugin, or basic PHP application. Your account shares a physical server with other customers, but each account has separate files and databases.
cPanel usually gives you File Manager, FTP or SFTP access, database tools, email settings, cron jobs, and a PHP version selector. The primary domain often points to public_html.
Resource limits matter. Shared accounts can cap CPU time, memory, concurrent processes, and file count. A small contact form is fine. A data-heavy app that runs long reports may hit those limits.
Use shared hosting when you want a simple control panel and don’t need to manage Linux server software.
Managed hosting reduces server work
Managed hosting costs more because the provider handles more of the operating work. Plans often include backups, SSL, PHP updates, caching, staging sites, firewall rules, and support for application errors.
This option suits a business site where downtime costs more than the hosting bill. It also helps when your team doesn’t have someone who can fix Nginx, PHP-FPM, or database service failures at midnight.
Managed platforms can restrict plugins, extensions, shell access, and custom server settings. Check those rules before moving a custom application.
VPS hosting gives control and responsibility
A VPS gives you a virtual server with admin or root access. You choose the web server, PHP version, database server, firewall, backups, and deployment process.
A common stack is Nginx, PHP-FPM, and MariaDB. Apache with PHP-FPM also works. You can configure the server around your application instead of working around shared-host limits.
A VPS is not “set and forget” hosting. You own patching, backups, access control, monitoring, and recovery unless you pay for a managed VPS.
Use a VPS when your app needs custom services, predictable resources, private networking, or server-level configuration.
CHECK THE PHP APP BEFORE YOU UPLOAD FILES
Don’t start with File Manager. First confirm what the application requires.
Read the app’s installation file, composer.json, framework documentation, and environment sample file. A Laravel application, for example, needs a web root that points to its public folder. Uploading the entire project into public_html can expose files that should stay private.
Match the PHP version and extensions
PHP versions vary by provider. A host may offer PHP 8.3 and 8.4 while another has PHP 8.5 available. The latest version isn’t always the correct choice if your application or plugin has not been tested on it.
Check the official PHP supported versions page before selecting a runtime. In September 2026, PHP 8.2, 8.3, 8.4, and 8.5 have active support status. PHP 8.2 security support ends on December 31, 2026.
Your app may also need extensions such as:
pdo_mysqlormysqlifor MySQL and MariaDB connections.mbstringfor multibyte text handling.openssl,curl,zip,gd, orimagickfor common web features.intlfor dates, currencies, and localized text.
Use the host’s current documentation to confirm which extensions are enabled. On many cPanel accounts, a PHP selector controls versions and extensions. For one example of how provider interfaces can differ, review this guide to managing PHP settings in cPanel.
Prepare the deployment record
Keep a small deployment record before changes go live. Store the domain, document root, PHP version, database name, database host, deployment date, and backup location.
Also record the last working version of the site. If an update fails, you need a known rollback point. Don’t depend on memory or an old browser tab.
SET UP THE DOMAIN, SSL, AND DOCUMENT ROOT
A domain only works after its DNS points to the correct hosting account. If you bought the domain elsewhere, update the A record or nameservers based on your host’s instructions.
DNS changes can take time to appear worldwide. Test with the temporary URL or hosts file only if your provider supports it. Don’t keep changing DNS records while waiting. That creates a harder problem to diagnose.
Point visitors to the public folder
The document root is the folder your web server exposes to visitors. On basic cPanel hosting, the primary domain commonly uses public_html.
That is not always the correct application folder.
| Application type | Typical web-accessible folder |
|---|---|
| Basic PHP site | public_html |
| Laravel application | public/ |
| Symfony application | public/ |
| WordPress install | The WordPress install directory |
For a Laravel app, keep .env, vendor, storage, and application source files outside the public web folder when possible. Point the domain to the project’s public directory.
If shared hosting won’t let you set a custom document root, place the private application files above public_html, then copy only the public entry files into the web directory. Update paths carefully. A wrong autoload.php path can cause a 500 error.
Turn on HTTPS before collecting data
Install a valid TLS certificate before using logins, contact forms, payment links, or admin tools. Most hosts provide free Let’s Encrypt certificates, but activation steps vary.
Set a single canonical site address. Choose either https://example.com or https://www.example.com, then redirect the other version. Mixed URLs create login, cookie, and search indexing problems.
UPLOAD FILES AND RUN THE APPLICATION INSTALL
When you host PHP website files, use SFTP or SSH when available. File Manager is acceptable for a small upload, but it becomes slow and error-prone for frequent releases.
Don’t upload local junk. Exclude .git, old backup archives, editor files, local database dumps, and private configuration files.
Use Composer correctly
Modern PHP applications often depend on Composer packages. If the host gives you SSH access, run:
composer install --no-dev --optimize-autoloader
Run that command from the project directory, not the public folder. The --no-dev flag avoids deploying development-only packages to production.
If your shared host has no SSH, build dependencies on a matching environment and upload the generated vendor folder. This works, but it is less reliable than running Composer on the server.
Don’t run composer update during a production deployment unless you intend to change dependency versions. Use the locked versions from composer.lock.
Configure environment values
Most modern apps store live settings in .env. Add the production site URL, database credentials, mail settings, cache driver, and environment mode.
Set production mode. Laravel uses APP_ENV=production and APP_DEBUG=false. Other frameworks have equivalent settings.
Never upload a local .env file with test API keys, personal email credentials, or database passwords. Create a separate production configuration file.
CREATE THE DATABASE AND CONNECT THE SITE
Most PHP applications use MySQL or MariaDB. You need three things: a database, a database user, and permission for that user to access the database.
On cPanel, use MySQL Databases or the Database Wizard. The cPanel Database Wizard documentation shows the normal sequence: create the database, create a user, then assign privileges.
Use the exact database names cPanel creates
cPanel often adds your account prefix to names. You may enter store_app, but cPanel creates something like account_store_app.
The same can happen to the username. Copy the final values exactly into your config file.
A typical PHP configuration needs values like these:
- Database host, often
localhoston shared hosting. - Database name, including any account prefix.
- Database username, including any account prefix.
- A strong database password.
- Database port, usually
3306unless the provider states otherwise.
Use a unique password for each database user. Don’t reuse your cPanel password. Store credentials in approved password storage, not in a public task board, email thread, or Git repository.
Import data before testing the live site
If you are moving an existing website, export the database from the old host and import it into the new one with phpMyAdmin or a command-line tool.
Then update the application URL and database settings. WordPress migrations may also require search-and-replace work because its site address appears in several database fields.
Take a backup before importing. A wrong import can overwrite tables without an easy undo button.
LOCK DOWN PERMISSIONS AND SECRETS
PHP sites need readable files. They do not need open access to every folder.
Use 644 for normal files and 755 for directories as a starting point. Writable application folders may need 775 or 750, depending on the server ownership model.
Give write access only where the app needs it
Common writable folders include upload, cache, session, and log directories. Laravel often needs write access to storage and bootstrap/cache.
Don’t set your whole website to 777. That makes files world-writable and can expose the account to abuse. If a folder fails to write, check the file owner and group first.
On a VPS, the deploy user and web-server user may differ. Solve that ownership mismatch instead of opening every permission.
Keep private files outside web access
Your .env file, database dump, backups, logs, and source configuration should not be reachable from a browser. Put them above the document root where the hosting setup allows it.
Also disable directory listing. A visitor should never be able to browse an uploads folder or find a backup archive because no index file exists.
FIX 404, 500, AND DATABASE CONNECTION ERRORS
Don’t guess at an error. Read the response code, check the server error log, then change one item at a time.
Keep a record of the URL, time, error message, recent change, and screenshot. That gives support or your developer something they can reproduce.
A 404 usually points to the wrong path
A 404 means the web server cannot find the route or file it expects. Check that the domain has the correct document root and that index.php exists in that folder.
For framework apps, confirm the domain points to public, not the project root. On Apache or LiteSpeed, also check .htaccess rewrite rules. On Nginx, review the site configuration and PHP location block.
Linux hosting is case-sensitive. Index.php and index.php are different files.
A 500 error is usually a server or PHP failure
A 500 error often comes from invalid PHP code, an unsupported PHP version, a missing extension, broken .htaccess rules, bad permissions, or exhausted memory.
First, read the error log. It may identify a missing class, syntax error, denied file write, or memory limit.
If the issue started after a PHP upgrade, switch back to the previous working version while you test compatibility. Don’t leave an old unsupported version in place long-term. Update the application and dependencies, then retest on a supported release.
Database errors usually come from copied credentials
“Error establishing a database connection” often means the database name, username, password, or host is wrong. It is common after a site moves to another cPanel account.
Check the exact values in your config file. Then confirm the database user is assigned to the database with the required privileges. The cPanel MySQL database guide covers user and database management within the panel.
If the credentials are correct, check whether the database service is running and whether the host requires a nonstandard database hostname.
FINAL CHECKS BEFORE YOU SHARE THE URL
Open the site in an incognito window. Test the home page, contact form, login, upload path, password reset, and any payment or booking flow.
Then check mobile pages. Confirm every important URL uses HTTPS and no browser security warnings appear.
A successful deployment is not only a page that loads. It is a site that can read its database, write only to approved folders, protect credentials, and recover after a bad update.
CONCLUSION
To host PHP website projects safely, match the hosting plan to the app, confirm its PHP requirements, and point the domain at the correct public folder.
Shared cPanel hosting is enough for many small sites. Managed hosting reduces operational work. A VPS gives full control, but it also gives you full responsibility.
Keep a backup, protect configuration files, and test each live change before your customers find the error first.
