Install WordPress on a Debian LAMP Stack

Published October 10, 2026

By John Dalesandro

The LAMP stack article builds a Debian server ready to host PHP applications. This guide continues from that configuration and installs WordPress.

The existing Apache virtual host, PHP-FPM, MariaDB server, and HTTPS configurations are reused. WordPress is installed in the document root rather than in a /wordpress subdirectory, so no virtual host changes are required.

Prerequisites

This guide assumes that the server is configured according to the LAMP stack article, including the PHP modules WordPress requires. The existing virtual host uses /www/example-com/public_html as its document root.

NOTE: Replace example-com and the database values below with the values used for the actual site.

Create the WordPress Database

The LAMP stack article establishes the use of a dedicated MariaDB database and user for each application. Skip this section if a database has already been created for this WordPress installation.

Otherwise, the MariaDB shell is opened with:

sudo mariadb

The database and application user are created with:

CREATE DATABASE example_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'example_user'@'localhost' IDENTIFIED BY 'strong_password_here';
GRANT ALL PRIVILEGES ON example_db.* TO 'example_user'@'localhost';
EXIT;

The database name, username, and password are required when configuring WordPress.

WordPress should use a dedicated MariaDB user rather than the MariaDB root account.

Download WordPress

The wget package is installed if it is not already present:

sudo apt install -y wget

The current WordPress release is downloaded to a temporary directory with:

wget -O /tmp/wordpress-latest.tar.gz https://wordpress.org/latest.tar.gz

WordPress distributes the current release as latest.tar.gz, and its documentation supports downloading the package directly to a server with wget.

The download is verified against the published SHA-1 checksum:

wget -O /tmp/wordpress-latest.tar.gz.sha1 https://wordpress.org/latest.tar.gz.sha1
echo "$(cat /tmp/wordpress-latest.tar.gz.sha1)  /tmp/wordpress-latest.tar.gz" | sha1sum -c -

The command reports OK when the archive matches.

Prepare the Document Root

If placeholder content exists in the document root, it should be removed first. Debian’s default DirectoryIndex order serves index.html before index.php, so a leftover index.html would hide the WordPress installer. Any test pages that call phpinfo() should also be removed. The directory contents are listed with:

ls -la /www/example-com/public_html

Any placeholder files are then removed, for example:

sudo rm -f /www/example-com/public_html/index.html

Extract WordPress Into the Site Root

The WordPress archive contains a top-level wordpress directory. A normal extraction would therefore create:

/www/example-com/public_html/wordpress/

That is not the desired layout for the existing site. The archive is extracted into the document root with -C, and --strip-components=1 removes the top-level wordpress directory:

sudo tar -xzf /tmp/wordpress-latest.tar.gz -C /www/example-com/public_html --strip-components=1

The downloaded archive and SHA-1 checksum can then be removed:

rm -f /tmp/wordpress-latest.tar.gz /tmp/wordpress-latest.tar.gz.sha1

The document root now contains the WordPress files directly:

/www/example-com/public_html/
├── index.php
├── wp-admin/
├── wp-content/
├── wp-includes/
├── wp-config-sample.php
└── ...

The existing Apache virtual host already points to /www/example-com/public_html, so no additional Apache configuration or /wordpress URL is required.

Set WordPress File Ownership and Permissions

The LAMP stack article establishes www-data as the owner of the document root. The same ownership is applied to the WordPress files:

sudo chown -R www-data:www-data /www/example-com/public_html

This ownership allows WordPress to update core files, plugins, and themes from the administration interface. It also means a compromised PHP process can modify those files.

The standard directory and file permissions are applied with:

sudo find /www/example-com/public_html -type d -exec chmod 755 {} \;
sudo find /www/example-com/public_html -type f -exec chmod 644 {} \;

The wp-config.php file does not exist yet, so its ownership and restrictive permissions are set after it is created.

Configure WordPress

The WordPress configuration file is created from the supplied template:

sudo cp /www/example-com/public_html/wp-config-sample.php \
    /www/example-com/public_html/wp-config.php

The file is then edited:

sudo nano /www/example-com/public_html/wp-config.php

The database placeholders are replaced with the values created earlier:

define( 'DB_NAME', 'example_db' );
define( 'DB_USER', 'example_user' );
define( 'DB_PASSWORD', 'strong_password_here' );
define( 'DB_HOST', 'localhost' );

DB_HOST remains localhost because MariaDB is running on the same server.

Generate Authentication Keys

A unique set of WordPress authentication keys and salts is generated with:

wget -qO- https://api.wordpress.org/secret-key/1.1/salt/

The resulting eight define() statements replace the corresponding placeholder values in wp-config.php.

The generated values should be unique to this installation.

The configuration file is then assigned to the web server user and restricted:

sudo chown www-data:www-data /www/example-com/public_html/wp-config.php
sudo chmod 640 /www/example-com/public_html/wp-config.php

The 640 mode allows the owner to read and write the file and the group to read it, while other users have no access. The file contains the database password and should therefore have restricted permissions.

Complete the WordPress Installation

The WordPress files and configuration are now in place, and the remaining setup is completed in a browser. The site’s HTTPS URL opens the WordPress installation screen:

https://www.example.com/

The installer requests a site title, administrator username, password, and e-mail address. The search engine visibility option should remain unchecked for a site intended to appear in search results.

The WordPress site URL should use the same www hostname established as the canonical URL in the Apache configuration from the LAMP stack article.

A unique administrator username and strong password should be used for the initial WordPress account.

Verify the WordPress Installation

The public site and administration interface can be verified at:

https://www.example.com/
https://www.example.com/wp-admin/

The site should load over HTTPS, and the administration interface should allow the new administrator account to sign in.

A post or page URL should also be tested after setting the preferred permalink structure under Settings > Permalinks. Saving the setting writes the rewrite rules to .htaccess. This works with the www-data ownership and the Apache configuration established in the LAMP stack article.

If a WordPress-generated URL returns a 404, the existing <Directory> block in the HTTPS virtual host should contain:

<Directory "/www/example-com/public_html">
    Options FollowSymLinks
    AllowOverride All
    Require all granted
</Directory>

After a change, the configuration is tested and Apache is reloaded with:

sudo apache2ctl configtest
sudo systemctl reload apache2

The HTTP virtual host should not be changed to AllowOverride All. The LAMP stack article intentionally enables .htaccess processing only on the HTTPS virtual host because HTTP requests are redirected before application content is served.

Summary

WordPress is now installed at the root of the existing site and served from the main domain, with no changes to the web server configuration.

The installation builds on the server from the LAMP stack article and uses its own dedicated database. The site is ready for content, themes, and plugins, and routine updates can run from the administration interface.