Installing WordPress with LEMP and MariaDB on Ubuntu

To install WordPress with LEMP and MariaDB on Ubuntu, you will set up a WordPress MariaDB database, install the required PHP packages, download WordPress, configure the web server and MariaDB database, and then complete the installation through the WordPress web interface.

Note

If you want to skip all the technical steps of setting up WordPress on your server and have it installed in minutes, then I have some great news for you! Our team of engineers has prepared a ready-to-use 1-click WordPress application for your convenience. Just choose a server, and while prompted to choose the operating system, choose WordPress from the dropdown menu. This will set up WordPress in minutes!

Prerequisites for Installing WordPress with LEMP and MariaDB

To install WordPress with the LEMP stack and MariaDB database, you need the following:

• An Ubuntu 24.04 server. We offer the globe's absolute lowest cost Ubuntu servers!
• Root access to your server or a sudo user. Check out our How to access your server using SSH guide to learn how to access your server and create a sudo user.
• The LEMP stack installed on your server. Use our Installing LEMP on Ubuntu 22.04 LTS guide to set it up. Or you can use our LEMP 1-Click Application to get started in minutes! Just choose a server, and while prompted to choose the operating system, choose LEMP from the dropdown menu.

Step 1 - Updating the Package Cache

Before you install WordPress with LEMP and MariaDB, you need to update your Ubuntu packages in the package manager cache to the latest available versions using the following command:

sudo apt update

Step 2 - Creating a WordPress MariaDB Database and User

WordPress needs a MySQL database to store your site's data, such as user information, posts, pages, etc. In this tutorial we'll use MariaDB, which is a compatible drop-in replacement for MySQL but with more features.

To create a MySQL/MariaDB database, use the mysql client to connect to MariaDB and access its command line interface with the following command:

sudo mysql

If you get an error that contains Access denied for user 'root', this means that the default authentication method has changed, and connecting to MariaDB requires a password for the root account. To solve this issue, use the following command to connect to MariaDB using the root user and a password:

mysql -u root -p

You'll be asked for your MySQL root password, enter it and then press Enter.

Note: If you've installed the LEMP stack using our 1-Click App, you'll find your MySQL root password in the App Details widget on your SSDNodes Dashboard. As demonstrated in the following image:

You should get a prompt similar to the following:

Now you can create a database for WordPress. We'll name the database wordpress, but feel free to use your site's name, or any other name you would like, just make sure to remember it. Use the following MySQL statement to create a database named wordpress:

CREATE DATABASE wordpress DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci;

This creates a database called wordpress with UTF-8 as a character set, which supports all alphabets and languages.

If you receive an error upon entering the preceding command, make sure you've typed it in correctly, and that you end it with a semicolon (;).

Next, you'll need to create a MariaDB user account that will manage this wordpress database. Only this one account can interact with the site's database, which is a good security best practice. For this new user, we'll use the name wp_user, but again, feel free to use another name of your choice.

To create a new MariaDB user account, use the following statement in the MariaDB command line interface. Remember to replace password with a strong password for your user account, or you might wake up some day to the news of your WordPress website transforming into an abnormal nightmare:

CREATE USER 'wp_user'@'localhost' IDENTIFIED BY 'password';

Now, you'll need to give all access permissions to the user account that will manage your wordpress database:

GRANT ALL ON wordpress.* TO 'wp_user'@'localhost';

Here, you use the GRANT ALL statement to grant all privileges on the wordpress database to your wp_user user.

Refresh the privileges for the preceding command to take effect and apply the permission changes to the database server:

FLUSH PRIVILEGES;

Exit out of the MariaDB command line interface and return to the regular Linux shell with the following command:

EXIT;

With this, you have a MariaDB database and a MariaDB user account that can be used by your WordPress website to store data. Next, you'll install some important PHP packages that WordPress needs to function properly.

Step 3 - Installing Required PHP Extensions for WordPress

WordPress requires a few additional PHP packages to be installed, in addition to the PHP packages that were installed with the LEMP stack. In this step, you'll use the apt command to install the most important PHP extensions that WordPress uses.

Note: The PHP packages we'll install are required for basic WordPress usage, but many WordPress plugins that extend the basic functionalities of WordPress come with their own requirements, and may require additional PHP extension packages to be installed. Refer to the documentation of the specific plugin you want to install to find out its required packages and install them with apt using the method we'll demonstrate in this step.

