How to Install Pangolin on a VPS for Secure Remote Access

Pangolin is an open-source remote-access platform that combines an identity-aware reverse proxy with WireGuard-based tunnelling. It gives private web applications a public HTTPS address and can also provide authorised client access to private services, without forwarding those application ports through the router at the remote site.

The important distinction is that Pangolin is not simply another proxy dashboard. Its Newt connector maintains an outbound tunnel from the private network to the public Pangolin server. You explicitly define the resources users may reach, then place authentication and access policies in front of them.

When Pangolin Is a Good Fit

Pangolin is not a reason to publish everything. Keep management interfaces private where possible, grant the smallest useful scope and treat the Pangolin administrator account as a privileged credential.

Understand the Four Moving Parts

A Newt site denies traffic until you create resources and assign access. That default matters: connecting a site should not expose every device behind it. Pangolin also supports local sites and basic WireGuard sites, but Newt is the sensible starting point for most deployments because it handles NAT traversal and the broader managed feature set.

Choose and Prepare the VPS

For a small installation, start with 2 vCPU, 2 GB RAM and 20 GB SSD. Use 4 GB RAM when the same VPS will handle several applications, more concurrent users or additional monitoring. Pangolin's official installer supports AMD64 and ARM64 Linux systems and recommends a current Ubuntu or Debian release.

• A Linux VPS with root access and a public IPv4 address
• A domain you control
• TCP ports 80 and 443 available
• UDP 51820 for site tunnels and UDP 21820 for clients
• An email address for certificate issuance and the first administrator
• Docker Engine and the Compose plugin, installed by the supported workflow

Patch the operating system and confirm no existing web server is already listening on the required ports:

sudo apt update
sudo apt full-upgrade -y
sudo ss -lntup | grep -E ':(80|443|51820|21820)\b' || true
docker --version
docker compose version

Create DNS and Firewall Rules First

Choose a base domain such as example.net and a dashboard hostname such as pangolin.example.net. Create an A record for the dashboard pointing to the VPS. Published resources normally use subdomains, so a wildcard A record such as *.example.net pointing to the same address keeps future resources simple.

Open only the ports Pangolin needs. With UFW, preserve SSH access before enabling the firewall:

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 51820/udp
sudo ufw allow 21820/udp
sudo ufw enable
sudo ufw status verbose

If you change Pangolin's tunnel or client ports, mirror those values in the firewall. Do not expose database, Docker API or internal application ports publicly.

Install Pangolin Community Edition

Use a dedicated directory because the installer writes its configuration into the current working directory. Read the installer before running it on a production system, then use the official download path:

sudo install -d -m 0750 /opt/pangolin
sudo chown "$USER":"$USER" /opt/pangolin
cd /opt/pangolin

curl -fsSL https://static.pangolin.net/get-installer.sh | bash
less ./installer
sudo ./installer

Select Community Edition unless you specifically need the commercial edition. Enter the base domain without a subdomain, choose the dashboard hostname, provide the certificate email and leave Gerbil enabled for tunnelled connections. SMTP is optional and can be added after the core service works.

The installer pulls the Pangolin, Gerbil and Traefik containers and starts them. When it finishes, open the initial-setup URL shown in the terminal, enter the one-time token, create the administrator and then create the first organisation.

cd /opt/pangolin
docker compose ps
docker compose logs --tail=100

Store the generated configuration as a secret. It contains values that can control the deployment and must not be committed to a public Git repository.

Connect a Private Network with Newt

In Pangolin, create a site and choose Newt. The dashboard generates an endpoint, site ID and secret. Run Newt on a host that can reach the private applications. A small always-on Linux machine or Docker host is ideal.

services:
  newt:
    image: fosrl/newt:latest
    container_name: newt
    restart: unless-stopped
    environment:
      PANGOLIN_ENDPOINT: https://pangolin.example.net
      NEWT_ID: replace-with-site-id
      NEWT_SECRET: replace-with-site-secret

docker compose up -d
docker compose logs -f newt

