Joomla and Drupal Hosting Guide: PHP, Database and Security Settings

If you are planning to host a Joomla or Drupal website, your success will depend far more on PHP, database and security settings than on any single plugin or theme choice. Both CMSs can run on almost any basic hosting account, but the difference between a sluggish, insecure site and a fast, stable one is almost always in how the server is configured. In this guide, we will walk through the key hosting decisions you should make for Joomla and Drupal: which PHP versions and extensions to enable, how to size and tune your database, and which security controls to turn on from day one. The goal is not just to “get it working”, but to build an environment that is maintainable, safe and scalable – whether you are on shared hosting, a VPS or a dedicated server at dchost.com.

Joomla vs Drupal: What They Expect From Your Hosting

Joomla and Drupal share many infrastructure requirements, but they have slightly different expectations from the underlying hosting stack. Understanding these differences helps you avoid mysterious timeouts or resource errors later.

Core technical requirements

• PHP: Both Joomla 4+ and Drupal 9/10 require modern PHP (PHP 8.1 or higher is the safe baseline). Older PHP versions may work but are risky from a security perspective.
• Database:
  • Joomla: Primarily MySQL/MariaDB (InnoDB), with UTF-8 (utf8mb4) support.
  • Drupal: MySQL/MariaDB or PostgreSQL. For most small–medium sites, MySQL/MariaDB is easier to host and tune.
• Web server: Apache with mod_php or PHP-FPM, Nginx + PHP-FPM, or LiteSpeed. All work well when PHP is tuned correctly.
• Command line access: SSH is highly recommended. Modern Drupal in particular leans heavily on Drush and Composer, which are best run over SSH.

Resource profile: how they actually behave

• Joomla: Often used for corporate sites, portals and magazines. Many installations rely on heavy templates and page builder extensions. That means more PHP execution time and memory per request, especially for logged-in users and admins.
• Drupal: Frequently chosen for more complex, structured content and multi-language or multi-site builds. Core plus many contributed modules can create a large codebase and database schema. Drupal likes more RAM and benefits greatly from proper caching.

In practice, this means you want PHP settings and database tuning that assume a medium-complexity application – not a tiny brochure site. Later in this guide, we will detail concrete values for memory_limit, max_execution_time, and database parameters that work well for most Joomla and Drupal projects.

Choosing the Right Hosting Platform for Joomla and Drupal

Joomla and Drupal can technically run anywhere from shared hosting to a full cluster of dedicated servers. The right choice depends on traffic, complexity and how much control you need over PHP and database tuning.

Shared hosting: good for starting small

Shared hosting is usually enough for:

• Small corporate or NGO sites with a few thousand visits per month.
• Development or demo instances.
• Simple content sites without heavy custom code.

On shared hosting you typically share CPU, RAM and disk I/O with other customers. You usually can control:

• PHP version per site (via a control panel selector).
• Basic php.ini values (memory, upload size, execution time).
• Database creation and user privileges within your account.

You cannot usually control:

• MySQL server global configuration (buffer pool size, query cache, etc.).
• Operating system level security (firewall rules, kernel updates).
• Advanced web server rules beyond what .htaccess or Nginx per-site includes allow.

If you go with shared hosting at dchost.com, plan to stay within the “single-site, low–medium traffic” use case and rely mainly on application-level optimizations and caching.

VPS hosting: the practical default for serious sites

A VPS (Virtual Private Server) is usually the sweet spot for serious Joomla and Drupal projects. You get:

• Dedicated vCPU, RAM and disk I/O allocations.
• Full control over PHP, the database daemon and web server.
• The ability to deploy staging environments and CLI tools (Composer, Drush) comfortably.

For many single-site or small multi-site setups, a VPS with 2–4 vCPUs, 4–8 GB RAM and fast SSD/NVMe storage is a strong baseline. Our article on how many vCPUs and how much RAM you really need provides a practical way to size resources; the same logic applies well to Joomla and Drupal.

On a VPS you are also responsible for security hardening. If you manage your own server, it is worth reviewing our VPS security hardening checklist covering SSH, firewalls and updates and applying equivalent practices for your Joomla or Drupal instance.

Dedicated servers and colocation: for high-traffic and compliance

Dedicated servers or colocated hardware at dchost.com make sense when:

• You run a large, high-traffic portal or multi-site Drupal network.
• You have strict data locality or compliance requirements.
• You want to separate web, database, cache and search roles across multiple machines.

In these scenarios you might run:

• One or more web servers (Apache/Nginx/LiteSpeed) behind a load balancer.
• Dedicated database servers (MySQL/MariaDB or PostgreSQL) with replication and failover.
• Separate servers for Redis/Memcached, Solr/Elasticsearch, and file storage.