To install the most important PHP extensions for WordPress, run the following command:

sudo apt install php-curl php-gd php-intl php-mbstring php-soap php-xml php-xmlrpc php-zip php-imagick

Here, you install the following packages:

• php-curl: Provides a CURL module for PHP. CURL is used in command lines and scripts to transfer data through URLs.
• php-gd: Provides a GD module for PHP. The GD library is a library that offers graphics drawing tools to manage image data.
• php-intl: Provides an Internationalisation module for PHP.
• php-mbstring: A package that provides the MBSTRING module for PHP, which is used to manage non-ASCII strings.
• php-soap: Provides the SOAP module for PHP. SOAP is an API architecture that uses the XML language to transfer data between software. Although it has been replaced by the more flexible REST architecture in most web services, SOAP is still used by some companies.
• php-xml: A package that provides a DOM, SimpleXML, WDDX, XML, and XSL module for PHP.
• php-xmlrpc: Provides a XMLRPC-EPI module for PHP. XML-RPC is a feature of WordPress that enables data to be transmitted via HTTP using XML for encoding.
• php-zip: Provides a Zip module for PHP. Zip is a tool that is used to archive and compress files.
• php-imagick: Imagick is a native php extension to create and modify images using the ImageMagick API.

Once the installation is complete, restart the php-fpm process for it to use the newly installed PHP extensions:

sudo systemctl restart php8.1-fpm.service

Note: You may have another version of php-fpm installed on your system, so you might have to change 8.1 in the preceding command with your version of PHP. To check your php-fpm version, use the following command:

sudo systemctl status php* | grep fpm.service

You should receive the full name and version of your php-fpm service:

With this, the required PHP extensions are now installed. Next, you'll configure Nginx to serve WordPress.

Step 4 - Configuring Nginx to Serve WordPress

Now that our WordPress database and the PHP extensions are ready, we'll configure the Nginx web server to serve the pages and posts of our website. We'll create a new root web directory for WordPress files, and use a new Nginx configuration file made specifically for the website.

First check Nginx’s status with the following command:

sudo systemctl status nginx

The output should show that the Nginx service is enabled and running:

By default, Nginx is configured to serve files out of a root web directory located at /var/www/html. This default configuration is suitable for small single-site web servers. However, hosting multiple sites using this method will quickly become unmanageable and cumbersome. Instead, it is best to create a root web directory for each site you’d like to host on your web server. In this tutorial, we will create a root web directory for our WordPress website located at /var/www/wordpress. Again, feel free to use your site's name or some other name instead of wordpress for this root web directory, just remember to use the correct path in your Nginx configuration.

Use the following command to create a root web directory for your WordPress site, replacing wordpress with your site’s name if you want:

sudo mkdir /var/www/wordpress

Next, open a new configuration file in Nginx’s sites-available directory, which is a directory that contains configuration for each of your sites. Again, make sure to replace wordpress with your name of choice:

sudo nano /etc/nginx/sites-available/wordpress

Paste into it the following:

server {
    listen 80;
    listen [::]:80;
    server_name <domain_name_or_IP>;
    access_log off;
    location / {
        rewrite ^ https://$host$request_uri? permanent;
    }
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name <domain_name_or_IP>;
    root /var/www/wordpress;
    index index.php index.html index.htm index.nginx-debian.html;
    autoindex off;
    ssl_certificate /etc/ssl/certs/lemp.pem;
    ssl_certificate_key /etc/ssl/private/lemp.key;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers HIGH:!aNULL:!MD5;

    location ~ \.php$ {
         include snippets/fastcgi-php.conf;
         fastcgi_pass unix:/var/run/php/php-fpm.sock;
         fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
         include fastcgi_params;
    }

    location / {
        try_files $uri $uri/ /index.php$is_args$args;
    }
    location = /favicon.ico { log_not_found off; access_log off; }
    location = /robots.txt { log_not_found off; access_log off; allow all; }
    location ~* \.(css|gif|ico|jpeg|jpg|js|png)$ {
        expires max;
        log_not_found off;
    }
}

Here, you have two server blocks representing configuration for two ports: port 80 which serves HTTP requests, and port 443 that serves HTTPS requests.

