Nginx Proxy Manager on VPS: Secure Setup and Usage Guide

Nginx Proxy Manager on VPS gives you a web interface for routing domains to websites, APIs, dashboards, and other reachable services through ports 80 and 443. The VoyraCloud application image provides a preinstalled, self-managed starting point on Cloud VPS or Residential IP VPS. You connect privately to the admin interface, create your own administrator, point your domains to the server, and configure each proxy host and certificate.

TL;DR

Select Nginx Proxy Manager in the VoyraCloud Cloud VPS or Residential IP VPS Images section instead of installing the application manually.
Port 81 is the administration interface and should remain private. Use the SSH Tunnel command shown in the resource details, then open the local address in your browser.
The image does not contain a default administrator account. Create the first administrator through the initial setup screen.
Ports 80 and 443 accept public HTTP and HTTPS traffic. Your domain must resolve to the VPS, and the required ports must be reachable before common Let’s Encrypt validation can succeed.
Create one Proxy Host for each domain or subdomain, enter a reachable upstream address and port, and enable WebSocket support only when the upstream application needs it.
The first release uses local SQLite. Application configuration and certificate material persist on the VPS, but you remain responsible for off-server backups, upgrades, certificate monitoring, DNS, and upstream security.
Certificate issuance and renewal depend on DNS, network reachability, challenge type, rate limits, and external services. They are capabilities, not guarantees.

What Is Nginx Proxy Manager?

Nginx Proxy Manager is an open-source interface for configuring Nginx-based proxy hosts, redirects, streams, access lists, and TLS certificates. It is useful when you want Nginx reverse-proxy capabilities without editing every server block by hand.

A reverse proxy sits between internet users and an upstream application. The browser connects to a public domain such as app.example.com; Nginx Proxy Manager receives the request on port 80 or 443 and forwards it to the configured application address and port. That upstream may run on the same VPS, in a Docker network, or on another server that the proxy can reach.

The official Nginx Proxy Manager guide lists proxy hosts, redirection hosts, streams, 404 hosts, Let’s Encrypt and custom certificates, access lists, user permissions, and audit logs among the project’s capabilities. The interface makes common routing work more approachable, but it does not remove the need to understand DNS, network exposure, application authentication, backups, and certificate lifecycle.

Nginx Proxy Manager is a practical choice for:

Routing several subdomains through one public server.
Publishing an internal web application without exposing its native port directly.
Terminating HTTPS in front of an HTTP upstream.
Managing redirects and certificates from one interface.
Proxying WebSocket-enabled dashboards or applications after testing their requirements.

It is not a managed security service, a web application firewall, a DDoS protection service, or a high-availability load-balancing platform. The application manages proxy configuration; you manage the server and every service behind it.

How Does the VoyraCloud Application Image Work?

The VoyraCloud image delivers Nginx Proxy Manager as a ready-to-initialize application on supported VoyraCloud VPS products while keeping administration private. You skip manual package installation and begin with the first-user setup, but the environment remains self-managed after delivery.

Component or responsibility	How it works
Application runtime	Preinstalled and started by the application image
Public HTTP traffic	Accepted on `80/tcp`
Public HTTPS traffic	Accepted on `443/tcp`
Admin interface	Available on `81/tcp`, bound privately and reached through SSH Tunnel
First administrator	Created by the customer in the initial setup screen
Database	Local SQLite for the first release
Persistent application data	Stored on the VPS across a normal restart
Persistent certificate data	Stored separately from ephemeral container state
Domains and DNS	Supplied and managed by the customer
Certificates	Requested or uploaded by the customer; issuance is not guaranteed
Upstream applications	Deployed, secured, monitored, and maintained by the customer
Updates and backups	Planned and performed by the customer

The application version shown in the VoyraCloud resource details is the version delivered when that resource was created. If you later update Nginx Proxy Manager yourself, that displayed value does not become a live application-version detector.

The image also does not create sample proxy hosts, attach a domain, preconfigure a DNS provider, or store third-party API credentials. This clean starting point prevents demo data and shared credentials from becoming part of a production server.

How to Start with the VoyraCloud Image

Start by deploying the application image, opening the private admin interface through an SSH Tunnel, and creating your own administrator before configuring public hosts. The management path and public traffic path are intentionally separate.