For production, place those values in a root-readable environment file or Docker secret instead of shell history. Restrict the file to mode 600. Do not paste real credentials into screenshots, support chats or a public Compose repository.

Newt can inspect Docker containers when given access to the Docker socket, but that socket is effectively root-level control of the host. Prefer explicit target addresses. If discovery is necessary, use a restricted socket proxy and enable network validation rather than casually mounting /var/run/docker.sock.

Publish the First Private Application

1. Create a resource inside the organisation.
2. Select the Newt site that can reach the application.
3. Choose a public HTTPS resource for a browser application.
4. Enter the internal target, such as 192.168.20.15:3000.
5. Assign a hostname such as status.example.net.
6. Add users or roles, then require authentication before testing externally.

Test from a network outside the private site, such as mobile data. Confirm the public hostname resolves to the VPS, TLS is valid, authentication appears before the application and the private target is not directly reachable from the internet.

For SSH, databases and other private protocols, create a private resource and use a Pangolin client. Avoid turning an administrative protocol into an unauthenticated public TCP endpoint simply because the tunnel makes it possible.

Harden the Control Plane

• Use a unique administrator password and enable multi-factor authentication.
• Integrate a trusted identity provider when central lifecycle control is required.
• Grant access by user or role to specific resources, not an entire site.
• Keep Pangolin, Traefik, Gerbil and Newt current, but review release notes before upgrades.
• Restrict SSH to keys, disable direct password login and keep the VPS firewall narrow.
• Protect Newt secrets and rotate them when a connector host is lost or reassigned.
• Monitor authentication, resource changes and unexpected connection attempts.
• Keep the dashboard hostname out of public application documentation where practical.

A tunnel removes inbound forwarding from the remote router; it does not make the application itself trustworthy. Patch the private app, remove default credentials and maintain its own backups.

Back Up and Update Pangolin Safely

Back up the installer-generated configuration, Pangolin data and any database volumes. Keep an encrypted copy outside the VPS. A provider snapshot is useful before an upgrade, but it should complement rather than replace an application-aware backup.

cd /opt/pangolin
docker compose ps
docker compose pull
docker compose up -d
docker compose logs --tail=100
docker image prune

Pin tested image versions if change control matters. After every update, verify the dashboard, one public resource, one private resource and at least one Newt connector before declaring the maintenance complete.

Common Pangolin Problems

Pangolin VPS FAQ

Is Pangolin an alternative to Cloudflare Tunnel?

It can fill a similar remote-access role while keeping the control plane on infrastructure you operate. The architecture, identity features and operational responsibility differ, so compare requirements rather than treating them as identical products.

Does Pangolin need a public IPv4 address?

A self-hosted Pangolin edge needs a publicly reachable address and domain. A public IPv4 address is the simplest deployment path, with IPv6 added when your clients and services can use it reliably.

Do I need to open ports at home?

Not for a Newt site. Newt establishes an outbound connection from the private network, which is useful behind NAT or a restrictive firewall.

How much RAM does Pangolin need?

Start with 2 GB RAM for a small deployment and choose 4 GB when supporting more resources, users or adjacent monitoring. Observe real container usage before scaling.

Can Pangolin expose Docker containers?

Yes. Newt can discover Docker services, but direct Docker socket access is highly privileged. Explicit targets or a restricted socket proxy are safer defaults.

Is Pangolin a full VPN?

It combines browser-based reverse proxy access with client-based private resource access. Its policy model is resource-focused rather than automatically placing every user on a flat private network.

Build the Tunnel Around Explicit Access

A dependable Pangolin deployment has a small public edge, correct DNS, narrowly opened ports, protected connector secrets and policies that grant access to named resources. That is much safer than exposing a collection of dashboards and administration ports one by one.

Deploy the public control plane on a HYEHOST Cloud VPS, manage its records with HYE DNS, and use Newt to connect the private networks where the applications actually live.

Official Resources

• Pangolin self-hosted quick install
• DNS and networking requirements
• Install a Newt site
• How Pangolin works
• Pangolin source repository