Run Discourse and WordPress on One VPS

Running Discourse and WordPress on one VPS lets you publish regular site content and host a community without maintaining two servers. The practical setup is to run each application in its own container and route separate subdomains to them; plan for enough memory, storage, backups, and email delivery before you begin.

What You’ll Need

• A VPS with a supported Linux distribution, a public IPv4 address, and preferably at least 4 GB of RAM. Discourse is resource-intensive; more memory and CPU are useful as traffic grows. Check the current Discourse installation requirements before choosing a smaller server.
• A domain name and two DNS names, such as forum.example.com and www.example.com (or blog.example.com).
• SSH access with an account that can run administrative commands, plus familiarity with editing configuration files and using Docker.
• A reliable SMTP service and credentials for Discourse email, and a plan for off-server backups of both applications and their data.

Step-by-Step

1. Choose the hostnames and check the server. Decide which hostname will serve WordPress and which will serve Discourse. Point each DNS A record to the VPS IPv4 address; add AAAA records only if the server is reachable over IPv6. Confirm DNS resolves before requesting certificates. Update the operating system, set up SSH key access, and configure a firewall to allow SSH and web traffic on ports 80 and 443. Do not expose database ports publicly.
2. Pick one reverse-proxy arrangement. Both applications need to answer normal web requests, so they cannot each independently bind the same public ports. A reverse proxy such as Nginx Proxy Manager, Caddy, or Nginx can listen on 80 and 443 and send requests to the correct application based on hostname. Alternatively, use Discourse’s supported Docker setup as the public proxy and configure WordPress behind it. Choose one approach and follow its documentation; avoid installing two competing services that both claim ports 80 or 443.
3. Install Docker and deploy Discourse using its supported method. Follow the current official Discourse installation instructions for a self-hosted Docker installation. Set the Discourse hostname to the forum subdomain, provide an administrator email, and configure SMTP rather than relying on local mail delivery. Ensure the installer or proxy arrangement will not take over ports already reserved for another service. Keep Discourse’s container configuration and persistent data in the locations specified by its installation method.
4. Deploy WordPress in separate containers. Use a maintained WordPress image with a separate MariaDB or MySQL database container. Give the database a strong password, keep it on an internal container network, and store database and WordPress files in persistent volumes. Set WordPress’s public URL to its chosen hostname and configure the reverse proxy to send that hostname to the WordPress web container. Do not publish the database port to the internet.
5. Connect hostnames to the proxy and enable HTTPS. Create a proxy rule for each hostname, pointing to the appropriate application and its internal port. Set the correct forwarding headers and enable WebSocket support for Discourse if the proxy requires an explicit setting; Discourse uses real-time connections. Once DNS points to the VPS and port 80 is reachable, request certificates through the proxy or configure the certificate process you chose. Redirect HTTP to HTTPS only after HTTPS works for both names.
6. Complete application setup. Visit the WordPress hostname and finish its setup, then visit the Discourse hostname and confirm that the administrator account and email work. In WordPress, set the site address to the HTTPS hostname. In Discourse, verify the site URL and SMTP settings in its administration area. Send test messages and check spam folders; a web server’s ability to send mail is not proof that email is delivered reliably.
7. Test isolation, persistence, and recovery. Open both sites in separate browser tabs, test login, images, uploads, and Discourse notifications, and verify certificates. Restart containers and confirm both sites return with their data intact. Create backups that include WordPress files and database, and use Discourse’s supported backup process. Copy backups to storage outside the VPS and periodically test restoring them.
8. Set a maintenance routine. Monitor memory, disk space, and logs. Update the operating system, container images, WordPress core, plugins, themes, and Discourse using their documented procedures. Back up before updates and avoid editing generated Discourse container settings without understanding how its rebuild process works.

Common Mistakes

• Running two public web servers on the same ports: only one service can bind a given IP address and port. Put a single proxy in front or configure the supported Discourse proxy arrangement.
• Using the same hostname for both apps: choose distinct hostnames, or deliberately configure a more complex path-based setup. Separate subdomains are simpler and less likely to break application URLs.
• Skipping persistent storage: containers can be replaced during updates. Keep databases, uploads, and application data in persistent volumes and back them up.
• Opening database ports or using weak credentials: keep databases private on the container network and use unique, strong passwords.
• Ignoring email and resource needs: Discourse depends on email for account verification and notifications, while insufficient RAM can cause slowdowns or container failures. Configure SMTP and monitor resource use.

Tips

• Use a staging environment or test changes during a quiet period, especially when changing proxy rules or application URLs.
• Record which service owns ports 80 and 443, where each volume lives, and how to rebuild each application.
• Set disk alerts and keep backups off the VPS. A backup stored only on the same server can be lost with the server.
• If the VPS is too small or the services compete for resources, moving WordPress or Discourse to a separate host is safer than trying to tune around repeated outages.

Troubleshooting

• A hostname shows the wrong site or a default page: check its DNS records, proxy hostname rule, and destination container. Confirm that each rule uses the correct internal port.
• Certificate issuance fails: verify the hostname resolves to the VPS, port 80 is reachable, and no other service is answering the certificate challenge. Correct DNS or firewall issues before retrying.
• One application will not start: inspect that application’s container logs and check available memory and disk space. Resolve the reported configuration or resource problem before repeatedly restarting it.
• Discourse loads but live updates fail: check the proxy’s WebSocket support and forwarding headers, then consult the proxy and Discourse logs.
• Emails are missing: verify SMTP host, port, authentication, and encryption settings. Check application logs and the mail provider’s delivery records; confirm DNS email-authentication records with the provider’s instructions.
• Changes disappear after a restart: check that persistent volumes are mounted at the correct paths. Restore from a known-good backup if data is missing; do not delete volumes as a troubleshooting shortcut.

Frequently Asked Questions

Can Discourse and WordPress run on the same VPS?
Yes. They can share a host when isolated in separate containers and routed by a reverse proxy, provided the server has enough resources.

Do I need two domain names?
No. One domain with two subdomains is enough, such as forum.example.com and www.example.com.

Can I install WordPress inside the Discourse container?
No. Keep them as separate applications. Discourse’s container is managed by its installation process and is not a general-purpose hosting environment.

How much RAM does the VPS need?
Requirements depend on traffic, plugins, and workload. Check current Discourse requirements and allow headroom for WordPress, databases, the proxy, and operating system; monitor actual use.

Can both sites use HTTPS?
Yes. The proxy can issue or use a separate certificate for each hostname. Make sure DNS and inbound web access are correct before requesting certificates.

Will a backup of the VPS be enough?
A full-server snapshot can help, but also maintain application-aware backups and copy them off-server. Test that you can restore both WordPress and Discourse.

Related

• Culling Grounds Codes: What They Are and How to Find Them
• AI Agent Code Reviews: Why the Diff Comes Last
• AI Web Crawlers: Are They Ruining the Internet?