Inspiration
CloudPanel is used by over 250K servers today and is excellent for managing servers and websites, but it lacks an official API and MCP integration. That means many operational workflows still depend on manual dashboard work, CLI commands, or unrestricted SSH access.
I wanted to build a safer and more programmable alternative: an automation layer that lets administrators, platforms, and AI agents work with server infrastructure through structured tools and explicit security boundaries.
The project began as an API and MCP wrapper for CloudPanel’s CLI, but it evolved into something broader: a secure server automation control plane.
What it does
CloudPanel Gateway provides three ways to automate infrastructure:
- REST APIs for applications and integrations
- MCP tools for AI agents
- A local administrator CLI for controlled server operations
It supports structured workflows around site management, logs, deployments, backups, runtime management, PHP and TLS controls, static/Node/SSR application hosting, and CloudPanel-compatible cron jobs.
The core goal is simple: make infrastructure programmable without giving every integration or AI agent unrestricted server access.
How I built it
I built the gateway in Go so it can be deployed as a single binary with a small operational footprint.
The architecture separates the public interfaces from privileged server actions:
Admin / Application / AI Agent
│
REST API · MCP · Local CLI
│
CloudPanel Gateway
│
Scoped privileged helper services
│
CloudPanel + operating system
I added scoped permissions, local policy gates, explicit confirmations for destructive actions, revision checks for concurrent changes, and audit events for sensitive operations.
For cron jobs, I researched how CloudPanel actually stores and applies scheduled tasks. Instead of creating a parallel system, the gateway updates CloudPanel’s SQLite records and atomically regenerates the corresponding managed cron file. This keeps the CloudPanel interface and server configuration aligned.
Challenges
The biggest challenge was safely exposing powerful server operations.
A direct CLI or shell wrapper would be flexible, but it would also make injection, privilege escalation, and accidental destructive actions much easier. I addressed that by using typed operations, validated inputs, constrained paths, scoped tokens, policy controls, and isolated privileged helpers.
Live testing also exposed real infrastructure issues that could not be found through static implementation alone:
- A SQLite write transaction could block when command construction opened another database connection.
- Service readiness checks could race before services finished binding to their ports.
- An isolated Nginx commit service could fail when an optional cache directory was unavailable.
- Release signing required a non-interactive Minisign design suitable for CI.
I fixed these issues and repeatedly validated the system on disposable CloudPanel servers. For example, I created, updated, inspected, and deleted harmless cron jobs while confirming that both CloudPanel’s database and /etc/cron.d remained consistent.
What I learned
I learned that secure automation is largely about defining boundaries, not simply exposing more commands.
The most useful pattern was to replace open-ended shell access with explicit, typed workflows. A safe automation system should make the correct path easy while requiring deliberate policy and confirmation for higher-risk actions.
I also learned the importance of verifying real deployments. Unit tests are essential, but testing installers, service startup, database behavior, and release artifacts on a real disposable server revealed the issues that matter most in production.
Log in or sign up for Devpost to join the conversation.