You can run a Discourse forum on a virtual private server (VPS) with the project’s supported Docker installation. Start with a fresh 64-bit Ubuntu or Debian server, root SSH access, a DNS name that points to it, and enough memory for the forum and its database. A small test installation can begin at one CPU core, 1 GB of RAM with swap, and 10 GB of disk; the recommended starting point is at least two cores, 2 GB of RAM, and 20 GB of disk.
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
The installer sets up Docker, downloads Discourse’s container configuration, asks for your hostname, administrator addresses, and email settings, then builds the application and requests a Let’s Encrypt certificate. After launch, you—not a hosting company—are responsible for updates, backups, disk capacity, host security, and email deliverability.
As an Amazon Associate I earn from qualifying purchases.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →What self-hosting Discourse on a VPS involves
Discourse is deployed as a Docker-based application on a Linux server. The VPS supplies the CPU, memory, storage, network address, and operating-system access; the Discourse container configuration supplies the forum application and its supporting services. The project’s documentation describes Docker as the only officially supported self-hosting method.
A conventional deployment has one public hostname such as forum.example.com. DNS sends that name to the VPS, the container listens on HTTP and HTTPS, and Let’s Encrypt issues a certificate after the hostname resolves correctly. Members then use the HTTPS address in a browser, while Discourse uses an SMTP service when it needs to send registration mail, password resets, digests, mailing-list messages, or process email replies.
This is a good fit when you need control over data, configuration, and upgrade timing and are willing to operate a Linux server. It is not a “set and forget” product: a forum owner must monitor storage, apply updates, test restores, and investigate failed email or container builds.
VPS requirements and sizing
Use a 64-bit Linux VPS with root SSH access and a Docker-compatible environment. The cloud installation guide recommends starting from a fresh Ubuntu or Debian image. A modern single-core processor is the minimum listed by the general installation guide, although two cores are recommended. The same guide lists PostgreSQL compatible with the deployed image, Redis 7, and Ruby 3.2 or newer among the software requirements.
| Use case | CPU | Memory | Disk | Interpretation |
|---|---|---|---|---|
| Small test or hobby forum | 1 core | 1 GB RAM plus swap | 10 GB | Minimum published starting point; leaves little room for uploads, plugins, logs, or traffic spikes. |
| Recommended starting server | 2 or more cores | 2 GB or more | 20 GB or more | More practical headroom for normal operation and maintenance. |
The minimum figures are not a performance guarantee. Uploaded images and files, database growth, backups, search indexing, plugins, and concurrent visitors all consume resources. Begin with the recommended tier if the forum will open to the public, and choose a VPS plan that lets you resize the server when usage grows.
Network and access prerequisites
- Root SSH access, or an account that can run commands through
sudo. - A publicly reachable IPv4 address; IPv6 and firewall controls are useful additions when your provider supports them.
- Docker support on the chosen VPS and permission to receive inbound traffic on TCP ports 80 and 443.
- Provider snapshots or backups if you plan to use them as one layer of disaster recovery.
The official cloud guide says the process works on any Docker-compatible cloud provider or local server. When comparing providers, evaluate root access, CPU and memory headroom, disk performance, snapshot tools, bandwidth, regional latency, address availability, firewall controls, reliability, support, and the complete monthly cost rather than choosing solely on advertised processor speed.
Choose the hostname and configure DNS first
Decide the permanent forum address before running the installer. A subdomain such as forum.example.com keeps the forum separate from a company website or other services. For testing, learning, or a hobby project, the guide also offers an optional *.discourse.diy subdomain.
- Create an A record for the chosen hostname at your DNS provider.
- Point that record to the VPS’s public IP address.
- Wait for the record to resolve publicly before starting certificate provisioning.
- Check that no old A or conflicting record sends the hostname to another server.
DNS is a prerequisite for HTTPS. The installer checks that the hostname resolves and requests a Let’s Encrypt certificate; if the record has not propagated or points to the wrong address, certificate issuance cannot complete. Do not substitute a private address or a hostname that is only visible inside your home network.
Install Discourse with the supported Docker workflow
Take a snapshot of the fresh VPS if your provider offers that feature, then connect over SSH. The following sequence follows the project’s cloud installation path.
- Connect to the server. Use your provider’s root SSH details, for example
ssh [email protected]. Replace the example address with the VPS address assigned to you. - Run the installer. Execute
wget -qO- https://raw.githubusercontent.com/discourse/discourse_docker/main/install-discourse | sudo bash. The script can install Docker and Git when they are absent, downloads the Discourse Docker configuration, and opens an interactive setup wizard. - Enter the hostname. Supply the DNS name you prepared, such as
forum.example.com. The value must match the address members will visit and the address covered by the certificate. - Provide administrator email addresses. These addresses are used during first registration and for administrative contact. Keep access to at least one of them while the forum is being configured.
- Choose the email path. Enter SMTP details if you want conventional email registration, password recovery, digests, mailing-list mode, or email replies. The current wizard can skip SMTP and enable Discourse ID login or social sign-in, but that does not replace SMTP for the traditional email features; you can add SMTP later.
- Review and confirm. Check every hostname and mail value in the generated configuration before accepting it. A typo here is easier to fix before the first build than after members arrive.
- Wait for the container build. The guide estimates roughly five to ten minutes. During this stage the installer checks ports 80 and 443, verifies DNS, tunes some settings for available resources, and requests HTTPS certificates through Let’s Encrypt when DNS is correct.
- Open the forum. Visit the HTTPS hostname, register with one of the administrator addresses supplied during setup, and complete Discourse’s in-app setup wizard.
The installer command is maintained in the project’s Docker repository; use the exact command above rather than copying an old blog’s fork or a third-party script.
Decide how to handle email
Email is optional during the initial wizard, but it determines which parts of Discourse will work immediately. SMTP is the outbound relay that delivers messages to members. Without it, users cannot rely on the normal email-driven account and notification workflows.
Configure SMTP during installation
Choose this route when you expect public registration, password resets, daily or weekly digests, mailing-list mode, or replies posted by email. Enter the relay hostname, port, authentication details, sender address, and any encryption settings requested by your mail provider. Use a sender address on a domain you control and make sure the relay permits that address.
Recommended Free Tools
Start without SMTP
Skipping SMTP can be sensible for a private trial or when you intend to use Discourse ID login or social sign-in first. The forum can still be opened and configured, but the conventional email features will remain unavailable until a working relay is added. Send a test message after configuration and inspect the relay’s delivery or rejection logs if mail does not arrive.
Protect deliverability
- Use a domain whose DNS and sender policy are under your control.
- Keep the sender address consistent with the authenticated SMTP account.
- Monitor bounces and complaints; a successfully submitted message is not proof that recipients accepted it.
- Remember that outbound email is an operating responsibility of the VPS owner, not something the Docker installer guarantees.
Finish the first-run configuration
After the HTTPS page loads, the in-app wizard asks about the forum’s name, description, default locale, categories, and moderation preferences. Create a second administrator only after confirming that the first administrative account can sign in and receive required notifications. Restrict registration or enable approval workflows if the forum is not ready for an open launch.
Check the public site in a private browser window. Confirm that the hostname redirects to HTTPS, a new account can complete the intended sign-in path, password recovery reaches the inbox, and uploads are stored successfully. These checks expose DNS, certificate, storage, and SMTP errors before you announce the forum.
Operate and update the installation
A running container still needs routine administration. Discourse provides a web-based admin upgrade page for normal upgrades. From SSH, the documented command-line alternative is:
Free tools Windows power users keep installed
One-click scans. No signup required.
cd /var/discourse
./launcher rebuild appA rebuild pulls the configured application image and recreates the app container. Schedule maintenance when a short interruption is acceptable, keep an administrator session available, and read the upgrade notes shown in the admin interface before confirming a major change.
Inspect logs when something fails
Start with the application log:
cd /var/discourse
./launcher logs appFor a shell inside the container, use:
cd /var/discourse
./launcher enter appThe Rails production log can provide additional detail when a web request or background job fails. Capture the first error and the time it occurred before restarting anything; repeated rebuilds can hide the original cause.
Secure the host
- Enable unattended security updates on Ubuntu or Debian.
- Use key-based SSH access where possible and remove unused accounts.
- Apply host firewall rules that expose only the services you actually need; the forum requires web access on ports 80 and 443, while administrative SSH should be limited to trusted sources when practical.
- Consider fail2ban for brute-force protection.
- Review provider alerts for unusual CPU, memory, disk, or network activity.
Plan backups and recovery
Backups are your responsibility. Keep copies of the database and uploaded files outside the VPS, monitor free disk space, and test a restore on a separate instance. A snapshot that has never been restored is not a verified recovery plan. The project documentation does not prescribe a universal retention schedule, so choose retention based on how much forum history you can afford to lose and how quickly you must recover.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Standalone container or multi-container deployment?
The standalone template is the easiest path and is appropriate for most single-server forums. It keeps the application, database, and Redis services in the arrangement expected by the standard installer.
| Architecture | Advantages | Costs and risks | Best fit |
|---|---|---|---|
| Standalone template | Simple installation, documented upgrade workflow, fewer moving parts | Less isolation and less flexibility when individual services need different hardware | Most new forums and single-VPS deployments |
| Multi-container deployment | Can reduce upgrade downtime, scale across servers, and place the database on stronger hardware | More complex networking, backups, monitoring, and firewalling; PostgreSQL and Redis must be protected from public access | Teams with scaling or isolation requirements and the operational skill to manage them |
Do not begin with a distributed design merely because it sounds more scalable. Add containers or servers when measured workload, maintenance windows, or database isolation justify the complexity. In every design, firewall PostgreSQL and Redis so they are reachable only by the services that need them.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Troubleshoot the common failure points
The installer cannot obtain a certificate
- Confirm the hostname’s A record resolves to the current VPS IP from outside your local network.
- Make sure ports 80 and 443 are permitted by both the VPS firewall and the provider’s network controls.
- Remove stale DNS records and wait for propagation before repeating the certificate step.
The build stops because the server is short on memory
Verify that the VPS has swap and compare its resources with the published minimum. Stop unrelated workloads, resize to the recommended two-core, 2 GB-or-more tier, and rebuild after the host has enough headroom. Avoid running a database-heavy application or another control panel on a minimum-size forum server.
Users cannot register or reset passwords
Check whether SMTP was skipped, then verify the relay hostname, port, credentials, sender address, and encryption settings. Inspect application logs and the SMTP provider’s rejection details. A successful login through Discourse ID does not prove that conventional email delivery is configured.
The forum becomes slow or runs out of disk
Inspect disk usage, uploaded files, logs, database growth, and backup copies. Increase disk capacity before it reaches 100 percent, and review whether retention or oversized uploads are consuming the volume. Add CPU or memory when sustained load—not a single short spike—shows the current VPS is undersized.
An upgrade fails
Read the first error in ./launcher logs app, confirm that DNS and disk space are healthy, and verify that the host can reach the configured image sources. Restore from a tested backup if the application cannot start, then resolve the underlying configuration or resource problem before attempting another rebuild.
A practical launch checklist
- Fresh 64-bit Ubuntu or Debian VPS with root SSH and Docker support.
- Hostname selected and A record pointed at the VPS.
- At least the published minimum resources, with swap; recommended resources for a public launch.
- Ports 80 and 443 available for web traffic and certificate issuance.
- Administrator addresses accessible during installation.
- SMTP configured and tested if email registration, resets, digests, mailing-list mode, or replies are required.
- HTTPS address verified in a private browser session.
- Security updates, SSH controls, and optional fail2ban enabled.
- External backups arranged, free disk monitored, and a restore procedure tested.
- Upgrade and log commands recorded for whoever will maintain the forum.
What to expect after launch
A VPS gives you control, but it also transfers the operating burden to you. The supported Docker workflow makes the initial deployment repeatable; it does not provide a universal capacity guarantee, backup policy, or email-delivery guarantee. Start with a modest but adequately sized server, keep DNS and SMTP details documented, upgrade through the web admin page or the documented rebuild command, and treat recovery testing as part of normal forum administration.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
