Newt Blueprint Generator
Generate and validate Pangolin Newt blueprint configurations in YAML or Docker Labels format. Use when creating Pangolin resource configurations, proxy resources, client resources, authentication settings, or Docker Compose blueprints.
Best use case
Newt Blueprint Generator is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Generate and validate Pangolin Newt blueprint configurations in YAML or Docker Labels format. Use when creating Pangolin resource configurations, proxy resources, client resources, authentication settings, or Docker Compose blueprints.
Teams using Newt Blueprint Generator should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/newt-blueprint-generator/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How Newt Blueprint Generator Compares
| Feature / Agent | Newt Blueprint Generator | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Generate and validate Pangolin Newt blueprint configurations in YAML or Docker Labels format. Use when creating Pangolin resource configurations, proxy resources, client resources, authentication settings, or Docker Compose blueprints.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Newt Blueprint Generator
Expert assistance for creating, validating, and managing Pangolin Newt blueprint configurations.
## When to Use This Skill
This skill should be triggered when:
- Creating Pangolin blueprint configurations
- Generating YAML configuration files for Newt
- Creating Docker Compose files with Pangolin labels
- Configuring proxy resources (HTTP, TCP, UDP)
- Setting up client resources for Olm
- Configuring authentication (SSO, basic auth, pincode, password)
- Validating blueprint configurations
- Troubleshooting blueprint validation errors
- Converting between YAML and Docker Labels formats
## Overview
Pangolin Blueprints are declarative configurations that allow you to define resources and their settings in a structured format. They support two formats:
1. **YAML Configuration Files**: Standalone configuration files
2. **Docker Labels**: Configuration embedded in Docker Compose files
## Blueprint Formats
### YAML Configuration Format
YAML configs can be applied using:
- **Newt CLI**: Pass `--blueprint-file /path/to/blueprint.yaml`
- **API**: POST to `/org/{orgId}/blueprint` with base64-encoded JSON body
Example Newt usage:
```bash
newt --blueprint-file /path/to/blueprint.yaml <other-args>
```
### Docker Labels Format
For containerized applications, blueprints can be defined using Docker labels with the `pangolin.` prefix.
Enable Docker socket access:
```bash
newt --docker-socket /var/run/docker.sock <other-args>
```
Or use environment variable:
```bash
DOCKER_SOCKET=/var/run/docker.sock
```
## Resource Types
### Proxy Resources
Proxy resources expose HTTP, TCP, or UDP services through Pangolin.
#### HTTP Proxy Resource Example
```yaml
proxy-resources:
resource-nice-id-uno:
name: this is a http resource
protocol: http
full-domain: uno.example.com
host-header: example.com
tls-server-name: example.com
headers:
- name: X-Example-Header
value: example-value
- name: X-Another-Header
value: another-value
rules:
- action: allow
match: ip
value: 1.1.1.1
- action: deny
match: cidr
value: 2.2.2.2/32
- action: pass
match: path
value: /admin
targets:
- site: lively-yosemite-toad
hostname: localhost
method: http
port: 8000
- site: slim-alpine-chipmunk
hostname: localhost
path: /admin
path-match: exact
method: https
port: 8001
```
#### TCP/UDP Proxy Resource Example
```yaml
proxy-resources:
resource-nice-id-dos:
name: this is a raw resource
protocol: tcp
proxy-port: 3000
targets:
- site: lively-yosemite-toad
hostname: localhost
port: 3000
```
#### Targets-Only Resources
Simplified resources containing only target configurations:
```yaml
proxy-resources:
additional-targets:
targets:
- site: another-site
hostname: backend-server
method: https
port: 8443
- site: another-site
hostname: backup-server
method: http
port: 8080
```
**Note**: When using targets-only resources, `name` and `protocol` fields are not required.
### Client Resources
Client resources define proxied resources accessible via Olm client (SSH, RDP):
```yaml
client-resources:
client-resource-nice-id-uno:
name: this is my resource
protocol: tcp
proxy-port: 3001
hostname: localhost
internal-port: 3000
site: lively-yosemite-toad
```
## Authentication Configuration
Authentication is **off by default**. Enable by adding fields in the `auth` section.
**Note**: Authentication is only allowed on HTTP resources, not TCP/UDP.
```yaml
proxy-resources:
secure-resource:
name: Secured Resource
protocol: http
full-domain: secure.example.com
auth:
pincode: 123456
password: your-secure-password
basic-auth:
user: asdfa
password: sadf
sso-enabled: true
sso-roles:
- Member
- Admin
sso-users:
- user@example.com
whitelist-users:
- admin@example.com
```
## Docker Labels Format
### Complete Docker Compose Example
```yaml
services:
newt:
image: fosrl/newt
container_name: newt
restart: unless-stopped
volumes:
- /var/run/docker.sock:/var/run/docker.sock
environment:
- PANGOLIN_ENDPOINT=https://app.pangolin.net
- NEWT_ID=h1rbsgku89wf9z3
- NEWT_SECRET=z7g54mbcwkglpx1aau9gb8mzcccoof2fdbs97keoakg2pp5z
- DOCKER_SOCKET=/var/run/docker.sock
nginx1:
image: nginxdemos/hello
container_name: nginx1
labels:
# Proxy Resource Configuration
- pangolin.proxy-resources.nginx.name=nginx
- pangolin.proxy-resources.nginx.full-domain=nginx.fosrl.io
- pangolin.proxy-resources.nginx.protocol=http
- pangolin.proxy-resources.nginx.headers[0].name=X-Example-Header
- pangolin.proxy-resources.nginx.headers[0].value=example-value
# Target Configuration - port and hostname auto-detected
- pangolin.proxy-resources.nginx.targets[0].method=http
- pangolin.proxy-resources.nginx.targets[0].path=/path
- pangolin.proxy-resources.nginx.targets[0].path-match=prefix
nginx2:
image: nginxdemos/hello
container_name: nginx2
labels:
# Additional target with explicit hostname and port
- pangolin.proxy-resources.nginx.targets[1].method=http
- pangolin.proxy-resources.nginx.targets[1].hostname=nginx2
- pangolin.proxy-resources.nginx.targets[1].port=80
networks:
default:
name: pangolin_default
```
### Docker Labels Considerations
- **Automatic Discovery**: When hostname and internal port are not defined, Pangolin auto-detects from container configuration
- **Site Assignment**: If no site is specified, resource is assigned to the discovering Newt site
- **Configuration Merging**: Configuration across containers is merged to form complete resource definitions
## Configuration Properties Reference
### Proxy Resources Properties
| Property | Type | Required | Description | Constraints |
|----------|------|----------|-------------|-------------|
| `name` | string | Conditional | Human-readable name | Required unless targets-only |
| `protocol` | string | Conditional | Protocol type (`http`, `tcp`, `udp`) | Required unless targets-only |
| `full-domain` | string | HTTP only | Full domain name | Required for HTTP, must be unique |
| `proxy-port` | number | TCP/UDP only | Port for raw TCP/UDP | Required for TCP/UDP, 1-65535, must be unique |
| `ssl` | boolean | No | Enable SSL/TLS | - |
| `enabled` | boolean | No | Whether resource is enabled | Defaults to `true` |
| `host-header` | string | No | Custom Host header | - |
| `tls-server-name` | string | No | SNI name for TLS | - |
| `headers` | array | No | Custom headers | Each requires `name` and `value` (min 1 char) |
| `rules` | array | No | Access control rules | See Rules section |
| `auth` | object | HTTP only | Authentication config | See Authentication section |
| `targets` | array | Yes | Target endpoints | See Targets section |
### Target Configuration Properties
| Property | Type | Required | Description | Constraints |
|----------|------|----------|-------------|-------------|
| `site` | string | No | Site identifier | - |
| `hostname` | string | Yes | Target hostname or IP | - |
| `port` | number | Yes | Target port | 1-65535 |
| `method` | string | HTTP only | Protocol method (`http`, `https`, `h2c`) | Required for HTTP |
| `enabled` | boolean | No | Whether target is enabled | Defaults to `true` |
| `internal-port` | number | No | Internal port mapping | 1-65535 |
| `path` | string | HTTP only | Path prefix, exact, or regex | - |
| `path-match` | string | HTTP only | Path matching type (`prefix`, `exact`, `regex`) | - |
### Authentication Properties
**Not allowed on TCP/UDP resources.**
| Property | Type | Required | Description | Constraints |
|----------|------|----------|-------------|-------------|
| `pincode` | number | No | 6-digit PIN | Must be exactly 6 digits |
| `password` | string | No | Password for access | - |
| `basic-auth` | object | No | Basic auth config | Requires `user` and `password` |
| `sso-enabled` | boolean | No | Enable SSO | Defaults to `false` |
| `sso-roles` | array | No | Allowed SSO roles | Cannot include "Admin" role |
| `sso-users` | array | No | Allowed SSO user emails | Must be valid emails |
| `whitelist-users` | array | No | Whitelisted user emails | Must be valid emails |
### Rules Configuration Properties
| Property | Type | Required | Description | Constraints |
|----------|------|----------|-------------|-------------|
| `action` | string | Yes | Rule action (`allow`, `deny`, `pass`) | - |
| `match` | string | Yes | Match type (`cidr`, `path`, `ip`, `country`) | - |
| `value` | string | Yes | Value to match | Format depends on match type |
### Client Resources Properties
| Property | Type | Required | Description | Constraints |
|----------|------|----------|-------------|-------------|
| `name` | string | Yes | Human-readable name | 2-100 characters |
| `protocol` | string | Yes | Protocol type (`tcp`, `udp`) | - |
| `proxy-port` | number | Yes | Port accessible to clients | 1-65535, must be unique |
| `hostname` | string | Yes | Target hostname or IP | 1-255 characters |
| `internal-port` | number | Yes | Port on target system | 1-65535 |
| `site` | string | No | Site identifier | 2-100 characters |
| `enabled` | boolean | No | Whether resource is enabled | Defaults to `true` |
## Validation Rules and Constraints
### Resource-Level Validations
1. **Targets-Only Resources**: A resource can contain only `targets` field, making `name` and `protocol` optional
2. **Protocol-Specific Requirements**:
- **HTTP Protocol**: Must have `full-domain` and all targets must have `method` field
- **TCP/UDP Protocol**: Must have `proxy-port` and targets must NOT have `method` field
- **TCP/UDP Protocol**: Cannot have `auth` configuration
3. **Port Uniqueness**:
- `proxy-port` values must be unique within `proxy-resources`
- `proxy-port` values must be unique within `client-resources`
- Cross-validation between proxy and client resources is not enforced
4. **Domain Uniqueness**: `full-domain` values must be unique across all proxy resources
5. **Target Method Requirements**: When protocol is `http`, all non-null targets must specify a `method`
## Common Validation Errors
### "Admin role cannot be included in sso-roles"
The `Admin` role is reserved and cannot be included in the `sso-roles` array.
**Solution**: Remove "Admin" from the `sso-roles` array.
### "Duplicate 'full-domain' values found"
Each `full-domain` must be unique across all proxy resources.
**Solution**: Use different subdomains or paths for multiple resources.
### "Duplicate 'proxy-port' values found"
Port numbers in `proxy-port` must be unique within their resource type.
**Solution**: Assign unique port numbers within `proxy-resources` and `client-resources` separately.
### "When protocol is 'http', all targets must have a 'method' field"
All targets in HTTP proxy resources must specify the connection method.
**Solution**: Add `method: http`, `method: https`, or `method: h2c` to all targets.
### "When protocol is 'tcp' or 'udp', targets must not have a 'method' field"
TCP and UDP targets should not include the `method` field.
**Solution**: Remove the `method` field from TCP/UDP resource targets.
### "When protocol is 'tcp' or 'udp', 'auth' must not be provided"
Authentication is only supported for HTTP resources.
**Solution**: Remove the `auth` section from TCP/UDP resources.
### "Resource must either be targets-only or have both 'name' and 'protocol' fields"
Resources must be either targets-only or complete resource definitions.
**Solution**: Either provide only `targets` field, or include both `name` and `protocol` fields.
## Workflow for Generating Blueprints
When a user requests a Pangolin Newt blueprint configuration:
1. **Gather Requirements**:
- Resource type (proxy or client)
- Protocol (HTTP, TCP, UDP)
- Domain or port requirements
- Target endpoints (hostname, port, site)
- Authentication needs (if HTTP)
- Access control rules (if any)
- Format preference (YAML or Docker Labels)
2. **Select Format**:
- Use **YAML** for standalone configurations or API deployment
- Use **Docker Labels** for containerized applications
3. **Validate Configuration**:
- Ensure protocol-specific requirements are met
- Check for unique `full-domain` (HTTP) or `proxy-port` (TCP/UDP)
- Verify authentication is only on HTTP resources
- Confirm all HTTP targets have `method` field
- Ensure TCP/UDP targets don't have `method` field
4. **Generate Configuration**:
- Create well-structured YAML or Docker Compose file
- Include helpful comments explaining each section
- Follow naming conventions (kebab-case for resource IDs)
5. **Provide Usage Instructions**:
- Explain how to apply the configuration (Newt CLI or API)
- Document any environment variables needed
- Include validation commands if applicable
## Best Practices
1. **Resource IDs**: Use descriptive, kebab-case identifiers (e.g., `web-app-prod`, `database-backup`)
2. **Target Organization**: Group related targets under the same resource ID
3. **Security First**: Enable authentication for sensitive HTTP resources
4. **Port Management**: Document port assignments to avoid conflicts
5. **Site Assignment**: Explicitly specify `site` for multi-site deployments
6. **Path Matching**: Use `prefix` for broad matches, `exact` for specific endpoints
7. **Headers**: Add custom headers for backend requirements (e.g., X-Forwarded-* headers)
8. **Rules**: Order rules from most specific to least specific
9. **Validation**: Always validate configurations before deployment
10. **Documentation**: Include comments in YAML or Docker Compose files explaining non-obvious choices
## Resources
- **API Documentation**: https://api.pangolin.net/v1/docs/#/Organization/put_org__orgId__blueprint
- **Python Example**: https://github.com/fosrl/pangolin/blob/dev/blueprint.py
- **Official Docs**: https://docs.pangolin.net/manage/blueprints
## Example Use Cases
### Use Case 1: Simple Web Application
**Requirements**: Expose a web app running on localhost:8080 via HTTPS at app.example.com
```yaml
proxy-resources:
web-app:
name: Web Application
protocol: http
full-domain: app.example.com
targets:
- hostname: localhost
port: 8080
method: https
```
### Use Case 2: TCP Database Access
**Requirements**: Expose PostgreSQL database on port 5432
```yaml
proxy-resources:
postgres-db:
name: PostgreSQL Database
protocol: tcp
proxy-port: 5432
targets:
- hostname: localhost
port: 5432
```
### Use Case 3: Multi-Target Load Balanced HTTP Service
**Requirements**: Multiple backend servers for the same domain
```yaml
proxy-resources:
api-service:
name: API Service
protocol: http
full-domain: api.example.com
targets:
- site: site-01
hostname: backend-01
port: 8080
method: http
- site: site-02
hostname: backend-02
port: 8080
method: http
```
### Use Case 4: Secured Resource with SSO
**Requirements**: Web app with SSO authentication
```yaml
proxy-resources:
secure-app:
name: Secure Application
protocol: http
full-domain: secure.example.com
auth:
sso-enabled: true
sso-roles:
- Member
- Developer
sso-users:
- admin@example.com
targets:
- hostname: localhost
port: 3000
method: https
```
## Communication Style
When generating blueprints:
- Ask clarifying questions if requirements are unclear
- Explain validation errors in plain language
- Provide complete, working examples
- Include comments for complex configurations
- Suggest security best practices proactively
- Offer both YAML and Docker Labels formats when appropriateRelated Skills
viral-generator-builder
Expert in building shareable generator tools that go viral - name generators, quiz makers, avatar creators, personality tests, and calculator tools. Covers the psychology of sharing, viral mechanic...
terragrunt-generator
Comprehensive toolkit for generating best practice Terragrunt configurations (HCL files) following current standards and conventions. Use this skill when creating new Terragrunt resources (root configs, child modules, stacks, environment setups), or building multi-environment Terragrunt projects.
steering-specs-generator
Extract tacit engineering knowledge through guided interviews and generate structured steerings. Use when user mentions "steerings", "tacit knowledge", "conventions", "engineering practices", "interview", or wants to document team/project knowledge. Also activates when user asks for "steerings for X", "document X conventions", "continue steerings", "resume interview", or wants to extract knowledge about a specific topic. Supports reviewing and transforming existing steerings to standard format. Auto-detects existing sessions and offers to continue incomplete ones.
spider-generator
Generate Scrapy spiders with best practices when creating new spiders, crawlers, or implementing scraping patterns. Automatically scaffolds spiders based on target website type and requirements.
spec-generator
Interview user in-depth to create a detailed spec
schematic-generator
Generates schematics, netlists, or HDL from requirements for hardware/PCB projects. Validates physical constraints. Use when building PCB, HDL, or hardware designs from approved requirements.
repo-docs-generator
Generate comprehensive AGENTS.md, README.md, and CLAUDE.md documentation for any repository. Deep-dives into codebase structure, identifies technologies, creates ASCII architecture diagrams, and respects existing documentation content.
promql-generator
Comprehensive toolkit for generating best practice PromQL (Prometheus Query Language) queries following current standards and conventions. Use this skill when creating new PromQL queries, implementing monitoring and alerting rules, or building observability dashboards.
PRD Generator for TaskMaster
Smart PRD generator with TaskMaster integration. Detects existing PRDs and offers execute/update/replace options. Generates comprehensive technical PRDs optimized for task breakdown, validates with 13 automated checks, and optionally executes tasks autonomously with datetime tracking and rollback support. Use when user requests "PRD", "product requirements", or mentions task-driven development. Default: PRD generation + handoff to TaskMaster. Optional: autonomous execution with 4 modes.
platxa-skill-generator
Autonomous skill creator for Claude Code CLI. Uses multi-phase orchestrated workflow with Task tool subagents to research domains, design architecture, generate content, and validate quality. Creates production-ready skills following Anthropic's Agent Skills specification.
plan-generator
Creates structured plans from requirements. Generates comprehensive plans with steps, dependencies, risks, and success criteria. Coordinates with specialist agents for planning input and validates plan completeness. Uses template-renderer for formatted output.
open-eth-terminal-action-generator
An agent that can help users with creating new actions to check into the codebase. It should generate action code and link it to the application after querying the user for information about the goal of the action.