Notice that, in the HTTP configuration, you use the rewrite directive in the location block to redirect HTTP requests to HTTPS.

In the preceding configuration file, you set up the following:

• listen: The port number Nginx will listen on. Here, you set its value to 80 in the HTTP server block, which is the port number assigned to HTTP. And you set it to 443 in the HTTPS server block, which is the port number for HTTPS.
• server_name: The domain names or IP addresses these two server block configurations should respond for. Make sure to replace `` with your domain name or IP address.
• access_log: Configures Nginx access logs, the special value off cancels all access_log directives on the current level.
• root: The root web directory, also known as the document root, that stores the files served by your website. Here, you set its value to /var/www/wordpress, which is the root web directory we created earlier, so make sure to set the proper value in your case.
• index: The order in which Nginx will prioritize index files for your website.
• autoindex: Configures Nginx auto indexing to enable or disable the ability to browse your files from the web browser. We set it to off to disable auto indexing.
• ssl_certificate: The SSL certificate file path. See Secure Your Site Using HTTPS for more information.
• ssl_certificate_key: The path of your SSL certificate's private key file.
• ssl_protocols: The protocols that will be used by SSL.
• ssl_ciphers: The ciphers that will be used by SSL.
• location ~ \.php$: A location block that handles PHP processing. It tells Nginx to handle any HTTP request with a URL that ends with .php with the directives included in this location block. This effectively points Nginx to the fastcgi-php.conf configuration file and the php-fpm.sock file, which declares the socket that is associated with php-fpm.
• location /: The main location block, which includes a try_files directive, and it allows Nginx to route HTTP requests to the WordPress index.php file.
• location = /favicon.ico: A location block for requests to /favicon.ico. Which you configure to disable logging for the favicon.ico file.
• location = /robots.txt: A location block for requests to /robots.txt. Which you configure to disable logging for the /robots.txt file.
• location ~* \.(css|gif|ico|jpeg|jpg|js|png)$: A location block to configure static files to be cached with the maximum value, which sets the browser cache expiration time in the far future. This is important because these static files are expensive resources to serve.

Next, you'll need to activate this Nginx server block configuration by linking your wordpress configuration file to the configuration file in Nginx’s sites-enabled directory using the following command:

sudo ln -s /etc/nginx/sites-available/wordpress /etc/nginx/sites-enabled

To check that your configuration file has been properly linked to Nginx’s sites-enabled directory, run the following command:

sudo ls -l /etc/nginx/sites-enabled

You should receive an output that’s similar to the following:

total 0
lrwxrwxrwx 1 root root 34 Aug 13 14:06 default -> /etc/nginx/sites-available/default
lrwxrwxrwx 1 root root 36 Aug 14 10:17 wordpress -> /etc/nginx/sites-available/wordpress

Here, you can see that your /etc/nginx/sites-available/wordpress configuration file has been successfully linked.

Next, unlink the default Nginx configuration from the /sites-enabled/ directory. This forces Nginx to use your wordpress configuration instead of the default configuration:

sudo unlink /etc/nginx/sites-enabled/default

To check that the default Nginx configuration has been properly unlinked from the sites-enabled directory, run the following command:

sudo ls -l /etc/nginx/sites-enabled

You should receive an output that’s similar to the following:

total 0
lrwxrwxrwx 1 root root 36 Aug 14 10:17 wordpress -> /etc/nginx/sites-available/wordpress

Here, you can see that the default configuration symlink is no longer in the sites-enabled directory, which means that it has been successfully unlinked.

Next, test your configuration’s syntax using the following command:

sudo nginx -t

You should receive an output that’s similar to the following:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

This output shows that there are no errors in the configuration file.

If you receive any errors, review your configuration file and make sure you’ve set your directives and values properly.

Next, reload Nginx for the changes you’ve made to take effect by running the following command:

sudo systemctl reload nginx

You now have Nginx configured to serve files from the /var/www/wordpress root web directory. Let's test the configuration using a test HTML file:

sudo nano /var/www/wordpress/test.html

Add the following HTML code to it:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Wordpress on LEMP Test Page</title>
</head>
<body>
    <h1>Test Page for WordPress Nginx Configuration</h1>
</body>
</html>