Open the VoyraCloud Nginx Proxy Manager page and continue to the VPS purchase flow.
Choose a supported Cloud VPS or Residential IP VPS configuration, then choose any region currently offered by that product.
Confirm that Nginx Proxy Manager is selected in the Images section, then create the VPS.
Wait until the resource is ready and the application health check has completed.
Open the resource details and locate the Application section.
Copy the SSH Tunnel command generated for that resource. It uses the actual SSH user, SSH port, and server address assigned to your VPS.
Run the command in a local terminal and keep that SSH session connected.
Open http://127.0.0.1:8181 in your local browser.
Complete the first-user screen with an administrator email and a unique, strong password.
Confirm that the dashboard opens, then sign out and sign back in once before adding production domains.

A typical tunnel has this shape:

ssh -p <ssh-port> -L 8181:127.0.0.1:81 <ssh-user>@<server-ip>

The local http://127.0.0.1:8181 address travels inside the encrypted SSH connection. It does not make port 81 public. Do not replace it with http://<server-ip>:81, and do not change the firewall or container binding merely to make administration more convenient.

If the local page does not open, check the SSH session first. Confirm that the tunnel remains connected, that no other local program already uses port 8181, and that the VPS application is running. The resource details are the source of truth for the SSH username and port; do not assume every VPS uses root on port 22.

Why Should Port 81 Stay Private?

Port 81 should stay private because it is the control plane for proxy routes, certificates, users, and access rules. Anyone who obtains administrator access can change where domains point, inspect configuration, or disrupt public services.

VoyraCloud therefore uses three distinct network roles:

Port	Purpose	Exposure
`80/tcp`	Public HTTP proxy traffic and common HTTP-01 validation	Public when required
`443/tcp`	Public HTTPS proxy traffic	Public
`81/tcp`	Nginx Proxy Manager administration	Private through SSH Tunnel

An SSH Tunnel is appropriate for both initial setup and routine administration because it avoids publishing a separate management endpoint. If your team later creates a protected administration domain, that is a user-managed design decision. It should use trusted HTTPS, strong application authentication, limited access where practical, and a documented recovery path.

Keeping port 81 private does not secure the upstream applications automatically. Every proxied dashboard, API, or website still needs suitable authentication, authorization, updates, and application-level security. Access Lists and basic HTTP authentication can add a layer for some use cases, but they are not replacements for correct security inside the upstream service.

What Must Be Ready Before You Add a Domain?

A domain, correct DNS records, reachable public ports, and a working upstream must be ready before a production proxy host can work reliably. Nginx Proxy Manager cannot create a domain or repair DNS records at an external provider.

Prepare the following:

A domain or subdomain you control.
An A record pointing to the VPS IPv4 address, plus an AAAA record only if IPv6 is intentionally configured and reachable.
Time for DNS changes to propagate according to your provider and record TTL.
Public reachability on port 80 when using an HTTP-01 challenge.
Public reachability on port 443 for the final HTTPS service.
An upstream application that responds at the address, port, and protocol you plan to enter.
A decision about whether traffic between the proxy and the upstream uses HTTP or HTTPS.

Check public DNS from outside the VPS before requesting a certificate. If the domain still resolves to an old address, the certificate authority will reach the wrong server. If you use a CDN or another proxy service in front, understand how its proxy mode affects validation and traffic before troubleshooting Nginx Proxy Manager.

Let’s Encrypt supports multiple challenge types. HTTP-01 commonly requires the certificate authority to reach port 80 for the requested hostname. DNS-01 requires correct DNS TXT records, often through provider-specific credentials or plugins. The image does not include a DNS provider account, API token, or assurance that every provider integration will work.

How Do You Create a Proxy Host?

Create a Proxy Host by mapping one or more domain names to a reachable upstream scheme, hostname or IP address, and port. Begin with one test service so DNS, routing, logs, and HTTPS can be verified before you add more hosts.

Connect to the admin interface through the SSH Tunnel.
Open Hosts, then Proxy Hosts, and choose Add Proxy Host.
Enter the domain or subdomain that already resolves to the VPS.
Select the upstream scheme, usually http or https.
Enter the upstream hostname or IP address.
Enter the upstream service port.
Enable WebSocket support only if the application uses WebSocket connections.
Save the host without a certificate first if you need to isolate basic routing problems.
Test the public HTTP route and inspect the upstream application behavior.
Add or request a certificate, enable the desired HTTPS options, and test again.

Use an upstream address that the Nginx Proxy Manager container can actually reach. 127.0.0.1 inside a container refers to that container, not automatically to another service or to the VPS host. For services running in Docker, a shared private Docker network can let Nginx Proxy Manager reach a service by container or service name without publishing the upstream port to every host interface. The project’s advanced configuration guide documents this private-network pattern.