The principles in this article still apply; you will just be applying them per tier rather than on a single machine.

PHP Settings for Stable and Fast Joomla/Drupal Sites

PHP is where most performance and stability wins are found for Joomla and Drupal. Misconfigured PHP can cause blank pages, 500 errors and random logouts, even when your code is perfectly fine.

Choosing the right PHP version

As of today, you should aim for:

• Joomla 4.x: PHP 8.1 or 8.2 is ideal.
• Drupal 9/10: PHP 8.1 or 8.2, depending on your module compatibility matrix.

Newer PHP versions bring:

• Better performance (often 10–20% more requests per second).
• Security improvements and active support from the PHP community.
• Stricter error handling, which helps catch bad code early.

Before upgrading, always test on a staging environment. Our practical PHP 8 upgrade checklist on shared hosting and VPS walks through a safe process that you can adapt for Joomla and Drupal.

Required and recommended PHP extensions

Exact requirements vary slightly by version and contributed modules, but in general you should enable:

• Core: json, mbstring, xml, xmlreader, xmlwriter, tokenizer, pdo, pdo_mysql (or pdo_pgsql), intl, curl, zip.
• Image processing: gd or imagick (check what your site is configured to use).
• Security/performance: opcache, sodium (for modern cryptography), fileinfo.

On a VPS you can manage these via your package manager (e.g. php-intl, php-opcache). On shared hosting, your control panel typically provides a selector to enable or disable extensions per domain.

php.ini values that actually matter

Here are sane starting points for a typical Joomla or Drupal site that uses a few complex extensions/modules and moderate media uploads:

• memory_limit = 256M (512M if you have many heavy modules or import jobs).
• max_execution_time = 120 (can be temporarily increased for migrations or large imports).
• max_input_time = 120.
• post_max_size = 64M.
• upload_max_filesize = 32M (or more if you upload large PDFs/videos directly).
• max_input_vars = 3000 or higher when you have large configuration forms.

On busy multi-user sites, these settings should be combined with proper PHP-FPM pool limits so that you do not exhaust RAM under peak load. For a deeper discussion of how these values relate to each other, see our detailed guide to choosing safe php.ini values; the same logic applies directly to Joomla and Drupal.

OPcache configuration

OPcache stores compiled PHP bytecode in memory so your scripts do not need to be re-parsed on every request. This can easily double the throughput of a Joomla or Drupal site on the same hardware.

Typical starting values:

• opcache.enable = 1
• opcache.memory_consumption = 256 (MB) for most single-site installations.
• opcache.interned_strings_buffer = 16
• opcache.max_accelerated_files = 20000
• opcache.validate_timestamps = 1 on shared hosting; can be 0 with manual cache resets on production clusters.
• opcache.revalidate_freq = 60

For larger, multi-site codebases or Composer-heavy Drupal installs, you may need to increase memory_consumption further. Monitor opcache_statistics to ensure you are not hitting the cache limit.

Error logging and display settings

On production, you usually want:

• display_errors = Off
• log_errors = On
• error_log = /var/log/php/error.log (or panel-managed log path).

This ensures errors are captured without exposing stack traces to visitors, which could leak sensitive paths or configuration details.

Database Configuration: MySQL/MariaDB and PostgreSQL Tuning

The database is where Joomla and Drupal spend a large portion of their time. Small improvements here can drastically improve latency, especially for logged-in users and admin pages.

Engine, charset and collation

• Storage engine: Use InnoDB for all Joomla and Drupal tables. Avoid MyISAM for new installations.
• Character set: utf8mb4 for full Unicode support (including emojis and multi-language content).
• Collation: utf8mb4_unicode_ci or utf8mb4_unicode_520_ci for most languages; check your CMS documentation for any language-specific advice.

For fresh installations, set the database default charset and collation correctly from the start. Migrating later is more painful.

Basic MySQL/MariaDB tuning on a VPS or dedicated server

On your own VPS or dedicated server, a few parameters have outsized impact:

• innodb_buffer_pool_size: Ideally 50–70% of available RAM on a dedicated database server; on a small all-in-one VPS, start with 1–2 GB and adjust after observing usage.
• innodb_log_file_size: 256–512 MB for moderate write workloads helps performance without overly long crash recovery.
• max_connections: Keep realistic (e.g. 100–200) and pair with proper PHP-FPM max children; over-allocating connections creates memory pressure.
• query_cache: Modern MySQL/MariaDB versions often perform better with the old query cache disabled in favor of application-level and OPcache-based caching.

If you are troubleshooting slow backends or high CPU load, our article on MySQL indexing and query optimization for large sites covers a methodology that applies equally well when analysing Joomla and Drupal databases.

