Free tools Windows power users keep installed
One-click scans. No signup required.
The most reliable small-VPS setup is OpenProject’s official Docker Compose deployment behind Nginx. Compose keeps the application services isolated, while Nginx owns the public IP, HTTPS certificate, redirects, and proxy headers. Set a permanent hostname and secret, persist the assets directory, and configure Nginx to send Host and X-Forwarded-Proto: https. Use the package installer only when your Linux distribution is explicitly supported and you do not need the isolation of containers.
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
What the finished architecture looks like
A production request should follow this path:
- A DNS record points your public OpenProject name, such as
openproject.example.com, to the VPS. - Nginx listens on ports 80 and 443. Port 80 redirects to HTTPS; port 443 terminates TLS.
- Nginx proxies the request to the OpenProject container through a host-mapped HTTP port, such as
127.0.0.1:8080. - OpenProject receives the original hostname and HTTPS state in forwarded headers, so it can build correct links and secure cookies.
- Database data and uploaded assets remain on persistent storage and are backed up independently of the containers.
The current Docker image does not terminate SSL itself. OpenProject’s documentation therefore recommends placing it behind a TLS-terminated proxy for production. Nginx is that edge proxy in this guide.
As an Amazon Associate I earn from qualifying purchases.
Recommended Free Tools
Choose Compose or the package installer first
OpenProject recommends Docker Compose for smaller, isolated installations and Helm for larger installations that need a Kubernetes-oriented operating model. On a single Linux VPS, Compose is usually the practical choice when Nginx or other software already occupies the host, when you want upgrades contained in a project directory, or when your distribution is newer than the package repositories support.
| Decision point | Docker Compose | Native package |
|---|---|---|
| Best fit | Small or isolated VPS deployment; existing Nginx; newer Linux release | Only a distribution and release listed as supported by the current package documentation |
| Service isolation | Application services run in containers with a Compose lifecycle | Processes and dependencies are integrated with the host operating system |
| Reverse proxy | Nginx can remain on the host and proxy to the mapped container port | The packaged process listens on 127.0.0.1:6000 by default, so Nginx proxies there unless you change the binding |
| HTTPS | OpenProject does not provide SSL termination; Nginx must terminate TLS and forward the HTTPS header | Nginx is still required when you want an external TLS endpoint; the custom-server configuration also requires X-Forwarded-Proto https |
| Persistence | Explicitly persist assets and back up the database and assets outside the container lifecycle | Use the package’s host-level data locations and backup procedure |
| Scaling direction | Appropriate for smaller instances; move to Helm when the installation becomes a larger deployment | Limited by the package’s supported operating-system matrix |
OpenProject specifically warns that packages are not built for newer Linux versions such as Ubuntu 24.04. If you are on such a release, use the Docker-based installation unless the current package documentation has added support for your exact version.
Prerequisites on the VPS
- A Linux VPS with a public IPv4 address (and IPv6 if you intend to publish one).
- A DNS A or AAAA record for the final fully qualified domain name, for example
openproject.example.com. - Docker Engine and the Docker Compose plugin installed from your distribution’s current instructions.
- Nginx installed on the host, with ports 80 and 443 allowed through the VPS firewall and cloud security group.
- A certificate and private key for the hostname. You can use your organization’s certificate process or an ACME client; the paths in the example below are illustrative.
- Enough disk for the database, uploaded files, logs, and growth. OpenProject’s official material does not publish one universal CPU, RAM, or storage baseline, so size the VPS from user count, attachment volume, database growth, and background jobs, then check the current system-requirements page before purchase.
Use a non-root administrative account for routine work. Keep Docker, Nginx, and the host kernel updated, and decide where encrypted off-host backups will be stored before importing real projects.
Install OpenProject with the official Compose files
1. Clone the stable Compose branch
From the directory where you keep service definitions, clone the stable branch with a shallow history:
git clone https://github.com/opf/openproject-docker-compose.git --depth=1 --branch=stable/17 openproject
cd openprojectThe branch name is part of the command. Image tags and supported branches can change, so check the current OpenProject Compose documentation when you create a new deployment.
2. Create and edit the environment file
Copy the supplied example and edit the resulting file:
cp .env.example .env
nano .envSet OPENPROJECT_HOST__NAME to the public FQDN users will enter. The double underscore in the variable name is intentional. If you configure collaborative features, set COLLABORATIVE_SERVER_URL to the collaboration service URL required by that configuration.
Review every value in .env, especially hostnames, ports, storage paths, mail settings, and any feature-specific endpoints. Treat the file as sensitive: it can contain credentials and service configuration.
3. Prepare persistent assets storage
If you keep the example OPDATA path, create the host directory and give it to the UID expected by the container:
sudo mkdir -p /var/openproject/assets
sudo chown 1000:1000 -R /var/openproject/assetsConfirm that the path in .env matches the directory you created. A mismatch or incorrect ownership commonly appears later as failed uploads or missing attachments. Keep database backups and asset backups outside the Compose project so deleting or recreating containers cannot delete your recovery copy.
4. Choose and protect SECRET_KEY_BASE
OpenProject requires a unique, stable SECRET_KEY_BASE. Treat it like a password and store it in a password manager or other protected secret store. Do not reuse a key from another installation and do not commit it to Git.
Changing this value is not a harmless rotation: OpenProject says it invalidates cookies, active sessions, and remembered two-factor-authentication tokens. Plan a maintenance window and require users to sign in again if you must replace it.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →5. Start the stack for the first time
For an initial HTTP-only check, the documented command is:
SECRET_KEY_BASE=<your-secret-key-base> OPENPROJECT_HTTPS=false docker compose up -d --build --pull alwaysReplace the value with your own secret. The command builds or refreshes images and starts the stack in the background. Check container status and logs with the normal Docker Compose commands for your installed version before exposing the service publicly.
OPENPROJECT_HTTPS=false is useful for an initial local startup while you are proving that the containers work. It disables secure session cookies and is strongly discouraged for production. Remove that flag for the production launch after Nginx is ready to terminate TLS and forward the correct headers.
6. Complete bootstrap and remove example credentials
The quick-start documentation’s printed or default admin credentials are bootstrap values, not production credentials. Sign in through the final HTTPS hostname, change the administrator password immediately, and remove any example credential from notes, shell history, or shared documentation. Create named administrator accounts for your team rather than sharing the bootstrap account.
Configure Nginx as the TLS terminator and reverse proxy
OpenProject must know that the browser connected over HTTPS even though the container-to-Nginx hop is HTTP. Nginx should preserve the original host and send the forwarding headers shown below.
HTTP redirect and HTTPS server
This configuration follows OpenProject’s documented proxy shape. Replace the hostname, certificate paths, and upstream port with the values used on your VPS:
server {
listen 80;
server_name openproject.example.com;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
server_name openproject.example.com;
ssl_certificate /etc/ssl/crt/server.crt;
ssl_certificate_key /etc/ssl/crt/server.key;
proxy_redirect off;
location / {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
proxy_pass http://127.0.0.1:8080;
}
}The container must actually be mapped to the host port used by proxy_pass. If your Compose file publishes another port, use that port instead of 8080. Keep the upstream bound to loopback when Nginx is on the same VPS so the application port is not unnecessarily exposed to the Internet.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Enable and validate the site
- Place the server block in the Nginx configuration location used by your distribution.
- Check the syntax with
sudo nginx -t. - Reload only after the test succeeds, using your distribution’s Nginx service command.
- Visit the HTTPS hostname and verify that the certificate name matches it, HTTP redirects to HTTPS, and OpenProject generates HTTPS links.
Do not copy certificate paths from the example blindly. The files must exist, be readable by Nginx, and include the appropriate certificate chain for clients that need it.
Understand HTTPS flags and the most common failure
ERR_SSL_PROTOCOL_ERROR
This error usually means a browser is attempting TLS against an endpoint that is speaking plain HTTP, or that the TLS listener and certificate configuration are incomplete. OpenProject starts with HTTPS behavior enabled by default in the Compose setup, but the image does not perform SSL termination. Confirm all of the following:
- Nginx is listening on 443 with a valid certificate and key.
- The DNS name in the browser reaches this VPS.
- Nginx proxies to the container’s HTTP port, not to a guessed HTTPS port.
- The container receives
X-Forwarded-Proto https. - You removed
OPENPROJECT_HTTPS=falsefrom the production start command.
Redirect loops or links pointing to HTTP
Check OPENPROJECT_HOST__NAME and the Nginx Host header first. Then verify that the proxy sends exactly X-Forwarded-Proto https. If Nginx omits that header, OpenProject can believe the request was insecure and produce incorrect redirects or URLs.
Uploads fail or attachments disappear
Check that the configured assets path is mounted into the container, exists on the host, and is owned by UID 1000 as required by the documented example. Also check free disk space and confirm that your backup job includes the assets directory as well as the database.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsThe service works locally but not through the hostname
Test in layers: confirm the containers are running, confirm the host-mapped port answers on loopback, inspect Nginx’s error log, and then test DNS and the firewall. A successful local response does not prove that ports 80 and 443 are reachable externally.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Backups, upgrades, and secret handling
Back up both kinds of state
OpenProject’s database contains application records, while the assets directory contains uploaded files. A usable recovery plan needs both, plus a copy of the Compose configuration and its protected environment values. Store backups outside the VPS or in a separate failure domain, encrypt them, restrict access, and periodically perform a restore test.
Keep configuration reproducible
Keep the Compose repository and your edited configuration under change control, but exclude secrets. Record the image or branch you deployed, the hostname, storage paths, Nginx configuration, and the date of each upgrade. This makes it possible to rebuild the host without relying on a running container as the only copy of your setup.
Upgrade deliberately
Read the release notes and current Compose instructions before pulling a newer branch or image. Back up the database and assets first, verify available disk space, then update during a maintenance window. Keep the previous configuration until health checks and a sign-in test succeed. Do not change SECRET_KEY_BASE as part of an ordinary upgrade.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
How much VPS capacity do you need?
There is no single official CPU, memory, or storage number that fits every OpenProject installation. Capacity depends on concurrent users, project and work-package counts, attachment sizes, database history, mail activity, search, and background jobs. A small team with few attachments has a different profile from an installation storing years of documents.
- Estimate database growth from projects, work packages, activity history, and audit data.
- Estimate asset growth from current attachments plus an annual safety margin.
- Allow headroom for background jobs, upgrades, database maintenance, and backups; do not size a server so tightly that routine jobs exhaust memory or disk.
- Monitor CPU, memory, disk usage, database latency, and job queues after launch.
- Compare the estimate with OpenProject’s current system-requirements page before committing to a VPS plan, because requirements and supported image versions can change.
Start with a conservative server and scale after observing real workload rather than treating an unqualified “minimum VPS” figure as a guarantee.
Production hardening checklist
- Use a unique, long
SECRET_KEY_BASEand protect it like a password. - Use the final FQDN in
OPENPROJECT_HOST__NAME; do not operate production users on a temporary IP address. - Terminate TLS at Nginx and redirect every HTTP request to HTTPS.
- Remove
OPENPROJECT_HTTPS=falsebefore production use. - Expose only the ports you need publicly; keep the container’s mapped application port on loopback where possible.
- Change bootstrap administrator credentials immediately and enable strong authentication policies for user accounts.
- Back up the database and persistent assets separately from the containers, and test restoration.
- Apply security updates to the VPS, Docker components, Nginx, and OpenProject images on a planned schedule.
- Monitor Nginx errors, container health, disk space, and failed background jobs.
- Document the hostname, proxy port, storage path, certificate renewal process, and recovery steps for another administrator.
When a package installation is still appropriate
The package route can make sense when your exact Linux distribution and release appear in OpenProject’s supported package documentation, you want host-integrated services, and no conflicting web stack makes isolation valuable. It is not the safer default merely because it avoids Docker. On newer distributions, including the Ubuntu 24.04 example called out by OpenProject, package availability may lag or be absent. In that case, Compose avoids forcing unsupported system packages onto the host.
For a packaged deployment behind Nginx, the internal process listens on 127.0.0.1:6000 by default. The proxy still needs to preserve the host and send X-Forwarded-Proto https; the same TLS and firewall principles apply. Choose one installation method for a given VPS rather than mixing package-managed and container-managed OpenProject services without a clear migration plan.
Quick Recap
Final pre-launch verification
- Resolve the FQDN to the intended VPS address.
- Confirm the Compose stack is running and the mapped port responds locally.
- Run
sudo nginx -tand reload Nginx only after a successful test. - Open the HTTPS URL and inspect the certificate, redirect behavior, and generated links.
- Sign in with the bootstrap account, change its password, and create named administrators.
- Create a test project, upload an attachment, and verify that it remains after a container restart.
- Confirm that database and asset backups complete and that their restore procedure is documented.
- Remove temporary HTTP settings and verify that secure cookies and HTTPS-only access are in effect.
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.
