mirror of
https://github.com/fosrl/docs-v2.git
synced 2026-09-27 16:29:07 +02:00
port mintlify to fumadocs
This commit is contained in:
miloschwartz
@@ -0,0 +1,191 @@
|
||||
---
|
||||
title: "How Pangolin Works"
|
||||
description: "Learn about the fundamentals of Pangolin and how they work together."
|
||||
---
|
||||
|
||||
This page explains Pangolin's concepts: the server, sites, resources, users, 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>
|
||||
<Step title="Make remote networks available with sites">
|
||||
Access remote networks using site connectors. Pangolin's lightweight connectors use intelligent routing and NAT traversal to make any network anywhere available. Once a site is created, you can access resources on that network from anywhere.
|
||||
</Step>
|
||||
|
||||
<Step title="Define resources">
|
||||
Create resources for the things users should reach on the network of your site. Each resource follows a protocol: HTTPS in the browser, an IP or network range over the client, SSH, remote desktop, LLM access, and more. Resources can be public or fully private.
|
||||
</Step>
|
||||
|
||||
<Step title="Users access resources">
|
||||
Authenticated users access resources via the protocol of the resource. Commonly, public resources are accessed through a web browser, while private resources are accessed through a Pangolin client. The same users, roles, and policies apply across both. Users don't think about connecting to a site, they just access resources and Pangolin routes to the right connector automatically.
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## Key Concepts
|
||||
|
||||
Pangolin relies on several components that work together to provide secure networking. Each component has a specific role in ensuring that only authenticated users can access the resources they are authorized to use.
|
||||
|
||||
### Pangolin Server
|
||||
|
||||
The Pangolin server is the central coordination component for your network. It stores configuration changes, manages access policies, and coordinates connections between clients and sites. The server handles user authentication, generates access control lists that determine what resources each user can reach, hosts the UI and API, and more. It is the brains of your Pangolin network.
|
||||
|
||||
You can use [Pangolin Cloud](https://app.pangolin.net/auth/signup), which is fully managed, or you can self-host your own Pangolin server for complete control over your infrastructure and data. See [Pangolin Cloud vs. Self-Hosted](/about/pangolin-cloud-vs-self-hosted).
|
||||
|
||||
<Card title="Try free on Pangolin Cloud" icon="cloud" href="https://app.pangolin.net/auth/signup" arrow="true" cta="Sign up free">
|
||||
Fastest way to get started with the fully managed control plane.
|
||||
</Card>
|
||||
|
||||
<Card title="Read about how to self-host Pangolin" icon="server" href="/self-host/quick-install">
|
||||
Learn how to deploy your own self-hosted Pangolin server.
|
||||
</Card>
|
||||
|
||||
### Sites
|
||||
|
||||
Sites connect remote networks to your Pangolin server. They use Pangolin Site connectors (sometimes referred by their engineering name, "Newt") to create secure tunnels from remote networks back to Pangolin. Sites let you expose [resources](/manage/resources/understanding-resources) on those networks to authorized users.
|
||||
|
||||
Sites are an expected to entirely be managed by administrators and are typically set-and-forget. Users don't need to know about sites, they just access resources that are available on the site.
|
||||
|
||||
<Frame caption="Manage Sites in the Pangolin dashboard, with status, uptime, and resource counts per site.">
|
||||
<img src="/images/sites.png" alt="Manage Sites page in the Pangolin dashboard"/>
|
||||
</Frame>
|
||||
|
||||
Sites run behind firewalls on remote networks. They maintain outbound connections to the Pangolin server. By default, sites block all traffic until you define resources and grant access. This ensures that just [deploying a site](/manage/sites/install-site) does not expose any network resources.
|
||||
|
||||
<Frame caption="Creating a site: pick a platform, copy the install command, and run the connector on the remote network.">
|
||||
<img src="/images/create-site.png" alt="Create Site page in the Pangolin dashboard"/>
|
||||
</Frame>
|
||||
|
||||
When [private resources](/manage/resources/understanding-resources#private-resource-types) (VPN-like access) are used, [clients](/manage/clients/understanding-clients) connect directly to the site connector using peer-to-peer (P2P) [NAT traversal](/manage/clients/nat-traversal). If the client is on the same network as the site connector, it will use the [local network address](/manage/clients/nat-traversal#same-network-detection).
|
||||
|
||||
The site connector is very intelligent and handles tunnel creation, NAT traversal, and routing. It makes remote networks available without requiring complex firewall rules or public IP addresses. They also unlock browser-based [SSH](/manage/resources/public/ssh), [RDP](/manage/resources/public/rdp), and [VNC](/manage/resources/public/vnc) resources, [private HTTP](/manage/resources/private/private-http) with edge TLS termination, intelligent [multi-site routing](/manage/resources/private/multi-site-routing) when the same resource is reachable from more than one location, and much more.
|
||||
|
||||
<Card title="Read more about sites" icon="plug" href="/manage/sites/understanding-sites">
|
||||
Learn about sites, how they work, and how to install and configure them.
|
||||
</Card>
|
||||
|
||||
### Resources
|
||||
|
||||
Pangolin is resource-based. A resource is the unit of access: you define it, grant users and roles, and Pangolin routes only authorized traffic. Users connect to resources, not to sites.
|
||||
|
||||
Resources follow different protocols depending on what you are exposing (for example, but not limited to):
|
||||
|
||||
- An HTTPS app, available in the browser
|
||||
- An IP address, reached through the Pangolin client
|
||||
- A network range, reachable through the Pangolin client
|
||||
- An [AI Gateway](/manage/ai/overview) resource for LLM access
|
||||
- Remote desktop
|
||||
- SSH
|
||||
|
||||
The access model stays the same while the protocol changes.
|
||||
|
||||
[Public resources](/manage/resources/understanding-resources#public-resource-types) are publically available proxies to your Pangolin server. Often, these are exposed as a public FQDN, like a website available in the web-browser or an API.
|
||||
|
||||
<Frame caption="Public resources in the dashboard: HTTPS, SSH, RDP, and VNC with health, uptime, and access URLs.">
|
||||
<img src="/images/public-resources.png" alt="Manage Public Resources page in the Pangolin dashboard"/>
|
||||
</Frame>
|
||||
|
||||
[Private resources](/manage/resources/understanding-resources#private-resource-types) require a [Pangolin client](/manage/clients/install-client) connection and stay off the public internet. They are for VPN-like, fully private access to resources on your remote network.
|
||||
|
||||
<Frame caption="Private resources in the dashboard: hosts, HTTP, SSH, and CIDR ranges with destinations and aliases.">
|
||||
<img src="/images/private-resources.png" alt="Manage Private Resources page in the Pangolin dashboard"/>
|
||||
</Frame>
|
||||
|
||||
You must define resources and assign access before users can reach them. By default, no resources are available on sites. This ensures that only explicitly defined resources can be accessed.
|
||||
|
||||
#### Resource Launcher
|
||||
|
||||
The Resource Launcher is the dashboard your users (non-admins) see. It lists every resource they are allowed to access in one place, grouped by site or label, with search and filters. Users open a web app, copy a hostname, or launch a private resource from that hub.
|
||||
|
||||
<Frame caption="The Resource Launcher, grouped by site, showing the resources a user can open.">
|
||||
<img src="/images/resource-launcher.png" alt="Resource Launcher in the Pangolin dashboard"/>
|
||||
</Frame>
|
||||
|
||||
Selecting a resource always expands a panel with the details that matter for that type: URL or alias, how to connect, and any extra setup. The screenshot below is an [AI Gateway](/manage/ai/overview) example. The same panel is used for every resource.
|
||||
|
||||
<Frame caption="Resource Launcher detail panel. This example shows a private SSH resource.">
|
||||
<img src="/images/resource-launcher-expanded.png" alt="Resource Launcher detail panel showing a private SSH resource as an example."/>
|
||||
</Frame>
|
||||
|
||||
<Card title="Resource Launcher" icon="grid-2" href="/manage/resource-launcher">
|
||||
Find, launch, and save views of the resources you can access.
|
||||
</Card>
|
||||
|
||||
<Card title="Read more about resources" icon="link" href="/manage/resources/understanding-resources">
|
||||
Learn about public and private resources and how to create them.
|
||||
</Card>
|
||||
|
||||
### Users and Roles
|
||||
|
||||
Identity lives in the same control plane as sites and resources. You manage your team in one place: Pangolin users, [identity providers](/manage/identity-providers/add-an-idp), and the [roles](/manage/access-control/create-user#roles) that grant access.
|
||||
|
||||
Use Pangolin's built-in users, or bring Google Workspace, Microsoft Entra ID, Okta, or any OIDC provider. Users authenticate once. That identity applies to the dashboard, browser resources, the Pangolin client, the AI Gateway, and everything else.
|
||||
|
||||
Roles group people for RBAC. You assign roles on each resource, so access follows the team rather than a separate list per protocol. A user's effective access is the union of what their roles can reach. The same users and roles apply to public resources, private resources, and AI Gateway resources.
|
||||
|
||||
<Frame caption="Users in the dashboard, with identity providers and roles managed together.">
|
||||
<img src="/images/users.png" alt="Manage Users page in the Pangolin dashboard"/>
|
||||
</Frame>
|
||||
|
||||
<Card title="Users and Roles" icon="users" href="/manage/access-control/create-user">
|
||||
Add internal or external users and assign roles for resource access.
|
||||
</Card>
|
||||
|
||||
<Card title="Add an Identity Provider" icon="key" href="/manage/identity-providers/add-an-idp">
|
||||
Let users sign in with Google, Microsoft Entra ID, Okta, or any OIDC provider.
|
||||
</Card>
|
||||
|
||||
### Clients
|
||||
|
||||
Clients are software components installed on user devices or machines. They let users and automated systems connect directly to sites to access [private resources](/manage/resources/understanding-resources#private-resource-types) through a secure tunnel. Clients also enforce access control and security at the edge.
|
||||
|
||||
Users authenticate through the client using their [accounts](/manage/access-control/create-user). [Machines](/manage/clients/credentials) connect with credentials. Once connected, users can reach all resources their account has access to. The client handles [routing](/manage/clients/nat-traversal) decisions and establishes encrypted tunnels to the appropriate [sites](/manage/sites/understanding-sites).
|
||||
|
||||
<Frame caption="User devices in the dashboard, with identity provider, connection status, and client version.">
|
||||
<img src="/images/user-devices.png" alt="User Devices page in the Pangolin dashboard"/>
|
||||
</Frame>
|
||||
|
||||
Clients are available on [all major platforms](/manage/clients/install-client). They work transparently with applications, so no application configuration is required.
|
||||
|
||||
<Card title="Download Pangolin clients" icon="download" href="https://pangolin.net/downloads" arrow="true">
|
||||
Get the client for Mac, Windows, Linux, iOS, and Android.
|
||||
</Card>
|
||||
|
||||
<Card title="Read more about clients" icon="desktop" href="/manage/clients/understanding-clients">
|
||||
Learn how user and machine clients connect to private resources.
|
||||
</Card>
|
||||
|
||||
### AI Gateway
|
||||
|
||||
An [AI Gateway](/manage/ai/overview) is a special resource type for LLM access. It is protocol-aware, in the same way an HTTPS resource understands HTTP.
|
||||
|
||||
<Frame caption="Creating a public resource with type set to AI Gateway.">
|
||||
<img src="/images/ai/create-ai-gateway-resource.png" alt="Create Public Resource form with Type set to AI Gateway"/>
|
||||
</Frame>
|
||||
|
||||
Pangolin already inspects HTTPS traffic to apply identity, access rules, [request logs](/manage/analytics/request), and analytics. An AI Gateway resource does the equivalent for model APIs. Because the gateway understands the LLM protocol, it can attribute each call to a user, record [cost and token usage](/manage/ai/usage-analytics), keep [chat session history](/manage/ai/session-logs), and enforce who can use which [models](/manage/ai/providers/model-routing) and [budgets](/manage/ai/budgets).
|
||||
|
||||
Access is identity-based. You grant users and roles on the resource the same way you do for HTTPS or SSH. Pangolin then decides which models that identity may call and whether a budget still allows the request.
|
||||
|
||||
<Frame caption="AI Gateway session logs, showing provider, model, resource, and the user who made the call.">
|
||||
<img src="/images/ai/expanded-session-logs.png" alt="AI Gateway session logs in the Pangolin dashboard"/>
|
||||
</Frame>
|
||||
|
||||
A [private AI Gateway](/manage/resources/private/ai-gateway) uses the [Pangolin client](/manage/clients/install-client) the same way every other private resource does. The client running on the end user's device already authenticated that user. Coding agents on that device call the resource over the tunnel, and Pangolin attributes the request to the connected identity. That eliminates provider API keys on the laptop: the upstream key stays on the [provider](/manage/ai/providers/overview).
|
||||
|
||||
<Card title="Read more about AI Gateway" icon="sparkles" href="/manage/ai/overview">
|
||||
Set up providers, resources, and identity-based access for coding agents and AI clients.
|
||||
</Card>
|
||||
|
||||
### Remote Nodes
|
||||
|
||||
Remote nodes are self-hosted Pangolin servers that you control while using Pangolin Cloud for management and coordination. You maintain complete control over your infrastructure and data flow, while the cloud handles the control plane, DNS, certificate management, and backups.
|
||||
|
||||
You can deploy multiple remote nodes for high availability and automatic failover. If your nodes become unavailable, traffic can optionally fail over to cloud infrastructure until you restore service.
|
||||
|
||||
<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>
|
||||
|
||||
## System Architecture
|
||||
|
||||
For a more technical picture of the software components and how they interact, see [System Architecture](/development/system-architecture).
|
||||
@@ -0,0 +1,60 @@
|
||||
---
|
||||
title: "Cloud vs. Self-Hosted"
|
||||
description: "Choose managed Pangolin Cloud or run the same software on your own infrastructure"
|
||||
---
|
||||
|
||||
You can run Pangolin as [Pangolin Cloud](https://app.pangolin.net/auth/signup) or [self-host](/self-host/quick-install) the same open-source software. Sites, resources, and clients work the same way in both. The difference is who operates the server: the control plane, DNS, certificates, and the nodes that terminate tunnels.
|
||||
|
||||
## Pangolin Cloud
|
||||
|
||||
Cloud is the managed control plane. You create an account, install [sites](/manage/sites/install-site) and [clients](/manage/clients/install-client), and define resources. Pangolin runs the dashboard, database, certificates, and globally distributed nodes.
|
||||
|
||||
Use Cloud when you want high availability, automatic updates, and less operational work. You can still keep traffic on infrastructure you control with [remote nodes](/manage/remote-node/understanding-nodes).
|
||||
|
||||
## Self-Hosted
|
||||
|
||||
Self-hosted Pangolin runs on a server you operate. You supply a public IP, a domain, and the listener ports. See [Quick Install](/self-host/quick-install) and [DNS and Networking](/self-host/dns-and-networking). You are responsible for updates, backups, certificates, and uptime.
|
||||
|
||||
Two editions:
|
||||
|
||||
- **Community Edition** is the core platform.
|
||||
- **[Enterprise Edition](/self-host/enterprise-edition)** uses the `ee` image and a license key. It unlocks extra identity, logging, and management features. Compare tiers on the [Self-Hosted pricing page](https://pangolin.net/pricing#Self-Hosted-identity-and-access-management).
|
||||
|
||||
<Check>
|
||||
Enterprise Edition is **free** for personal use and organizations with less than $100,000 USD gross annual revenue. You still need a license key. Larger organizations need a paid license.
|
||||
</Check>
|
||||
|
||||
## Remote Nodes (Hybrid)
|
||||
|
||||
[Remote nodes](/manage/remote-node/understanding-nodes) are a middle path but are part of Pangolin Cloud. You run the node (tunnels, TLS, relay) on your server and bandwidth. Cloud still handles the dashboard, DNS, certificates, and failover. If your node goes down, traffic can fail over to other nodes or cloud points of presence.
|
||||
|
||||
Public TCP/UDP listeners that bind a port on the Pangolin host are a self-hosted-server feature. On Cloud, deploy a remote node for that. See [TCP / UDP](/manage/resources/public/raw-resources).
|
||||
|
||||
## Quick Comparison
|
||||
|
||||
| | Pangolin Cloud | Self-hosted |
|
||||
|---|---|---|
|
||||
| **Control plane** | Managed | You run Pangolin, Traefik, and Gerbil |
|
||||
| **Traffic path** | Cloud nodes, or your [remote nodes](/manage/remote-node/understanding-nodes) | Your server |
|
||||
| **DNS and certificates** | Managed | You configure DNS and Let's Encrypt |
|
||||
| **Updates and backups** | Included | You operate them |
|
||||
| **High availability** | Included | You design it ([clustering](/self-host/clustering/understanding-clustering) on Enterprise) |
|
||||
| **Identity and logs** | Cloud plans | Community core; extra IdPs, streaming, and AI session logs on [Enterprise Edition](/self-host/enterprise-edition) |
|
||||
| **Data residency** | Cloud regions, or traffic on your remote nodes | Entirely on your infrastructure |
|
||||
| **Best for** | Fast start and less ops | Air-gapped networks, full control, compliance that requires self-hosting |
|
||||
|
||||
Cloud and self-hosted plans are listed separately on [pricing](https://pangolin.net/pricing). Click "Self-Hosted" at the top to toggle between deployment options.
|
||||
|
||||
## When to Use Each
|
||||
|
||||
Use **Pangolin Cloud** if you want to start quickly, get HA and certificate management included, and optionally attach remote nodes so tunnel traffic stays on your network.
|
||||
|
||||
Use **self-hosted** if the control plane and data must stay on infrastructure you operate, you need an air-gapped or fully isolated deployment, or you already run Pangolin as Community or Enterprise Edition.
|
||||
|
||||
<Card title="Start on Pangolin Cloud" icon="cloud" href="https://app.pangolin.net/auth/signup" arrow="true" cta="Sign up">
|
||||
Managed control plane. Install sites and clients, then define resources.
|
||||
</Card>
|
||||
|
||||
<Card title="Self-host Pangolin" icon="server" href="/self-host/quick-install">
|
||||
Install Community Edition or Enterprise Edition with the quick installer.
|
||||
</Card>
|
||||
@@ -0,0 +1,76 @@
|
||||
---
|
||||
title: "Pangolin vs. Bifrost vs. LiteLLM"
|
||||
description: "What are the similarities and differences between Pangolin's AI Gateway and traditional LLM gateways like Bifrost and LiteLLM?"
|
||||
---
|
||||
|
||||
Pangolin's [AI Gateway](/manage/ai/overview) does the work you would expect from a traditional LLM gateway: one URL in front of many providers, model routing, usage tracking, and access control. The difference is how it is built. It is a protocol-aware Pangolin resource, so identity, tunnels, and governance are the same system you already use for HTTPS and SSH.
|
||||
|
||||
## Why Use a Gateway
|
||||
|
||||
Coding agents and AI clients want a provider URL and a key. If every laptop holds the org's OpenAI, Anthropic, or Gemini key, you cannot tell who spent what, you cannot limit which models a contractor may call, and rotating a leaked key means touching every machine.
|
||||
|
||||
An AI gateway sits in front of those upstream APIs. Clients call the gateway. The gateway authenticates the caller, picks a provider and model, records usage, and forwards the request with the org's real key. LiteLLM and Bifrost are dedicated products for that job. Pangolin does it as an identity-aware resource on the same platform as the rest of your application and infrastructure access.
|
||||
|
||||
## A Protocol-Aware Resource
|
||||
|
||||
An [AI Gateway resource](/manage/ai/overview) is not a separate stack. It is a Pangolin resource type, the same way HTTP/HTTPS is a type for web apps and SSH is a type for terminals.
|
||||
|
||||
Pangolin already inspects HTTPS to apply identity, access rules, [request logs](/manage/analytics/request), and analytics. An AI Gateway resource does the equivalent for model APIs. Because it understands the LLM protocol, it can attribute each call to a user, record [cost and token usage](/manage/ai/usage-analytics), keep [chat session history](/manage/ai/session-logs), and enforce who can use which [models](/manage/ai/providers/model-routing) and [budgets](/manage/ai/budgets).
|
||||
|
||||
That is the justification in Pangolin terms: an identity-aware gateway, not only a model router.
|
||||
|
||||
## What Each Solution Provides
|
||||
|
||||
**[LiteLLM](https://docs.litellm.ai)** is a dedicated LLM proxy. It presents a unified API in front of many model providers, with virtual keys, spend tracking, fallbacks, and load balancing. Teams often run it as a self-hosted proxy or use its SDK inside applications.
|
||||
|
||||
**[Bifrost](https://www.getmaxim.ai/bifrost)** is a dedicated LLM gateway focused on complex routing rules, failover, and performance. For example, you can use it to route requests to different models based on the user's location or the request's content. You can also run it downstream of Pangolin as a [Custom provider](/manage/ai/providers/custom/bifrost) when Pangolin should authenticate callers and Bifrost should pick models.
|
||||
|
||||
**Pangolin** provides the same gateway job as a [protocol-aware resource](/about/how-pangolin-works#ai-gateway). Providers, model lists, [virtual API keys](/manage/ai/virtual-api-keys) on public resources, budgets, and session logs are all there. Identity comes from Pangolin users, roles, and (for private AI gateway resources) the [desktop client](/manage/clients/install-client). Site and client tunnels are how you reach self-hosted models and how you keep provider keys off laptops.
|
||||
|
||||
## Identity-Aware Gateway
|
||||
|
||||
Access follows the resource. You grant [users and roles](/manage/access-control/create-user) the same way you do for other Pangolin resources. Pangolin then decides which models that identity may call and whether a [budget](/manage/ai/budgets) still allows the request.
|
||||
|
||||
On a [public AI Gateway](/manage/resources/public/ai-gateway), coding agents send a [virtual API key](/manage/ai/virtual-api-keys). Pangolin identity keys identify the user; you grant the user or role, not the key.
|
||||
|
||||
On a [private AI Gateway](/manage/resources/private/ai-gateway), the [Pangolin client](/manage/clients/install-client) running on the end user's device already authenticated that user. Coding agents on that device call over the tunnel fully privately. Pangolin attributes the request to the connected identity. That eliminates provider API keys on the laptop: the upstream key never leaves the provider.
|
||||
|
||||
## Virtual API Keys
|
||||
|
||||
On other gateways you mint a key for each person, then keep track of who holds which key and which models that key may call. Pangolin [virtual API keys](/manage/ai/virtual-api-keys) work the other way around.
|
||||
|
||||
Every user already has an **identity key**. You do not grant the key access to the gateway. You grant the [user or role](/manage/access-control/create-user) access to the AI Gateway resource and its models. The key only identifies the caller as that user. When you change who is on the resource, the key follows. You do not manage a key inventory as the source of access.
|
||||
|
||||
Users retrieve their own key:
|
||||
|
||||
- Log in at the public gateway URL in a browser, using Pangolin or their [identity provider](/manage/identity-providers/add-an-idp). After login, Pangolin presents the key.
|
||||
- Open the Resource Launcher, pick the resource, and copy the key. The launcher also shows which models they can use and how to configure a coding agent to use the key.
|
||||
- Admins can [email keys](/manage/ai/virtual-api-keys#email-keys-to-users) to users.
|
||||
|
||||
You can still mint **manual keys**, the same way other gateways issue arbitrary virtual keys. Use those for services, machines, CI, or a person if you want a key that is not tied to resource grants. Creating the key grants access to the public gateways you scope it to. See [Identity Keys vs Manual Keys](/manage/ai/virtual-api-keys#identity-keys-vs-manual-keys).
|
||||
|
||||
## Tunneling
|
||||
|
||||
Tunneling is a Pangolin strength, on both sides of the network.
|
||||
|
||||
### Sites: Self-Hosted Models on Remote Networks
|
||||
|
||||
A [site connector](/manage/sites/understanding-sites) sits on the network where [Ollama](/manage/ai/providers/custom/ollama), [vLLM](/manage/ai/providers/custom/vllm), or another model server already runs. [Custom providers](/manage/ai/providers/custom) use **Site Targets** so the gateway reaches that API over the tunnel. The model host does not need a public IP or an inbound port. Pangolin can also call cloud providers from the node, so one resource can mix hosted APIs and self-hosted models.
|
||||
|
||||
You can put LiteLLM or Bifrost on that same site network and attach them as a Custom provider. Pangolin authenticates; the downstream gateway routes.
|
||||
|
||||
### Clients: Remote Access Without Provider Keys
|
||||
|
||||
Users connect with the Pangolin client, then reach a private AI Gateway the same way they reach a private host or SSH resource. That is how someone on a laptop uses a self-hosted model on a remote network, or a cloud provider, without holding the upstream key. The client connection is the credential so you don't need to distribute virtual API keys to users.
|
||||
|
||||
## When to Use Each Solution
|
||||
|
||||
Use **LiteLLM** if you want a dedicated Python proxy or SDK in front of many providers, and you already have a network path and your own identity layer.
|
||||
|
||||
Use **Bifrost** if you want a dedicated high-performance LLM gateway for routing and failover. You can run it on its own, or behind Pangolin as a [Custom provider](/manage/ai/providers/custom/bifrost).
|
||||
|
||||
Use **Pangolin** if you want LLM access as an identity-aware resource: the same users and roles as the rest of Pangolin, site tunnels to self-hosted models, and client tunnels that authenticate and govern usage at the edge so provider keys stay off devices.
|
||||
|
||||
<Card title="AI Gateway Overview" icon="sparkles" href="/manage/ai/overview">
|
||||
Set up providers, resources, and identity-based access for coding agents and AI clients.
|
||||
</Card>
|
||||
@@ -0,0 +1,77 @@
|
||||
---
|
||||
title: "Pangolin vs. Proxy vs. VPN"
|
||||
description: "What are the similarities and differences between Pangolin and traditional reverse proxies and VPNs?"
|
||||
---
|
||||
|
||||
Pangolin combines the capabilities of both a reverse proxy and a VPN into a single platform. It provides reverse proxy functionality through public resources and VPN functionality through private resources, all with zero-trust access control and distributed architecture.
|
||||
|
||||
## 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. They are usually protocol-aware of HTTPS only.
|
||||
|
||||
**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](/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 |
|
||||
|------------|--------------------------|-----------------|----------|
|
||||
| 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 |
|
||||
| No open inbound ports | No | Sometimes | Yes — outbound site tunnels |
|
||||
| TLS at the network edge (private) | No | No | Yes — [private HTTP/HTTPS](/manage/resources/private/private-http) |
|
||||
| Multi-site routing and failover | Uncommon | Uncommon | Yes — automatic site selection |
|
||||
|
||||
## Reverse Proxy Capabilities
|
||||
|
||||
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 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.
|
||||
|
||||
**TCP and UDP** resources bind to a port on the Pangolin server for raw protocol proxying when you need a public pipe without a domain name or auth layer.
|
||||
|
||||
Unlike traditional reverse proxies, Pangolin does not require public IP addresses or open ports on your network. Sites create outbound tunnels to Pangolin, so your applications remain behind firewalls.
|
||||
|
||||
## VPN Capabilities
|
||||
|
||||
Pangolin's private resources function like a zero-trust VPN—but with tighter scope than a traditional VPN.
|
||||
|
||||
**Host and CIDR** resources route traffic to specific machines or subnets over the tunnel. Users only reach what you explicitly grant them, with optional per-resource port restrictions—not an entire flat network.
|
||||
|
||||
**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](/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.
|
||||
|
||||
## Why Pangolin Combines Both
|
||||
|
||||
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 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.
|
||||
|
||||
## Infrastructure and Availability
|
||||
|
||||
Traditional reverse proxies and VPNs typically run on a single server. If that server fails, all access is lost. They also require public IP addresses and open ports, which adds complexity and security concerns.
|
||||
|
||||
Pangolin uses a distributed architecture with multiple nodes. If one node fails, traffic automatically routes to another node. Sites create outbound tunnels, so your networks do not need public IP addresses or open ports.
|
||||
|
||||
When a resource is reachable from multiple site connectors, Pangolin selects the healthiest path based on latency and availability—users connect to the resource, not to a specific site. You can deploy multiple remote nodes for high availability. If your nodes become unavailable, traffic can optionally fail over to cloud infrastructure until you restore service.
|
||||
|
||||
## When to Use Each Solution
|
||||
|
||||
Use a traditional reverse proxy if you only need to expose web applications over HTTP/HTTPS, you have a public IP address, and you do not need advanced access control or high availability.
|
||||
|
||||
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, 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.
|
||||
Reference in New Issue
Block a user