Run WordPress, PHP, MySQL, Node.js and MongoDB on One VPS

A single VPS can host WordPress and custom applications using PHP, MySQL, Node.js and MongoDB, provided you separate services and manage their resources carefully. This guide uses Ubuntu, Nginx and systemd; you will need a domain, SSH access and enough memory for your expected workload.

What You’ll Need

• A VPS running a currently supported Ubuntu LTS release. At least 2 GB RAM is a practical starting point for a light test setup; production workloads may need substantially more. Check actual memory use rather than assuming every application will fit.
• A non-root sudo account, SSH access, and a domain whose DNS records you can edit.
• Basic familiarity with the Linux command line, DNS, and editing configuration files.
• Application code, WordPress files, and a plan for backups. Do not use this setup as a substitute for tested backups or monitoring.

Step-by-Step

1. Connect and update the server. Log in using SSH as your sudo user, then run sudo apt update and sudo apt upgrade. Reboot if the upgrade requires it. Configure your cloud firewall to allow SSH from a trusted address where possible, and allow inbound TCP ports 80 and 443 for web traffic. Do not expose database ports 3306 or 27017 publicly.
2. Point DNS to the VPS. At your DNS provider, create an A record for the website hostname pointing to the server’s IPv4 address. Add an AAAA record only if IPv6 is configured and reachable. DNS changes can take time to become visible. Choose hostnames for the WordPress site and any Node.js applications, such as example.com and app.example.com.
3. Install Nginx, PHP and MySQL. Install the packages with sudo apt install nginx mysql-server php-fpm php-mysql php-curl php-gd php-mbstring php-xml php-zip php-intl. Package names and PHP versions depend on the Ubuntu release; use its supported packages rather than adding an unfamiliar repository unnecessarily. Check services with systemctl status nginx, systemctl status mysql and systemctl status php*-fpm.
4. Secure MySQL and create a WordPress database. Run sudo mysql_secure_installation if provided by your distribution, review its prompts, and avoid remote root access. In MySQL, create a dedicated database and user, replacing the example password with a long, unique secret:
   sudo mysql
CREATE DATABASE wordpress_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'wp_user'@'localhost' IDENTIFIED BY 'replace-with-a-long-unique-password';
GRANT ALL PRIVILEGES ON wordpress_db.* TO 'wp_user'@'localhost';
FLUSH PRIVILEGES;
EXIT;
   Keep these credentials private. Avoid putting passwords in shell history or publishing them in a repository.
5. Install WordPress and configure PHP. Download WordPress from its official distribution source, verify the download where practical, and place the files in a dedicated web root such as /var/www/example.com. Set ownership and permissions so the web server can read the files and make only required directories writable. Copy wp-config-sample.php to wp-config.php, then enter the database name, user, password and host (localhost). Add unique authentication keys and salts using WordPress’s official secret-key service. Do not make the whole site world-writable.
6. Configure Nginx for WordPress. Create a server block for the domain with its document root, index.php as an index, and PHP requests passed to the PHP-FPM socket that exists on your system. Use the standard WordPress front-controller rule so unknown paths reach /index.php, while existing files are served directly. Enable the site, run sudo nginx -t, and reload Nginx only if the test passes. Visit the domain to complete WordPress setup in your browser.
7. Install Node.js and run an application as a service. Install a maintained Node.js release using a trusted source appropriate for your distribution. Put the app in its own directory, install dependencies from its lockfile, and configure it to listen on a local port such as 3000. Create a systemd unit that runs the app as a dedicated, unprivileged user, sets its working directory and environment, and restarts it after failure. Start and enable the unit, then inspect it with systemctl status your-app and journalctl -u your-app.
8. Proxy a Node.js hostname through Nginx. Add a separate Nginx server block for app.example.com that proxies requests to http://127.0.0.1:3000. Set the forwarded host and client/protocol headers; WebSocket applications may also need upgrade headers. Keep the Node port bound to localhost and closed in the firewall. Test with nginx -t, reload, and check the hostname.
9. Install and secure MongoDB only if needed. Use MongoDB’s official installation instructions for your Ubuntu release and a supported MongoDB version; do not assume the Ubuntu archive contains the version you need. Start and enable the service, then check its status. Keep MongoDB bound to localhost for applications on this VPS, enable authentication, create an application-specific database user with only the required permissions, and store its credentials outside public code. Do not open port 27017 to the internet.
10. Enable HTTPS and verify each service. After DNS resolves to the VPS, install Certbot using the recommended method for your system and obtain certificates for each hostname. Configure automatic renewal and test it with Certbot’s dry-run option. Check WordPress, the Node app, database connections, service restarts and logs. Set up encrypted off-server backups for both databases and WordPress files, and periodically test restoring them.

