In this guide, we will deploy WordPress on a virtual machine running Ubuntu 24.04. The deployed configuration will include Nginx, PHP-FPM, MariaDB, Redis Object Cache, a domain, and a Let’s Encrypt SSL certificate.
The final architecture looks like this: user → HTTPS → Nginx → PHP-FPM and WordPress → MariaDB → Redis. To make it even clearer, we have prepared a screenshot:
For the installation, you will need a VPS with a public IP address, Ubuntu 24.04 LTS, and open TCP ports 22, 80, and 443. For a small WordPress installation, a configuration with 2 vCPU, 4 GB of RAM, and 20 GB of disk space is sufficient.
Of course, given the popularity of containers today, it is often easier to find or prepare a docker-compose.yml file and, after installing Docker, run everything described below with a single command: docker-compose up -d. However, we will walk through the good old manual installation process, at least to understand what is happening “under the hood”.
First, we will create a virtual machine, attach a Floating IP, and check the network rules. Then we will install Nginx, PHP-FPM, MariaDB, and Redis, create a separate database and user for WordPress, download the CMS files, and configure access permissions.
Nginx will accept HTTP and HTTPS requests and pass PHP files to PHP-FPM. MariaDB will store the site’s pages, users, and settings. Redis will be used for object caching and to reduce the number of repeated database queries.
The site will use the following subdomain: wordpress.deploy-test-lab.com
After creating the DNS record, we will issue a Let’s Encrypt SSL certificate and configure an automatic redirect from HTTP to HTTPS. Then we will go through the WordPress installation wizard, create an administrator account, and connect Redis Object Cache.
As a result, we will have a working WordPress site available over HTTPS, with a dedicated MariaDB database, Redis caching, and automatic startup of all required services after the VPS is rebooted.
WordPress Architecture on a VPS
Before installation, it is useful to understand which components will run on the server and what each of them does. As a web application, WordPress does not run on its own: it depends on a web server, PHP, a database, and caching.
Required components
To deploy WordPress, we will install several components:
| Component | Purpose |
| Ubuntu 24.04 LTS | Virtual machine operating system |
| Nginx | Handles HTTP and HTTPS requests and terminates SSL |
| PHP-FPM | Executes WordPress PHP code |
| MariaDB | Stores site pages, users, and settings |
| WordPress | Content management system |
| Redis | Caches objects and reduces repeated database queries |
| Certbot | Issues and renews the Let’s Encrypt SSL certificate |
For a small installation, a VPS with 2 vCPUs, 4 GB of RAM, and 20 GB of disk space is sufficient. The server will also need a public IP address and inbound TCP ports 22, 80, and 443.
How Nginx, PHP-FPM, MariaDB, and Redis Work Together
When a user opens a website, the request first reaches Nginx. Nginx can serve static files—images, CSS, and JavaScript—directly.
If a PHP page is requested, Nginx passes it to PHP-FPM. PHP executes the WordPress code, and WordPress queries MariaDB for the page content, settings, and user data.
Redis complements this setup with an object cache. WordPress can store frequently used query results in Redis and retrieve them later without repeatedly querying MariaDB.
As a result, each component performs a specific role: Nginx receives requests, PHP-FPM runs WordPress, MariaDB stores persistent data, and Redis speeds up repeated operations.
Preparing the Virtual Machine
We will start the installation by creating a clean virtual machine running Ubuntu 24.04 LTS. Then we will attach a public IP address, check the network rules, and connect to the server over SSH.
Creating a VM in the cloud control panel
Create a new virtual machine in the cloud control panel. For the demo WordPress site, use the following configuration:
- VM name — wordpress-guide;
- Image — Ubuntu 24.04 LTS;
- 2 vCPUs;
- 4 GB of RAM;
- 20 GB system disk;
- Project private network;
- SSH key pair authentication.
Save the private SSH key when creating the key pair. You will need it to connect to the server, and it usually cannot be retrieved again.
After confirming, wait until the status changes to Active.
Assigning a public IP address and configuring the firewall
The virtual machine is assigned a private address within the cloud network. To connect to it from the internet and make WordPress available via a domain, you need to assign a Floating IP.
In our example, the VM was assigned:
Private IP: 172.30.16.104
Floating IP: 203.0.113.10
The following inbound TCP ports are required:
| Port | Purpose |
| 22 | SSH connection |
| 80 | HTTP and Let’s Encrypt certificate issuance |
| 443 | HTTPS |
You can configure these rules in a security group in the cloud control panel.
Connecting to the server via SSH
We will use the command line. For example, on Windows you can use PowerShell or Windows Terminal. Go to the directory where the private SSH key is saved and run the command: ssh -i .\wordpress-guide.pem ubuntu@<FLOATING_IP>
Note that the ssh command is available by default in modern versions of Windows. In older versions, you can install it separately or use alternative clients.
Replace <FLOATING_IP> with the public IP address of your virtual machine. You can find it in the list of instances or in the Floating IPs section of the cloud control panel.
In our case, the server has been assigned the address 203.0.113.10, so the command looks like this: ssh -i .\wordpress-guide.pem [email protected]
The key file name may also be different in your case. Instead of wordpress-guide.pem, specify the path to your own private key.
The username depends on the selected image. For Ubuntu cloud images, the ubuntu user is typically used.
When you connect for the first time, SSH will ask you to confirm the server fingerprint. Enter: yes
After successful authentication, a terminal session on the virtual machine will open. All subsequent commands are run directly on the VPS.
Updating Ubuntu
Before installing the WordPress stack, update the package lists and upgrade the installed packages:
sudo apt update
sudo apt upgrade -y
Then install the basic utilities: sudo apt install -y curl wget unzip ca-certificates ufw
Check the system version: lsb_release -a
After the update, you can proceed with installing Nginx, PHP-FPM, MariaDB, and Redis.
Installing Nginx, PHP, MariaDB, and Redis
Installing system packages
After updating Ubuntu, install the Nginx web server, MariaDB, Redis, PHP-FPM, and the PHP extensions required for WordPress:
sudo apt install -y nginx mariadb-server redis-server \
php-fpm php-mysql php-curl php-gd php-intl php-mbstring \
php-xml php-zip php-redis
The php-fpm package installs the PHP FastCGI Process Manager, which Nginx will use to execute PHP code. The other extensions provide support for connecting to MariaDB, processing images, archives, XML, multibyte strings, and network requests.
The current version of WordPress recommends using PHP 8.3 or later and MariaDB 10.11 or later. Suitable versions of these components are available in the standard Ubuntu 24.04 repositories.
After installation, enable the services to start automatically:
sudo systemctl enable nginx
sudo systemctl enable mariadb
sudo systemctl enable php8.3-fpm
sudo systemctl enable redis-server
Start them if they have not already been started automatically: sudo systemctl start nginx mariadb php8.3-fpm redis-server
Checking running services
Check the status of all four services with a single command:
for service in nginx mariadb php8.3-fpm redis-server; do
printf "%-15s " "$service:"
systemctl is-active "$service"
done
If the installation is working correctly, each service will show the active status:
nginx: active
mariadb: active
php8.3-fpm: active
redis-server: active
You can check an individual service in more detail. For example, for Nginx, use the following command: sudo systemctl status nginx –no-pager
If all components are running, you can proceed to preparing the database.
Configuring MariaDB
Run the built-in MariaDB secure installation script: sudo mariadb-secure-installation
The script will prompt you to change security settings step by step. The set of questions may vary depending on the MariaDB version. For a standalone WordPress server, the recommended choices are:
- Keep database administrator login via the Unix socket;
- Remove anonymous users;
- Disable remote login for the root user;
- Remove the test database;
- Reload the privilege tables.
Remote access to MariaDB is not required for this configuration: WordPress and the database run on the same virtual machine.
After the script finishes, open the MariaDB console: sudo mariadb
If you see a prompt such as MariaDB [(none)]>, the connection was successful.
Creating a WordPress database and user
Create a separate database:
CREATE DATABASE wordpress
DEFAULT CHARACTER SET utf8mb4
COLLATE utf8mb4_unicode_ci;
Next, create the user that WordPress will use to connect to MariaDB:
CREATE USER ‘wordpress_user’@’localhost’
IDENTIFIED BY ‘STRONG_DATABASE_PASSWORD’;
Replace STRONG_DATABASE_PASSWORD with your own strong password. You will need it later when filling in the wp-config.php file.
Grant the user privileges only on the WordPress database:
GRANT ALL PRIVILEGES ON wordpress.*
TO ‘wordpress_user’@’localhost’;
Apply the changes: FLUSH PRIVILEGES;
Check the created database: SHOW DATABASES;
The list should include the wordpress entry. After checking, exit MariaDB: EXIT;
Using a dedicated user restricts its access to a single database instead of granting WordPress administrative privileges on the entire MariaDB server. The official WordPress guide also provides for creating the database and a user with privileges on it in advance.
Verifying Redis
Make sure Redis responds to local requests: redis-cli ping
A healthy server will return: PONG
Redis is installed on the same VM and must not be directly accessible from the internet. WordPress will connect to it locally through the php-redis PHP extension. The redis-cli ping check is recommended in the official Redis documentation.
At this point, the server-side part of the stack is ready: Nginx accepts web requests, PHP-FPM executes PHP code, MariaDB is ready to store the site data, and Redis handles the object cache.
Installing WordPress
Downloading and Deploying Files
Go to the temporary directory and download the latest stable version of WordPress from the official website:
cd /tmp
curl -O https://wordpress.org/latest.tar.gz
Extract the archive: tar -xzf latest.tar.gz
Move the extracted directory to /var/www: sudo mv wordpress /var/www/wordpress
Check the contents: ls -la /var/www/wordpress
The directory should contain WordPress files and folders, including:
index.php
wp-admin
wp-content
wp-includes
wp-config-sample.php
After the transfer is complete, you can delete the downloaded archive: rm /tmp/latest.tar.gz
The official manual WordPress installation process also involves downloading the distribution package, creating a database, and then running the installation script in a browser.
Configuring Ownership and Permissions
Make the files owned by the www-data system user, which PHP-FPM and Nginx use to work with the site content: sudo chown -R www-data:www-data /var/www/wordpress
Set directory permissions to 755: sudo find /var/www/wordpress -type d -exec chmod 755 {} \;
Set file permissions to 644: sudo find /var/www/wordpress -type f -exec chmod 644 {} \;
This configuration allows the owner to modify files, while other users can only read them and traverse directories. There is no need to set 777 permissions on the WordPress directory.
Creating wp-config.php
Create a working configuration file from the template:
sudo cp /var/www/wordpress/wp-config-sample.php \
/var/www/wordpress/wp-config.php
Open it in an editor: sudo nano /var/www/wordpress/wp-config.php
Find the database configuration block:
define( ‘DB_NAME’, ‘database_name_here’ );
define( ‘DB_USER’, ‘username_here’ );
define( ‘DB_PASSWORD’, ‘password_here’ );
define( ‘DB_HOST’, ‘localhost’ );
Replace the values with the database details created in MariaDB:
define( ‘DB_NAME’, ‘wordpress’ );
define( ‘DB_USER’, ‘wordpress_user’ );
define( ‘DB_PASSWORD’, ‘STRONG_DATABASE_PASSWORD’ );
define( ‘DB_HOST’, ‘localhost’ );
Replace STRONG_DATABASE_PASSWORD with the same password you specified when creating the MariaDB user.
Next, open the official WordPress secret key generator in your browser: https://api.wordpress.org/secret-key/1.1/salt/
Copy the generated block and use it to replace the lines containing AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY, and the corresponding SALT values in wp-config.php.
Save the changes with Ctrl+O, confirm the file name by pressing Enter, and close Nano with Ctrl+X.
After editing, also restrict access to the configuration file: sudo chmod 640 /var/www/wordpress/wp-config.php
Connecting WordPress to MariaDB
You can verify the database details before configuring Nginx. Log in as the user you created: mariadb -u wordpress_user -p wordpress
Enter the database password. After a successful connection, the following prompt will appear: MariaDB [wordpress]>
Check the current database: SELECT DATABASE();
Expected result: wordpress
End the session: EXIT;
This confirms that the database exists, the user can authenticate, and the user has access to it. WordPress will create the required tables later, when you run the installation wizard.
The CMS files and database settings are now prepared. The next step is to create an Nginx server block and pass PHP requests to PHP-FPM.
Configuring Nginx
Creating a server block
Create a separate Nginx configuration file for WordPress: sudo nano /etc/nginx/sites-available/wordpress
Add the following configuration to the file:
server {
listen 80;
listen [::]:80;
server_name wordpress.deploy-test-lab.com;
root /var/www/wordpress;
index index.php index.html;
access_log /var/log/nginx/wordpress_access.log;
error_log /var/log/nginx/wordpress_error.log;
client_max_body_size 64M;
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}
location ~ /\.ht {
deny all;
}
}
The server_name directive must contain the domain or subdomain that will be used for the site. In our case, this is: wordpress.deploy-test-lab.com
If you use a different domain, replace it both in the Nginx configuration and in the subsequent Certbot commands.
The root directive points to the directory containing the WordPress files. The try_files directive first checks whether the requested file or directory exists, and then forwards the request to index.php. This allows WordPress to handle permalinks for pages and posts.
Save the file with Ctrl+O, press Enter, and close Nano with Ctrl+X.
Enable the configuration by creating a symbolic link in the sites-enabled directory:
sudo ln -s /etc/nginx/sites-available/wordpress \
/etc/nginx/sites-enabled/wordpress
You can disable the default Nginx configuration so that it does not intercept requests to the server: sudo rm -f /etc/nginx/sites-enabled/default
Separate server blocks allow a single VPS to serve multiple sites with different domains and directories. Nginx selects the appropriate block based on the address and the server_name value.
Connecting PHP-FPM
Nginx does not execute PHP code itself. Requests for files with the .php extension are forwarded to the PHP-FPM service via a Unix socket:
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}
Verify that the PHP-FPM socket exists: ls -l /run/php/
The output should include the following file: php8.3-fpm.sock
You can also check the installed PHP version: php -v
Also check the PHP-FPM status: systemctl is-active php8.3-fpm
If it is running correctly, the command will return: active
If a different PHP version is installed on the server, you must update the socket name in the Nginx configuration. For example, for PHP 8.4, the path may look like /run/php/php8.4-fpm.sock.
Checking the Nginx Configuration
Before applying the changes, check the syntax of all configuration files: sudo nginx -t
If there are no errors, Nginx will output the following messages:
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
The -t option checks the configuration syntax and verifies that the files referenced in it are accessible.
After a successful check, reload the configuration without stopping the web server: sudo systemctl reload nginx
Check the server response at the local address: curl -I -H "Host: wordpress.deploy-test-lab.com" http://127.0.0.1
At this stage, the response may show a 200, 301, or 302 status code, depending on the state of the WordPress installation. The important point is that the request is handled by the server block you created and that Nginx does not return a configuration error.
Domain and SSL
Creating a DNS Record
To make the site accessible by its domain name, create an A record in the DNS zone.
For the subdomain used in this guide, the settings are as follows:
| Parameter | Value |
| Type | A |
| Name | wordpress |
| IPv4 address | 203.0.113.10 |
| TTL | Auto or the default value |
In this case, 203.0.113.10 is the Floating IP of our virtual machine. In your configuration, specify the public IP assigned to your VPS.
If the DNS zone is managed through Cloudflare, you can set the record to DNS only mode during the initial setup. In this mode, DNS returns the server’s real IP address and does not route requests through the Cloudflare proxy.
After saving the record, check which address the subdomain points to: getent hosts wordpress.deploy-test-lab.com
Alternatively, run the check from your local computer: nslookup wordpress.deploy-test-lab.com
The result should show the VPS public IP: 203.0.113.10
DNS updates may take some time to propagate. Request the certificate only after the domain starts pointing to the correct server.
Additionally, check that the site is accessible over HTTP: curl -I http://wordpress.deploy-test-lab.com
To validate the domain over HTTP, the server must be externally accessible on TCP port 80. Let’s Encrypt uses this port for HTTP-01 validation, so fully closing port 80 after configuring HTTPS is also not recommended.
Issuing a Let’s Encrypt Certificate
To automatically obtain a certificate and configure Nginx, install Certbot. The official Certbot instructions for Nginx recommend installing it via Snap:
sudo snap install core
sudo snap refresh core
sudo snap install –classic certbot
Check the installed version: /snap/bin/certbot –version
Request a certificate for the subdomain:
sudo /snap/bin/certbot –nginx \
-d wordpress.deploy-test-lab.com
Certbot will prompt you to enter an email address, accept the terms of service, and choose whether to share the address with the project’s partners.
After confirmation, Certbot will:
- Verify that the domain points to this server;
- Issue a Let’s Encrypt certificate;
- Add SSL settings to the Nginx configuration;
- Configure a redirect from HTTP to HTTPS.
The –nginx plugin can automatically modify the web server configuration and enable HTTPS for an existing HTTP site. Before you run Certbot, the site must be accessible through Nginx using its domain name.
After issuing the certificate, check the configuration again: sudo nginx -t
Then verify that automatic certificate renewal works: sudo /snap/bin/certbot renew –dry-run
This command performs a test renewal without replacing the active certificate.
Verifying HTTPS and automatic redirects
Open the following URL in your browser: https://wordpress.deploy-test-lab.com
The connection should be secured with a valid certificate, and the browser should not display any security warnings.
Check the redirect from HTTP: curl -I http://wordpress.deploy-test-lab.com
The response should include a redirect status code and the HTTPS URL:
HTTP/1.1 301 Moved Permanently
Location: https://wordpress.deploy-test-lab.com/
Then check the response from the secure version: curl -I https://wordpress.deploy-test-lab.com
Depending on the current stage of the WordPress installation, the server should return either a successful response or a redirect to the setup wizard: HTTP/2 200 or HTTP/2 302
Thus, requests to the site are handled by Nginx, unencrypted connections are redirected to HTTPS, and the Let’s Encrypt certificate is used to protect traffic.
Initial WordPress Setup
Launching the Installation Wizard
After configuring the domain, Nginx, and SSL, open the site in a browser. In our case, the URL is: https://wordpress.deploy-test-lab.com
Since the WordPress tables have not yet been created, the initial setup wizard will open instead of the completed site. First, select the interface language and click Continue.
If the wizard does not open automatically, go to: https://wordpress.deploy-test-lab.com/wp-admin/install.php
WordPress uses the settings from the wp-config.php file, connects to the previously created MariaDB database, and creates the required tables in it during installation.
Creating an administrator account and configuring site settings
On the next screen, enter the basic site settings:
- Site name — for example, Deploy Test Lab;
- Username — administrator login;
- Password — a strong unique password;
- Your email — the administrator’s address;
- Search engine visibility — for a temporary staging environment, you can ask search engines not to index the site.
It should be noted separately that it is not recommended to use the standard name admin as the login. For a production project, it is better to choose a separate name that is difficult to guess.
The visibility setting does not block access to the site; it only sends a request to search engines not to index it. For a demo environment, this setting can be enabled, and before publishing a full site, it should be disabled in the Settings → Reading.
Click Install WordPress. Once complete, a successful installation message and a login button will appear.
Log in using the account you created: https://wordpress.deploy-test-lab.com/wp-login.php
The site title, email address, and some other settings can be changed later in the admin dashboard.
Checking the Admin Dashboard
After you sign in, the WordPress admin dashboard will open: https://wordpress.deploy-test-lab.com/wp-admin/
The main Dashboard page displays information about the site status, posts, comments, and current WordPress configuration. The sidebar menu lets you manage pages, posts, users, themes, plugins, and general settings.
Verify that:
- The admin dashboard opens over HTTPS;
- The site name is displayed correctly;
- Dashboard pages load correctly;
- The browser does not show any certificate warnings.
After this, the basic WordPress installation can be considered complete. Next, we will set up a persistent Redis object cache.
Connecting to Redis
Installing and activating Redis Object Cache
Redis is already installed on the VPS, and the php-redis extension provides communication between PHP and the Redis server. Now you need to connect WordPress to Redis using the Redis Object Cache.
In the admin dashboard, go to: Plugins → Add Plugin
In the search field, enter: Redis Object Cache
Select the plugin Redis Object Cache, install it, and click Activate.
The plugin adds persistent object caching to WordPress. Frequently used query results can be stored in Redis and retrieved again without querying MariaDB. Redis does not replace the database: the site’s persistent data is still stored in MariaDB.
For the current configuration, Redis runs locally with the default settings:
Host: 127.0.0.1
Port: 6379
Database: 0
The plugin usually detects the local Redis instance automatically. To explicitly set the connection parameters, open the file: sudo nano /var/www/wordpress/wp-config.php
Before the line: /* That’s all, stop editing! Happy publishing. */
add:
define( ‘WP_REDIS_HOST’, ‘127.0.0.1’ );
define( ‘WP_REDIS_PORT’, 6379 );
define( ‘WP_REDIS_DATABASE’, 0 );
define( ‘WP_REDIS_PREFIX’, ‘wordpress:’ );
The prefix helps separate the keys for this WordPress site from data used by other applications if the same Redis server is later used by multiple projects.
Save the file and restart PHP-FPM: sudo systemctl restart php8.3-fpm
Check that Redis and PHP-FPM are running: systemctl is-active redis-server php8.3-fpm
If everything is OK, the expected result is: active
Checking the Redis connection
In the WordPress dashboard, open: Settings → Redis
If the Redis server is available, connection information will appear on the plugin page. Click Enable Object Cache, to install the object-cache.php drop-in file and enable persistent object caching.
After activation, check the main indicators:
Status: Connected
Drop-in: Valid
Redis: Reachable
The names of individual fields may vary slightly depending on the plugin version, but the main status should indicate a successful connection.
Also make sure WordPress has created the drop-in file: ls -l /var/www/wordpress/wp-content/object-cache.php
Check Redis from the terminal: redis-cli ping
The response should remain the same: PONG
You can view the number of stored keys with the following command: redis-cli DBSIZE
Immediately after connecting, the value may be low. Open several pages on the site and in the admin dashboard, then run the command again. The number of keys should increase.
Once the status changes to Connected, WordPress starts using Redis as a persistent object cache. Clearing the cache does not delete posts, pages, or settings from MariaDB; it only removes temporary data that WordPress will recreate when needed.
Post-Installation Verification
Service Status
After completing the configuration, check the status of all stack components:
for service in nginx mariadb php8.3-fpm redis-server; do
printf "%-15s " "$service:"
systemctl is-active "$service"
done
Expected result:
nginx: active
mariadb: active
php8.3-fpm: active
redis-server: active
If any service is not running, check its detailed status. For example: sudo systemctl status nginx –no-pager
You can check mariadb, php8.3-fpm, and redis-server in the same way.
Checking the site and HTTPS
Open the site in a browser. In our case, it is: https://wordpress.deploy-test-lab.com
Make sure the home page loads without errors and that the browser does not display a certificate warning.
Check the HTTP redirect: curl -I http://wordpress.deploy-test-lab.com
The response should include a 301 or 308 status code and a Location header with the HTTPS URL:
Location: https://wordpress.deploy-test-lab.com/
Then check the secure version: curl -I https://wordpress.deploy-test-lab.com
The server should return a successful response or redirect to another WordPress page.
Checking the Database and Redis
Check database access as the WordPress user: mariadb -u wordpress_user -p wordpress
After entering the password, run: SHOW TABLES;
After the installation is complete, the database should contain WordPress tables, including wp_posts, wp_users, wp_options, and others.
Close the session: EXIT;
Check the Redis response: redis-cli ping
Expected result: PONG
Then check the number of keys: redis-cli DBSIZE
If Redis Object Cache is enabled and the site has already been accessed several times, the value should be greater than zero.
You can also check whether the drop-in file exists: ls -l /var/www/wordpress/wp-content/object-cache.php
Verifying automatic startup after reboot
Make sure all services are enabled to start automatically:
for service in nginx mariadb php8.3-fpm redis-server; do
printf "%-15s " "$service:"
systemctl is-enabled "$service"
done
Each component should show a status of enabled.
Reboot the VPS: sudo reboot
The SSH connection will be disconnected. Wait about a minute, then connect to the server again: ssh -i .\wordpress-guide.pem [email protected]
In your command, use the name of your own private key and the public IP address of your virtual machine.
After logging in again, check the services once more:
for service in nginx mariadb php8.3-fpm redis-server; do
printf "%-15s " "$service:"
systemctl is-active "$service"
done
Also open the site in a browser and confirm that WordPress is still accessible over HTTPS and that Redis Object Cache retains the Connected status.
After this check, you can consider the virtual machine, web server, PHP, database, Redis, and SSL to be working correctly and starting automatically.
Conclusion
As a result, a complete WordPress stack based on Nginx, PHP-FPM, MariaDB, and Redis has been deployed on a VPS running Ubuntu 24.04 LTS. The site is accessible by its domain name over HTTPS, and the Let’s Encrypt certificate is renewed automatically.
Nginx handles incoming requests and passes PHP files to PHP-FPM. MariaDB stores the site’s persistent data, while Redis Object Cache reduces the number of repeated database queries. All core services are enabled to start automatically and continue running after the virtual machine is rebooted.
This configuration is suitable for a small website, blog, corporate page, or test project. As the load grows, it can be expanded by increasing the VPS resources, enabling backups, moving the database to a separate server, or adding a CDN.
FAQ
What VPS configuration do you need for WordPress?
For a small website or test environment, a virtual machine with 2 vCPUs, 4 GB of RAM, and at least 20 GB of disk space is sufficient. This is enough to run Ubuntu, Nginx, PHP-FPM, MariaDB, Redis, and WordPress itself.
If traffic grows, the number of plugins increases, or a resource-heavy theme is used, VPS resources can be scaled up without changing the overall architecture.
Can WordPress be installed without Redis?
Yes. Redis is not a required WordPress component. The site will continue to run with Nginx, PHP-FPM, and MariaDB.
Redis Object Cache is used to speed up repeated operations and reduce the number of database requests. For a small site, the effect may be moderate, but as traffic grows, object caching becomes more useful.
Why use MariaDB instead of MySQL?
WordPress supports both systems. This guide uses MariaDB because it is available in the standard Ubuntu repositories and is compatible with WordPress.
At the time this guide was prepared, WordPress recommends PHP 8.3 or later and MariaDB 10.11 or later.
Why is PHP-FPM needed?
Nginx does not execute PHP code itself. It forwards PHP requests to PHP-FPM, which runs WordPress and returns the result to the web server.
If PHP-FPM is stopped or the server block specifies an incorrect socket path, PHP pages will not be processed.
Can WordPress be accessed using only an IP address?
Before configuring a domain, you can test the server using its public IP address, but for regular operation it is better to use a domain name.
A domain is required for convenient access to the site and for issuing a proper Let’s Encrypt SSL certificate. In addition, Nginx selects the appropriate server block based on the server_name value and the Host header.
Should port 80 remain open after HTTPS is configured?
Yes. Port 80 is used to redirect users from HTTP to HTTPS and may be required for domain validation when issuing or renewing a certificate via HTTP-01.
The site’s primary traffic is carried over HTTPS on port 443.
Where are WordPress files and data stored?
In this configuration, the WordPress files are located in the following directory: /var/www/wordpress
Pages, settings, users, and other persistent data are stored in the MariaDB database named wordpress. Redis contains only a temporary object cache and does not replace the primary database.
What happens after the VPS is rebooted?
If Nginx, MariaDB, PHP-FPM, and Redis have been enabled with systemctl enable, they will start automatically with Ubuntu.
After the reboot, we recommend checking the status of the services, the site’s availability over HTTPS, and the status of Redis Object Cache.
Sources
- WordPress.org. Requirements
- WordPress Developer Resources. How to install WordPress
- WordPress Developer Resources. Before You Install
- Nginx Documentation. How nginx processes a request
- Nginx Documentation. Module ngx_http_core_module
- Nginx Documentation. Server names
- Certbot. Nginx instructions
- Redis Documentation. Install Redis Open Source on Linux
- Redis Documentation. Install Redis
