Free tools Windows power users keep installed
One-click scans. No signup required.
You can run WordPress on Debian with Nginx: Nginx serves static files and forwards PHP requests to PHP-FPM, while MariaDB or MySQL stores the site’s data. Use a supported Debian release and current packages, configure HTTPS, and finish the WordPress installer only after the web server, PHP-FPM, and database are ready. Then optimize in stages, measuring each change instead of guessing at database settings.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
How the WordPress, Nginx, PHP-FPM, and database stack fits together
WordPress supports Nginx. In this arrangement, Nginx handles incoming HTTP and HTTPS connections, delivers static assets such as images and stylesheets, and passes requests for PHP scripts to PHP-FPM. PHP runs WordPress code, which reads and writes site content in a MariaDB or MySQL database. These components have separate configuration and failure modes, so a useful installation plan brings them up in that order rather than treating WordPress as a single package.
As an Amazon Associate I earn from qualifying purchases.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →WordPress’s server requirements list PHP 7.4 or greater, HTTPS support, and either MariaDB 10.11 or greater or MySQL 8.0 or greater; they recommend Apache or Nginx. Those are requirements published on WordPress.org as accessed on October 14, 2026. For a new installation, choose versions supported by the Debian release and compatible with the WordPress version you intend to run; do not interpret the PHP minimum as a recommendation to install an old PHP release.
HTTPS is part of the setup, not an optional finishing touch. It protects traffic between visitors and the site and is listed among WordPress’s current server prerequisites. A working TLS certificate also lets you configure the site to use its HTTPS address consistently.
#1 Best Overall
Choose a Debian release and a WordPress delivery method
Start with a Debian release that remains supported and whose packages meet the current requirements for WordPress, PHP, and the database. Debian’s package page lists these WordPress versions in 2026:
| Debian release | WordPress version listed by Debian in 2026 |
|---|---|
| Debian 11 (Bullseye) | 5.7.14 |
| Debian 12 (Bookworm) | 6.1.9 |
| Debian 13 (Trixie) | 6.8.3 |
These figures describe Debian’s packaged WordPress versions as listed in 2026; they are not a guarantee that every listed Debian release is still supported or that the package version is the newest upstream release. Check the release’s support status and package versions before choosing it. This distinction matters because the Debian package and WordPress upstream files have different update paths.
Debian’s WordPress package
The Debian package integrates with Debian’s packaging and configuration conventions. It can be convenient when you want updates managed through the operating system’s package tools and are comfortable following Debian’s layout for configuration and content. Debian documents package-specific paths and a WP_CONTENT_DIR approach; do not assume the package’s files and configuration work exactly like a manual upstream installation.
Upstream WordPress files
Installing upstream files gives you a direct WordPress file tree in the document root you choose. You take responsibility for applying WordPress updates and keeping that copy aligned with current requirements. In either case, protect configuration and credentials from public access, decide deliberately which account owns writable files, and keep a clear separation between site content and publicly served code where your chosen installation method supports it.
The practical choice is about control and maintenance, not whether Nginx can serve one option better. A Debian package follows the distribution’s integration model; upstream files put more of the update and layout decisions in your hands. Avoid mixing package-managed files with a second, manually copied WordPress tree in the same location.
Prepare the host and install the server components
Update the operating system first, then install Nginx, PHP-FPM, the PHP extensions required by the WordPress version and plugins you plan to use, and MariaDB or MySQL. The exact PHP-FPM package name and socket path depend on the Debian release and installed PHP version, so inspect the installed service and its configured socket rather than copying a version-specific path blindly.
sudo apt update
sudo apt upgrade
sudo apt install nginx mariadb-server php-fpm php-mysqlThis is a starting set of packages, not a complete extension checklist for every site. Add the extensions required by your selected WordPress version and workload using Debian packages appropriate to the installed PHP version. Once installed, verify that Nginx, the PHP-FPM service, and the database service are running. If PHP-FPM is absent or unavailable, Nginx cannot execute WordPress’s PHP entry point; a browser may show an error or a download prompt rather than a functioning site.
Run MariaDB’s hardening procedure before creating the site database. Then create a separate database and a dedicated database account for this WordPress installation. Debian’s documented workflow grants the application account only the permissions needed for its normal database operations. Do not reuse an administrative database login for the website.
CREATE DATABASE wordpress CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'wordpress_user'@'localhost' IDENTIFIED BY 'replace-with-a-unique-secret';
GRANT ALL PRIVILEGES ON wordpress.* TO 'wordpress_user'@'localhost';
FLUSH PRIVILEGES;Use a unique, strong password in place of the example value, and record it in a secure password manager or other protected location. The database name, account, and permissions above are illustrative values; adapt them to your installation and database policy. The principle is to scope the user to the WordPress database rather than grant broad server-wide privileges.
Place WordPress files and protect its configuration
Choose the domain’s document root and put either the Debian-managed package in its documented layout or upstream WordPress files in that root. Set ownership and write permissions intentionally: the web server needs access to read site code and serve assets, while only the locations WordPress must modify should be writable under the workflow you choose. Broadly making the whole tree writable makes later maintenance and security harder to reason about.
Configure the database connection using the chosen installation method. A manual upstream deployment normally records these settings in wp-config.php; a Debian package may use Debian’s configuration mechanism and paths instead. In either case, database credentials must not be exposed as downloadable files or placed in a public directory where they can be read directly. Keep backups of configuration and site data separate from the public document root.
Before proceeding, confirm that the files are in the directory Nginx will serve and that the Nginx worker can read them. If WordPress needs to write uploads or other content, grant write access only to the relevant content locations, following the conventions of the package or deployment method. This avoids a common trap: fixing an upload problem by loosening permissions across the entire site.
Configure the Nginx server block and PHP-FPM
Create an Nginx server block for the site’s domain. Set the document root, include index.php among the index files, route requests for existing files normally, and send unresolved paths to WordPress’s /index.php. That fallback is what allows WordPress to handle pretty permalinks and other routes that are not physical files.
server {
listen 80;
server_name example.com www.example.com;
root /var/www/example.com;
index index.php index.html;
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ .php$ {
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass unix:/run/php/php-fpm.sock;
}
}The example illustrates the routing pattern, not a ready-to-paste server block: set the domain and document root to your own values, and replace the socket path with the socket actually provided by the installed PHP-FPM service. Debian’s PHP-FPM socket commonly includes a PHP version in its filename, so confirm it on the host. The SCRIPT_FILENAME parameter must resolve to the PHP file Nginx is passing to PHP-FPM.
Recommended Free Tools
Do not expose arbitrary PHP files unnecessarily. WordPress’s Nginx handbook includes PHP handling guidance and exclusions for sensitive paths; review those rules and adapt them to the site’s actual directory layout. Avoid blindly copying generic snippets whose assumptions about the document root, PHP socket, or cache setup do not match the host.
Test the Nginx configuration before reloading it. If the test fails, correct the reported syntax or path problem before applying the configuration. After a successful test, reload Nginx, then check the site by domain. A web installer should only be started once Nginx can reach PHP-FPM and the database is reachable with the credentials you configured.
sudo nginx -t
sudo systemctl reload nginxUse the browser’s WordPress installer to enter the site title and administrator details and complete setup. If the page cannot connect to the database, check the database name, username, password, host, and database service first. If PHP appears as text or downloads, inspect the PHP-FPM service, the server block’s PHP location, and the FastCGI socket path. If a permalink returns a 404 while the home page loads, inspect the Nginx try_files fallback.
Enable TLS and make the HTTPS address consistent
Obtain a valid certificate and private key for the domain, then configure Nginx with a TLS listener and paths to those files. The Nginx WordPress handbook provides examples using TLS listeners, HTTP/2, and HSTS. Treat those examples as a configuration pattern, not a reason to copy older cipher or protocol settings unchanged: align protocol and cipher choices with the current Nginx and security baseline for the host.
Rank #4
After HTTPS works, make the WordPress site address use the HTTPS version of the domain and ensure visitors arriving over HTTP are directed to HTTPS. Check both the bare domain and any configured www hostname so that certificate coverage and redirection agree with the hostnames in the server block. Keep certificate renewal operational; an expired certificate breaks the secure connection even if Nginx and WordPress are otherwise healthy.
HSTS tells browsers to use HTTPS for future visits, so enable it only when HTTPS is correctly deployed for the hostnames and subdomains covered by the policy. A premature or overly broad HSTS policy can make a misconfiguration harder for visitors to bypass. First validate the certificate, redirects, and HTTPS behavior, then decide whether the policy is appropriate.
Choose a caching layer without breaking WordPress behavior
There are two distinct places to cache rendered pages: a WordPress page-cache plugin can operate within WordPress, while Nginx FastCGI cache can store responses at the web-server layer. Both aim to avoid repeating PHP work for eligible requests, but they differ in where rules are configured, how invalidation is managed, and how much of the behavior is visible in WordPress versus Nginx configuration and logs.
| Approach | Where rules and troubleshooting live | Operational trade-off |
|---|---|---|
| WordPress page-cache plugin | WordPress administration and plugin configuration | Convenient to manage from WordPress, but depends on the plugin’s behavior and cache invalidation integration. |
| Nginx FastCGI cache | Nginx server configuration and web-server diagnostics | Can cache before WordPress executes, but requires careful request exclusions and explicit invalidation planning. |
Do not enable both layers without understanding how they interact. A cached page can remain stale after content changes if invalidation does not reach every cache layer. Decide which layer owns invalidation and how editors or deployment steps will clear affected pages.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11For Nginx FastCGI cache, follow the handbook’s exclusion approach. At minimum, bypass cache for administration pages, POST requests, requests with query strings, and users identified as logged in or recently commenting. Feeds and sitemaps may also need exclusion depending on how the site generates and updates them. These rules protect personalized or state-changing requests from receiving a response generated for a different request.
- Administration: Do not serve cached responses for the WordPress administration area or its login flow.
- POST requests: Bypass cache because these requests can submit forms or change state.
- Query strings: The handbook’s examples exclude query-string requests; caching them safely requires understanding what each parameter changes.
- Logged-in and recently commenting users: Exclude them so private or user-specific views are not served as shared page content.
- Feeds and sitemaps: Decide whether they should bypass cache or have a deliberately short and correctly invalidated cache policy.
Test the exclusions with the actual workflows the site uses, including login, comments, forms, search, and content updates. Caching is not a substitute for correct PHP-FPM or database configuration; first establish a working uncached site, then add caching and confirm that the relevant visitor and editor experiences still behave correctly.
Best Value
Optimize in stages, then measure
Keep Debian, Nginx, PHP, and MariaDB current before tuning individual settings. Outdated components can undermine performance and security, while speculative tuning can introduce harder-to-diagnose problems without improving the pages visitors experience. Establish a baseline for the site first, then make one class of change at a time and verify its effect.
1. Serve static assets efficiently
Nginx can serve images, stylesheets, scripts, and other static files directly rather than sending them through PHP. Confirm that static requests resolve to files in the document root and are not accidentally routed to WordPress by an overbroad rule. Set suitable cache-control or Expires headers for static assets so browsers can reuse files between visits. Choose lifetimes with the asset-update process in mind: long-lived caching works best when changed assets receive a new filename or version identifier.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
2. Enable PHP opcode caching
Enable PHP opcode caching using the package and configuration available for the installed PHP version. Opcode caching reduces repeated parsing and compilation work for PHP code; it does not cache the final WordPress page for every visitor and does not replace a page cache. Confirm the extension is enabled for the PHP-FPM service, not just another PHP execution mode, and restart or reload the relevant service after changing configuration.
3. Inspect cache behavior before database tuning
Check whether the workload is spending time regenerating pages that could be safely cached, whether PHP requests are reaching the intended FPM pool, and whether static files are being served directly. Only then investigate database performance with evidence from the actual site. WordPress describes database tuning as a specialized task and recommends InnoDB-aware tuning; avoid copying arbitrary buffer sizes or server settings without understanding available memory, concurrent workload, and the database’s role on the host.
Measure the same pages and workflows before and after a change, including a logged-out page and any dynamic or logged-in views important to the site. If a change makes administration slower, breaks comments, or serves old content, roll it back and inspect the cache or service configuration that changed. Keep the working configuration so recovery does not depend on remembering every edit.
Decide whether to self-manage or use managed hosting
A self-managed Debian VPS gives you control over Nginx, PHP-FPM, MariaDB, TLS, filesystem layout, and cache policy. That control comes with responsibility for operating-system updates, PHP and database maintenance, certificate renewal, backups, monitoring, and incident diagnosis. Logs and configuration are directly available, which can help when you know how to operate the stack but also means you own the operational work.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsManaged WordPress hosting shifts some of that server maintenance to the provider, though included services and control vary by provider. It can be a better fit when you do not want to maintain Nginx, PHP-FPM, MariaDB, TLS, and cache rules yourself. Compare what the service actually handles—updates, backups, certificates, caching, and support—rather than assuming the word “managed” covers every responsibility. A Debian VPS is more appropriate when you need host-level control and are prepared to maintain each layer.
Common failure points and a practical diagnosis order
- Nginx reports a configuration error: Run
nginx -t, correct the indicated syntax or referenced-file problem, and reload only after the test succeeds. - The browser downloads PHP or displays PHP source: Treat PHP execution as broken. Verify PHP-FPM is running and that the server block passes scripts to its real socket.
- The site cannot connect to its database: Confirm the database service is running and the WordPress credentials identify the database and user you created. Check that secrets have not been pasted with extra characters or changed in only one configuration location.
- The home page works but permalinks fail: Ensure Nginx uses a
try_filesfallback to/index.phpfor non-file requests. - Uploads fail after installation: Review ownership and write permissions for the content locations WordPress needs; do not make the entire code tree world-writable as a shortcut.
- Visitors see stale or incorrect pages: Inspect page-cache and FastCGI-cache invalidation and confirm that administration, POST, query-string, logged-in, and commenting-user requests are excluded as intended.
- HTTPS produces warnings or loops: Check that the certificate covers the requested hostname, the TLS server block is active, and the HTTP redirect and WordPress HTTPS address agree.
Diagnose from the edge inward: first check DNS and hostname coverage, then Nginx configuration and logs, PHP-FPM service and socket, WordPress configuration and permissions, and finally database service and credentials. This sequence narrows the fault to the component that handles the request at that stage.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
