Managing Resources at Scale with Pangolin Blueprints

When teams expose services across multiple environments, the biggest challenges are usually consistency and scale. You might run a mix of cloud services, on‑prem systems, or even IoT devices in the field. Each environment has different access methods and security considerations, but you still need a single way to expose them securely, apply authentication, and control traffic.

Pangolin Blueprints provide a way to define this centrally. Instead of applying reverse proxy rules manually in different places, you describe each resource once using a declarative configuration. Pangolin then applies that configuration, ensuring that proxies, authentication, and target mappings stay consistent no matter where the service runs.

Examples: YAML and Docker Labels

A Blueprint for a single HTTP service can be described in YAML. Below, a Grafana instance in a VPC is exposed at a domain with SSO enabled:

 1proxy-resources:
 2  grafana:
 3    name: Grafana
 4    protocol: http
 5    full-domain: grafana.example.com
 6    auth:
 7      sso-enabled: true
 8    targets:
 9      - hostname: localhost
10        port: 3000
11        method: http
12

For containerized workloads, you can define the same setup directly in a docker-compose.yml file using labels. The Newt agent detects these at startup and automatically provisions them in Pangolin:

 1services:
 2  grafana:
 3    image: grafana/grafana
 4    container_name: grafana
 5    labels:
 6      - pangolin.proxy-resources.grafana.name=Grafana
 7      - pangolin.proxy-resources.grafana.full-domain=grafana.example.com
 8      - pangolin.proxy-resources.grafana.protocol=http
 9      - pangolin.proxy-resources.grafana.auth.sso-enabled=true
10      - pangolin.proxy-resources.grafana.targets[0].method=http
11      - pangolin.proxy-resources.grafana.targets[0].port=3000
12

This approach means you don’t need to configure the proxy separately. Your Compose stack definition and your network access controls live in one place.

Watch It in Action

This short walkthrough shows a Grafana service being exposed with a Pangolin Blueprint, both through YAML and Docker labels.

How Teams Use Blueprints

Once services can be declared as code, a wide set of use cases follow naturally:

• Temporary environments: Spin up a staging or preview stack with Docker Compose and have Pangolin automatically register domains, enforce authentication, and route traffic without extra configuration.
• Multiple offices or sites: Connect tunnels from different physical networks into Pangolin, then apply the same proxy rules and security policies consistently across locations.
• IoT and edge environments: Define resources for devices that exist outside your main datacenter and manage access centrally, with the same login rules as cloud applications.
• Hybrid and multi‑cloud setups: Expose services running across providers while keeping control of how traffic flows and what authentication is required, all from one dashboard.

Blueprints also make it easier to handle traffic distribution and availability. You can attach multiple targets to a single resource, allowing Pangolin to automatically balance requests across services or fail over if one goes offline.

Here’s an example of a resource with two HTTP backends:

 1proxy-resources:
 2  webapp:
 3    name: WebApp
 4    protocol: http
 5    full-domain: app.example.com
 6    targets:
 7      - hostname: localhost
 8        port: 8080
 9        method: http
10        site: "aws-vpc-01"
11      - hostname: localhost 
12        port: 8080
13        method: http
14        site: "aws-vpc-02"
15

For developers and operators, this keeps traffic rules explicit. Adding or removing targets is done through the config file rather than by re‑entering settings into a UI.

Centralized Control

Another advantage of Blueprints is centralization. Access policies, authentication rules, and connection definitions are applied at the proxy layer and enforced the same way across all resources. For example:

• Require SSO for certain applications while leaving others public.
• Apply path‑based rules to allow or block specific endpoints.
• Restrict access to resources by IP or region.

Because these settings are declarative, they can be versioned, audited, and reviewed in the same way as application code. This reduces configuration drift and makes it easier for teams to collaborate on network and access policies.

Final Thoughts

Pangolin Blueprints provide a way to treat reverse proxy configurations as code and deploy applications that exist on any network anywhere. Whether you define YAML files checked into Git, or embed labels in Compose stacks, service definitions and access controls are created automatically when infrastructure comes online.

That makes it straightforward to manage reverse proxies, authentication policies, load balancing, and site‑to‑site connections from a single place without duplicating manual steps across environments.

Learn more by reading our documentation.