Install WordPress on a VPS Without a Marketplace

WordPress does not require a one-click marketplace. On a VPS you already control nginx, PHP-FPM, and a database. Installing core yourself means you choose the PHP version, the web root, the database user, and the update path. Marketplace images hide those choices until they break. This is the DIY install on Ubuntu 24.04 in Lucknow: MariaDB, PHP 8.3 FPM, nginx, official WordPress tarball, and a wp-config you can read.

Netbay does not ship a WordPress button. That is a feature. You get an Intel Xeon Platinum VPS with High-Speed SSD and L3/L4 DDoS filtering, then you put the CMS on it the same way you would on any clean Ubuntu box.

Database and user, nothing shared with root

Install MariaDB from Ubuntu packages. Create a dedicated database and a user that can only see that database. Do not use the root account in wp-config.php. Bind MariaDB to 127.0.0.1.

sudo apt-get update
sudo apt-get install -y nginx php8.3-fpm php8.3-mysql php8.3-xml php8.3-mbstring php8.3-curl php8.3-zip php8.3-gd php8.3-intl mariadb-server unzip
sudo mysql -e "CREATE DATABASE wordpress CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"
sudo mysql -e "CREATE USER 'wpuser'@'localhost' IDENTIFIED BY 'change-this-db-password';"
sudo mysql -e "GRANT ALL PRIVILEGES ON wordpress.* TO 'wpuser'@'localhost'; FLUSH PRIVILEGES;"

utf8mb4 is required for emoji and many plugins. latin1 is a gift you will pay for later. Store the password in a password manager, not in chat logs.

Official core, not a random zip

Download the latest tarball from wordpress.org (or a known-good version pin). Extract into /var/www/wordpress. Web root is the directory that contains wp-login.php, not a parent folder. Owner is the deploy user; group is www-data. wp-content/uploads must be writable by FPM.

Copy wp-config-sample.php to wp-config.php and set DB_NAME, DB_USER, DB_PASSWORD, DB_HOST=localhost, and DB_CHARSET=utf8mb4. Generate salts from the official salt API and paste them. Do not leave AUTH_KEY as put your unique phrase here.

server {
    listen 80;
    server_name blog.example.com;
    root /var/www/wordpress;
    index index.php;
    client_max_body_size 32m;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

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

    location ~* /(?:uploads|files)/.*.php$ {
        deny all;
    }

    location ~ /. {
        deny all;
    }
}

try_files with /index.php?$args is the permalink engine. Apache .htaccess is not used. If permalinks 404, this location is wrong. The uploads deny block stops a dropped PHP webshell in the media library from executing.

Reload nginx, visit the hostname, and run the famous five-minute installer. Then delete any leftover wordpress tarball from /tmp. Put HTTPS in front with certbot after DNS points at the VPS. The first HTTP-only hour is only for bootstrap.

Hardening that marketplace images skip

define DISALLOW_FILE_EDIT as true so the admin UI cannot edit plugins. define FS_METHOD as direct only if you understand that FPM will write plugin files; the safer path is to update from a deploy user over SSH, not from the web UI. define WP_DEBUG as false. define DISABLE_WP_CRON as true and add a real crontab (covered in the cron post). Set table prefix to something other than wp_ if you want a small hurdle; it is not a security boundary.

Keep wp-config.php unreadable by others: 640, deploy:www-data. Do not put it in a git repo with production salts. xmlrpc.php is an attack surface; deny it in nginx if you do not need Jetpack or mobile pingbacks.

Limit login rate at nginx or with a small plugin you actually review. The VPS already has DDoS Protected L3/L4 filtering, which is the wrong layer for /wp-login.php brute force. That is application abuse, not a volumetric flood. Fail2ban on the auth log or an allowlist for wp-admin is the right layer.

PHP upload_max_filesize, post_max_size, and nginx client_max_body_size must agree or the media library fails silently. 32M is a reasonable default. Opcache should be on. memory_limit 256M is enough for core plus a sane plugin set; page builders can demand more.

Updates, backups, and what you own

You own core updates. Enable automatic updates for minor core, or pin and apply them from SSH. Plugin updates from the UI write as www-data, which means www-data must own those files. That conflicts with a deploy-user-owned tree. Pick one model: either the web user deploys plugins (marketplace-like, weaker), or you update from git/composer-style and the UI cannot write (stronger). For a brochure site, UI updates are convenient. For anything that takes payments, prefer SSH updates.

Back up the database with mysqldump and back up wp-content/uploads. Core and themes can be reinstalled. Uploads and the database cannot. Dump nightly onto the High-Speed SSD and copy the dump off-box. Test a restore once.

Do not install a caching plugin, an SEO plugin, a slider plugin, and a backup plugin on day one. Get TTFB honest with opcache and nginx static first. Add a page cache later if you need it.

Takeaway

A marketplace install is someone else's php.ini, someone else's cron, and someone else's surprise PHP version. A DIY WordPress on Ubuntu is a tarball, a database user, an nginx try_files vhost, and a wp-config you can grep. That is the production shape.

You can spin up an Ubuntu 24.04 instance on Netbay in under 60 seconds and install WordPress this way in Lucknow - netbayhosts.in.