Hosting a custom PHP application properly requires more than uploading files to a server. A stable production setup should cover the runtime version, web server configuration, document root, dependencies, environment variables, file permissions, caching, background jobs, logging, and backups. When these pieces are aligned, your application becomes easier to maintain, safer to update, and more resilient under real traffic.
This guide explains how to host a custom PHP application in a production environment using a hosting platform or control panel such as Plesk. It is useful whether you are deploying a small internal tool, a client portal, or a larger application built with plain PHP or a custom framework.
Choose the right hosting environment
The first step is selecting an environment that matches the needs of your application. A custom PHP app can run on shared hosting, a VPS, or a managed hosting platform, but not every option is equally suitable for production.
When shared hosting is enough
Shared hosting can work for lightweight applications with modest traffic, especially if the app is mostly read-only, has few background tasks, and uses standard PHP extensions. It is usually the simplest option when you need:
- One website or a small number of domains
- Managed PHP versions and basic database support
- Simple deployment through a control panel
- Lower operating overhead
When you should use a VPS or managed hosting
If your app has queues, cron jobs, WebSocket services, custom server rules, or higher traffic, a VPS or managed hosting platform is typically a better fit. You get more control over PHP workers, system resources, process management, and security settings.
For production applications, look for:
- Support for multiple PHP versions
- SSH access and deployment tools
- Configurable memory limits and execution time
- Database management and backups
- SSL/TLS support and security hardening options
Prepare the application for production
Before uploading anything, confirm that your codebase is ready for deployment. A custom PHP application should behave differently in production than in development.
Separate development and production settings
Never keep development values in your live environment. Use environment-specific configuration for database credentials, API keys, cache drivers, mail settings, and debug flags. In production, debug output should be disabled or minimized.
Common production settings include:
- Debug mode disabled
- Production database credentials
- Real SMTP or transactional mail service settings
- Cache and session storage configured for production
- Logging enabled with appropriate retention
Install dependencies before deployment
If your application uses Composer, install dependencies with the production flag so development packages are excluded. This reduces risk and keeps the deployment lighter.
- Use a fixed Composer lock file
- Deploy tested versions only
- Do not update dependencies directly on production unless necessary
For framework-based projects, also verify that the framework caches, compiled templates, or generated assets are created correctly before going live.
Set the correct PHP version and extensions
A common reason for deployment issues is an incompatible PHP version. Check the application requirements first, then configure the hosting environment accordingly. Many hosting panels, including Plesk, let you select a PHP version per domain.
Match the runtime to the application
Always compare your app’s minimum PHP version with the version available on the server. If the codebase was developed on PHP 8.2, do not deploy it to an older runtime. Production stability depends on compatibility at both the language and extension level.
Enable required PHP extensions
Most custom PHP applications rely on a specific set of extensions. Common examples include:
- pdo_mysql or pdo_pgsql
- mbstring
- openssl
- curl
- intl
- zip
- gd or imagick
- xml and json
If you use a control panel, check the PHP settings for the domain and enable only what the application needs. This keeps the environment clean and easier to troubleshoot.
Configure the document root correctly
One of the most important production steps is pointing the web server to the correct document root. For many PHP applications, the public-facing files should be in a dedicated public or htdocs directory, not in the project root.
Use a public directory for web access
A proper structure often looks like this:
/appfor source code/publicfor index.php, assets, and web-accessible files/storageor/varfor logs, uploads, and temporary data
This setup helps protect sensitive files such as configuration, source code, and internal scripts from direct access.
Check routing and rewrite rules
Most custom PHP applications need URL rewriting so requests are routed through a front controller. On Apache, this usually means enabling rewrite rules through .htaccess. On Nginx, it requires an equivalent server block configuration.
If you are using Plesk or a similar panel, confirm that:
- Pretty URLs are supported
- The rewrite configuration is active
- Requests to missing files are redirected to the application entry point
Set file permissions and ownership safely
Incorrect permissions can break the application or create security risks. The goal is to allow the web server to read the necessary files and write only where needed.
Use least-privilege permissions
General guidance for production PHP applications:
- Code files should usually be read-only for the web server
- Writable directories should be limited to uploads, cache, and logs
- Configuration files should not be writable from the browser
Avoid setting broad permissions like 777. That may appear to solve upload problems, but it increases the attack surface and can cause ownership issues later.
Review ownership after deployment
If files are uploaded via SFTP, Git deployment, or a CI pipeline, verify that the correct user owns the project files. On managed hosting platforms, the application owner and the web server user should be aligned as much as possible to avoid permission conflicts.
Configure environment variables and secrets
Custom PHP applications often store runtime values in environment files or server-level variables. This is the preferred approach for sensitive information because it keeps secrets out of the source code repository.
What should be stored as variables
- Database credentials
- Application key or encryption key
- Mail server settings
- External API credentials
- Cache and session connection settings
If your hosting platform supports it, configure these values in the control panel instead of hardcoding them in the application. This makes it easier to rotate credentials and manage different environments.
Protect secret files
If your app uses a file like .env, ensure it is not accessible from the web. The file should stay outside the public directory, and the web server should not expose it through directory listing or misconfigured rules.
Set up the database properly
Most PHP applications depend on MySQL, MariaDB, or PostgreSQL. A production database should be created, secured, and backed up separately from the application code.
Create a dedicated database and user
Do not use a shared root account for the application. Instead, create a dedicated database and a restricted user account with only the required privileges. In many hosting panels, this can be done from the database management section.
Recommended practice:
- One database per application when possible
- One dedicated user for that database
- Strong passwords stored securely
- Limited privileges instead of full administrative access
Check collation, charset, and engine settings
Before launch, verify that the database uses the correct character set, especially if your app supports multilingual content or user-generated input. UTF-8 support should be configured consistently across the app and database.
Handle caching and performance early
Performance is not only about server hardware. A custom PHP application should use caching intelligently to reduce load and improve response times.
Common caching layers
- Opcode cache such as OPcache
- Application-level cache for query results or rendered pages
- Object cache or memory cache if the app supports it
- Browser caching for static assets
OPcache is especially important for PHP production environments. Make sure it is enabled and tuned for your server resources. If your application has its own caching system, configure cache directories to be writable and monitored.
Optimize assets and response time
Compress and minify frontend assets where appropriate, and serve static files with sensible cache headers. If your hosting platform supports HTTP/2 or HTTP/3, enable it to improve delivery of assets such as CSS, JavaScript, and images.
Plan for cron jobs and background processes
Many custom PHP applications need scheduled jobs for imports, notifications, cleanup tasks, reports, or queue processing. These should not be triggered by users visiting the site.
Use system cron or panel scheduler
In production, schedule tasks through cron or the hosting control panel. For example, a Laravel or Symfony app may need commands run every minute, hourly, or nightly.
- Run scheduled tasks through the server scheduler
- Separate frequent tasks from expensive ones
- Log job output for troubleshooting
Keep long-running tasks outside the web request
Background work such as email sending, PDF generation, image processing, and API synchronization should be handled asynchronously when possible. This prevents slow page loads and request timeouts.
Configure logging and monitoring
Reliable production hosting depends on knowing what is happening on the server. Logs help you detect configuration errors, failed requests, database issues, and application exceptions.
Log what matters
Your application should log errors, warnings, and important operational events. Good log hygiene includes:
- Separate application and server logs
- Log rotation to avoid disk usage problems
- Clear timestamps and context for each error
- Restricted access to logs because they may contain sensitive data
Monitor resource usage
Watch CPU, RAM, disk usage, and database load after deployment. Sudden spikes can indicate inefficient queries, runaway cron jobs, or traffic patterns that require scaling. In a managed hosting environment or Plesk panel, resource monitoring can often be checked directly from the dashboard.
Secure the application before going live
Security should be part of the deployment process, not an afterthought. A properly hosted PHP application should reduce unnecessary exposure.
Enable HTTPS
Install an SSL certificate and redirect all traffic to HTTPS. This protects user sessions and sensitive data and is also important for SEO and trust.
Disable directory listing and expose only public files
Ensure the web root contains only files that are meant to be public. Block access to configuration files, backups, log files, and development assets.
Keep software updated
Regularly update the PHP version, framework, libraries, and server packages. When possible, test updates in staging before applying them to production.
Recommended deployment checklist
Before launching a custom PHP application, review this checklist:
- Correct PHP version selected
- Required PHP extensions enabled
- Document root points to the public directory
- Rewrite rules configured and tested
- Production environment variables set
- Database created with a restricted user
- Composer dependencies installed for production
- Writable directories verified
- HTTPS enabled and redirects working
- Cron jobs and background processes scheduled
- Logs and backups configured
- Debug mode disabled
Common hosting mistakes to avoid
Many production issues come from a few repeated mistakes. Avoid these when hosting a custom PHP application:
- Placing the entire application inside the public directory
- Leaving development credentials in production
- Using a PHP version that is too old or untested
- Setting insecure file permissions
- Running background jobs through the browser
- Skipping backups before deployment
- Ignoring log files until something breaks
Addressing these items early saves time and reduces the risk of downtime.
FAQ
Can I host a custom PHP application on shared hosting?
Yes, if the application is lightweight and does not need special services or heavy background processing. For more demanding apps, a VPS or managed hosting platform is usually more suitable.
What is the best document root for a PHP app?
In most cases, the document root should point to the public directory only, such as public or htdocs. This keeps private files outside web access.
Do I need Composer on production?
If the application uses Composer-managed dependencies, yes. The usual approach is to install dependencies during deployment with production settings, not manually edit packages on the live server.
How do I know which PHP extensions my app needs?
Check the application documentation, framework requirements, and any error messages during startup. Common extensions include mbstring, curl, openssl, intl, zip, and database drivers.
Should I use .htaccess or server configuration?
Either can work depending on the web server. Apache often uses .htaccess, while Nginx uses server-level rewrite rules. In a managed environment, the hosting panel may generate or help configure these rules.
How often should I back up the application?
It depends on how often the data changes. Daily backups are a good baseline for many production sites, while transactional systems may need more frequent snapshots or database dumps.
Conclusion
Hosting a custom PHP application properly means treating deployment as an operational process, not just a file transfer. The most important steps are choosing the right hosting environment, matching the PHP runtime, securing the document root, setting safe permissions, configuring environment variables, and planning for logs, caching, cron jobs, and backups.
Whether you manage the site through a control panel like Plesk or work directly on a VPS, a structured production setup makes your application easier to support and safer to scale. If you follow the checklist in this guide, you will have a much stronger foundation for running custom PHP applications in a real hosting environment.