Pangolin 1.23: High Availability and Clustering

Pangolin 1.23 is here. This is a smaller release, but the flagship change is a big one for self-hosters: you can now deploy high availability and clustering yourself. 1.23 also brings sites into the Pangolin CLI, adds a master list of organizations in the server admin panel, support for more than one server admin, and a more useful Resource Launcher side panel. Let's walk through it.

Release Highlights

Self-Service High Availability and Clustering

Clustering has existed in Pangolin for a long time. Running multiple server instances as one system, with shared state, failover, and regional distribution, was already possible. The catch was how you got there. Setup depended on external proprietary components, including a custom DNS server and a cert manager, and standing it up meant a contract engagement with us on top of Enterprise Edition.

1.23 folds that work into the main Pangolin container. DNS resolution and certificate management that used to live outside the stack now run inside Pangolin itself. The deployment path is streamlined, and there is public documentation for it.

Read Understanding Clustering for the architecture, requirements, and a walkthrough of a two-node cluster.

High availability is included on the self-serve Scale tier and on custom Enterprise contracts. License keys are free for personal use and for organizations under the revenue threshold. Businesses that need to purchase a license can buy Scale on the Self-Hosted pricing page. If you need more capacity than Scale, or SLA support, contact us for a custom contract.

Sites in the Pangolin CLI

If you have ever wondered why the company behind Pangolin is named Fossorial, it is a classification of animals that dig tunnels. That overarching name is why Pangolin's components are named after fossorial animals too: Pangolin, Gerbil, Newt, and the rest.

Newt is the tunnel connector that runs on the remote private network. It handles the intelligent networking and NAT traversal Pangolin uses to make your resources available securely to users anywhere. 1.23 integrates Newt directly into the Pangolin CLI, so you can start a site with the same tool you already use for SSH, client connections, and the rest of the product:

pangolin up site --id <id> --secret <secret> --endpoint https://app.pangolin.net

You can also run a site from the fosrl/pangolin-cli container:

services:
    pangolin-site:
        image: fosrl/pangolin-cli
        container_name: pangolin-site
        restart: unless-stopped
        environment:
            - PANGOLIN_ENDPOINT=https://app.pangolin.net
            - SITE_ID=<id>
            - SITE_SECRET=<secret>

Because the site connector now lives in the CLI, installing a system service is a single command too. The CLI can install and manage a service on your host for you, and it is cross-platform. On Linux it uses systemd, on macOS it uses launchd, and on Windows it uses Windows service commands. That creates a persistent site connection from that host.

sudo pangolin service install site \
  --id <id> \
  --secret <secret> \
  --endpoint https://app.pangolin.net

Check the service status:

sudo pangolin service status site

And to get the logs:

sudo pangolin service logs site

We are moving toward the Pangolin CLI for as much as possible, so users and admins only need to download one CLI for everything Pangolin. As a result, the create site wizard in the dashboard now treats the CLI method as the preferred, default way to install a new site, and Newt is renamed to Pangolin Site in that flow.

Existing Newt deployments keep working. Leave them as they are, or switch to the CLI when you want to. Newt will continue to be provided in all of its current forms for the foreseeable future. Newt is lighter weight because it does not include the rest of the CLI. If you need the smallest possible binary or container, use Newt directly.

In 1.23, the dashboard reports which agent a site is using, whether that is the CLI or Newt itself, and the version.

Read more about installing a site in the docs.

Organizations List in Server Admin

The server admin panel is for the people who run a self-hosted instance. There was already a master list of every user on the server, across all organizations. 1.23 adds the same kind of list for organizations.

You can see every org on the instance in one place: name, ID, owner, and counts for users, sites, and resources. You can search the table and delete an organization from it.

Server admins can see this list even if they are not a member of an organization. That visibility does not include silently joining an org or impersonating a member. To see an organization's contents in the dashboard, a server admin still has to be a member of that org.

Multiple Server Admins

You can now have more than one server admin account. From the users table in the server admin panel, you can promote a user to server admin and demote one back. That makes it easier to share instance management without passing around a single admin login.

Resource Launcher Side Panel

The Resource Launcher is still the place non-admins go to find and open what they have access to. Expand a resource and the side panel now carries more of the context you need without leaving the launcher.

A Sites widget lists every site that makes the resource reachable. If a resource has targets on more than one site, or routes through more than one site, all of those sites show up together. From the list you can filter the launcher down to that site, or jump straight to the admin page for the site if you are an organization admin.

For private SSH resources, the panel also shows a ready-to-copy pangolin ssh command, so you can start a session from the launcher instead of reconstructing the CLI invocation by hand.

General Improvements and Bug Fixes

A few smaller additions made it into 1.23 as well:

1. Dependency security updates.

As always, this release also includes various UI improvements and bug fixes throughout the product.