PostgreSQL basics for Drupal

Drupal supports PostgreSQL natively. If you choose Postgres, make sure you:

• Use a recent version (e.g. 14+).
• Set sane values for shared_buffers (15–25% of RAM) and work_mem (2–16 MB per connection, depending on reports and views).
• Enable regular autovacuum and monitor table bloat.

For deeper Postgres-specific tuning on a VPS, our friendly VPS playbook for PostgreSQL performance provides concrete configuration examples.

Database users and privileges

Never connect Joomla or Drupal to the database as a root or superuser account. Instead:

• Create a separate database and user per site (e.g. joomla_site, drupal_site).
• Grant only the needed privileges on that database (SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, INDEX, DROP).
• Restrict host access (e.g. 'joomla_site'@'localhost') so credentials cannot be used from arbitrary machines.

This limits the blast radius if configuration files are compromised and simplifies backup and restore operations.

Backups and point-in-time recovery

At minimum, ensure you have:

• Automated daily logical backups (e.g. mysqldump, pg_dump), stored off-server.
• Additional backups before major updates (core upgrades, big module changes, migrations).
• Periodic test restores to confirm backups are actually usable.

For larger deployments, you may want incremental, point-in-time recovery with binlog/WAL archiving. Our guide on MySQL backup strategies with mysqldump and XtraBackup explains where each approach fits; the same trade-offs apply for complex Joomla and Drupal installations.

Security Hardening for Joomla and Drupal Hosting

Even a perfectly tuned Joomla or Drupal site can be taken down by a simple security misconfiguration. Security is a shared responsibility between the application and the hosting environment.

Keep the CMS and extensions updated

This sounds obvious, but many compromises start with old core or modules:

• Enable core update notifications in Joomla or Drupal.
• Schedule a monthly maintenance window to apply module/extension updates.
• Use a staging site to test major upgrades before production.

On a VPS or dedicated environment, avoid leaving outdated PHP and database versions installed, even if unused; attackers often scan for known vulnerable versions.

File permissions and ownership

On Linux-based hosting, a common recommended layout is:

• Files: 644 (owner read/write, group/others read).
• Directories: 755 (owner read/write/execute, group/others read/execute).
• Configuration files (e.g. configuration.php, settings.php): more restrictive, such as 640 or 600.

Our article on Linux file permissions for shared hosting and VPS explains why these numbers matter and what to avoid (like 777) when hosting PHP applications.

Isolating sites and system users

On a VPS or dedicated server hosting multiple Joomla and Drupal sites, use separate system users and virtual hosts for each project:

• One Unix user per site (e.g. joomla_client1, drupal_client2).
• Separate document roots and PHP-FPM pools for each user.
• File permissions that prevent cross-site access.

This way, a compromised extension in one site cannot easily be used to modify code in another project on the same server.

HTTPS, TLS and secure cookies

All modern Joomla and Drupal sites should run over HTTPS only. Use HSTS and modern TLS ciphers where possible. Our guide on SSL/TLS protocol updates and modern cipher choices shows what your servers should be using now.

In addition, configure:

• Secure cookies: Set Secure and HttpOnly flags on session cookies.
• SameSite: Consider SameSite=Lax or Strict where compatible, especially for admin login cookies.
• Admin path protection: Restrict /administrator (Joomla) or /user/login (Drupal) by IP, rate limiting or additional authentication where possible.

HTTP security headers and WAF

HTTP security headers provide another layer of defense:

• Content-Security-Policy (CSP): Limits where scripts, styles and images can be loaded from.
• Strict-Transport-Security (HSTS): Forces browsers to use HTTPS.
• X-Frame-Options: Prevents clickjacking by disallowing framing.
• X-Content-Type-Options: Stops MIME-type sniffing.

For concrete Nginx/Apache examples, see our guide on how to correctly set HTTP security headers like CSP and HSTS. These recommendations apply equally well to Joomla and Drupal.

Beyond headers, a Web Application Firewall (WAF) can block many common attack patterns before they hit your CMS. Our overview of Web Application Firewalls for small and medium sites explains how ModSecurity-based origin WAFs and CDN WAF rules help protect PHP applications from SQL injection, XSS and brute-force attacks.

Server-side hardening

On VPS and dedicated environments, complement application-level security with:

• SSH hardening (key-based auth, non-root logins, restricted users).
• Firewall rules allowing only necessary ports (80/443 and SSH from trusted IPs).
• Fail2ban or similar tools to block repeated login attempts.
• Regular OS and package updates, ideally via a planned patch schedule.

If your Joomla or Drupal site runs on a custom VPS at dchost.com, combining these measures with the VPS security hardening checklist covering SSH, firewalls and updates will significantly reduce your attack surface.