For an application on another server, restrict the upstream service so only trusted sources can reach it when the application and network design allow that. Do not assume that hiding the public port in a link makes it private.

How Do WebSocket Applications Work?

WebSocket applications work through Nginx Proxy Manager when the Proxy Host has WebSocket support enabled and the upstream application is configured for the public URL. Both the initial HTTP upgrade and the long-lived connection must survive the full route.

WebSocket failures often appear as a dashboard that loads but never updates, repeated reconnect messages, or browser console errors. Check:

The WebSocket support option on the Proxy Host.
The upstream protocol, address, and port.
The application’s configured public origin or base URL.
Any application-specific trusted-proxy setting.
Browser developer tools for failed upgrade requests.
Nginx Proxy Manager and upstream logs.
CDN, firewall, or intermediary timeouts.

Enabling one checkbox cannot guarantee compatibility with every application. Some services require additional headers, larger upload limits, longer timeouts, path rewrites, or their own reverse-proxy configuration. Apply custom Nginx directives only when you understand their scope and have a rollback plan.

How Do TLS Certificates and Renewal Work?

Nginx Proxy Manager can request Let’s Encrypt certificates or use certificates you provide, but successful issuance and renewal depend on conditions outside the application image. DNS, challenge reachability, certificate-authority rate limits, provider APIs, clock accuracy, and account configuration can all affect the result.

For a common HTTP-01 setup:

Confirm that the domain resolves publicly to the VPS.
Confirm that port 80 reaches Nginx Proxy Manager.
Open the Proxy Host’s SSL settings.
Request a new Let’s Encrypt certificate.
Accept the applicable terms and provide the required contact information.
Save the configuration and wait for the request to finish.
Open the HTTPS domain and inspect the certificate in the browser.
Verify HTTP-to-HTTPS behavior if you enable a redirect.

For DNS-01, use only a provider and credential flow that you have reviewed and tested. Limit API-token permissions where the DNS provider supports it, store credentials carefully, and rotate them if they are exposed. VoyraCloud does not provide or manage these credentials.

Renewal should be monitored rather than assumed. Record the certificate expiration date, check application logs, and test renewal behavior before a certificate approaches expiry. A certificate that issued once can later fail to renew because DNS changed, port 80 became blocked, credentials expired, a provider changed its API, or the server stopped running.

Custom certificates also need lifecycle ownership. You must track their expiration, replacement, private-key protection, and recovery. Never paste private keys into tickets, screenshots, or public documentation.

What Data Persists, and What Should You Back Up?

The image preserves the SQLite database, Nginx Proxy Manager configuration, users, proxy definitions, and certificate data across a normal VPS restart, but persistence is not a backup. A deleted VPS, damaged filesystem, accidental configuration change, failed upgrade, or compromised administrator account can still destroy or invalidate local data.

The official setup instructions separate application data from Let’s Encrypt certificate storage. The VoyraCloud image follows the same persistence principle while using local SQLite for the first release.

Your backup plan should protect:

The application data containing the SQLite database and settings.
Proxy Hosts, Redirect Hosts, Streams, Access Lists, users, and audit records.
Let’s Encrypt account and certificate material.
Uploaded custom certificates and private keys.
Any user-created custom Nginx configuration.
A record of DNS, upstream addresses, firewall rules, and external dependencies.

Store a recovery copy outside the VPS and protect it as sensitive material. Certificate private keys and administrative data should be encrypted in transit and at rest. Define retention, access, and deletion rules, then rehearse a restore to a separate test environment before relying on the process.

A normal container recreation with intact persistent data should not erase the configuration, but deleting or replacing persistent storage is different. Review what an update or maintenance command will change before running it.

How Should You Maintain the Deployment?

Maintain the deployment by monitoring public routes, certificate expiry, container health, resource usage, logs, backups, and upstream applications as separate responsibilities. A working proxy cannot make an unhealthy upstream reliable.

Use this operational checklist:

Monitor the public HTTP and HTTPS endpoints from outside the VPS.
Monitor certificate expiration and investigate renewal errors promptly.
Review 4xx, 5xx, timeout, and upstream connection errors.
Track CPU, memory, disk space, and log growth.
Keep the VPS operating system, Docker runtime, Nginx Proxy Manager, and upstream applications on supported versions.
Back up persistent application and certificate data before upgrades.
Read the project’s release notes and upgrade guidance.
Test important routes, WebSocket connections, redirects, and certificates after a change.
Keep a documented rollback or restore procedure.
Restrict SSH and administrator access, and remove users who no longer need control.

