{"id":4611,"date":"2026-02-06T16:03:03","date_gmt":"2026-02-06T13:03:03","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/best-php-ini-settings-for-wordpress-and-laravel-on-shared-hosting-and-vps\/"},"modified":"2026-02-06T16:03:03","modified_gmt":"2026-02-06T13:03:03","slug":"best-php-ini-settings-for-wordpress-and-laravel-on-shared-hosting-and-vps","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/best-php-ini-settings-for-wordpress-and-laravel-on-shared-hosting-and-vps\/","title":{"rendered":"Best php.ini Settings for WordPress and Laravel on Shared Hosting and VPS"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>If you run WordPress or Laravel on shared hosting or a <a href=\"https:\/\/www.dchost.com\/vps\">VPS<\/a>, your php.ini settings quietly decide whether your site feels fast and stable or slow and fragile. The application code, database and caching are important, but PHP itself is the engine that executes every request. If the engine is misconfigured, you get timeouts, white screens, failed uploads, random 500 errors and resource\u2011limit warnings \u2013 even on good hosting hardware.<\/p>\n<p>In this guide, we will walk through the most important php.ini directives for WordPress and Laravel, explain what they actually do and give concrete, tested values for typical site sizes on both shared hosting and VPS plans. We will also highlight where shared hosting limits stop you, when it makes sense to move to a VPS, and how we set things up in practice when deploying projects on dchost.com infrastructure. You can treat this as a checklist: compare it with your current settings, adjust carefully, and you will usually see an immediate improvement in stability and developer happiness.<\/p>\n<div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#Why_phpini_Matters_So_Much_for_WordPress_and_Laravel\"><span class=\"toc_number toc_depth_1\">1<\/span> Why php.ini Matters So Much for WordPress and Laravel<\/a><\/li><li><a href=\"#Where_and_How_You_Can_Edit_phpini_on_Shared_Hosting_and_VPS\"><span class=\"toc_number toc_depth_1\">2<\/span> Where and How You Can Edit php.ini on Shared Hosting and VPS<\/a><ul><li><a href=\"#On_shared_hosting_cPanel_DirectAdmin_style\"><span class=\"toc_number toc_depth_2\">2.1<\/span> On shared hosting (cPanel \/ DirectAdmin style)<\/a><\/li><li><a href=\"#On_a_VPS_root_sudo_access\"><span class=\"toc_number toc_depth_2\">2.2<\/span> On a VPS (root \/ sudo access)<\/a><\/li><\/ul><\/li><li><a href=\"#Core_phpini_Settings_for_Any_Modern_WordPress_or_Laravel_Site\"><span class=\"toc_number toc_depth_1\">3<\/span> Core php.ini Settings for Any Modern WordPress or Laravel Site<\/a><ul><li><a href=\"#1_memory_limit\"><span class=\"toc_number toc_depth_2\">3.1<\/span> 1. memory_limit<\/a><\/li><li><a href=\"#2_max_execution_time_and_max_input_time\"><span class=\"toc_number toc_depth_2\">3.2<\/span> 2. max_execution_time and max_input_time<\/a><\/li><li><a href=\"#3_upload_max_filesize_and_post_max_size\"><span class=\"toc_number toc_depth_2\">3.3<\/span> 3. upload_max_filesize and post_max_size<\/a><\/li><li><a href=\"#4_max_input_vars\"><span class=\"toc_number toc_depth_2\">3.4<\/span> 4. max_input_vars<\/a><\/li><li><a href=\"#5_datetimezone\"><span class=\"toc_number toc_depth_2\">3.5<\/span> 5. date.timezone<\/a><\/li><li><a href=\"#6_OPcache_and_performancerelated_settings\"><span class=\"toc_number toc_depth_2\">3.6<\/span> 6. OPcache and performance\u2011related settings<\/a><\/li><\/ul><\/li><li><a href=\"#Recommended_phpini_Settings_for_WordPress_on_Shared_Hosting\"><span class=\"toc_number toc_depth_1\">4<\/span> Recommended php.ini Settings for WordPress on Shared Hosting<\/a><ul><li><a href=\"#Baseline_phpini_for_a_smalltomedium_WordPress_site\"><span class=\"toc_number toc_depth_2\">4.1<\/span> Baseline php.ini for a small\u2011to\u2011medium WordPress site<\/a><\/li><li><a href=\"#WordPress_staging_and_maintenance_tools\"><span class=\"toc_number toc_depth_2\">4.2<\/span> WordPress staging and maintenance tools<\/a><\/li><li><a href=\"#Debug_settings_for_development_vs_production\"><span class=\"toc_number toc_depth_2\">4.3<\/span> Debug settings for development vs production<\/a><\/li><\/ul><\/li><li><a href=\"#Recommended_phpini_Settings_for_Laravel_on_Shared_Hosting_and_VPS\"><span class=\"toc_number toc_depth_1\">5<\/span> Recommended php.ini Settings for Laravel on Shared Hosting and VPS<\/a><ul><li><a href=\"#Laravel_on_shared_hosting\"><span class=\"toc_number toc_depth_2\">5.1<\/span> Laravel on shared hosting<\/a><\/li><li><a href=\"#Laravel_on_a_VPS_separating_web_and_CLI_behaviour\"><span class=\"toc_number toc_depth_2\">5.2<\/span> Laravel on a VPS: separating web and CLI behaviour<\/a><\/li><\/ul><\/li><li><a href=\"#Debugging_Logging_and_Security_Options_in_phpini\"><span class=\"toc_number toc_depth_1\">6<\/span> Debugging, Logging and Security Options in php.ini<\/a><ul><li><a href=\"#Error_reporting_levels\"><span class=\"toc_number toc_depth_2\">6.1<\/span> Error reporting levels<\/a><\/li><li><a href=\"#Log_file_placement_and_rotation\"><span class=\"toc_number toc_depth_2\">6.2<\/span> Log file placement and rotation<\/a><\/li><li><a href=\"#Securityrelated_directives_worth_checking\"><span class=\"toc_number toc_depth_2\">6.3<\/span> Security\u2011related directives worth checking<\/a><\/li><\/ul><\/li><li><a href=\"#PHP_Version_and_Compatibility_WordPress_Laravel_and_PHP_8x\"><span class=\"toc_number toc_depth_1\">7<\/span> PHP Version and Compatibility: WordPress, Laravel and PHP 8.x<\/a><\/li><li><a href=\"#Tuning_for_Growth_When_to_Raise_Limits_and_When_to_Move_to_a_VPS\"><span class=\"toc_number toc_depth_1\">8<\/span> Tuning for Growth: When to Raise Limits and When to Move to a VPS<\/a><\/li><li><a href=\"#Summary_and_Next_Steps\"><span class=\"toc_number toc_depth_1\">9<\/span> Summary and Next Steps<\/a><\/li><\/ul><\/div>\n<h2><span id=\"Why_phpini_Matters_So_Much_for_WordPress_and_Laravel\">Why php.ini Matters So Much for WordPress and Laravel<\/span><\/h2>\n<p>Both WordPress and Laravel are written in PHP. Every page view, API call, cron job, Artisan command or WooCommerce checkout runs inside a PHP process that is governed by php.ini. That file (plus a few .ini overrides) defines hard limits and default behaviour for:<\/p>\n<ul>\n<li><strong>How much RAM<\/strong> each PHP process can use (<code>memory_limit<\/code>).<\/li>\n<li><strong>How long scripts may run<\/strong> before they are killed (<code>max_execution_time<\/code> and <code>max_input_time<\/code>).<\/li>\n<li><strong>How large uploads<\/strong> and forms can be (<code>upload_max_filesize<\/code>, <code>post_max_size<\/code>, <code>max_input_vars<\/code>).<\/li>\n<li><strong>How errors are handled<\/strong> (<code>error_reporting<\/code>, <code>display_errors<\/code>, <code>log_errors<\/code>).<\/li>\n<li><strong>How sessions and cookies behave<\/strong> (session\u2011related directives and security flags).<\/li>\n<li><strong>Which PHP extensions and accelerators<\/strong> are available (like OPcache).<\/li>\n<\/ul>\n<p>The same code can behave very differently depending on these values. For example, a WooCommerce checkout with a big cart might work fine with a <code>256M<\/code> memory limit but constantly fail with <code>64M<\/code>. A Laravel import job may need a higher <code>max_execution_time<\/code> and a larger <code>post_max_size<\/code> to process CSV uploads.<\/p>\n<p>We have a separate deep dive on the individual PHP resource limits in our article <a href=\"https:\/\/www.dchost.com\/blog\/en\/php-ayarlarini-dogru-yapmak-memory_limit-max_execution_time-ve-upload_max_filesize-kac-olmali\/\">Choosing the right <code>memory_limit<\/code>, <code>max_execution_time<\/code> and <code>upload_max_filesize<\/code><\/a>. Here, we focus specifically on the combination of settings that tends to work best for WordPress and Laravel on shared hosting and VPS.<\/p>\n<h2><span id=\"Where_and_How_You_Can_Edit_phpini_on_Shared_Hosting_and_VPS\">Where and How You Can Edit php.ini on Shared Hosting and VPS<\/span><\/h2>\n<h3><span id=\"On_shared_hosting_cPanel_DirectAdmin_style\">On shared hosting (cPanel \/ DirectAdmin style)<\/span><\/h3>\n<p>On most shared hosting platforms, you do not edit the global server php.ini directly. Instead, you typically have one or more of these options:<\/p>\n<ul>\n<li><strong>Per\u2011account php.ini or .user.ini:<\/strong> Many panels let you customize certain directives for your account or per directory by adding a <code>php.ini<\/code> or <code>.user.ini<\/code> in <code>public_html\/<\/code>. The server merges those with the global defaults.<\/li>\n<li><strong>GUI editor in the control panel:<\/strong> cPanel often has a \u201cSelect PHP Version\u201d or \u201cMultiPHP INI Editor\u201d section where you can change the most common settings without touching files manually.<\/li>\n<li><strong>.htaccess overrides:<\/strong> On Apache with mod_php, some directives can be changed via <code>.htaccess<\/code> using <code>php_value<\/code> and <code>php_flag<\/code>. On modern setups (PHP\u2011FPM), this is less common and .user.ini is preferred.<\/li>\n<\/ul>\n<p>Remember that shared hosting also enforces <strong>account\u2011level resource limits<\/strong> (CPU, RAM, I\/O, entry processes). Even if you bump <code>memory_limit<\/code> in php.ini, you cannot exceed the account\u2019s real memory allocation. If you often see \u201cResource Limit Reached\u201d, it\u2019s worth reviewing our article <a href=\"https:\/\/www.dchost.com\/blog\/en\/cpanel-kaynak-limitleri-nedir-cpu-io-ram-ve-entry-processes-limitlerini-dogru-okumak\/\">Understanding cPanel resource limits<\/a>.<\/p>\n<h3><span id=\"On_a_VPS_root_sudo_access\">On a VPS (root \/ sudo access)<\/span><\/h3>\n<p>On a VPS, you (or your sysadmin) control the full PHP stack. Typical locations:<\/p>\n<ul>\n<li><code>\/etc\/php\/8.2\/fpm\/php.ini<\/code> \u2013 PHP\u2011FPM for web requests.<\/li>\n<li><code>\/etc\/php\/8.2\/cli\/php.ini<\/code> \u2013 CLI PHP for <code>php artisan<\/code> and <code>wp-cli<\/code>.<\/li>\n<li><code>\/etc\/php\/8.2\/mods-available\/*.ini<\/code> \u2013 individual extension configs.<\/li>\n<\/ul>\n<p>After changing php.ini on a VPS, you must restart or reload PHP\u2011FPM (and sometimes the web server):<\/p>\n<ul>\n<li><code>systemctl reload php8.2-fpm<\/code> (Debian\/Ubuntu).<\/li>\n<li><code>systemctl restart php-fpm<\/code> (AlmaLinux \/ Rocky Linux with generic service names).<\/li>\n<\/ul>\n<p>One common mistake with Laravel is forgetting that the CLI and FPM have <strong>separate php.ini files<\/strong>. Long\u2011running queue workers or schedulers use <code>\/etc\/php\/*\/cli\/php.ini<\/code>, so you may need a higher <code>memory_limit<\/code> or a different <code>max_execution_time<\/code> there than in the web SAPI. We use this separation intentionally in many Laravel deployments on our VPS plans.<\/p>\n<h2><span id=\"Core_phpini_Settings_for_Any_Modern_WordPress_or_Laravel_Site\">Core php.ini Settings for Any Modern WordPress or Laravel Site<\/span><\/h2>\n<p>Let\u2019s look at the essential directives you should review for any WordPress or Laravel project, regardless of hosting type.<\/p>\n<h3><span id=\"1_memory_limit\">1. memory_limit<\/span><\/h3>\n<p><code>memory_limit<\/code> caps how much RAM each PHP process can use. If a script exceeds it, PHP throws a fatal \u201cAllowed memory size exhausted\u201d error.<\/p>\n<ul>\n<li><strong>Too low:<\/strong> random white screens, WooCommerce admin pages failing, large Elementor pages or Laravel collections causing fatal errors.<\/li>\n<li><strong>Too high on shared hosting:<\/strong> a single heavy request can eat too much of your account\u2019s limited RAM and impact other sites.<\/li>\n<\/ul>\n<p>Practical ranges we see work well:<\/p>\n<table border=\"1\" cellpadding=\"6\" cellspacing=\"0\">\n<tr>\n<th>Use case<\/th>\n<th>Suggested memory_limit<\/th>\n<\/tr>\n<tr>\n<td>Small WordPress blog (shared)<\/td>\n<td>128M<\/td>\n<\/tr>\n<tr>\n<td>WooCommerce \/ page builders (shared)<\/td>\n<td>256M<\/td>\n<\/tr>\n<tr>\n<td>Medium WordPress or Laravel app on VPS<\/td>\n<td>256M \u2013 512M<\/td>\n<\/tr>\n<tr>\n<td>Heavy Laravel jobs \/ imports (CLI)<\/td>\n<td>512M \u2013 1024M (per worker)<\/td>\n<\/tr>\n<\/table>\n<p>On a VPS, aligning <code>memory_limit<\/code> with PHP\u2011FPM pool settings is important so you do not overcommit RAM. We break this down in more detail in our PHP\u2011FPM and Laravel tuning articles, such as <a href=\"https:\/\/www.dchost.com\/blog\/en\/laravel-prod-ortam-optimizasyonu-nasil-yapilir-php%E2%80%91fpm-opcache-octane-queue-horizon-ve-redisi-el-ele-calistirmak\/\">Laravel production optimization with PHP\u2011FPM and OPcache<\/a>.<\/p>\n<h3><span id=\"2_max_execution_time_and_max_input_time\">2. max_execution_time and max_input_time<\/span><\/h3>\n<p><code>max_execution_time<\/code> sets how long (in seconds) a script is allowed to run before PHP terminates it. <code>max_input_time<\/code> controls how long PHP may spend parsing input data (POST\/GET files). Example ranges:<\/p>\n<ul>\n<li>Front\u2011end page views: 30\u201360s is usually enough. If a page takes longer, the bottleneck is elsewhere.<\/li>\n<li>WordPress plugin updates or WooCommerce imports: 120\u2013300s on shared hosting can be helpful.<\/li>\n<li>Laravel queue workers: often set to <code>0<\/code> (unlimited) and controlled by Supervisor\/systemd instead.<\/li>\n<\/ul>\n<p>On shared hosting you may not be allowed to set extremely high values. On a VPS, you have more freedom, but hanging scripts will still waste resources, so do not just set everything to \u201cunlimited\u201d.<\/p>\n<h3><span id=\"3_upload_max_filesize_and_post_max_size\">3. upload_max_filesize and post_max_size<\/span><\/h3>\n<p>These two work together:<\/p>\n<ul>\n<li><code>upload_max_filesize<\/code> \u2013 maximum size of a single uploaded file.<\/li>\n<li><code>post_max_size<\/code> \u2013 maximum size of the full POST body (all files + form fields).<\/li>\n<\/ul>\n<p><code>post_max_size<\/code> should be at least as large as <code>upload_max_filesize<\/code>, usually a bit higher (for form overhead).<\/p>\n<table border=\"1\" cellpadding=\"6\" cellspacing=\"0\">\n<tr>\n<th>Scenario<\/th>\n<th>upload_max_filesize<\/th>\n<th>post_max_size<\/th>\n<\/tr>\n<tr>\n<td>Simple blog, small images<\/td>\n<td>8M \u2013 16M<\/td>\n<td>16M \u2013 32M<\/td>\n<\/tr>\n<tr>\n<td>WooCommerce store with product images<\/td>\n<td>32M \u2013 64M<\/td>\n<td>64M \u2013 96M<\/td>\n<\/tr>\n<tr>\n<td>WordPress media\u2011heavy \/ video uploads<\/td>\n<td>128M+<\/td>\n<td>128M \u2013 256M<\/td>\n<\/tr>\n<tr>\n<td>Laravel APIs importing CSV \/ XLSX<\/td>\n<td>64M \u2013 256M<\/td>\n<td>128M \u2013 512M<\/td>\n<\/tr>\n<\/table>\n<p>If you plan frequent large uploads, also think about web server timeouts, browser behaviour and chunked uploads. We cover full upload strategy in <a href=\"https:\/\/www.dchost.com\/blog\/en\/buyuk-medya-dosyalari-icin-yukleme-stratejisi-php-nginx-apache-ve-cdn-ile-parcali-upload\/\">our guide to large media file uploads with PHP, Nginx\/Apache and chunking<\/a>.<\/p>\n<h3><span id=\"4_max_input_vars\">4. max_input_vars<\/span><\/h3>\n<p><code>max_input_vars<\/code> limits how many form fields PHP will accept. WordPress admin pages with complex option screens, big menus or page builders can easily hit the default of <code>1000<\/code>. Symptoms are mysterious: some settings randomly reset or are not saved.<\/p>\n<p>Safe typical values:<\/p>\n<ul>\n<li>Standard WordPress sites: 2000\u20133000.<\/li>\n<li>WooCommerce + big theme options \/ page builders: 3000\u20135000.<\/li>\n<li>Laravel back\u2011offices with large forms: 3000+ (depending on usage).<\/li>\n<\/ul>\n<h3><span id=\"5_datetimezone\">5. date.timezone<\/span><\/h3>\n<p>Always set <code>date.timezone<\/code> to your primary region, for example:<\/p>\n<ul>\n<li><code>date.timezone = Europe\/Istanbul<\/code><\/li>\n<li><code>date.timezone = Europe\/Berlin<\/code><\/li>\n<\/ul>\n<p>This prevents PHP notices and ensures consistent log timestamps, cron behaviour and scheduled tasks across WordPress and Laravel.<\/p>\n<h3><span id=\"6_OPcache_and_performancerelated_settings\">6. OPcache and performance\u2011related settings<\/span><\/h3>\n<p>On PHP 7+ and especially PHP 8.x, OPcache is critical. It keeps compiled PHP bytecode in memory so each request does not have to re\u2011parse PHP files. On shared hosting you typically just enable OPcache; on a VPS you can fine\u2011tune it.<\/p>\n<p>We have a full, tested configuration in <a href=\"https:\/\/www.dchost.com\/blog\/en\/php-opcache-ayarlari-wordpress-laravel-ve-woocommerce-icin-en-iyi-konfigurasyon-rehberi\/\">PHP OPcache settings for WordPress, Laravel and WooCommerce<\/a>, but at minimum ensure:<\/p>\n<ul>\n<li><code>opcache.enable=1<\/code> (for web).<\/li>\n<li><code>opcache.memory_consumption<\/code> is high enough (e.g. 128\u2013256M for medium sites).<\/li>\n<li><code>opcache.max_accelerated_files<\/code> is large enough (e.g. 10000\u201320000).<\/li>\n<\/ul>\n<h2><span id=\"Recommended_phpini_Settings_for_WordPress_on_Shared_Hosting\">Recommended php.ini Settings for WordPress on Shared Hosting<\/span><\/h2>\n<p>On shared hosting, we usually have three goals for WordPress:<\/p>\n<ol>\n<li>Avoid white screens and failed uploads.<\/li>\n<li>Keep resource usage under the account limits.<\/li>\n<li>Have safe defaults for both the front end and wp\u2011admin.<\/li>\n<\/ol>\n<h3><span id=\"Baseline_phpini_for_a_smalltomedium_WordPress_site\">Baseline php.ini for a small\u2011to\u2011medium WordPress site<\/span><\/h3>\n<p>You can adapt and place something like this in <code>public_html\/php.ini<\/code> or use the equivalent values in your panel\u2019s PHP editor (exact syntax varies by host):<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">memory_limit = 256M\nmax_execution_time = 60\nmax_input_time = 60\nmax_input_vars = 3000\nupload_max_filesize = 64M\npost_max_size = 64M\n\n; Always set your timezone\ndate.timezone = Europe\/Istanbul\n\n; Error handling for production\nerror_reporting = E_ALL &amp; ~E_DEPRECATED &amp; ~E_STRICT\ndisplay_errors = Off\nlog_errors = On\nerror_log = \/home\/USERNAME\/logs\/php-error.log\n\n; Security-related\nexpose_php = Off\nsession.cookie_httponly = 1\nsession.cookie_secure = 1\nsession.use_strict_mode = 1\n<\/code><\/pre>\n<p>Explanations:<\/p>\n<ul>\n<li><strong>256M memory_limit:<\/strong> usually enough for WooCommerce sites with a reasonable plugin set. If you use heavy page builders + many plugins, you may need 384M, but check your host\u2019s limits first.<\/li>\n<li><strong>60s execution\/input time:<\/strong> balances long plugin updates with the risk of scripts hanging forever.<\/li>\n<li><strong>64M upload\/post size:<\/strong> suitable for typical image and small video uploads.<\/li>\n<li><strong>Error logging to a custom file:<\/strong> keeps errors out of public output and centralises them for debugging.<\/li>\n<li><strong>Secure session cookies:<\/strong> <code>httponly<\/code> helps mitigate XSS stealing cookies; <code>secure = 1<\/code> makes sure cookies are only sent over HTTPS (make sure your site is actually using HTTPS).<\/li>\n<\/ul>\n<p>If you are in the process of migrating everything to HTTPS, or want guidance on HSTS and canonical redirects, our article <a href=\"https:\/\/www.dchost.com\/blog\/en\/httpden-httpsye-gecis-rehberi-seo-kayipsiz-ssl-migrasyonu-hsts-ve-canonical-ayarlari\/\">Full HTTP\u2192HTTPS migration with HSTS and canonical settings<\/a> walks through the hosting\u2011side steps.<\/p>\n<h3><span id=\"WordPress_staging_and_maintenance_tools\">WordPress staging and maintenance tools<\/span><\/h3>\n<p>When you clone a site to a staging subdomain or run heavy maintenance plugins (database cleaners, search\/replace, backup tools), temporarily raising <code>max_execution_time<\/code> to 120\u2013300 seconds can help. After you are done, bring it back down so buggy plugins cannot hang for minutes.<\/p>\n<p>If you frequently run staging environments on shared hosting, our article <a href=\"https:\/\/www.dchost.com\/blog\/en\/paylasimli-hostingde-wordpress-staging-ortami-kurmak-adim-adim-uygulamali-rehber\/\">Setting up a WordPress staging environment on shared hosting<\/a> gives a full workflow, including database sync and safe DNS\/URL choices.<\/p>\n<h3><span id=\"Debug_settings_for_development_vs_production\">Debug settings for development vs production<\/span><\/h3>\n<p>For live WordPress sites, keep <code>display_errors = Off<\/code>. Showing raw PHP errors to visitors is both a security and UX problem, and can leak file paths and SQL queries. Use:<\/p>\n<ul>\n<li><code>WP_DEBUG<\/code>, <code>WP_DEBUG_LOG<\/code> and <code>WP_DEBUG_DISPLAY<\/code> in <code>wp-config.php<\/code> for app\u2011level debugging.<\/li>\n<li><code>log_errors = On<\/code> in php.ini to have PHP\u2011level issues recorded privately.<\/li>\n<\/ul>\n<p>We go deeper into safe logging strategy in <a href=\"https:\/\/www.dchost.com\/blog\/en\/php-hata-kayitlarini-dogru-yapilandirmak-display_errors-error_log-ve-log_level\/\">PHP error logging best practices on hosting servers<\/a>.<\/p>\n<h2><span id=\"Recommended_phpini_Settings_for_Laravel_on_Shared_Hosting_and_VPS\">Recommended php.ini Settings for Laravel on Shared Hosting and VPS<\/span><\/h2>\n<p>Laravel has slightly different patterns than WordPress. It is more likely to have:<\/p>\n<ul>\n<li>Long\u2011running queue workers or Horizon.<\/li>\n<li>Scheduled tasks via <code>php artisan schedule:run<\/code>.<\/li>\n<li>API endpoints with large JSON payloads.<\/li>\n<li>Artisan commands for imports, reports and maintenance.<\/li>\n<\/ul>\n<p>This means you usually tune both <strong>FPM (web)<\/strong> and <strong>CLI<\/strong> php.ini separately.<\/p>\n<h3><span id=\"Laravel_on_shared_hosting\">Laravel on shared hosting<\/span><\/h3>\n<p>Laravel can work on shared hosting if you do not need persistent queue workers and your jobs are light. In this environment, you are constrained similarly to WordPress:<\/p>\n<ul>\n<li><strong>No long\u2011running workers:<\/strong> you will likely use database queue + <code>php artisan queue:work --once<\/code> or rely on synchronous jobs.<\/li>\n<li><strong>Moderate memory_limit:<\/strong> 256M is a reasonable starting point.<\/li>\n<\/ul>\n<p>A typical php.ini for a small Laravel app on shared hosting might look like:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">memory_limit = 256M\nmax_execution_time = 60\nmax_input_time = 60\nupload_max_filesize = 32M\npost_max_size = 32M\nmax_input_vars = 3000\n\ndate.timezone = Europe\/Istanbul\n\nerror_reporting = E_ALL &amp; ~E_DEPRECATED &amp; ~E_STRICT\ndisplay_errors = Off\nlog_errors = On\nerror_log = \/home\/USERNAME\/logs\/laravel-php-error.log\n\nexpose_php = Off\nsession.cookie_httponly = 1\nsession.cookie_secure = 1\n<\/code><\/pre>\n<p>You should still keep Laravel\u2019s own <code>.env<\/code> set to <code>APP_ENV=production<\/code> and <code>APP_DEBUG=false<\/code> in production, so Laravel does not leak stack traces to visitors.<\/p>\n<h3><span id=\"Laravel_on_a_VPS_separating_web_and_CLI_behaviour\">Laravel on a VPS: separating web and CLI behaviour<\/span><\/h3>\n<p>On a VPS, you get the most out of Laravel by running:<\/p>\n<ul>\n<li>Nginx or Apache \u2192 PHP\u2011FPM for web requests.<\/li>\n<li>Supervisor\/systemd for <code>php artisan queue:work<\/code> or Horizon.<\/li>\n<li>Cron for <code>php artisan schedule:run<\/code>.<\/li>\n<\/ul>\n<p>Here, we often apply different limits:<\/p>\n<ul>\n<li><strong>Web (FPM) php.ini:<\/strong> moderate <code>memory_limit<\/code> per request (256M\u2013512M), <code>max_execution_time<\/code> around 60s.<\/li>\n<li><strong>CLI php.ini:<\/strong> higher <code>memory_limit<\/code> for expensive jobs (512M\u20131024M), <code>max_execution_time = 0<\/code> for workers, and control restarts at the process manager level.<\/li>\n<\/ul>\n<p>Example (FPM php.ini snippets):<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">; \/etc\/php\/8.2\/fpm\/php.ini\nmemory_limit = 512M\nmax_execution_time = 60\nmax_input_time = 60\npost_max_size = 64M\nupload_max_filesize = 64M\nmax_input_vars = 5000\n<\/code><\/pre>\n<p>Example (CLI php.ini snippets):<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">; \/etc\/php\/8.2\/cli\/php.ini\nmemory_limit = 1024M\nmax_execution_time = 0\nmax_input_time = 0\n<\/code><\/pre>\n<p>And then in Supervisor for queue workers (conceptual example):<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">[program:laravel-worker]\ncommand=\/usr\/bin\/php \/var\/www\/app\/artisan queue:work --sleep=3 --tries=3\nnumprocs=4\nautostart=true\nautorestart=true\n<\/code><\/pre>\n<p>This way, web traffic cannot starve the server with huge memory usage, but background workers still get enough space to process big jobs. For a full Laravel deployment playbook on VPS (including Nginx, PHP\u2011FPM and Horizon), see <a href=\"https:\/\/www.dchost.com\/blog\/en\/my-no-drama-playbook-for-deploying-laravel-on-a-vps-nginx-php%E2%80%91fpm-queues-horizon-and-truly-zero%E2%80%91downtime-releases\/\">our Laravel on VPS deployment guide<\/a>.<\/p>\n<h2><span id=\"Debugging_Logging_and_Security_Options_in_phpini\">Debugging, Logging and Security Options in php.ini<\/span><\/h2>\n<h3><span id=\"Error_reporting_levels\">Error reporting levels<\/span><\/h3>\n<p>For PHP 8.x in production, a common pattern is:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">error_reporting = E_ALL &amp; ~E_DEPRECATED &amp; ~E_STRICT\ndisplay_errors = Off\nlog_errors = On\n<\/code><\/pre>\n<p>This keeps logs detailed enough for developers, while not exposing errors to users. During development (on a separate dev\/staging environment), you might temporarily use:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">error_reporting = E_ALL\ndisplay_errors = On\nlog_errors = On\n<\/code><\/pre>\n<p>Just make sure you never leave <code>display_errors = On<\/code> in production.<\/p>\n<h3><span id=\"Log_file_placement_and_rotation\">Log file placement and rotation<\/span><\/h3>\n<p>Set <code>error_log<\/code> to a path outside the public web root when possible, for example:<\/p>\n<ul>\n<li><code>\/home\/USERNAME\/logs\/php-error.log<\/code> on shared hosting.<\/li>\n<li><code>\/var\/log\/php\/php-error.log<\/code> on VPS with proper permissions.<\/li>\n<\/ul>\n<p>On a VPS, combine this with logrotate to avoid disk growth. If you want a more structured observability stack, we describe centralised log management on VPS environments using modern tooling in our article <a href=\"https:\/\/www.dchost.com\/blog\/en\/vps-kaynak-kullanimi-izleme-rehberi-htop-iotop-netdata-ve-prometheus\/\">VPS resource usage and monitoring<\/a>.<\/p>\n<h3><span id=\"Securityrelated_directives_worth_checking\">Security\u2011related directives worth checking<\/span><\/h3>\n<p>php.ini is not a full security solution, but a few directives help reduce risk:<\/p>\n<ul>\n<li><code>expose_php = Off<\/code> \u2013 hides the exact PHP version in HTTP headers.<\/li>\n<li><code>allow_url_fopen = On\/Off<\/code> \u2013 turning it off blocks some remote file includes, but also breaks legitimate use (<code>file_get_contents()<\/code> on URLs). In many shared setups, it stays <code>On<\/code> and WAF rules add protection.<\/li>\n<li><code>session.cookie_httponly = 1<\/code> \u2013 prevents JavaScript access to cookies, reducing XSS impact.<\/li>\n<li><code>session.cookie_secure = 1<\/code> \u2013 ensures cookies are only sent over HTTPS (set once your site is fully HTTPS).<\/li>\n<li><code>session.use_strict_mode = 1<\/code> \u2013 mitigates session fixation by rejecting uninitialised IDs.<\/li>\n<li><code>disable_functions<\/code> \u2013 you can disable high\u2011risk functions like <code>exec<\/code>, <code>shell_exec<\/code>, <code>passthru<\/code> on shared hosting if you never need them. On Laravel deployments that run CLI tools, be careful not to break legitimate usage.<\/li>\n<\/ul>\n<p>Combine these PHP options with good practices at the application level (hardened admin logins, WAF, 2FA). For WordPress, we shared a complete login hardening approach, including XML\u2011RPC and reCAPTCHA, in <a href=\"https:\/\/www.dchost.com\/blog\/en\/wordpress-guvenli-giris-mimarisi-2fa-ip-kisitlama-recaptcha-ve-xml-rpc-korumasi\/\">our secure WordPress login architecture guide<\/a>.<\/p>\n<h2><span id=\"PHP_Version_and_Compatibility_WordPress_Laravel_and_PHP_8x\">PHP Version and Compatibility: WordPress, Laravel and PHP 8.x<\/span><\/h2>\n<p>Your php.ini settings always sit on top of a specific PHP version. Recent WordPress and Laravel versions run best on modern PHP 8.x \u2013 but some older plugins and packages may have compatibility issues.<\/p>\n<p>When upgrading PHP on shared hosting or a VPS, we recommend:<\/p>\n<ul>\n<li>Testing WordPress themes\/plugins or Laravel dependencies on a staging copy first.<\/li>\n<li>Ensuring OPcache is enabled and tuned properly on the new version.<\/li>\n<li>Reviewing <code>error_reporting<\/code> and logs carefully after the upgrade for deprecations.<\/li>\n<\/ul>\n<p>We maintain a detailed step\u2011by\u2011step process in our article <a href=\"https:\/\/www.dchost.com\/blog\/en\/php-8-gecis-rehberi-paylasimli-hosting-ve-vpste-wordpress-ve-laraveli-guvenle-yukseltmek\/\">PHP 8 upgrade guide on shared hosting and VPS for WordPress and Laravel<\/a>, which you can follow alongside adjusting your php.ini.<\/p>\n<h2><span id=\"Tuning_for_Growth_When_to_Raise_Limits_and_When_to_Move_to_a_VPS\">Tuning for Growth: When to Raise Limits and When to Move to a VPS<\/span><\/h2>\n<p>On shared hosting we encourage customers to treat php.ini tuning as a way to <strong>stabilise<\/strong> their sites, not as a way to squeeze every last drop of capacity out of a limited account. Signs that you are hitting the ceiling even after reasonable php.ini adjustments:<\/p>\n<ul>\n<li>Frequent \u201cResource Limit Reached\u201d messages in the control panel.<\/li>\n<li>WooCommerce checkouts or admin screens timing out during traffic spikes.<\/li>\n<li>Laravel jobs that cannot finish within the short execution windows shared hosting allows.<\/li>\n<li>Regular 5xx errors under moderate concurrent traffic.<\/li>\n<\/ul>\n<p>In those cases, it is not enough to keep raising <code>memory_limit<\/code> or <code>max_execution_time<\/code>. Moving the project to a properly sized VPS with dedicated CPU\/RAM and tailored php.ini + PHP\u2011FPM pools will bring far more predictable performance. We summarise capacity planning for common workloads in our article <a href=\"https:\/\/www.dchost.com\/blog\/en\/wordpress-blog-woocommerce-ve-saas-icin-kac-cpu-ne-kadar-ram\/\">How many vCPUs and how much RAM you really need for WordPress, WooCommerce and SaaS<\/a>.<\/p>\n<p>On dchost.com we see a typical path:<\/p>\n<ol>\n<li>Start on shared hosting with conservative but stable php.ini values.<\/li>\n<li>Optimise WordPress or Laravel code and enable OPcache \/ caching.<\/li>\n<li>Once the project grows (traffic, orders, background jobs), move to a VPS and re\u2011tune php.ini and PHP\u2011FPM around that project\u2019s real profile.<\/li>\n<\/ol>\n<p>If you also manage your own hardware, the same principles apply on <a href=\"https:\/\/www.dchost.com\/dedicated-server\">dedicated server<\/a>s or colocation: plan PHP limits, pool sizes and OPcache memory based on your CPU\/RAM budget, then verify with real\u2011world benchmarks.<\/p>\n<h2><span id=\"Summary_and_Next_Steps\">Summary and Next Steps<\/span><\/h2>\n<p>The right php.ini values for WordPress and Laravel are not magic numbers; they are practical limits that reflect your site\u2019s size, traffic patterns and hosting environment. On shared hosting, your goal is to avoid obvious bottlenecks (too\u2011low <code>memory_limit<\/code>, tiny upload sizes, low <code>max_input_vars<\/code>) while respecting account limits. On a VPS, you have more freedom to separate web and CLI configurations, allocate enough memory for OPcache and background workers, and tune PHP\u2011FPM pools for predictable concurrency.<\/p>\n<p>As a quick checklist, review at least: <code>memory_limit<\/code>, <code>max_execution_time<\/code>, <code>max_input_time<\/code>, <code>upload_max_filesize<\/code>, <code>post_max_size<\/code>, <code>max_input_vars<\/code>, <code>date.timezone<\/code>, error handling (<code>display_errors<\/code>, <code>log_errors<\/code>), OPcache, and a few security\u2011oriented directives. Combine those with solid application\u2011level practices (caching, database tuning, secure logins) and you will feel the difference in day\u2011to\u2011day stability.<\/p>\n<p>If you are unsure whether your current hosting plan or php.ini setup is enough for your next phase \u2013 a growing WooCommerce store, a Laravel SaaS, or a content\u2011heavy blog \u2013 our team at dchost.com can help you evaluate options across shared hosting, VPS, dedicated servers and colocation. We work with these settings in real projects every day and can help you translate your business requirements into a concrete, safe PHP configuration and hosting architecture.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>If you run WordPress or Laravel on shared hosting or a VPS, your php.ini settings quietly decide whether your site feels fast and stable or slow and fragile. The application code, database and caching are important, but PHP itself is the engine that executes every request. If the engine is misconfigured, you get timeouts, white [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":4612,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-4611","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-teknoloji"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/4611","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=4611"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/4611\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/4612"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=4611"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=4611"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=4611"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}