How to Install Redmine on Windows Server Using an Ubuntu VM

If your infrastructure standard requires Windows Server, the cleanest way to use Redmine 1-Click is not to force a native Windows install. Instead, keep Windows Server as the host and run Redmine inside a dedicated Ubuntu virtual machine. This preserves a supported Linux application stack while fitting into a Windows-led environment.

Quick evaluation with WSL — If you just want to test Redmine before committing to a full VM, you can run the installer inside WSL2 (Windows Subsystem for Linux) on a machine with Ubuntu installed from the Microsoft Store. The bash script will work as-is. However, WSL is not recommended for production: it lacks reliable service auto-start on reboot, uses NAT networking that complicates external access, and has partial systemd support that may cause instability under load. For anything beyond a local demo, use a dedicated Ubuntu VM as described below.

1. Why This Deployment Model Works

Redmine 1-Click is designed for supported Linux servers. A dedicated Ubuntu VM gives the installer the environment it expects while still letting your team manage the physical or virtual host through Windows Server tooling.

Windows Server

Acts as the host platform, hypervisor layer, and infrastructure control point.

Ubuntu VM

Acts as the actual Redmine server, with its own OS, packages, services, logs, and firewall rules.

Redmine Stack

Runs fully inside the VM: web server, Ruby, database, Redmine files, and SSL automation.

Do not split the stack across both systems. Running the web app in Linux but the database or reverse proxy on Windows increases complexity and weakens the value of a 1-click deployment.

2. Recommended Architecture

For most teams, the most stable baseline looks like this:

  • Host OS: Windows Server with your preferred virtualization layer.
  • Guest OS: Ubuntu 24.04 LTS, freshly provisioned.
  • Redmine stack: MariaDB + Apache + Passenger, or PostgreSQL + Nginx + Passenger.
  • Access model: SSH into the Ubuntu VM and run the installer there.
  • Networking: expose ports 80 and 443 to the Ubuntu VM, not just to the Windows host.

If you want the lowest-friction path, start with Ubuntu 24.04, MariaDB, and Apache + Passenger. It is a practical default for teams that value operational simplicity over stack experimentation.

3. Size the Ubuntu VM for the Workload

Start with realistic capacity instead of minimum survival specs.

Profile CPU RAM Storage Use case
Entry 1 vCPU 2 GB 20 GB SSD Small teams, light plugin use, limited attachments.
Standard 2 vCPU 4 GB 40 GB SSD Most production installations.
Performance 4+ vCPU 8+ GB 80+ GB SSD Heavier projects, large attachments, or many plugins.

Keep in mind that the VM must absorb both application load and maintenance activity such as package upgrades, gem installation, log rotation, and backups.

4. Choose the Right Network Model Before Installation

The Redmine stack can be correct and still fail if the VM networking is wrong.

Model How it works Operational impact
Bridged or external switch The Ubuntu VM gets its own network presence and behaves like an independent server. Usually the simplest option for DNS, SSL, and troubleshooting.
NAT with port forwarding The Windows host keeps the main address and forwards traffic to the Ubuntu guest. Works well, but requires careful forwarding of 22, 80, and 443.
  • Use a static IP for the Ubuntu VM whenever possible.
  • Point your Redmine DNS record to the address that ultimately reaches the VM.
  • For Let's Encrypt, inbound port 80 must reach the Ubuntu guest during certificate validation.
  • Restrict SSH access by source IP or VPN where possible.
If DNS points to the Windows host but 80 and 443 are not forwarded correctly to Ubuntu, SSL issuance can fail even though the Redmine installer itself is healthy.

5. Prepare Ubuntu as a Fresh Redmine Target

Before you generate the installer, make sure the Ubuntu guest is treated as a dedicated Linux server:

  • No preexisting Apache, Nginx, MySQL, PostgreSQL, or Ruby workloads.
  • Sudo access is available for the account you will use.
  • Outbound internet is open for packages, gems, Redmine downloads, and optional SSL issuance.
  • Disk space and memory headroom are available for the initial install and later upgrades.
  • Time sync and DNS resolution are correct inside the VM.

Think of the Ubuntu guest as if it were a clean VPS. The closer it is to a fresh Linux server, the more predictable the installation will be.

6. Generate and Run the Installer Inside the VM

In the Redmine 1-Click wizard, choose your Linux stack, set the domain, pick the SSL mode, and generate the installer script. Then upload the script to the Ubuntu VM and run it there, not on the Windows host.

sudo bash redmine-1click.sh

Good deployment defaults for this setup

  • OS: Ubuntu 24.04 LTS.
  • Database: MariaDB for a simple default, PostgreSQL if your team already operates it.
  • Web server: Apache + Passenger for simplicity, Nginx + Passenger if your team already standardizes on Nginx.
  • SSL: Let's Encrypt if the VM is reachable on port 80 from the public internet.

7. Validate the Installation Like a Production Service

After the installer completes, check the environment at the service boundary, not only in the terminal:

  • Confirm login works through the final Redmine URL.
  • Restart the Ubuntu VM and verify Redmine comes back cleanly.
  • Verify that the chosen web server starts automatically after reboot.
  • Confirm ports 80 and 443 still reach the guest after host-level firewall rules apply.
  • Archive the installer log and keep the support log available for troubleshooting.

This is also the right time to confirm VM auto-start after host reboot, so Windows patch cycles do not leave Redmine offline longer than expected.

8. Operate Backups and Monitoring at the Right Layer

A Windows-hosted Linux guest still needs Linux-native operational discipline.

  • Take daily database backups inside the Ubuntu VM.
  • Back up attachments, plugins, themes, and configuration files from the guest filesystem.
  • Keep at least one offsite copy outside the Windows host.
  • Use VM snapshots as a short-term safety net before major changes, not as the only backup method.
  • Monitor CPU, memory, disk growth, and HTTP health on the guest itself.
A VM snapshot is useful before upgrades, but it is not a substitute for application-aware backups and restore testing.

9. Common Mistakes to Avoid

  • Running the installer on the Windows host instead of inside Ubuntu.
  • Publishing the Windows host on 80 and 443 without forwarding traffic to the guest.
  • Installing Redmine into a reused Ubuntu VM that already hosts other services.
  • Keeping Redmine on Linux but moving the database to Windows just because the host is Windows.
  • Assuming the VM network is correct without testing DNS, HTTPS, and reboot behavior.

The goal is simple: keep Windows responsible for hosting the VM, and keep Ubuntu responsible for being the Redmine server. That separation is what makes this model maintainable.

10. Frequently Asked Questions

Can I run Redmine natively on Windows Server without a VM?
Technically yes, but it is not recommended. Ruby on Windows has known issues with native gem extensions, path handling, and service management. A dedicated Ubuntu VM gives you a fully supported Linux stack with far fewer operational surprises.
Which hypervisor should I use on Windows Server?
Hyper-V is the natural choice since it is built into Windows Server. VirtualBox and VMware Workstation also work for smaller deployments. The key requirement is that the Ubuntu guest can receive inbound traffic on ports 80, 443, and 22.
Does the Redmine 1-Click installer work inside WSL2?
WSL2 can run the installer, but it is not a production-grade environment. WSL2 lacks proper systemd support in older Windows builds, and networking behavior differs from a real VM. For production use, a full Ubuntu VM is more reliable.
How do I handle SSL if the Windows host owns the public IP?
Forward ports 80 and 443 from the Windows host to the Ubuntu VM. Let's Encrypt validation happens over port 80, so the traffic must reach the Ubuntu guest during certificate issuance. Once forwarding is in place, the installer handles SSL automatically.