Originally posted by dystopiandev June 20, 2025
I've noticed the recommended way to programmatically setup pangolin is via the integration api, and that works with an api key, which one must logon to the admin dash to create. If it were possible to provide some init/seed data for sites, resources, etc, that would make it easier to provision in IaC.
Is it possible or planned to have pangolin setup entirely with no usage of the web ui, or have I missed a guide in the docs for achieving exactly this?
Originally created by @oschwartz10612 on GitHub (Sep 8, 2025).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/1438
Originally assigned to: @oschwartz10612 on GitHub.
### Discussed in https://github.com/orgs/fosrl/discussions/952
<div type='discussions-op-text'>
<sup>Originally posted by **dystopiandev** June 20, 2025</sup>
I've noticed the recommended way to programmatically setup pangolin is via the integration api, and that works with an api key, which one must logon to the admin dash to create. If it were possible to provide some init/seed data for sites, resources, etc, that would make it easier to provision in IaC.
Is it possible or planned to have pangolin setup entirely with no usage of the web ui, or have I missed a guide in the docs for achieving exactly this?</div>
@marcschaeferger commented on GitHub (Sep 8, 2025):
@oschwartz10612 Thanks for moving this forward!
To make Pangolin future-proof and seamlessly integrable into CI/CD and IaC deployment workflows and to align with industry best practices, I suggest we combine the following approaches:
1. Kubernetes Operator for Declarative Management
I’ve already opened Issue #1439 for this.
A Kubernetes Operator would allow full management of Pangolin through CRDs (Custom Resources):
Automated initial bootstrap (Admin user + API Key seeded from Kubernetes Secrets).
All entities (sites, resources, endpoints, users, etc.) managed as declarative YAML manifests.
Continuous reconciliation of the desired state by the Operator (following the established Kubernetes pattern).
Enables GitOps flows through ArgoCD, Flux, etc.
As discussed, only alignment/agreements and some optimizations plus documentation remain. Before that, I would also like to complete full OTEL integration, security hardening, and further Docker image improvements.
2. Bootstrap and Seed Config for Docker & Traditional Deployments
For non-Kubernetes environments, a declarative configuration approach should also be possible:
bootstrap.yaml: One-time initialization for admin account and API key (run only at first startup).
seed.yaml: Idempotent application of initial resources.
Example:
bootstrap:createAdmin:trueadminUser:adminadminPassword:(provided via ENV or auto-generated)createApiKey:true# API key is generated and logged only once at startupseed:enabled:truepath:/etc/pangolin/seed.yaml
Works in cloud-native (Kubernetes) and traditional (VM, bare metal, Docker) environments.
Enables completely UI-free provisioning.
100% compatible with GitOps, CI/CD, and secret management solutions (Vault, SOPS, etc.).
Reproducible, idempotent deployments.
Tasks
Finalize schema definitions for bootstrap.yaml and seed.yaml.
Implement startup logic to detect and apply bootstrap/seed files on first launch.
Agree on CRD structure in #1439 for fully declarative Kubernetes-native control.
Develop a CLI concept for functional parity with the UI.
I’d be happy to contribute by helping draft a design document, creating sample manifests/configs, and assisting with implementation.
<!-- gh-comment-id:3264683273 -->
@marcschaeferger commented on GitHub (Sep 8, 2025):
@oschwartz10612 Thanks for moving this forward!
To make Pangolin future-proof and seamlessly integrable into CI/CD and IaC deployment workflows and to align with industry best practices, I suggest we combine the following approaches:
## 1. **Kubernetes Operator for Declarative Management**
I’ve already opened [Issue #1439](#1439) for this.
A Kubernetes Operator would allow full management of Pangolin through CRDs (Custom Resources):
- Automated initial bootstrap (Admin user + API Key seeded from Kubernetes Secrets).
- All entities (sites, resources, endpoints, users, etc.) managed as declarative YAML manifests.
- Continuous reconciliation of the desired state by the Operator (following the established Kubernetes pattern).
- Enables GitOps flows through ArgoCD, Flux, etc.
As discussed, only alignment/agreements and some optimizations plus documentation remain. Before that, I would also like to complete full OTEL integration, security hardening, and further Docker image improvements.
---
## 2. **Bootstrap and Seed Config for Docker & Traditional Deployments**
For non-Kubernetes environments, a declarative configuration approach should also be possible:
- **`bootstrap.yaml`**: One-time initialization for admin account and API key (run only at first startup).
- **`seed.yaml`**: Idempotent application of initial resources.
**Example:**
```yaml
bootstrap:
createAdmin: true
adminUser: admin
adminPassword: (provided via ENV or auto-generated)
createApiKey: true
# API key is generated and logged only once at startup
seed:
enabled: true
path: /etc/pangolin/seed.yaml
```
**Example: Docker Compose**
```yaml
services:
pangolin:
image: pangolin:1.9.4
volumes:
- ./bootstrap.yaml:/etc/pangolin/bootstrap.yaml
- ./seed.yaml:/etc/pangolin/seed.yaml
environment:
PANGOLIN_ADMIN_PASSWORD: "${PANGOLIN_ADMIN_PASSWORD}"
```
---
## 3. **CLI Tool (`pangolinctl`) for Declarative Management**
After the bootstrap process, a dedicated CLI tool (similar to `ceph`, `calicoctl`, `grafanactl` or even `kubectl`) could provide:
- Applying/updating resources from local files.
- Exporting the current configuration (ideal for GitOps pull workflows).
- API-connected mode for automation pipelines.
→ Ideally, both the Operator and CLI provide the same capabilities, ensuring parity between Kubernetes, Docker, and VM installations. They could both call a REST API for the Configuration. One Example: https://grafana.com/docs/grafana/latest/observability-as-code/grafana-cli/
---
## 4. **Advantages of This Approach**
- Works in **cloud-native** (Kubernetes) and **traditional** (VM, bare metal, Docker) environments.
- Enables **completely UI-free** provisioning.
- 100% compatible with **GitOps**, **CI/CD**, and secret management solutions (Vault, SOPS, etc.).
- Reproducible, **idempotent deployments**.
---
### Tasks
- Finalize schema definitions for `bootstrap.yaml` and `seed.yaml`.
- Implement startup logic to detect and apply bootstrap/seed files on first launch.
- Agree on CRD structure in [#1439](#1439) for fully declarative Kubernetes-native control.
- Develop a CLI concept for functional parity with the UI.
I’d be happy to contribute by helping draft a design document, creating sample manifests/configs, and assisting with implementation.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @oschwartz10612 on GitHub (Sep 8, 2025).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/1438
Originally assigned to: @oschwartz10612 on GitHub.
Discussed in https://github.com/orgs/fosrl/discussions/952
Originally posted by dystopiandev June 20, 2025
I've noticed the recommended way to programmatically setup pangolin is via the integration api, and that works with an api key, which one must logon to the admin dash to create. If it were possible to provide some init/seed data for sites, resources, etc, that would make it easier to provision in IaC.
Is it possible or planned to have pangolin setup entirely with no usage of the web ui, or have I missed a guide in the docs for achieving exactly this?
@oschwartz10612 commented on GitHub (Sep 8, 2025):
Also discussed in:
https://github.com/orgs/fosrl/discussions/108
https://github.com/orgs/fosrl/discussions/182
@marcschaeferger commented on GitHub (Sep 8, 2025):
@oschwartz10612 Thanks for moving this forward!
To make Pangolin future-proof and seamlessly integrable into CI/CD and IaC deployment workflows and to align with industry best practices, I suggest we combine the following approaches:
1. Kubernetes Operator for Declarative Management
I’ve already opened Issue #1439 for this.
A Kubernetes Operator would allow full management of Pangolin through CRDs (Custom Resources):
As discussed, only alignment/agreements and some optimizations plus documentation remain. Before that, I would also like to complete full OTEL integration, security hardening, and further Docker image improvements.
2. Bootstrap and Seed Config for Docker & Traditional Deployments
For non-Kubernetes environments, a declarative configuration approach should also be possible:
bootstrap.yaml: One-time initialization for admin account and API key (run only at first startup).seed.yaml: Idempotent application of initial resources.Example:
Example: Docker Compose
3. CLI Tool (
pangolinctl) for Declarative ManagementAfter the bootstrap process, a dedicated CLI tool (similar to
ceph,calicoctl,grafanactlor evenkubectl) could provide:→ Ideally, both the Operator and CLI provide the same capabilities, ensuring parity between Kubernetes, Docker, and VM installations. They could both call a REST API for the Configuration. One Example: https://grafana.com/docs/grafana/latest/observability-as-code/grafana-cli/
4. Advantages of This Approach
Tasks
bootstrap.yamlandseed.yaml.I’d be happy to contribute by helping draft a design document, creating sample manifests/configs, and assisting with implementation.