Pelican Deployment Manager is an independent, web-based control plane for deploying and maintaining Pelican Panel and Wings across multiple Linux servers.
It is designed for operators who need more than a one-time installer. The manager discovers existing infrastructure before making changes, requires explicit confirmation for production operations, and records every job through a persistent background queue.
Live project: https://pelican.legacyhosting.xyz/
Important
This is an independent community project created by Angel Knutsen Aune. It is not an official Pelican product and is not endorsed or maintained by the Pelican team.
Panel and node fleets evolve over time. A server may be new, partially configured, already running Pelican, or connected to an existing production Panel. Treating every server like a blank machine can destroy configuration or create duplicate resources.
Pelican Deployment Manager uses a discovery-first lifecycle instead:
- verify the SSH host key;
- inspect the target without changing it;
- classify the actual Panel and Wings state;
- present only actions relevant to the server's selected role;
- revalidate immediately before a remote change;
- execute the change as an observable, auditable background job;
- verify the resulting version and health.
- Register Panel, Node, or combined Panel + Node servers.
- Discover operating-system, architecture, CPU, memory, storage, network, and service information over SSH.
- Detect all active IPv4 and IPv6 addresses instead of relying on manually entered addresses.
- Detect existing Panel and Wings installations, versions, configuration, and runtime status before offering lifecycle actions.
- Pin and verify SSH host keys before authentication.
- Support password, private-key, and passphrase-protected key authentication.
- Encrypt SSH, Pelican API, Cloudflare, node configuration, database, and application secrets with authenticated encryption.
- Keep the encryption keyring in machine-local configuration outside the repository and web root.
- Redact known secret material before job output is stored or streamed.
- Connect to existing Pelican Panels through the Application API.
- Create Panel nodes with resource limits derived from verified inventory.
- Retrieve and protect node configuration without exposing it to the browser.
- Install Pelican Panel or Wings only after discovery confirms that the target is safe to provision.
- Update existing Panel and Wings installations through separate guarded workflows.
- Preserve
/etc/pelican/config.ymlduring Wings updates. - Use verified release artifacts, backups, health checks, and rollback protection.
- Validate scoped Cloudflare API tokens and discover accessible zones.
- Build A and AAAA record plans from observed public addresses.
- Preserve unknown DNS records and modify only records owned by the manager.
- Enforce DNS-only behavior for node hostnames that require direct Wings and SFTP connectivity.
- Obtain and renew Let's Encrypt certificates with Certbot, including Cloudflare DNS-01 support.
- Record certificate issuer, fingerprint, validity, expiry, and renewal state.
- Execute remote work through persistent MariaDB-backed workers.
- Prevent concurrent mutations of the same server with leases and locks.
- Display weighted progress and redacted live output through Server-Sent Events.
- Refresh server health and installed versions on a schedule.
- Monitor published Pelican Panel and Wings releases through GitHub.
- Support explicitly enabled, per-component automatic update policies with timezone-aware maintenance schedules.
Pelican Deployment Manager intentionally separates observation from mutation. Opening a page, testing a credential, checking releases, or running preflight does not install or update software.
Remote changes are guarded by:
- explicit operator confirmation;
- current role and authorization checks;
- a fresh preflight and component-state check;
- verified SSH host-key pinning;
- idempotency markers and per-server locking;
- release target and SHA-256 validation;
- protection against overwriting unknown or partial installations;
- backups and post-change health verification where applicable;
- persistent, redacted job and audit records.
No automation can eliminate deployment risk. Operators remain responsible for independent backups, credential scope, network policy, and reviewing changes before approving them on production systems.
Web interface
│
▼
CodeIgniter application ── MariaDB state, jobs, and audit records
│ │
│ ▼
└──────────────────────────── Background workers
│
┌────────────────┼────────────────┐
▼ ▼ ▼
Verified SSH Pelican API Cloudflare API
│
▼
Managed Linux servers
The application is built with PHP, CodeIgniter 4, MariaDB, phpseclib, and server-side rendered views. Long-running operations are handled by CLI workers rather than web requests.
The current operating-system policy recognizes:
- Ubuntu 22.04, 24.04, and 26.04;
- Debian 11, 12, and 13;
- AlmaLinux 8, 9, and 10;
- Rocky Linux 8, 9, and 10;
- CentOS Stream 10.
Support in the policy means that the manager may offer compatible lifecycle drivers after preflight. It does not guarantee compatibility with every custom image, network policy, package mirror, or previously modified installation.
The project is under active development and has been exercised against real Panel and Wings infrastructure. Review the code and test in an isolated environment before using it against production systems.
Bug reports and focused contributions are welcome through the personal GitHub repository. Please use private security advisories for vulnerabilities.
The original Pelican Deployment Manager source code is released under the MIT License, copyright © 2026 Angel Knutsen Aune.
Pelican itself is a separate project. Its name, logo, source code, and other assets are not relicensed by this repository. See NOTICE.md for attribution and compatibility information.