Performance and Caching: Beyond Basic PHP Settings

PHP and database tuning get you a long way, but real-world Joomla and Drupal performance also depends on caching architecture and network-level optimizations.

Application-level caching

Both Joomla and Drupal have built-in caching layers and support additional modules/extensions:

• Joomla: Enable Conservative or Progressive caching as appropriate for your template and modules. Use cache plugins for page and module caching where safe.
• Drupal: Use the internal page cache and dynamic page cache. For more complex sites, consider Redis or Memcached for cache and session storage.

On a VPS, Redis is often a good default. Our guide on choosing between file, Redis and Memcached for PHP sessions and cache explains how in-memory stores reduce disk I/O and speed up authenticated requests – the same principles benefit Joomla and Drupal.

Reverse proxy and CDN

For higher-traffic or geographically distributed audiences, consider:

• A reverse proxy cache (Nginx microcaching or Varnish) in front of your PHP backend.
• A CDN to cache static assets (images, CSS, JS) close to visitors.

Even a few seconds of microcaching for anonymous traffic can drastically cut PHP load. If you are curious how microcaching works in practice, our article on using Nginx microcaching to speed up PHP applications gives real configuration examples that you can adapt to Joomla and Drupal front controllers.

HTTP/2, HTTP/3 and compression

Make sure your hosting environment supports:

• HTTP/2 and optionally HTTP/3 (QUIC): Multiplexing improves page load times when many assets are requested.
• Gzip/Brotli compression: Reduces transfer size for HTML, CSS and JavaScript.

Combining modern protocols with a well-configured CDN and caching strategy is an easy win for Core Web Vitals and perceived performance.

Cron jobs and queues

Drupal relies heavily on cron for tasks like clearing caches and running scheduled jobs; Joomla also uses background tasks via plugins and cron. On shared hosting, use the panel’s cron interface to hit the CMS cron URL periodically. On a VPS, run CLI cron commands under the correct user, e.g.:

*/10 * * * * /usr/bin/php /var/www/drupal/web/core/scripts/cron.php --root=/var/www/drupal/web >/dev/null 2>&1

Ensure cron is set up from day one; otherwise caches may never be cleared, search indexes stay stale, and scheduled tasks pile up.

Practical Hosting Checklists for Joomla and Drupal

To make this concrete, here are checklists you can use when launching a new Joomla/Drupal site or auditing an existing one.

New site launch checklist

• PHP:
  • PHP 8.1 or 8.2 selected for the site.
  • Required extensions (intl, mbstring, json, pdo_mysql/pdo_pgsql, gd/imagick, opcache) enabled.
  • php.ini tuned: 256M+ memory, reasonable upload and execution limits.
• Database:
  • Dedicated database and user created per site.
  • Charset utf8mb4, collation utf8mb4_unicode_ci.
  • Backup job configured and tested.
• Security:
  • Site available only over HTTPS, with a valid SSL certificate.
  • File permissions set to 644/755, no 777 directories.
  • Admin accounts using strong passwords and 2FA if available.
  • Basic WAF rules enabled (origin or CDN).
• Performance:
  • Application caching turned on and tested.
  • OPcache enabled and working.
  • Cron configured (panel or CLI) and verified.

Existing site audit checklist

• Versions:
  • Joomla/Drupal core and all extensions/modules up to date.
  • PHP version supported and actively maintained.
• Logs:
  • PHP error logs checked for recurring warnings or fatal errors.
  • Web server logs reviewed for 4xx/5xx spikes.
• Database health:
  • No oversized log or cache tables; prune old sessions and watchdog/log entries.
  • Slow queries logged and analysed for possible indexing.
• Security posture:
  • No unused admin users; stale accounts removed.
  • HTTP security headers (HSTS, CSP, X-Frame-Options) verified.
  • Backups exist and at least one recent restore test has been performed.

Bringing It All Together

Hosting Joomla or Drupal well is not about a single magic setting; it is about aligning PHP, database and security decisions so they reinforce each other. Modern PHP with OPcache keeps CPU usage under control, a properly tuned MySQL/MariaDB or PostgreSQL instance prevents slow queries from stalling pages, and sane security defaults – from file permissions to TLS and WAF rules – reduce the risk that a small misstep becomes a major incident.

At dchost.com, we see daily how much smoother Joomla and Drupal projects run when these fundamentals are in place from day one. Whether you start on a shared plan or move up to a VPS, dedicated server or colocation, you can use this guide as a baseline checklist for every new project and every periodic audit. If you are planning a migration, a PHP upgrade or a new multi-site architecture and want to validate your hosting design, our team is happy to help you translate these best practices into a concrete server layout on our infrastructure.