There is an incredible amount of information out there about installing WordPress – a Google search for “WordPress install” yields 488,000 results as of this writing. Yet among those results are very few tutorials that comprehensively explain how to install both WordPress and the underlying operating system in a way that’s maintainable in the long term. Perhaps that’s because the right configuration varies so much depending on specific needs, or perhaps it’s because a comprehensive guide doesn’t make for an easy-to-read article.

In this post we’re trying to combine the best of both worlds, by providing a bash script that automates WordPress installation on Ubuntu and walking through it to explain what each section does and the design trade‑offs we made. (If you are an advanced user, you may want to skip this post and go directly to the script, downloading and modifying it for your environment.) The resulting WordPress installation is scriptable, supports Let’s Encrypt, uses NGINX Unit, and has production‑ready settings.

We’re building on the architecture for deploying WordPress with NGINX Unit that’s described in an earlier post on our blog, while also installing and configuring features not covered there (or in many other tutorials):

• The WordPress CLI
• Let’s Encrypt and TLS/SSL certificates
• Automated Let’s Encrypt renewals
• NGINX caching
• NGINX compression
• NGINX HTTPS and HTTP/2
• Process automation

This post describes setting up WordPress on a single node where the static asset web server, PHP processing server, and database are co‑located. Installation of a multi‑host, multi‑service WordPress configuration is a potential future topic. What else would you like us to cover in a future post? Let us know in the comments section at the end of the blog!

Prerequisites

• A compute instance – container (LXC or LXD), virtual machine, or bare metal machine – with at least 512 MB of available memory, running Ubuntu 18.04 or later
• Ports 80 and 443 on the compute instance are open to the Internet
• A domain name already associated with the compute instance’s public IP address
• root privileges or equivalent access via sudo

Architecture Overview

The application architecture is the same as described in the previous blog post: a three‑tier web application. It includes PHP scripts that must be executed by a PHP processor and static files that have to be delivered by a web server.

General Principles

• Many of the configuration commands in the script are wrapped in conditionals (if statements), for idempotency: the script can run multiple times without risk of changing settings that are already correct.
• The script installs software from repositories wherever possible. This enables you to apply security patches to the system with a single command (for Ubuntu, apt upgrade).
• The commands make a best effort to detect if they are running in a container and change their configuration accordingly.
• When specifying the number of processes or threads to run in the configuration, the script provides a best guess of automatic configuration parameters that work in containers, virtual machines, or bare metal machines (on line 278 for NGINX Unit and line 306 for NGINX).
• We’ve written the configuration with an automation‑first approach, which we hope can serve as a model for creating your own reusable infrastructure as code.
• All commands run as root because they change the core system configuration, but in the runtime state WordPress runs under a regular user identity.

Setting Environment Variables

Before running the script, set the following environment variables.

• WORDPRESS_DB_PASSWORD – The password for the WordPress database.
• WORDPRESS_ADMIN_USER – The username of the WordPress administrator.
• WORDPRESS_ADMIN_PASSWORD – The password for the WordPress administrator.
• WORDPRESS_ADMIN_EMAIL – The email address of the WordPress administrator.
• WORDPRESS_URL – The full URL for the WordPress site, starting with https://.
• LETS_ENCRYPT_STAGING – Blank by default, but set to 1 if you are using staging Let’s Encrypt servers, which is necessary when frequently testing new deployments of your configuration. Otherwise, Let’s Encrypt might block your IP address temporarily for making excessive requests.

The script checks that the WordPress‑related variables are set and exits if any are not (lines 8–42, not shown here). Lines 572–576 check the value of LETS_ENCRYPT_STAGING.

#blog #tech #wordpress #nginx unit #ubuntu