Set Up WordPress Without Apache, Nginx, or IIS Using Gruxi

WordPress is a hugely popular PHP application that powers a significant portion of the web. Traditionally, WordPress deployments rely on Apache or Nginx as the front-facing web server, often as part of a larger LAMP or LEMP stack.

Gruxi gives you a smaller setup with easier administration. It can serve WordPress on Linux through PHP-FPM or on Windows through managed PHP-CGI, while also handling static files, TLS, and site configuration from the built-in admin UI.

If you are looking for a practical alternative to Apache, Nginx, IIS that works well during development as well as in production, this guide walks through the setup from start to finish.

What WordPress needs

At a high level, WordPress needs three things:

• PHP to execute the application
• MySQL-compatible database storage
• TLS/HTTPS if you want a realistic modern setup

Traditionally, Apache or Nginx sits in front of PHP and the database. With Gruxi, that front-end server role is handled directly by Gruxi instead.

That is useful in two common cases:

• you want a lighter local WordPress stack for development and testing
• you want a simpler hosting setup for a personal site, a client project, or a agency deployment

WordPress also expects URL rewriting for pretty permalinks, so the Gruxi site configuration needs to account for that. We will cover that explicitly below.

Prerequisites

Before you begin, make sure you have these pieces ready:

• Gruxi installed and running - See the Getting Started documentation
• a MySQL-compatible database such as MySQL or MariaDB
• PHP installed and configured for WordPress - either PHP-FPM on Linux or managed PHP-CGI on Windows
• the WordPress files downloaded to a directory on disk

For the database, you can use either a local installation or a Docker container. The important part is simply that WordPress can reach it and that you know the database name, username, password, and host.

For the WordPress files, use a normal extracted WordPress download from wordpress.org.

Example locations:

Windows:
C:\sites\wordpress

Linux:
/var/www/wordpress

Examples setting up Gruxi on Linux and Windows

• For Linux, see the PHP on Linux example.
• For Windows, see the PHP on Windows example.
• For Docker Compose, see the Docker Compose PHP Gruxi example.

Configure Gruxi for WordPress

Once Gruxi is running, open the admin UI at https://localhost:8000 and sign in as admin. On first startup, Gruxi prints the initial password to its startup output.

Then create or edit a site in the configuration area.

1. Set the site hostname and TLS behavior

For local testing, you can use localhost, a custom local hostname, or the default wildcard site if this is your only site.

If you want WordPress over HTTPS, use a hostname that resolves to your Gruxi server and enable TLS on the relevant binding. Gruxi can generate a self-signed certificate for local development, which is often enough for testing login flows, plugin callbacks, and secure cookies.

For production, you would point your real domain at Gruxi and configure TLS accordingly. The TLS certificates documentation covers that in more detail.

2. Add the rewrite function WordPress needs

Add the rewrite function OnlyWebRootIndexForSubdirs to the site.

This matters because WordPress relies on rewritten requests for permalinks. Without this, many pages outside the physical file structure will not route through index.php correctly.

3. Add a Static File Processor

Add a Static File Processor with priority 1.

Set the Web Root to your WordPress directory, for example:

Windows: C:\sites\wordpress
Linux: /var/www/wordpress

This lets Gruxi serve images, CSS, JavaScript, and other static assets directly.

4. Add a PHP Processor

Add a PHP Processor with priority 2.

For Linux:

• Set Served By to PHP-FPM
• Set Local Web Root to your WordPress directory, such as /var/www/wordpress
• Set FastCGI IP:Port to your PHP-FPM listener, such as 127.0.0.1:9000 or php-fpm:9000
• Set FastCGI Web Root to the path WordPress uses inside the PHP environment

For Windows:

• Set Served By to Windows PHP-CGI (managed)
• Create or select a managed PHP instance pointing to php-cgi.exe
• Set Local Web Root to your WordPress directory, such as C:\sites\wordpress

5. Set server software spoofing

Set Server Software Spoofing to nginx.

This is a WordPress-specific compatibility detail. WordPress checks server software behavior in ways that can affect permalink handling and related features. Using nginx here keeps WordPress on a well-supported path.

Save the configuration and reload it.

At that point, Gruxi is ready to serve the WordPress files and pass PHP requests to the configured runtime.

Install WordPress

With the site configured, the rest looks like a normal WordPress install.

First, create a database and user for WordPress in MySQL or MariaDB. For example, you might create:

• database: wordpress
• user: wordpress
• password: a strong password of your choice

Then make sure the WordPress files are present in the directory you configured as the web root.

Open the site in your browser using the hostname you configured in Gruxi:

http://localhost/

Or, if you enabled TLS for local development:

https://localhost/

You should see the standard WordPress installer.

Follow the normal WordPress setup steps:

1. Select the site language.
2. Enter the database name, username, password, host, and table prefix.
3. Let WordPress generate or write the configuration.
4. Set the site title, admin username, password, and email address.
5. Complete the installation and sign in.

If WordPress cannot connect to the database, the issue is almost always one of these:

• the database host is wrong
• the database user or password is wrong
• the database server is not reachable from the machine or container where WordPress is running

If the homepage loads but internal pages fail, check the rewrite function and the Server Software Spoofing value first. Those are the two most common WordPress-specific configuration misses.

Verify the setup and manage it through Gruxi

After installation, sign in to /wp-admin/ and confirm that the WordPress dashboard loads correctly.

Then test a few normal actions:

• open the dashboard
• change the site title or permalink settings
• upload a media file
• open a post or page with a pretty permalink

If those work, the setup is in good shape.

From the Gruxi admin UI, you can also manage the server side of the deployment:

• review site configuration
• monitor the server state
• adjust PHP handler settings
• reload configuration changes without switching to a separate web server stack

That is one of the practical advantages of using Gruxi here. You can easily manage the server configuration without fiddling with Apache, Nginx, or IIS config files. This is especially useful if you are testing multiple WordPress projects or different PHP versions on the same machine.

WordPress now runs on Gruxi

You now have WordPress running on Gruxi without Apache, Nginx, or IIS. The overall model stays familiar, with WordPress using PHP and MySQL as usual, but the front-end server layer is simpler and easier to manage.

For WordPress developers who want a lighter stack, this is a clean way to keep the PHP workflow they already know while dropping some of the usual infrastructure overhead.

If you want to keep going, the next useful references are the WordPress example, the PHP processor docs, the site processors docs, and the broader Getting Started documentation.