Pangolin 1.22: AI Gateway for Cloud and Self-Hosted Models
Pangolin 1.22 is here. This release introduces AI Gateway: an identity-aware proxy in front of both public cloud APIs (OpenAI, Anthropic, Gemini, etc.) and self-hosted model servers (Ollama, vLLM, Mistral, etc.), so coding agents and AI clients call a Pangolin URL. You can publish that URL as a public resource with personal virtual API keys, or keep it private on the Pangolin client tunnel, where the connected client is the credential. The Pangolin client eliminates the need for API keys for authentication. Budgets, session history, and usage analytics sit in front of every call. 1.22 also brings SSH, RDP, and VNC public resources to Community Edition, along with SSH and HTTPS private resources. Let's walk through it.
Release Highlights
AI Gateway
An AI Gateway is a new type of Pangolin resource that works like an HTTPS resource: it gets a domain, sits behind Pangolin's reverse proxy, and uses the same users, roles, and identity. The difference is what it proxies. Instead of forwarding browser traffic to HTTP targets, it speaks the API formats of the providers you attach (Chat Completions, Anthropic Messages, Gemini generateContent, and others) and forwards each request to the matching upstream.
Coding agents and AI clients already expect an API URL and a key. Point them at Pangolin instead of at OpenAI, Anthropic, Gemini, Ollama, or vLLM, and the organization keeps the real upstream secrets, decides who can call which models, and sees what ran.
Cloud and Self-Hosted Models
Pangolin is built around self-hosting, so AI Gateway has first-party support for models you run yourself: Ollama and vLLM on your own hardware, including machines like a DGX Spark. Mix those with existing cloud providers such as Anthropic, OpenAI, and others on the same gateway.
Configure OpenAI, Anthropic, Google Gemini, Amazon Bedrock, Vertex AI, Microsoft Foundry, OpenRouter, or Vercel AI Gateway once per organization. That centralizes each provider's API key (your OpenAI key, Anthropic key, and the rest) on the provider itself, instead of copying it into env files or sharing it across the organization.
Self-hosted models use the same provider object. Create a Custom provider for Ollama, vLLM, Bifrost, or any other endpoint, pick the API capabilities it speaks, and point it at the endpoint URL. The distinctive Pangolin piece is sites. Install a site connector on the network that runs the model server, then add Site Targets on the provider's Network tab. The gateway reaches that API over the tunnel, the same way a public HTTPS resource reaches an internal app. The model server stays on the private network protected by Pangolin's reverse proxy which is how remote users and agents get to it.
You can attach cloud and self-hosted providers on the same resource. One URL can serve Claude from Anthropic, GPT from OpenAI, and a local Llama from Ollama. Allow and block lists on the provider, plus inherit-or-select on the resource, decide which models each gateway exposes.
Read more about custom providers, Ollama, and vLLM in the docs.
Public and Private Gateways
AI Gateway resources can either be public or private.
A public AI Gateway resource gets a fully qualified domain name. Coding agents and AI clients anywhere call that URL and send a virtual API key on every request. Pangolin checks the key, attributes the call to a user or a named key, and forwards to the selected provider with the real upstream secret. The provider key never leaves Pangolin.
A private AI Gateway resource is reachable only on devices connected with the Pangolin client. Nothing is published to the internet and authentication is keyless because the connected client is the credential.
You can run both. A public gateway for contractors, services, and machines that are not on the overlay. A private gateway for staff whose machines already run the Pangolin client. Multiple gateway resources can also split providers and model lists by role: staff get OpenAI and Anthropic, contractors get a tighter set.
Read more about public and private AI Gateway resources in the docs.
Keyless Authentication with the Pangolin Client
If the Pangolin client is already on the machine, you should not have to mint another secret for Claude Code or Codex. Private AI Gateway resources authenticate with that client session.
The user (or a machine identity) connects with the Pangolin client. The overlay already proved who they are, the same way it does for private HTTPS and SSH. Grant users, roles, or machines on the resource, then point the coding agent at the private gateway URL. Pangolin attributes the call to the connected user and forwards it upstream, including Remote-* identity headers when the client maps to a person.
Some agents still expect something in the API key field. For example, Codex and Claude Code require a key to be set. Use the literal string none:
{
"apiKeyHelper": "echo 'none'",
"env": {
"ANTHROPIC_BASE_URL": "https://ai.internal.example.com"
}
}
The Pangolin CLI can automate that config. Run pangolin configure claude or pangolin configure codex and it writes the client's settings file, so you do not edit it by hand. Most clients will not start if it is missing, and they will send traffic to the real provider instead of through Pangolin.
Read more about private AI Gateway resources in the docs.
Identity Keys and How You Distribute Them
Every organization user already has an identity key. It is unique to their account and authenticates them as that user. Access follows Users and Roles on the public AI Gateway resource, the same pattern as a public HTTPS resource. When the user is known, Pangolin forwards that identity upstream as Remote-* headers. Keys look like this:
pangolin-key-os27sbax.f3asds4wivpvdqgwjp7j5taaor4m
Admins can email identity keys from AI Gateway → Virtual API Keys, either to everyone or to specific users and roles. The email includes the key and the public gateway URLs to call. People can also copy their own key by logging in at the resource URL in their browser, opening the Resource Launcher, or visiting Your API Keys via https://<dashboard-url>/<org-id>/keys.
For services, machines, and shared agents that should not depend on a person's resource grants, create a manual key. Scope it to selected public gateways or to every public gateway in the org, optionally associate a user for tracking, and email it on generation.
Read more about virtual API keys in the docs.
Budgets, Analytics, and Session Logs
Set a cap in USD or tokens on a provider, a model, a resource, a role, or a virtual API key. Pangolin checks every matching enabled budget before it forwards a request. If any one is already at its maximum, the call is blocked.
Usage analytics rolls up cost, tokens, and request volume across those same dimensions. Filter by provider, model, resource, role, user, and key. The numbers come from the same recorded usage that budgets enforce.
Session logs store the prompt and response for each call, with filters by provider, model, user, key, and resource. Expand a row for the transcript or raw JSON. Session logs are available in Pangolin Cloud and self-hosted Enterprise Edition.
Read more about budgets, usage analytics, and session logs in the docs.
Connecting Coding Agents
Each AI Gateway resource has ready-to-copy setup for common clients. The Pangolin CLI can write the config for you:
pangolin configure claude
pangolin configure codex
That picks the organization and resource, fetches a key when the resource needs one, and writes the client's settings file. The same identity key, or the same connected client session on a private resource, works across those tools.
You can also configure a client by hand. For Claude Code, put this in ~/.claude/settings.json:
{
"apiKeyHelper": "echo 'pangolin-key-os27sbax.f3asds4wivpvdqgwjp7j5taaor4m'",
"env": {
"ANTHROPIC_BASE_URL": "https://ai-gateway.example.com"
}
}
There are setup guides for Claude Code, Codex, OpenCode, and Gemini CLI, plus Open WebUI, Claude Desktop, and OpenClaw.
Start from the AI Gateway overview. Provider types, capabilities, and model routing are covered under AI Providers.
SSH, RDP, VNC, and Private HTTPS in Community Edition
Browser-based SSH, RDP, and VNC shipped in Pangolin 1.19 as Enterprise features. 1.22 unlocks them for Community Edition as public resources.
Users visit a public FQDN, complete Pangolin authentication, and get a full interactive session in the browser: a web terminal for SSH, a Windows remote desktop for RDP with clipboard and file transfer, a remote display for VNC. You manage them as public resources next to HTTP, with the same users, roles, SSO, and access rules.
Private resources get SSH and HTTPS in Community Edition too. With the Pangolin client connected, you can SSH over the tunnel with pangolin ssh and open internal apps at a real HTTPS hostname on the overlay. Those client-based resource types were Enterprise-only, but they are in Community Edition now too.
Pangolin SSH mode is still the default when you create an SSH resource: sessions run through the site connector, so you configure the resource in the dashboard rather than standing up OpenSSH on the host. Standard SSH Server mode remains when you need to reach an existing OpenSSH daemon.
Guides: SSH in the Browser, RDP in the Browser, VNC in the Browser, and How to SSH with Pangolin. Docs: public SSH, RDP, VNC, private SSH, and private HTTPS.
Certificate Status in Community Edition
Public resources now show certificate validity in Community Edition, including the Valid badge on the resource page. You can see whether TLS for a hostname is in good shape from the same place you already manage the resource.
General Improvements and Bug Fixes
A few smaller additions made it into 1.22 as well:
- Mock-test an alert action. From the alert rule editor, send a test notification so you can confirm email and webhook actions before the rule fires on a real event.
- Resource labels in blueprints. Attach labels when you define resources in YAML or container labels. See Blueprints.
- Log table fixes. Log retention now reads the correct organization setting, and refresh buttons on logs tables fetch a new date as expected.
As always, this release also includes various UI improvements and bug fixes throughout the product.
Pangolin is an open-source infrastructure company that provides secure, zero trust remote access for teams of all sizes. Built to simplify user workflows and protect critical systems, Pangolin helps companies and individuals connect to their networks, applications, and devices safely without relying on traditional VPNs. With a focus on device security, usability, and transparency, Pangolin empowers organizations to manage access efficiently while keeping their infrastructure secure.
Keep reading
- Pangolin 1.20: Resource Launcher & Global Command Palette
- Comparison - Pangolin vs. Zscaler
Comparison - Pangolin vs. ZscalerHow a self-hostable open-source access platform and an enterprise cloud security suite differ in architecture, traffic routing, deployment, and fit.
Product - Comparison - Pangolin vs. NetBird
Comparison - Pangolin vs. NetBirdA comparison of two WireGuard-powered remote access solutions and their differences in architecture, permissions, and use cases.
Product