Save and close the file.

Use your browser to navigate to this test.html file:

https://<domain_name_or_IP>/test.html

As always, replace <domain_name_or_IP> with your domain name or IP address.

If you haven't set up an SSL certificate from a Certificate Authority like Let's Encrypt, you will receive a "Not Secure" error informing you that the connection to your server is not secure. This error message is normal because your website is encrypted and secured with a self-signed certificate, and the browser does not recognize it since your server is not one of its known certificate authorities.

Click the Advanced button or More information depending on the browser, and choose to proceed. The following is an example of the error in the Google Chrome browser:

Once you proceed, you'll receive the message Test Page for WordPress Nginx Configuration. Which means that the Nginx configuration is correct.

To secure your WordPress website using a valid SSL certificate, check out the Creating and Installing a CA Certificate section of our Secure Your Site Using HTTPS with Self-Signed or CA SSL Certificates on Ubuntu article.

You now have Nginx configured and tested, and you can now download and install the WordPress files on your server and serve them with Nginx, which is what we'll do in the next step.

Step 5 - Downloading WordPress and Setting up its Configuration File

You've created a database for your WordPress site, installed the required PHP extensions, and configured Nginx. Now, you are ready to download WordPress files and set them up in your root web directory.

First go to your /tmp temporary directory, in which you'll download the WordPress release compressed in a tar.gz archive:

cd /tmp

Next, use wget to download the latest WordPress release using the following command:

wget https://wordpress.org/latest.tar.gz

Once the download finishes, use the tar command line tool to extract the package:

tar -xzvf latest.tar.gz

Check that a new wordpress folder is in your /tmp directory and display its contents with ls:

ls /tmp/wordpress

You should see a list of files. These files represent the source code of WordPress.

The WordPress documentation recommends that you rename the wp-config-sample.php sample configuration file into wp-config.php, which is the file name WordPress uses for configuration. Use the following command to copy the wp-config-sample.php file into a file called wp-config.php to be used by WordPress:

cp /tmp/wordpress/wp-config-sample.php /tmp/wordpress/wp-config.php

Next, copy the contents of this wordpress directory into your /var/www/wordpress root web directory using the following command:

sudo cp -a /tmp/wordpress/. /var/www/wordpress

Now check the contents of your /var/www/wordpress root web directory:

sudo ls -l /var/www/wordpress

You should receive an output similar to the following:

Nginx will need permissions to modify the /var/www/wordpress directory, so you'll need to assign its ownership to the www-data user and group, which is the user and group that Nginx uses. Run the following command to assign the root web directory to Nginx's user and group:

sudo chown -R www-data:www-data /var/www/wordpress

With this, WordPress code is in your root web directory, and Nginx has permission to modify it in order to serve and update it.

Configuring WordPress with MariaDB

Next, you'll need to set up some WordPress configurations for your site to function properly.

First, set up secret keys required for WordPress to enhance security. You can generate the required secret keys using an online service that WordPress provides. Use the following command to get random and secure secret keys from the WordPress API:

curl -s https://api.wordpress.org/secret-key/1.1/salt/

You'll get random values similar to the following:

You can copy the keys you get and paste them into your wp-config.php configuration file.

Note: Do not share your unique secret keys with anyone!

Copy the keys you receive and open the wp-config.php configuration file:

sudo nano /var/www/wordpress/wp-config.php

Find the following section:

define('AUTH_KEY',         'put your unique phrase here');
define('SECURE_AUTH_KEY',  'put your unique phrase here');
define('LOGGED_IN_KEY',    'put your unique phrase here');
define('NONCE_KEY',        'put your unique phrase here');
define('AUTH_SALT',        'put your unique phrase here');
define('SECURE_AUTH_SALT', 'put your unique phrase here');
define('LOGGED_IN_SALT',   'put your unique phrase here');
define('NONCE_SALT',       'put your unique phrase here');

And replace the values with your unique secret keys.

Next, configure WordPress to use the database you created earlier. Look for the following lines in your configuration file, and set the proper values to them:

define( 'DB_NAME', 'wordpress' );

/** MySQL database username */
define( 'DB_USER', 'wp_user' );

/** MySQL database password */
define( 'DB_PASSWORD', 'password' );

Here you set the following configuration values:

• DB_NAME: The database name you created in Step 2.
• DB_USER: The database user name.
• DB_PASSWORD: The database password.

Next, to allow Nginx to write files to your WordPress website, add the following line to wp-config.php. This forces WordPress to use direct file IO requests from within PHP. Make sure to add it before the line that instructs you to stop editing the configuration:

define( 'FS_METHOD', 'direct' );
/* That's all, stop editing! Happy publishing. */

Save and close the file.

You now have the required WordPress configuration. Next, we'll perform one last thing to finish up our WordPress installation journey, where you'll use the web interface that comes with WordPress to set up your website.

Step 6 - Finishing up Your WordPress & MariaDB Installation

You've created a MariaDB database, installed the required PHP extensions, configured the Nginx web server to serve your website, and configured your WordPress website through the wp-config.php file. It is now time to finish the installation through the WordPress web interface.

First, navigate to your website using your browser:

https://<domain_name_or_IP>/

You'll receive a web form asking you to choose your WordPress site's language:

Next, you'll be asked to set a title for your website, a user name, a password, your email address, and search engine visibility. Set your preferred values and click Install WordPress.

Note: For security reasons, it is recommended to choose a hard to guess username. Avoid using your first name or common names such as admin or administrator.

You'll be redirected to a page notifying you that the installation was successful, and asking you to login using the username and password you've set.

Logging in will take you to the WordPress dashboard:

Now visit your site with your web browser:

https://<domain_name_or_IP>/

Your website is now officially online!

Congrats

You now have your very own place on the Internet! You can use your WordPress website to create a blog, an online shop, or an online gallery to show your amazing art, or whatever else you'd like!

Explore the WordPress dashboard to learn more about what you can do. For example, go to Appearance > Themes to select a new theme for your website.

Important Note

What we’ve done in this article is suitable for testing purposes and personal use, whereas if you want to publish your site to production, and securely process your customers’ online transactions, we do suggest you check our Secure Your Site Using HTTPS with Self-Signed or CA SSL Certificates on Ubuntu blog article.

Reader Alert!

If you feel that the technical instructions in this tutorial are time-consuming, or beyond your expertise, you can choose a very convenient and practical solution, ready-made, fully and professionally tested, and developed by SSD Nodes (That is us ). Just visit our website, choose the server’s specifications that fit your needs, and while prompted to choose among the operating systems and the 1-Click Applications we have, choose WordPress from the dropdown menu, complete your checkout, and in a couple of minutes our algorithms will take care of all the technical aspects smoothly and effortlessly, just for you!

Bonus: All our 1-Click applications are now installed with an active HTTPS self-signed certificate!

Way more practical, smooth, and headacheless, isn’t it?

Well, WordPress might be the most popular way to host a website—blog or not—but it's not the only way. Or even the best way, depending on your circumstances.

Because WordPress depends on a MySQL database to store information about posts, pages, users, and comments, the technical overhead to keep things running smoothly is a little more complex than plain 'ol HTML and CSS.

Having a database is another opportunity for failure, another potential attack vector, and constantly pinging a database can slow down popular websites, forcing administrators to rely on caching.

And that leaves many developers looking for fast, well-supported WordPress alternatives.

What's different about a flat-file CMS?

Flat-file content management systems (CMS) present an alternative vision: instead of pulling content from a database, these systems pull content from a plain text/Markdown file.

These text files can be edited in text editors or via a WordPress-like dashboard and can be deployed via Git, SCP, FTP, and more. That makes for faster and secure WordPress alternatives—you just choose which features you need most.

Pros and cons of a flat file CMS as a WordPress alternative

Before we dive into the options, and in all fairness, let's take a moment to consider why you would and wouldn't want to host your website via a flat-file CMS.

The pros:

• Full-feature
• No SQL injection: Even great developers can create SQL injection vulnerabilities—leaving a database out of the equation certainly boosts security in this regard, and lowers the risk of catastrophic crashes.
• Version control everything: If you use Git for your projects, controlling your entire site—from templates to actual content—becomes trivial. You get all the peace of mind of version control without any additional complexity.
• Speed: Without database queries, pages should load faster—because speeds affect everything from conversions to Google search rank, which could make an impact on the bottom line.

The cons:

• Lack of plugins/community: All of the flat-file CMSs listed below have communities that are significantly smaller than WordPress', or even others like Django. This means fewer available plugins and potentially less community technical support if things go wrong.
• Unfamiliar environment: If you're a web developer building websites for clients, they might not appreciate being thrown into a new CMS environment after spending most of their time in WordPress previously. If it's a personal website, you should consider your own learning curve as well.
• No search or sort: Without a database to organize your content, reliable site search, and sorting becomes a lot more difficult to implement. Some flat-file CMSs have similar capabilities, but they're usually not quite as inherently robust as what you get with a relational database.

The unknowns:

• Development speed: Some argue that flat-file is easier to develop, but I think it's safer to say that this mostly depends on what you're trying to develop, and how complex the end result is meant to be. There's no clear winner here except whatever solution gets the job done.
• Flexibility: Again, chalk this one up to developer skill and ambition. Flat-file CMSs are likely to be less complex than WordPress' internals, but that could be both good and bad, depending on your needs.

Flat-file CMS vs. static site generator

You might have heard another term thrown around when it comes to WordPress alternatives: the static site generator. While both flat-file and static blogs ditch a database in favor of plain text or Markdown files to store content, they do have their differences.

Flat-file blogs use technologies like PHP to read the contents of those files and build/serve pages as users request them. With a static blog, you instead build pages once, copy them onto a VPS, and serve them as plain .html files with a web server. Both have their advantages and disadvantages, but no matter which route you choose, you're going to get a WordPress alternative that's faster and more secure.

One negative of static site generators is that they're truly developer-focused—there's no dashboard or content editor to help you manage your posts. You'll have to get familiar with a good code editor and the command line to write content and deploy the generated site. At the same time, they're even easier to manage, as all you have to worry about is a bunch of plain text served by Apache or Nginx.

With that cleared up, let's get to some of the most popular and proven flat-file CMSs out there!

Here are our top 12 flat-file CMS WordPress alternatives:

1. Grav

Probably the most popular flat-file WordPress alternative out there—Grav was built to focus on speed and simplicity. The Twig templating language helps you do all the usual loops and inserting variables, and Markdown files make editing content a breeze. It's PHP-based and licensed under MIT.

Website: getgrav.org

2. Flextype

Designed in part to be a replacement for Monstra (which was removed from this list due to being unsupported), Flextype is an open-source, PHP-based flat-file CMS that still can use the power of shortcodes and a plugin API to please more advanced users. Overall, a promising new contender in a field that's shrunk a bit from its heyday a few years ago.

Website: flextype.org

3. Typesetter

Typesetter has been around for years and seems to be still going strong. The GPL-licensed open-source project is based on PHP and comes with jQuery, CKEditor, Bootstrap, and Sass/Less built-in for easier development. They claim it's 8 times faster than WordPress, which is intriguing enough to make it worth a quick installation. Typesetter also uses a "true WYSIWYG" editor, which allows you to edit all the text on your site, presumably without actually diving into the underlying code.

Website: typesettercms.com

4. Pico

Pico is actually one of the main points of inspiration for Grav and uses the same Twig templates and Markdown files. It's even more barebones than Grav, which makes it great for those who want to build their sites locally and then deploy instantly via Git.

Website: picocms.org

5. October

October really bills itself as client-friendly, so it might be a good choice for web developers who are building products for their own clients. It's based on the proven Laravel PHP framework and comes with a really slick-looking dashboard for making changes to both the content and the underlying code.

Website: octobercms.com

7. WonderCMS

Another one in active development, WonderCMS lets you edit just about any aspect of the website with a WYSIWYG editor—handy for those who want maximum flexibility or want their clients to be able to tweak on their own. There's no configuration necessary, and it comes with a bunch of built-in features like one-click backups.

Website: wondercms.com

8. razorCMS

razorCMS aims to combine two different technologies together to make the build-out a little easier. The public-facing site is basic PHP and flat files, whereas the management console is an angularJS web application. razorCMS also has a supported Docker installation, which might be an added bonus for those who want to keep all their applications separate.

Website: razorcms.co.uk

9. Automad

Automad claims it uses a "human-readable syntax" for creating custom themes without any knowledge of PHP, and solves some of the aforementioned cons of flat-file—it comes with built-in caching and search in just a few steps. All content is stashed in easy-to-use, version-controllable .txt files.

