[Plugin] Docker Swarm Manager — community plugin for Swarm monitoring

[alfonsokuen]

Docker Swarm Manager Plugin

Hi! I built a community plugin that adds Docker Swarm monitoring and management to PegaProx, inspired by #152.

Repository: https://github.com/alfonsokuen/pegaprox-docker-swarm

What it does

A full-featured Docker Swarm management interface that runs as a PegaProx plugin. Connects to Swarm manager nodes via SSH (using paramiko, already bundled with PegaProx) and provides:

• Dashboard — Swarm overview with node resource metrics (CPU, RAM, Disk), container counts
• Nodes — List with status, availability, role, engine version, resources
• Services — 24 API endpoints: list, scale, restart, remove, logs, tasks
• Stacks — List, deploy from YAML, remove
• Containers — List with start/stop/restart actions and log viewer
• Networks, Volumes, Images — Full listing
• Settings — SSH host config with connection testing

Architecture

• Backend: Python __init__.py (24 API endpoints, 30KB)
• Frontend: React SPA swarm.html using PegaProx's bundled React/Tailwind/Babel (33KB)
• No additional dependencies required — uses paramiko (already in PegaProx)
• Background polling with configurable interval
• 15s TTL cache for performance
• Audit logging for all actions

Installation

cd /opt/PegaProx/plugins/
git clone https://github.com/alfonsokuen/pegaprox-docker-swarm.git docker_swarm
cp docker_swarm/config.example.json docker_swarm/config.json
# Edit config.json with your Swarm manager SSH credentials
chown -R pegaprox:pegaprox docker_swarm/
chmod 600 docker_swarm/config.json

Then: Settings → Plugins → Rescan → Enable

Tested on

• PegaProx Beta 0.9.5
• Docker Swarm 29.4.0 (3-node cluster, 44 services)
• Debian 13 (trixie) LXC container

Screenshots

The plugin includes a dark-themed React SPA that matches PegaProx's design language, with sidebar navigation, resource metrics with progress bars, sortable tables, modal dialogs for logs/tasks/scaling, and toast notifications.

Happy to accept feedback or contribute this upstream if there's interest!

[MrMasterbay]

Hi @alfonsokuen ,

how is the data getting encrypted?
Because I think it would be very uncomfortable to have SSH data laying around in a completely open config.json file.

Regards,
Nico

[alfonsokuen]

Hi @MrMasterbay, great point — you're absolutely right.

Currently config.json stores SSH credentials in plaintext, protected only by chmod 600 file permissions and password masking in API responses. That's not enough.

I'm working on migrating to SSH key-based authentication instead of passwords. Here's what's coming:

• _ssh_exec() will use SSH keys (via paramiko's key_filename) as the primary auth method
• The installer will generate a dedicated keypair and distribute the public key via ssh-copy-id
• config.json will reference a key file path instead of storing passwords
• Password-based auth remains as an optional fallback, but won't be the default
• No secrets stored in config files — the private key lives separately with strict permissions (chmod 600)

This is the industry standard approach (same as Ansible, Terraform, etc.) and eliminates the plaintext credential problem entirely.

Thanks for flagging this, Nico — expect this in the next release.

[alfonsokuen]

Quick update @MrMasterbay — SSH key-based authentication is now implemented and shipped.

Changes landed:

• _ssh_exec() now uses SSH keys via paramiko's key_filename as the primary auth method
• Installer generates a dedicated keypair and distributes the public key via ssh-copy-id
• config.json references the key file path instead of storing passwords
• Password-based auth remains as an optional fallback, but is no longer the default
• No secrets stored in config files — the private key lives separately with strict chmod 600 permissions

This matches the industry-standard approach (Ansible, Terraform, etc.) and eliminates the plaintext credential problem entirely.

Thanks again for flagging this, Nico — please pull the latest release and let me know if anything looks off.