Common Mistakes

• Opening MySQL or MongoDB ports publicly “for convenience.” Use localhost or a private network and restrict firewall access.
• Running Node.js in an SSH session. It will stop when the session ends; use systemd or another process manager.
• Using the wrong PHP-FPM socket in Nginx. Socket names vary by installed PHP version; inspect the PHP-FPM configuration rather than copying a guessed path.
• Giving WordPress or application files overly broad write permissions, or reusing database credentials across sites.
• Installing every service before checking RAM, storage and workload. WordPress, Node.js and MongoDB can compete for memory and disk I/O.

Tips

• Keep each app in a separate directory and run it under its own limited Linux user.
• Use environment files with restricted permissions for secrets, and keep them outside publicly served directories.
• Monitor disk space, memory, CPU and service logs. Configure log rotation and remove obsolete backups safely.
• Patch the operating system and application dependencies regularly, and schedule backups that include database dumps as well as uploaded files.
• For heavier traffic or strict uptime needs, consider moving databases to managed services or separate servers to reduce contention and simplify scaling.

Troubleshooting

If a domain does not load, confirm its DNS address and firewall rules, then run sudo nginx -t and inspect sudo journalctl -u nginx. A 502 response usually means Nginx cannot reach PHP-FPM or Node.js: verify the relevant service is running, the socket or port matches, and local permissions allow access. If WordPress reports a database connection error, confirm the database is active and check the database name, user, password and host in wp-config.php.

For a Node.js failure, use journalctl -u your-app to find startup errors, confirm the working directory and environment variables, and check that the chosen port is not already in use. MongoDB connection failures often come from a stopped service, incorrect credentials, or an application using the wrong hostname. Keep it on localhost unless a carefully restricted private-network connection is required. After changing configuration, validate it before reloading services.

Frequently Asked Questions

Can WordPress and Node.js use the same domain?
Yes. Nginx can route different hostnames or URL paths to different backends. Separate hostnames are generally simpler to configure and troubleshoot.

Do I need both MySQL and MongoDB?
No. WordPress requires a supported relational database such as MySQL or MariaDB. Install MongoDB only if another application needs it.

How much RAM does one VPS need?
It depends on traffic, plugins, Node.js workload and database size. A small test setup may run with 2 GB, but production use should be sized from measured peak usage and leave room for the operating system.

Can I expose MongoDB so a remote app can connect?
Avoid exposing it directly to the public internet. Prefer a private network or VPN, require authentication, and limit firewall access to known sources.

Will this setup automatically scale?
No. One VPS has finite CPU, memory and storage and is a single failure point. Monitor it, maintain backups, and move or split workloads when capacity or availability requires it.

Do I need HTTPS for every hostname?
Yes, use valid TLS certificates for each public site or app hostname, and configure renewals. HTTPS protects connections between visitors and the server, but does not replace secure passwords, patching or backups.

Related

• WordPress Menu Plugins: How to Choose One
• Choose an AI Coding Model for OpenCode
• Coding Agents in CI/CD: A Safe Integration Guide