pangolin_mirror/docs-v2
1
0
Fork 0
mirror of https://github.com/fosrl/docs-v2.git synced 2026-09-08 23:21:32 +02:00
Code Issues Packages Projects Releases Wiki Activity

update vs reverse proxy vs vpn

Browse Source
This commit is contained in:
miloschwartz
2026-09-08 15:02:40 -04:00
parent 0591952fe8
commit e03b5b1faf
3 changed files with 23 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
about/how-pangolin-works.mdx
View File

@@ -2,6 +2,9 @@
title: "How Pangolin Works"
description: "Learn about the fundamentals of Pangolin and how they work together to provide simple and secure network access."
---
This page explains Pangolin's concepts: the server, sites, resources, and clients. Read it first. For a more technical picture of the software components and how they interact, see [System Architecture](/development/system-architecture) after this page.
## Basic Steps
<Steps>
@@ -113,4 +116,8 @@ You can deploy multiple remote nodes for high availability and automatic failove
<Card title="Read more about remote nodes" icon="circle-nodes" href="/manage/remote-node/understanding-nodes">
Learn about remote nodes and how they provide high availability and simplified operations.
</Card>
</Card>
## System Architecture
For a more technical picture of the software components and how they interact, see [System Architecture](/development/system-architecture).

21
about/pangolin-vs-reverse-proxy-vs-vpn.mdx
View File