Website: automad.org

All of the options above have been entirely free and open-source (FOSS), but there are some truly impressive flat-file CMSs that require a paid license. In all fairness, we couldn't leave them out entirely.

10. SingleCMS

A relative newcomer onto the scene, SingleCMS is ridiculously simple. You can convert your plain HTML website into one managed by SingleCMS by changing the extension, adding a few small bits of code, and telling SingleCMS where you want to enable rich editing. You or your clients can then manage their own content with almost no complexity. A license currently costs $39 and comes with a year of free updates. Backups are available but come at an additional cost.

Website: singlecms.com

11. Kirby

Kirby has an impressive list of clients, such as Joyent, Mercedes-Benz, and Smashing Magazine. Installation is as easy as uploading a handful of files to your server. A single site license costs €99 and comes with all the features enabled by default.

Website: getkirby.com

12. Statamatic

Who needs just a blog when you can build any type of content thanks to rich content types, routes, and templating capabilities? Statamatic is built on Laravel and lets you version control everything, "from content to config." A single license will set you back $199, but for web development agencies, there's an unlimited license version for up to $199/month.

Website: statamatic.com

The wider world of WordPress alternatives

Not convinced that a flat-file CMS is right for you, but you still want to try one of the many WordPress alternatives? You're in luck. You can try Ghost, which also uses a database but is generally perceived as more modern and developer-friendly. Jekyll is another popular static site WordPress alternative that's open-source and actively developed by the GitHub team. And if you want to go all-in on static site generators, I can't recommend Hugo enough.

The beauty of EasyEngine is that it not only sets up a WordPress blog, but automatically installs its dependencies, such as Nginx, PHP, MySQL, and others. There are a bunch of built-in features like caching and HHVM. With a single command, you can create a variety of WordPress configurations, such as WP Super Cache + Multisite, or Redis cache + single site.

As of v3.4.0, EasyEngine comes with built-in support for Let's Encrypt as well.

In this tutorial, we'll cover the details in installing EasyEngine and setting up a single WordPress site that uses HTTPS powered by a Let's Encrypt certificate.

Prerequisites

• A VPS running any of our OS options—Ubuntu 16.04, Debian 9, Debian 8, or CentOS 7.
• A non-root, sudo-enabled user. If you only have a root user, see our SSH tutorial for details on creating new users.
• A registered domain name.

Notes

• This tutorial uses variables to represent user-specific configurations, such as server IP addresses, passwords, domain names, and more. Whenever you see one of these variables, you should replace them with your specific details.

Step 1: Install EasyEngine

Debian: Before we even try installing EasyEngine, let's install ca-certificates. If you don't install this, the wget portion of the following command will fail without any output.

$ sudo apt-get install ca-certificates

To install EasyEngine, simply run the command below:

$ wget -qO ee rt.cx/ee && sudo bash ee

The command first downloads the EasyEngine install script using wget, and then executes it using bash. As usual, we recommend that you take a moment to check out the script itself to ensure that it's not installing anything you don't want.

Step 2: Configure your DNS

Before you begin, make sure that you have pointed your domain toward your VPS' IP address. In this case, both www.DOMAIN.LTD and DOMAIN.TLD need to point to the server. Let's Encrypt requires these to match up in order to give the certificate. If you bought your domain name via SSD Nodes, we provide the necessary DNS to establish this configuration. If you bought your domain elsewhere, consider setting up a free CloudFlare account to use their DNS tools.

Step 3: Run EasyEngine

EasyEngine aims to make installing WordPress incredibly easy, and the same goes when adding a Let's Encrypt certificate on top of that. It's all done in a single command:

$ sudo ee site create DOMAIN.TLD --wp --letsencrypt

You'll start to see output in the terminal as EasyEngine begins to download, install, and configure packages.

At some point, you will be requested to confirm that you want to use Let's Encrypt. Just type in y, followed by Enter.

Letsencrypt is currently in beta phase.
Do you wish to enable SSl now for example.com?
Type "y" to continue [n]:y

If Let's Encrypt setup works successfully, you'll see the following output:

Let's Encrypt successfully setup for your site
Your certificate and chain have been saved at /etc/letsencrypt/live/example.com/fullchain.pem
Configuring Nginx SSL configuration
Adding /var/www/example.com/conf/nginx/ssl.conf
Adding /etc/nginx/conf.d/force-ssl-example.com.conf
Added HTTPS Force Redirection for Site  http://DOMAIN.TLD
Creating Cron Job for cert auto-renewal
Reload : nginx     [OK]
Congratulations! Successfully Configured SSl for Site  https://DOMAIN.TLD
Your cert will expire within 89 days.

This basic configuration sets up a cron job to renew your certificate before it expires after 90 days.

You can access the root of the WordPress installation via /var/www/example.com/htdocs. Even better, you'll now be able to visit your new WordPress site via your domain.

Already have an EasyEngine site?

If you already have a WordPress site running via EasyEngine, you can \add a Let's Encrypt certificate and reconfigure Nginx—again, with a single command.

$ sudo ee site update example.com --letsencrypt

As with the basic installation in step 2, this will enable a cron job to ensure the certificate is renewed regularly.

Conclusion

You should now be up and running with a SSL-enabled WordPress site, all in just a few commands.

If you want to update the EasyEngine core, simply run ee update.

You can also update your individual sites with new features, such as caching, with the ee site update command:

$ sudo ee site update DOMAIN.TLD --wp --wpfc

The EasyEngine documentation contains many more tweaks, so curious developers should take some time to peruse them. Happy blogging!

Redis is an open source data structure store, and it's popular among WordPress users for its simplicity and highly optimized approach to caching, which can help pages load significantly faster.

Why caching? In a normal WordPress installation, when a user browses to the index page (index.php), the MySQL database is queried for the posts within the loop. This is usually pretty quick, but if you have multiple loops or many concurrent users, the sheer volume of database queries can become overwhelming for your VPS. A caching layer like Redis will query the database once and create a plain HTML file that it will serve instead of normal index.php file, which will boost page loads and dramatically cut back on database queries.

Prerequisites

• A VPS running Ubuntu 16.04
• A working WordPress installation—check out our previous guides on a bare WordPress installation, using EasyEngine or Docker.

Step 1. Installing Redis

Redis is available in the default package repositories for all our OS options, so installation is a breeze.

$ sudo add-apt-repository ppa:chris-lea/redis-server
$ sudo apt-get update
$ sudo apt-get install redis-server php-redis

Now, we'll quickly verify that Redis was installed correctly by running redis-cli. If you see the prompt change to 127.0.0.1:6379>, you're off to a good start, and if you run the ping command, you should see PONG in response.

$ redis-cli
127.0.0.1:6379> ping
PONG

Step 2. Configuring Redis

Next, we need to set up a few configurations to make PHP and Redis work together, and for Redis to work as a cache. Open the /etc/redis/redis.conf file in the editor of your choosing, and add the following lines to the end of the file.

maxmemory 256mb
maxmemory-policy allkeys-lru

The RAM allotted in the maxmemory 256mb line can be increased according to your needs.

Finally, we'll restart the Redis server.

$ sudo service redis-server restart

Step 3. Connecting WordPress to Redis

The easiest way to connect WordPress to Redis is by using a popular plugin called Redis Object Cache. Simply install the plugin via the WordPress dashboard and then navigate to the settings. You should see a screen like the following.

The plugin immediately recognizes our Redis installation, and all you have to do is click the Enable Object Cache button to start using Redis as a caching layer for WordPress.

Step 4. Double-check that the cache is working

Before we move on, let's take a moment to ensure that Redis is actually being used as a caching layer for WordPress. Type in the following command, which will enable a real-time log of Redis activity.

$ redis-cli monitor

If the cache is working properly, you'll start to see output like the following:

1501199997.504554 [0 127.0.0.1:58530] "PING"
1501199997.505818 [0 127.0.0.1:58530] "GET" "wp_:default:is_blog_installed"
1501199997.509033 [0 127.0.0.1:58530] "GET" "wp_:options:notoptions"
1501199997.509179 [0 127.0.0.1:58530] "GET" "wp_:options:alloptions"

Hit Ctrl + c to end output.

And with that, your WordPress implementation should be cached and ready to serve pages faster than ever before! Proof that not every speed boost needs to come with incredibly complex administration—there's a good reason why so many people love and use Redis on their VPS.