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

port mintlify to fumadocs

Browse Source
This commit is contained in:
miloschwartz
2026-09-25 15:31:51 -04:00
parent dc54fb1017
commit 63199a588c
373 changed files with 13533 additions and 4577 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/docs/development/contributing.mdx
+326
View File
@@ -0,0 +1,326 @@
---
title: "Contribution Guide"
description: "Set up your local development environment for contributing to Pangolin"
---
This guide describes how to set up your local development environment for contributing to Pangolin. We recommend using Docker Compose for the most consistent development experience across different environments.
## Prerequisites
- Node 24
- NPM 11 or similar
- Go 1.25
- Git
- Docker & Docker Compose
- Python (for NPM builds)
- Make
- G++
<Info>
For managing multiple versions of Go, you may want to use [gvm](https://github.com/moovweb/gvm).
For managing multiple versions of NodeJS, you may want to use [nvm](https://github.com/nvm-sh/nvm).
</Info>
## Setup Your Repository
Below is an example if you're working on the Pangolin repository.
<Steps>
<Step title="Fork and clone">
[Fork](https://help.github.com/articles/fork-a-repo/) the repository(ies) to your own GitHub account and [clone](https://help.github.com/articles/cloning-a-repository/) to your local device:
```bash
git clone https://github.com/YOUR_USERNAME/pangolin.git
cd pangolin/
```
</Step>
<Step title="Add upstream remote">
Add the remote `upstream`:
```bash
git remote add upstream https://github.com/fosrl/pangolin.git
```
</Step>
<Step title="Create feature branch">
Create a new branch:
```bash
git checkout -b BRANCH_NAME dev
```
It is recommended to give your branch a meaningful name, relevant to the feature or fix you are working on.
**Good examples**:
- `docs-docker`
- `feature-new-system`
- `fix-title-cards`
**Bad examples**:
- `bug`
- `docs`
- `feature`
- `fix`
- `patch`
</Step>
<Step title="Open pull request">
If you open a pull request, open it against the `dev` branch of the original repository.
</Step>
</Steps>
## Important Best Practices for PRs
- **Keep PRs small and single-purpose**: One feature, fix, or improvement per PR for easier review and testing.
- **Prefer improvements over new features**: If you want to propose a net-new feature, contact us by email or on Discord first so we can confirm it fits the roadmap and help scope it.
- **Frontend consistency**:
- Use existing styles, components, and patterns.
- Use Credenza for modals and Zod for form validation.
- Keep Tailwind classes minimal; prefer component defaults.
- Look for an existing example and mirror that pattern. Extract a small reusable component only when it clearly improves reuse.
- **Stick to established patterns**: Avoid introducing new architectures or abstractions without discussing them with us first.
- **Auth changes require extra care**:
- Pangolin is multi-tenant. Handle user controls at the org level (varies by control) or globally via the server admin panel as appropriate.
- Protect all API routes with the correct middleware and verify user permissions and access to referenced entities before performing actions.
- **Database changes**:
- Keep SQLite and Postgres schemas fully in sync and backward compatible.
- Use datatypes supported by both databases.
- No need to write versioned migrations; maintainers will handle these during releases.
- **Add visuals**: Include screenshots or short videos when applicable to speed up reviews.
## Databases
Pangolin supports two database types: SQLite and Postgres. You can switch between them with the provided scripts:
Before running these, read local development setup below.
```bash
npm run set:sqlite
# or
npm run set:pg
```
After switching, regenerate and apply the schema using the matching scripts for that database. Keep both SQLite and Postgres schemas fully in sync and backward compatible.
## Private Files and Directories
Pangolin includes both AGPLv3 code and some proprietary code licensed under the Fossorial Commercial License. Proprietary files include a license header and often live in directories whose names start with `private`.
You may edit proprietary files in your PR as long as your PR includes the required CLA.
- Frontend: no proprietary code.
- Backend: proprietary code exists, primarily under `server/private/`. Subdirectories mirror the structure under `server/`.
To keep the AGPLv3 distribution fully compliant, be careful about imports:
- AGPLv3 files must never import from the private directory. In TypeScript, the alias `#private/` points to proprietary code and should only be used inside other private files.
- If you must expose proprietary behavior to AGPLv3 code, use a dynamic import pattern. Create a file that mirrors the proprietary file’s relative location between `server/private` and `server`, and ensure the exported APIs have exactly matching function signatures. Dynamic import aliases start with `#dynamic`.
- At build time, depending on the build flag, `#dynamic` imports are resolved to the appropriate implementation (AGPLv3 or proprietary).
Build flags control which distribution you are working on: `oss`, `enterprise`, or `saas`. Enterprise and SaaS include proprietary code; OSS must be 100% AGPLv3 compliant and excludes proprietary code. Use the existing npm scripts to switch:
```bash
npm run set:oss
# or npm run set:enterprise
# or npm run set:saas
```
Switching distributions updates TypeScript path aliases so `#dynamic` resolves to the correct locations. The build flag is also used in code to conditionally enable or disable features per distribution.
As a rule of thumb, write as much AGPLv3 code as possible. Place only core, distribution-specific functionality in the proprietary layer (Enterprise/SaaS).
Database schemas are never proprietary; all distributions share the same schemas.
If you have any questions about this setup, email us or reach out on Discord.
## Pangolin Development Setup
Choose your preferred development approach. We strongly recommend Docker Compose for the most consistent experience across all platforms.
### Local Development
<Steps>
<Step title="Install dependencies">
Install package dependencies:
```bash
npm install
```
</Step>
<Step title="Configure environment">
Ensure you have a `config/` directory at the root with a `config.yml` inside. Refer to the [Pangolin Configuration docs](/self-host/advanced/config-file) or the `config.example.yml` in the repo for a sample of what to include in that file.
<Warning>
You may need to tweak this to run in dev, such as setting the `dashboard_url` to `http://localhost:3002`.
</Warning>
</Step>
<Step title="Set your environment">
Choose to build from the oss/enterprise/saas codebase:
```bash
npm run set:oss
# or npm run set:enterprise
# or npm run set:saas
```
Then choose your database:
```bash
npm run set:sqlite
# or npm run set:pg
```
</Step>
<Step title="Generate database schema">
Generate the database schema and push it:
```bash
npm run db:generate
npm run db:push
```
</Step>
<Step title="Start development server">
Start the development server using Docker Compose:
```bash
docker compose up --build
```
Or, start the development server directly:
```bash
npm run dev
```
</Step>
</Steps>
## Exit Nodes
When running Pangolin for the first time there will be no exit nodes. This means that there have been no Gerbil "exit nodes" registered in the database, and therefore, you cannot create Newt sites. When Gerbil first starts up and requests its config from Pangolin for the first time it gets registered as an exit node.
The easiest way to resolve this is to run Gerbil and have it register in your dev environment. Download the Gerbil binary and run it with localhost:
```bash
./gerbil \
--reachableAt=http://localhost:3004 \
--generateAndSaveKeyTo=/var/config/key \
--remoteConfig=http://localhost:3001/api/v1/
```
Or enter in a dummy exit-node manually to the database:
```
INSERT INTO "exitNodes" (
"name",
"address",
"endpoint",
"publicKey",
"listenPort",
"reachableAt",
"type"
)
VALUES (
'exit-node-1',
'10.0.0.1/24',
'gerbil.pangolin.net',
'abc123',
1234,
'gerbil.pangolin.net',
'gerbil'
);
```
## Windows Development Considerations
<Warning>
Windows users with Docker Desktop + WSL2: File change detection may not work properly when project files are stored on the Windows filesystem.
</Warning>
<Tabs>
<Tab title="WSL2 Filesystem (Recommended)">
**Best performance and compatibility**
- **Where to store your project files:**
- For best performance, always store your project inside the Linux filesystem of your Docker or Default WSL2 instance, e.g. `/home/<user>/pangolin`.
- If other WSL instances are used, ensure the Docker Desktop WSL integration is enabled for that distribution.
- For further information, see Link Section below.
- **Accessing WSL2 files from Windows:**
- You can access your WSL2 home directory from Windows using the UNC path: `\\wsl$\<DistroName>\home\<user>\pangolin` (replace `<DistroName>` with your actual WSL distribution, e.g. `Ubuntu-22.04`).
- This path works in Windows Explorer, VS Code, and other Windows applications. You can drag & drop files, create shortcuts, or map a network drive for convenience.
- **Note:** This UNC path is for Windows tools only. Do not use it for Docker container mounts.
- **How to mount WSL2 files in Docker containers:**
- Always use the absolute Linux path from inside WSL2 for Docker volumes. This is the only method fully supported and recommended by Docker.
- **Correct Docker Compose example:**
```yaml
services:
app:
volumes:
- /home/<user>/pangolin:/app
```
- **Correct docker run example:**
```bash
docker run -v /home/<user>/pangolin:/app my-image
```
- **Never use `\\wsl$` or Windows paths** (e.g. `/mnt/c/...`) for Docker volumes when running with the WSL2 backend. This is not supported and can lead to poor performance or errors.
- File watchers and hot reload works natively when your project is inside the WSL2 filesystem and mounted using the Linux path.
<Note> You may want to use the [VS Code Remote - WSL extension](https://code.visualstudio.com/docs/remote/wsl) or [VS Code Remote - SSH Extension](https://code.visualstudio.com/docs/remote/ssh) to open your project folder directly in VSCode from the WSL/Remote Filesystem for seamless Development. </Note>
**Reference Links**
- [WSL Docker Best Practices](https://docs.docker.com/desktop/features/wsl/best-practices/)
- [Use WSL for Development](https://docs.docker.com/desktop/features/wsl/use-wsl/)
- [WSL2 Setup](https://docs.docker.com/desktop/features/wsl/)
</Tab>
<Tab title="Windows Filesystem + Polling (Workaround)">
If you need to keep your files on the native Windows filesystem (`C:\Users\...`), enable **Polling Mode** for file watchers.
Enable polling mode by adding the following environment variables to your `docker-compose.yml` or `.env` file:
For `.env`:
```env
WATCHPACK_POLLING=true
CHOKIDAR_USEPOLLING=true
```
For `docker-compose.yml`:
```yaml
environment:
- WATCHPACK_POLLING=true
- CHOKIDAR_USEPOLLING=true
```
<Note>This increases CPU usage but ensures file watchers work properly. Polling mode is not required when working directly on the WSL filesystem.</Note>
</Tab>
</Tabs>
## Component Development
### Gerbil
- Go 1.25
```bash
make local
```
### Newt
- Go 1.25
```bash
make local
```
### Olm
- Go 1.25
```bash
make local
```
content/docs/development/feature-requests-and-bug-reports.mdx
+114
View File
@@ -0,0 +1,114 @@
---
title: "Feature Requests & Bug Reports"
description: "How to submit feature requests and report bugs for Pangolin"
---
We welcome contributions from the community to help improve Pangolin. To ensure your feedback is properly tracked and prioritized, use the repository that matches the component where your issue or request belongs.
## Pick the Right Repository
Pangolin is made up of multiple components. To get the fastest response, file your request or bug report in the repository that matches what you're using.
### Server Components
<CardGroup cols={2}>
<Card title="Pangolin" icon="server" href="https://github.com/fosrl/pangolin">
Dashboard and core platform.
[Discussions](https://github.com/fosrl/pangolin/discussions) and [Issues](https://github.com/fosrl/pangolin/issues).
</Card>
<Card title="Newt" icon="plug" href="https://github.com/fosrl/newt">
Site and network connector.
[Issues](https://github.com/fosrl/newt/issues).
</Card>
<Card title="Gerbil" icon="circle-nodes" href="https://github.com/fosrl/gerbil">
WireGuard interface management service.
[Issues](https://github.com/fosrl/gerbil/issues).
</Card>
</CardGroup>
### User Clients
<CardGroup cols={2}>
<Card title="Windows App" icon="desktop" href="https://github.com/fosrl/windows">
Pangolin desktop application for Windows.
[Issues](https://github.com/fosrl/windows/issues).
</Card>
<Card title="Android App" icon="desktop" href="https://github.com/fosrl/android">
Pangolin mobile application for Android.
[Issues](https://github.com/fosrl/android/issues).
</Card>
<Card title="Apple Apps" icon="desktop" href="https://github.com/fosrl/apple">
Pangolin application for macOS, iOS, and iPadOS.
[Issues](https://github.com/fosrl/apple/issues).
</Card>
<Card title="Pangolin CLI" icon="desktop" href="https://github.com/fosrl/cli">
Pangolin CLI client for Linux and macOS environments.
[Issues](https://github.com/fosrl/cli/issues).
</Card>
</CardGroup>
## Feature Requests
We encourage you to submit feature requests in the [GitHub Discussions section](https://github.com/fosrl/pangolin/discussions) of the Pangolin repository. This allows the community to:
- **Upvote features** they want to see implemented
- **Provide feedback** and suggestions on proposed features
- **Discuss implementation details** and alternatives
- **Help prioritize** which features to work on next
<Note>
Feature requests with community support (upvotes and positive feedback) are more likely to be prioritized for development.
</Note>
## Bug Reports
Bug reports should be submitted in GitHub Issues for the relevant repository:
### Server Components
- **Pangolin**: [fosrl/pangolin/issues](https://github.com/fosrl/pangolin/issues)
- **Newt**: [fosrl/newt/issues](https://github.com/fosrl/newt/issues)
- **Gerbil**: [fosrl/gerbil/issues](https://github.com/fosrl/gerbil/issues)
### User Clients
- **Windows App**: [fosrl/windows/issues](https://github.com/fosrl/windows/issues)
- **Android App**: [fosrl/android/issues](https://github.com/fosrl/android/issues)
- **Apple Apps**: [fosrl/apple/issues](https://github.com/fosrl/apple/issues)
- **Pangolin CLI**: [fosrl/cli/issues](https://github.com/fosrl/cli/issues)
- **Olm**: [fosrl/olm/issues](https://github.com/fosrl/olm/issues)
Using the correct repo ensures:
- **Proper tracking** of bugs through their lifecycle
- **Developer visibility** for quick resolution
- **Version tracking** and regression testing
- **Duplicate detection** and consolidation
<Warning>
Please provide as much detail as possible to help developers reproduce and fix the issue quickly.
</Warning>
## Before Submitting
- Search existing discussions and issues to avoid duplicates
- Provide clear, detailed information
- Include steps to reproduce (for bugs)
- Test on the latest version of Pangolin
- Check if the issue is environment-specific
## Alternative Channels
<CardGroup cols={2}>
<Card title="Security Issues" icon="shield">
For security vulnerabilities, please email security@pangolin.net instead of posting publicly.
</Card>
<Card title="General Questions" icon="question">
For general questions, use [GitHub Discussions](https://github.com/fosrl/pangolin/discussions) with the "Q&A" category, or come chat with us on [Discord](https://pangolin.net/discord).
</Card>
</CardGroup>
content/docs/development/system-architecture.mdx
+178
View File
@@ -0,0 +1,178 @@
---
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.
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.
<Frame caption="High-level Pangolin architecture">
<img src="/images/system-diagram.png" alt="Pangolin system architecture diagram"/>
</Frame>
## Control Plane
The control plane is the Pangolin server application. It stores organization state in a database, exposes the dashboard and REST API, handles authentication and authorization, and pushes configuration to every node, site connector, and client in real time over WebSocket.
Responsibilities include:
- **Policy and identity** — users, roles, clients, machines, and access rules that determine which resources each principal can reach
- **Resource and site definitions** — targets, destinations, routing preferences, certificates, and health-check configuration
- **Orchestration** — coordinates tunnel peers, DNS records, and ingress routes as you create or change resources
- **Telemetry** — connection state, relay status, and operational signals surfaced in the dashboard
You can run the control plane yourself ([self-hosted](/self-host/quick-install)) or use [Pangolin Cloud](https://app.pangolin.net/auth/signup), where the control plane is fully managed. In both cases, the same orchestration model applies: connectors and nodes pull config from the control plane rather than accepting inbound management connections.
## Nodes
A **node** is the networking edge of your Pangolin deployment. It terminates inbound traffic from the public internet, manages WireGuard tunnels, and relays client traffic when a direct peer path is unavailable.
On a self-hosted deployment, your Pangolin server runs as a single node by default. [Enterprise clustering](/self-host/clustering/understanding-clustering) spreads multiple nodes behind a load balancer with shared database state. On [Pangolin Cloud](/manage/remote-node/understanding-nodes), you can add **remote nodes**: infrastructure you operate that still receives configuration from the cloud control plane.
Each node runs several cooperating processes:
| Role | Engineering codename | What it does |
| --- | --- | --- |
| Ingress / reverse proxy | Traefik | Terminates TLS, routes HTTP(S) and protocol-aware public resources, and forwards authenticated requests into the tunnel fabric |
| Tunnel manager | Gerbil | Maintains WireGuard peers for site connectors and clients, performs SNI-based routing, and relays UDP when hole punching fails |
| Auth middleware | Badger | Traefik plugin that enforces Pangolin authentication on public resources via forward auth |
The control plane writes certificates, Traefik router definitions, and WireGuard peer lists that these processes consume. Nodes do not need direct database access from site connectors; they only need reachability to the control plane and open listener ports on the public side.
<CardGroup cols={2}>
<Card title="DNS and port requirements" icon="network-wired" href="/self-host/dns-and-networking">
Required listener ports, firewall rules, and DNS records for a node.
</Card>
<Card title="Clustering for high availability" icon="server" href="/self-host/clustering/understanding-clustering">
Multi-node Enterprise deployments with shared state and failover.
</Card>
<Card title="Remote nodes on Pangolin Cloud" icon="circle-nodes" href="/manage/remote-node/understanding-nodes">
Run your own node while using the cloud control plane for management.
</Card>
</CardGroup>
## Site Connectors
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 is a **Pangolin Site**. The site opens:
1. A **WebSocket** to the control plane for configuration, health, and coordination
2. A **WireGuard** tunnel to the node's tunnel manager (Gerbil) for encrypted data traffic
Site connectors are deny-by-default proxies. Deploying one does not expose hosts on the network; traffic is forwarded only for [resources](/manage/resources/understanding-resources) you define and grant access to. The connector resolves backend targets on the remote network and delivers packets there.
Pangolin Sites support the full feature set: public and private resources, protocol-aware proxies, multi-site routing, health checks, and edge TLS for private HTTP. Other connector types ([local](/manage/sites/understanding-sites#local-site) and [basic WireGuard](/manage/sites/understanding-sites#basic-wireguard-site)) exist for specialized self-hosted cases.
<Card title="Understanding sites" icon="plug" href="/manage/sites/understanding-sites">
Site types, deployment models, and connector capabilities.
</Card>
## Clients
**Clients** are endpoint agents on user devices or machines. They authenticate to the control plane, receive an access control list, and establish WireGuard tunnels so users can reach [private resources](/manage/resources/understanding-resources#private-resource-types).
Two client classes share the same tunnel stack:
- **User devices** — GUI apps on desktop and mobile; users sign in with their Pangolin identity or SSO
- **Machines** — CLI clients for servers and automation; authenticate with an ID and secret
### Shared client stack (Olm)
Every Pangolin client shares a common networking core called **Olm** (engineering codename). Olm holds the WireGuard tunnel logic, hole punching and relay negotiation, route installation, and DNS overrides that all clients rely on. Platform apps embed or invoke Olm rather than reimplementing that stack themselves.
How Olm is hosted depends on the client:
- **macOS and iOS** — Olm runs inside the platform's network extension
- **Windows and Android** — Olm runs as the tunnel service behind the native app
- **Pangolin CLI** — spawns Olm as a subprocess and manages it over a local API
- **Olm CLI** — exposes Olm directly for minimal machine-client deployments
Olm is an internal building block, not a product surface. Use the [native clients](/manage/clients/install-client) built for each operating system for the best experience, support, and integration with OS networking APIs. Direct Olm usage is limited to advanced machine-client and automation scenarios; see [Olm (Advanced)](/manage/clients/install-client#olm-advanced) if you need that path.
Once connected, the client installs routes for each authorized destination. Pangolin selects the correct site connector automatically; users connect to resources, not to sites directly. See [multi-site routing](/manage/resources/private/multi-site-routing) for how failover works when a resource spans multiple connectors.
<CardGroup cols={2}>
<Card title="Understanding clients" icon="desktop" href="/manage/clients/understanding-clients">
User devices, machine clients, and how access is granted.
</Card>
<Card title="Install clients" icon="download" href="/manage/clients/install-client">
Downloads for Mac, Windows, Linux, iOS, iPadOS, and Android.
</Card>
</CardGroup>
## Peer-to-Peer and Relay Paths
Client-to-site traffic does not always traverse your node. Pangolin negotiates the best available path for each tunnel.
### Direct peer-to-peer (hole punching)
By default, the control plane coordinates **NAT hole punching** so a client and site connector can form a direct WireGuard peer connection. Traffic then flows client ↔ site without passing through the node's relay layer. This path typically offers lower latency and less bandwidth use on the node.
### Relay through the node
When hole punching fails (restrictive NAT, symmetric NAT, or blocked UDP), the client and site fall back to **relaying** through the node's tunnel manager (Gerbil). Gerbil listens on UDP port 21820 by default, accepts the client's WireGuard packets, and forwards them into the site connector's existing tunnel. The connection stays encrypted end to end; only the network path changes.
Site connectors use a separate default port (51820 UDP) for their outbound tunnels to the node. Relay is optional and can be disabled per client if you require direct paths only.
<Card title="NAT traversal" icon="route" href="/manage/clients/nat-traversal">
Hole punching vs relay, how to check `isRelay` status, and tuning options.
</Card>
## Traffic Paths
Two dominant flows cover most deployments.
### Inbound: public resources
Public resources accept traffic from the internet on your node's ingress layer.
```
Internet → Node ingress (Traefik) → Auth (Badger) → Tunnel (Gerbil) → Site connector (Newt) → Backend target
```
HTTP, HTTPS, SSH, RDP, and VNC public resources terminate authentication at the node before traffic enters the tunnel. TCP and UDP public resources bind to node ports and proxy raw traffic without an auth layer. Certificate issuance, router config, and access rules are all driven by the control plane.
<Card title="Public resources" icon="globe" href="/manage/resources/understanding-resources#public-resource-types">
Protocol types, targets, and how ingress maps to backends.
</Card>
### Outbound: private resources via client
Private resources are reachable only when a client is connected and authorized.
```
Client ↔ (direct peer or relay via Gerbil) ↔ Site connector (Newt) → Destination on remote network
```
The client installs routes for IP, CIDR, or FQDN destinations. The site connector resolves and delivers traffic on the remote LAN. For private HTTP, TLS can terminate at the connector so applications stay off the public internet entirely.
<Card title="Private destinations" icon="lock" href="/manage/resources/private/destinations">
How IP, CIDR, FQDN, and alias destinations are resolved and routed.
</Card>
## Component Reference
Pangolin's open-source repositories map to the roles above. Codenames are used throughout the codebase and deployment tooling.
| Component | Repository | Role |
| --- | --- | --- |
| Pangolin | [fosrl/pangolin](https://github.com/fosrl/pangolin) | Control plane server |
| Clients | [fosrl/cli](https://github.com/fosrl/cli), [fosrl/windows](https://github.com/fosrl/windows), [fosrl/apple](https://github.com/fosrl/apple), [fosrl/android](https://github.com/fosrl/android) | Endpoint agents |
| Site Connector | [fosrl/cli](https://github.com/fosrl/cli) | Connect remote networks for public and private resources |
| Gerbil | [fosrl/gerbil](https://github.com/fosrl/gerbil) | Node tunnel manager and relay |
| Badger | [fosrl/badger](https://github.com/fosrl/badger) | Traefik forward-auth middleware |
| Newt | [fosrl/newt](https://github.com/fosrl/newt) | Shared site networking stack |
| Olm | [fosrl/olm](https://github.com/fosrl/olm) | Shared client networking stack (tunnels, NAT traversal, DNS) |
For local development setup and how these repositories interact in a dev environment, see [Contributing](/development/contributing).