Add WordPress to a VPS Running a Rails App

You can run WordPress alongside a Rails app on one VPS by giving each site its own domain or subdomain and routing requests through a web server or reverse proxy. This guide uses Nginx, PHP-FPM, and MySQL or MariaDB for WordPress while leaving the Rails app’s existing process manager and deployment in place. Before starting, identify how Rails is served and make a backup; changing shared web-server settings can take both sites offline.

What You’ll Need

• SSH access with an account that can use sudo.
• A domain or subdomain for WordPress, with DNS pointing to the VPS. For example, use blog.example.com and keep Rails on example.com.
• A current backup of the server configuration and Rails app, plus a database backup if applicable.
• A working Rails deployment and knowledge of its current web server, listening port or socket, and process manager (such as Puma).
• A supported PHP version with PHP-FPM and the PHP extensions WordPress requires, plus MySQL or MariaDB. Exact package names depend on your Linux distribution.

Step-by-Step

1. Record the existing setup. Check your distribution and inspect the active web-server configuration and Rails service. On a system using systemd, systemctl status nginx or systemctl status apache2 may identify the server; use the service name actually installed. Find the Rails upstream (often a local TCP port or Unix socket), existing site configuration, and deployment procedure. Do not assume that Rails runs on a particular port or that Nginx is already installed.
2. Choose how the two sites will be separated. The simplest arrangement is Rails on its current hostname and WordPress on a new subdomain, such as blog.example.com. Create an A record pointing the subdomain to the VPS IPv4 address; add an AAAA record only if the server is correctly configured for IPv6. Allow DNS time to update. If both apps must share one hostname, use distinct paths such as /blog; this needs extra care with WordPress URLs, Rails routes, and static assets, so a subdomain is usually easier.
3. Back up and plan the web-server change. Copy the active Nginx or Apache site configuration and note how to restore it. Ensure only one service is bound to public ports 80 and 443. If Nginx already handles Rails, add a separate virtual host to it; do not install or start another web server that tries to claim those same ports. If Apache is in use, configure WordPress as another virtual host there or deliberately use a proxy architecture.
4. Install WordPress dependencies. Install PHP-FPM, a supported PHP version and the required PHP extensions, plus MySQL or MariaDB if you do not already have a database server. Use your operating system’s maintained packages and current WordPress requirements. Avoid replacing system PHP or database components blindly: check whether Rails or other services depend on them. Enable and start the relevant services, then confirm they are running.
5. Create a dedicated database and account. In the database server, create a database for WordPress and a separate user with privileges limited to that database. Use a unique, strong password and keep it private. Do not reuse Rails database credentials or grant the WordPress account broad administrative privileges. Save the database name, username, password, and host for the installer.
6. Download WordPress into its own directory. Create a document root such as /var/www/blog, separate from the Rails application and its public directory. Obtain WordPress from its official project site and extract the files there. Set ownership and permissions according to your distribution and PHP-FPM user: the web process needs to read the files, and only the directories that need updates or uploads should be writable. Avoid making the whole installation world-writable.
7. Add a site configuration without altering Rails routing. In Nginx, create a separate server block with server_name blog.example.com and a document root pointing to the WordPress directory. Pass PHP requests to the correct PHP-FPM socket or local port for your installed version, and use WordPress’s standard front-controller fallback so permalink requests reach index.php. Keep the existing Rails server block and its proxy-to-Puma settings unchanged. Check the configuration with nginx -t before reloading; for Apache, use its configuration test and enable the appropriate virtual host and PHP-FPM integration.
8. Enable HTTPS and reload carefully. Once DNS resolves to the VPS and port 80 is reachable, obtain a certificate using your chosen ACME client. Configure the WordPress host to redirect HTTP to HTTPS, and retain the Rails host’s existing certificate and redirects. Test configuration syntax before reloading the web server, then verify both hostnames. If certificate issuance fails, check DNS, firewall rules, and whether another service is answering the challenge.
9. Complete WordPress setup and test both apps. Visit the WordPress hostname over HTTPS and enter the database details to run the installer. Set the site title and an administrator account with a unique password. In WordPress settings, confirm the site address uses the correct HTTPS hostname. Test the home page, login, media uploads, and a permalink page. Then test Rails routes, assets, and any background jobs or health checks. Keep the backup until both sites work after a web-server reload and a server restart.

