{"id":156,"date":"2026-06-06T09:03:00","date_gmt":"2026-06-06T09:03:00","guid":{"rendered":"https:\/\/blog.offshorekaka.in\/?p=156"},"modified":"2026-08-27T05:39:02","modified_gmt":"2026-08-27T05:39:02","slug":"install-wordpress-on-offshore-vps","status":"publish","type":"post","link":"https:\/\/offshorekaka.in\/blog\/install-wordpress-on-offshore-vps\/","title":{"rendered":"How to Install WordPress on an Offshore VPS"},"content":{"rendered":"
\n

Installation Guides<\/span><\/p>\n

WordPress on a bare VPS<\/h2>\n

A fresh offshore VPS<\/a> has nothing on it. No web server, no database, no PHP. Installing WordPress means building that stack first, then dropping WordPress on top of it.<\/p>\n

It is about twenty minutes of work. The parts people get wrong are file ownership and the PHP extensions, and both produce errors that look like something else entirely.<\/p>\n

\n
Time<\/strong>20 minutes.<\/span><\/div>\n
Order<\/strong>Secure the server first, then install.<\/span><\/div>\n
Common trap<\/strong>Wrong ownership on wp-content.<\/span><\/div>\n<\/div>\n<\/div>\n
On this page<\/strong>Before you install anything<\/a>The stack<\/a>The database<\/a>WordPress itself<\/a>The vhost<\/a>SSL and finishing up<\/a>FAQ<\/a><\/div>\n

Before you install anything<\/h2>\n

Harden the server first. It takes twenty minutes and the IP is already being scanned. Non-root user, firewall, key-only SSH, fail2ban. Our VPS security checklist<\/a> is the short version.<\/p>\n

Point DNS at the server too, since you will want a certificate at the end and that needs the domain resolving here.<\/p>\n

The stack<\/h2>\n
apt update\napt install nginx mariadb-server php-fpm php-mysql php-curl php-gd php-xml php-mbstring php-zip php-intl unzip -y<\/code><\/pre>\n
Those PHP extensions are not optional padding. Leave out php-gd<\/code> and image resizing silently stops working, so thumbnails never generate. Leave out php-curl<\/code> and WordPress cannot reach the update servers, so the dashboard sits there saying it cannot check for updates and never explains why. Leave out php-mbstring<\/code> and anything non-English breaks.<\/p>\n
Secure MySQL before going further:<\/p>\n
mysql_secure_installation<\/code><\/pre>\n
This sets a root password, removes the anonymous accounts and drops the test database. All three exist by default on a fresh install.<\/p>\n
The database<\/h2>\n
mysql -u root -p<\/code><\/pre>\n
CREATE DATABASE wordpress CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;\nCREATE USER 'wpuser'@'localhost' IDENTIFIED BY 'a-long-random-password';\nGRANT ALL PRIVILEGES ON wordpress.* TO 'wpuser'@'localhost';\nFLUSH PRIVILEGES;\nEXIT;<\/code><\/pre>\n
Use utf8mb4<\/code>, not utf8<\/code>. MySQL’s utf8<\/code> is a three byte subset that cannot store emoji or a lot of non-Latin text, and you find out when a post silently truncates at the first emoji.<\/p>\n
Grant on wordpress.*<\/code> only, and use 'localhost'<\/code> rather than '%'<\/code>. A database user that can connect from anywhere on the internet is a mistake you make once.<\/p>\n
WordPress itself<\/h2>\n
cd \/var\/www\nwget https:\/\/wordpress.org\/latest.tar.gz\ntar xzf latest.tar.gz\nmv wordpress yourdomain.com\nrm latest.tar.gz<\/code><\/pre>\n
Now ownership, which is where most installs go wrong:<\/p>\n
chown -R www-data:www-data \/var\/www\/yourdomain.com\nfind \/var\/www\/yourdomain.com -type d -exec chmod 755 {} ;\nfind \/var\/www\/yourdomain.com -type f -exec chmod 644 {} ;<\/code><\/pre>\n
\"Terminal
755 on directories, 644 on files, owned by the web server user.<\/figcaption><\/figure>\n
The user is www-data<\/code> on Ubuntu and Debian, nginx<\/code> or apache<\/code> on the RHEL family. Get it wrong and WordPress cannot write, so uploads fail and plugin installs ask for FTP credentials. That FTP prompt is almost always an ownership problem, not an FTP one.<\/p>\n
The vhost<\/h2>\n
Create \/etc\/nginx\/sites-available\/yourdomain.com<\/code>:<\/p>\n
server {\n    listen 80;\n    server_name yourdomain.com www.yourdomain.com;\n    root \/var\/www\/yourdomain.com;\n    index index.php index.html;\n\n    location \/ { try_files $uri $uri\/ \/index.php?$args; }\n\n    location ~ .php$ {\n        include snippets\/fastcgi-php.conf;\n        fastcgi_pass unix:\/run\/php\/php8.3-fpm.sock;\n    }\n\n    location ~* \/wp-content\/uploads\/.*.php$ { deny all; }\n}<\/code><\/pre>\n
The try_files<\/code> line is what makes pretty permalinks work. Without it every URL except the homepage returns 404, and people spend an hour in the permalinks settings page looking for the problem.<\/p>\n
That last block stops PHP executing inside uploads. It costs nothing and it neutralises the most common backdoor, as covered in our malware guide<\/a>.<\/p>\n
ln -s \/etc\/nginx\/sites-available\/yourdomain.com \/etc\/nginx\/sites-enabled\/\nnginx -t && systemctl reload nginx<\/code><\/pre>\n
Always nginx -t<\/code> before reloading. A syntax error caught here is a non-event; the same error found after a reload takes the site down.<\/p>\n
SSL and finishing up<\/h2>\n
apt install certbot python3-certbot-nginx -y\ncertbot --nginx -d yourdomain.com -d www.yourdomain.com<\/code><\/pre>\n
Then open the site in a browser and run the WordPress installer. It asks for the database name, user and password you created above.<\/p>\n
Two things to do straight after:<\/p>\n