For a broader server-maintenance baseline, see the VoyraCloud VPS management guide. The VPS provides the server foundation; it does not include managed application operations, automatic backup, or guaranteed certificate renewal.

Common Problems and the Fastest Checks

Most Nginx Proxy Manager failures can be narrowed down by checking DNS, public ports, proxy configuration, upstream reachability, and logs in that order.

Symptom	First checks
Local admin page does not open	SSH Tunnel is connected, local port 8181 is free, application is running
Domain reaches the wrong server	Public `A`/`AAAA` records and DNS propagation
502 Bad Gateway	Upstream scheme, address, port, service status, and Docker network
504 Gateway Timeout	Upstream response time, firewall, network route, and timeout requirements
Certificate request fails	DNS target, port 80, challenge type, provider credentials, rate limits, and logs
HTTPS works but app redirects incorrectly	Public base URL, forwarded-proxy settings, and upstream application configuration
Dashboard loads but live updates fail	WebSocket support, origin rules, intermediary timeouts, and browser console
Configuration disappears after maintenance	Persistent data was replaced, detached, deleted, or not included in recovery

Avoid repeatedly requesting certificates while the underlying DNS or network issue remains. Repeated attempts can make troubleshooting slower and may encounter certificate-authority rate limits. Fix the failed prerequisite, read the error log, and then retry deliberately.

FAQ

Can I access the Nginx Proxy Manager admin interface from the public internet?

The VoyraCloud image keeps the admin interface private and expects you to access it through an SSH Tunnel. Port 81 controls proxy routes, users, and certificates, so it should not be exposed merely for convenience. Use the tunnel command in the resource details and open the local address while the SSH session remains connected.

Does the image include a default administrator password?

No, the image does not provide a shared default administrator account or password. Create your own first administrator through the initial setup screen. Use a unique password, protect the email account associated with recovery, and do not place credentials in support tickets or screenshots.

Does Nginx Proxy Manager automatically configure my DNS?

No, you must configure DNS with your domain provider. Point the required record to the VPS and verify public resolution before adding a certificate. DNS challenge integrations may use provider-specific credentials, but the image does not include a provider account, token, or guarantee of compatibility.

Is a Let’s Encrypt certificate guaranteed to issue and renew?

No, certificate issuance and renewal cannot be guaranteed. Success depends on correct DNS, reachable validation ports or DNS challenge records, certificate-authority policies and rate limits, valid provider credentials where applicable, and a healthy running server. Monitor expiration and renewal results.

Can Nginx Proxy Manager proxy WebSocket applications?

Yes, it can proxy WebSocket traffic when WebSocket support is enabled and the upstream application is configured correctly. You still need to test the public origin, connection upgrades, timeouts, headers, and any application-specific trusted-proxy settings.

Does the image include WAF or DDoS protection?

No, the image does not include a managed WAF, DDoS protection service, or a guarantee that upstream applications are secure. Nginx Proxy Manager provides routing and certificate-management features. Application authentication, patching, access control, network protection, and incident response remain separate responsibilities.

Is the local SQLite database backed up automatically?

No, local persistence does not create an off-server backup. The SQLite database and certificate data should survive a normal restart, but you must create, secure, retain, and test your own recovery copies outside the VPS.

Can I use one VPS for several domains?

Yes, one deployment can route multiple domains or subdomains when the server has enough capacity and each upstream is configured correctly. Capacity depends on traffic, TLS activity, response sizes, logs, upstream behavior, and any other workloads sharing the VPS. High availability and zero-downtime operation are not included.

Conclusion

Nginx Proxy Manager on VPS is a good fit when you want a self-managed reverse proxy with a web interface and you are prepared to own DNS, upstream applications, certificates, updates, monitoring, and backups. The VoyraCloud application image removes the manual installation step while preserving a private administration path through SSH Tunnel.

Begin with one domain and one known-good upstream. Keep port 81 private, verify DNS before requesting a certificate, test WebSocket behavior where required, and protect both SQLite application data and certificate material with an off-server recovery plan. This measured approach is more reliable than adding many hosts before the basic path has been verified.

Review the VoyraCloud Nginx Proxy Manager application page for the image workflow, then choose a supported VoyraCloud Cloud VPS or Residential IP VPS configuration based on expected traffic, TLS activity, logs, upstream applications, and other services sharing the server.