Common Mistakes

• Replacing the Rails site configuration: Add a distinct virtual host instead of overwriting the existing proxy configuration. A syntax test does not prove Rails routing still works, so test it too.
• Installing a second web server on the same ports: Nginx and Apache cannot both bind to the same public address and port without an intentional proxy arrangement.
• Pointing WordPress at the Rails document root: Keep its files and database separate to prevent accidental exposure, deployment conflicts, and confusing URL handling.
• Using incorrect PHP-FPM details: Socket paths and service names vary. Check the installed pool configuration rather than copying an example that may not exist.
• Making every file writable: Broad permissions weaken the site. Grant only the access needed by the web process, particularly for uploads and updates.
• Forgetting DNS or HTTPS prerequisites: A certificate cannot be issued reliably until the hostname resolves to the VPS and the challenge can reach the server.

Tips

• Use a subdomain for the least complicated separation. If you need WordPress under a path on the Rails domain, test redirects, cookies, canonical URLs, and asset paths before launch.
• Keep the Rails and WordPress deployments independent, with separate directories, database credentials, backups, and update procedures.
• Check disk space, memory, and database capacity before adding WordPress. Both apps share VPS resources, and traffic spikes or backups can affect Rails performance.
• Schedule updates for WordPress core, themes, plugins, PHP, and the operating system. Remove unused plugins and take a database and file backup before major updates.

Troubleshooting

The WordPress hostname shows the Rails app: Check the DNS record, the Nginx or Apache server_name, and which virtual host is the default. Confirm the new configuration is enabled and reload the correct service.

You see a 502 or 504 error: Check that PHP-FPM is running and that the configured socket or port matches its pool settings. Inspect the web-server error log and PHP-FPM log for permission or connection errors. If Rails alone has the error, verify its application service and upstream address instead.

WordPress reports a database connection error: Confirm the database service is running and check the database name, user, password, and host in the WordPress configuration. Test credentials locally where possible and ensure the account has privileges on the WordPress database.

Permalink pages return 404: Verify the WordPress rewrite fallback is present and that the web server permits the required configuration. Save the permalink settings again in the WordPress dashboard, then test a page. Avoid applying WordPress rewrite rules to the Rails host.

HTTPS or uploads fail: For HTTPS, check DNS, certificate status, and port 443. For uploads, check free disk space, PHP upload limits, and permissions on the uploads directory; do not solve permission issues by making the entire site writable.

Frequently Asked Questions

Can Rails and WordPress run on one VPS?
Yes. A web server can route each hostname to the appropriate app, while WordPress uses PHP-FPM and a database. Available memory and traffic determine how comfortably they share the machine.

Do I need to move or rewrite my Rails app?
No. If it is already served correctly, keep its deployment and upstream configuration. Add a separate WordPress host configuration and test Rails after reloading the web server.

Can WordPress use the same domain as Rails?
Yes, using a subdomain is straightforward. A path such as example.com/blog is also possible but requires careful web-server and WordPress URL configuration.

Can I use SQLite for WordPress?
WordPress normally uses MySQL or MariaDB. Do not assume a SQLite plugin is a drop-in replacement; use a database setup supported by your WordPress version and hosting configuration.

Will adding WordPress affect Rails performance?
It can, because both apps share CPU, memory, disk, and possibly database resources. Monitor resource use after launch and consider a larger VPS or separate hosting if capacity is insufficient.

What should I back up?
Back up the WordPress database, WordPress files including uploads, web-server configuration, and the Rails app and its database. Test that you can restore the backups.

Related

• How to Remove Caulk From a Chrome Shower Door
• Not Enough Memory to Run Excel? How to Fix It
• ChatGPT Image Uploads: How to Analyze a Picture