@@ -9,17 +9,18 @@ Pangolin combines the capabilities of both a reverse proxy and a VPN into a sing
## What Each Solution Provides
**Reverse Proxies** expose web applications to the internet. They handle SSL termination, load balancing, and basic authentication. Users access applications through web browsers using domain names.
**Reverse Proxies** expose web applications to the internet. They handle SSL termination, load balancing, and basic authentication. Users access applications through web browsers using domain names. They are usually protocol-aware of HTTPS only.
**VPNs** create encrypted tunnels that give users access to entire private networks. Users install client software and connect to a VPN server. Once connected, they can access any resource on the network they have network-level access to.
**VPNs** create encrypted tunnels that give users access to entire private networks as if they were on the local network. Users install client software and connect to a VPN server. Once connected, they can access any resource on the network they have network-level access to.
**Pangolin** provides both capabilities—and several things neither traditional tool does on its own. Public resources work like a reverse proxy, allowing browser-based access to specific applications. Private resources work like a zero-trust VPN, giving users access to specific hosts or network ranges when connected with a client.
**Pangolin** provides both capabilities, and several things neither traditional tool does on its own. [Public resources](/manage/resources/understanding-resources#public-resource-types) are publicly served proxies. That is often a website in a browser, but it can also be an API or an [AI Gateway](/manage/ai/overview). [Private resources](/manage/resources/understanding-resources#private-resource-types) work like a zero-trust VPN, giving users access to specific hosts or network ranges when connected with a client.
## What Pangolin Does Differently
| Capability | Traditional reverse proxy | Traditional VPN | Pangolin |
|------------|--------------------------|-----------------|----------|
| Browser access to web apps | Yes | No | Yes — public HTTP/HTTPS |
| Publicly served proxies | Web apps | No | Yes: HTTP/HTTPS, APIs, [AI Gateway](/manage/ai/overview) |
| Protocol-aware proxies | HTTPS | No | Yes: HTTPS, SSH, RDP, VNC, AI providers, and more |
| Browser SSH, RDP, VNC | No | No | Yes — public SSH, RDP, VNC |
| Client-only private access | No | Yes | Yes — host, CIDR, SSH, private HTTP |
| Per-resource access control | Limited | Network-wide | Yes — users and roles per resource |
@@ -29,9 +30,11 @@ Pangolin combines the capabilities of both a reverse proxy and a VPN into a sing
## Reverse Proxy Capabilities
Pangolin's public resources function as reverse proxies—and go further than HTTP alone.
Pangolin's public resources function as reverse proxies. They are publicly served, not limited to web browsers. A traditional reverse proxy is usually protocol-aware of HTTPS only. Pangolin understands many protocols, including HTTPS, SSH, RDP, VNC, and AI provider APIs, so identity, access rules, and logging apply to each the same way.
**HTTP/HTTPS** resources expose web applications through domain names with automatic SSL certificates. Users access them in a browser with no client installed. Identity-aware access control supports SSO, MFA, and rules based on user identity, roles, geographic location, IP addresses, and URL paths.
**HTTP/HTTPS** resources expose web applications and APIs through domain names with automatic SSL certificates. A browser is the common client; any HTTP client can call the same FQDN. Identity-aware access control supports SSO, MFA, and rules based on user identity, roles, geographic location, IP addresses, and URL paths.
**AI Gateway** resources are public proxies for LLM APIs. Coding agents call the FQDN instead of the upstream provider. Pangolin authenticates the caller and applies identity, model access, and budgets. See [AI Gateway](/manage/ai/overview).
**SSH, RDP, and VNC** resources render full sessions in the browser. Users get a terminal, Windows desktop, or VNC display without installing SSH clients or remote desktop software—while still passing through Pangolin authentication first.
@@ -47,7 +50,7 @@ Pangolin's private resources function like a zero-trust VPN—but with tighter s
**Private HTTP/HTTPS** resources behave like a reverse proxy that only exists on the tunnel. TLS terminates at your [site edge over peer-to-peer transport](/manage/resources/private/private-http)—the application is never reachable from the public internet, only from connected clients with valid access.
**Private SSH** resources provide terminal access via `pangolin ssh`, with optional automatic user provisioning from Pangolin identity—no manual key distribution required.
**[Private SSH](/manage/resources/private/ssh)** resources provide terminal access via `pangolin ssh`, with optional automatic user provisioning from Pangolin identity—no manual key distribution required.
Clients work transparently with applications. No application configuration is required. Users connect once and can access all their authorized resources. The client handles routing and establishes encrypted tunnels automatically.
@@ -55,7 +58,7 @@ Clients work transparently with applications. No application configuration is re
Many organizations need both reverse proxy and VPN capabilities. You might want to expose a customer portal through a browser while also giving developers SSH access to internal servers and a private HTTPS dashboard that never touches the public internet.
With Pangolin, you use one platform for all of these. Public resources handle browser-based access—including SSH, RDP, and VNC when you want sessions without a client. Private resources handle tunnel-only access to hosts, subnets, internal HTTPS apps, and CLI SSH. Both use the same authentication system, access control policies, and infrastructure.
With Pangolin, you use one platform for all of these. Public resources handle publicly served access: websites in a browser, APIs, [AI Gateway](/manage/ai/overview) resources, and SSH, RDP, and VNC sessions. Private resources handle tunnel-only access to hosts, subnets, internal HTTPS apps, and CLI SSH. Both use the same authentication system, access control policies, and infrastructure.
This unified approach simplifies management. You configure users, roles, and access policies once. Those policies apply to both public and private resources. You do not need to maintain separate systems for reverse proxy and VPN access.
@@ -73,4 +76,4 @@ Use a traditional reverse proxy if you only need to expose web applications over
Use a traditional VPN if you need broad network access, you can accept the security risks of flat network visibility, and you do not need application-specific access control.
Use Pangolin if you need both reverse proxy and VPN capabilities, browser-based SSH/RDP/VNC, private HTTPS with edge TLS termination, granular per-resource access control, multi-site routing, high availability, or outbound-only connectivity without open ports on your networks.
Use Pangolin if you need both reverse proxy and VPN capabilities, publicly served APIs and AI gateways, browser SSH/RDP/VNC, private HTTPS with edge TLS termination, granular per-resource access control, multi-site routing, high availability, or outbound-only connectivity without open ports on your networks.

8
development/system-architecture.mdx
View File

@@ -3,15 +3,13 @@ title: "System Architecture"
description: "A technical overview of how Pangolin's control plane, nodes, connectors, and clients fit together"
---
## Open Source
Every layer of Pangolin is open source, from the control plane server through site connectors and end-user clients. Each component has its own repository under [fosrl on GitHub](https://github.com/fosrl); the [component reference](#component-reference) at the bottom of this page lists them.
The software that powers [Pangolin Cloud](https://app.pangolin.net) is open source as well. The SaaS control plane runs the same codebase as self-hosted Pangolin, and that code lives in the main [fosrl/pangolin](https://github.com/fosrl/pangolin) repository. Nothing described here is proprietary or hidden behind the managed service.
The software that powers [Pangolin Cloud](https://app.pangolin.net) is open source as well. The SaaS control plane runs the same codebase as self-hosted Pangolin, and that code lives in the main [fosrl/pangolin](https://github.com/fosrl/pangolin) repository.
Pangolin is split into a **control plane** (configuration, identity, and orchestration) and a **data plane** (encrypted tunnels, ingress, and relay). Sites and clients both initiate **outbound** connections to a Pangolin node, which keeps remote networks behind firewalls reachable without opening inbound ports on those networks.
Pangolin is split into a **control plane** (configuration, identity, and orchestration) and a **data plane** (encrypted tunnels, ingress, and relay). For [public resources](/manage/resources/understanding-resources#public-resource-types), site connectors initiate **outbound** connections to a Pangolin node so the node can reverse-proxy traffic into the remote network without opening inbound ports there. For [private resources](/manage/resources/understanding-resources#private-resource-types), [clients](/manage/clients/understanding-clients) connect **peer-to-peer** to the site; the node is only in the data path as a relay when a direct path cannot be established. See [Peer-to-Peer and Relay Paths](#peer-to-peer-and-relay-paths).
For a product-level walkthrough of sites, resources, and clients, see [How Pangolin Works](/about/how-pangolin-works). This page focuses on how those pieces are implemented and how traffic moves through the system.
@@ -64,7 +62,7 @@ The control plane writes certificates, Traefik router definitions, and WireGuard
## Site Connectors
A **site connector** runs on a remote network (server, VM, container, or appliance) and maintains persistent **outbound** connections to a Pangolin node. It is the bridge between your private LAN and the platform.
A **site connector** runs on a remote network (server, VM, container, or appliance) and is the bridge between your private LAN and the platform. For public resources it maintains persistent **outbound** connections to a Pangolin node so ingress can reverse-proxy into the LAN. For private resources, clients form a **peer-to-peer** path to the connector; the node is only in that data path as a relay when hole punching fails.
The primary connector implementation is **Newt** (codename). Newt opens: