Whenever you provision a new VPS or manage a fleet of Linux servers, you are usually confronted with an uncomfortable compromise between two contrasting paradigms. If you are searching for a lean Dokploy alternative, that compromise is exactly what led me to build scontrol, a server control panel written in Rust.
- Traditional Web Hosting Panels (e.g., HestiaCP, CloudPanel, cPanel): They excel at managing multi-runtime PHP-FPM, Python, and Node.js sites. However, they almost completely ignore modern GitOps, Docker Compose microservices, and containerized deployment workflows. Furthermore, their heavy reliance on Bash string concatenation creates inherent remote-code-execution (RCE) attack surfaces.
- Modern Self-Hosted PaaS Platforms (e.g., Dokploy, Coolify): They offer delightful developer ergonomics and Git-push-to-deploy workflows. However, they bring immense runtime baggage: heavy Node.js / Next.js processes, forced Docker Swarm overlays on single-node setups, and auxiliary proxy containers like Traefik. As a result, your host server easily eats 1 to 2 GB of RAM before serving a single line of application code.
Frustrated by having to choose between legacy script-based control panels and bloated container-in-container PaaS stacks, I decided to engineer a solution tailored to my own infrastructure needs: scontrol.
In this article, I share the technical story behind scontrol, its architectural principles, how it compares with Dokploy, and why Rust is the ideal foundation for server management.
What is scontrol?
scontrol is a memory-safe, lightweight server control panel and PaaS deployment engine built in pure Rust for Ubuntu and Debian hosts. It is designed as a lean Dokploy alternative that also hosts native PHP and Node.js sites.
Its core philosophy is straightforward: Leverage the host system’s native capabilities, eliminate redundant abstraction layers, and enforce absolute security at the compiler level.
scontrol unifies two previously separate worlds into a single, cohesive dashboard:
- Native Multi-Runtime Web Hosting: Manage PHP (via PHP-FPM), Node.js, Python, static assets, and Nginx reverse proxies out of the box.
- Dokploy-Style Docker PaaS: Deploy Git repositories or raw Docker Compose projects with an asynchronous deployment queue, bounded log retention, live log streaming, zero-downtime redeploys, and automatic Let’s Encrypt certificates.
Why Rust? Resource Footprint and Memory Safety
The primary duty of a server control panel is to manage resources for your applications, not consume those resources itself.
Node.js-based panels incur significant overhead: a V8 runtime, background package managers (pnpm), and WebSocket daemons can consume hundreds of megabytes of resident memory. In contrast, scontrol runs directly on the host as two lean, compiled Rust binaries:
panel-api: An unprivileged daemon running as userscontrol, powering the Axum HTTP server and built-in Model Context Protocol (MCP) server.panel-agent: A root-level host daemon that listens strictly over a local Unix domain socket (/run/scontrol/agent.sock) to perform privileged operations (Nginx, systemd, Certbot, Docker).
Measured Resource Footprint (Benchmarks)
| Component / Metric | scontrol Footprint | Notes |
|---|---|---|
| Idle Memory (scontrol Daemons) | ~15 – 50 MB RAM | Combined panel-api + panel-agent. Measured at 13.9 MB total idle RSS on release builds. |
| Total Base System Idle RAM | ~80 – 130 MB RAM | Includes scontrol daemons + PostgreSQL (panel state) + Host Nginx. |
| Base Disk Footprint | ~300 – 450 MB | Stripped binaries (~35 MB), compiled React frontend, and minimal OS dependencies. |
| Idle CPU Utilization | Practically 0% | Event-driven deployment queue (tokio::sync::Notify) with zero busy-waiting loops. |
Dokploy Alternative Architecture: scontrol vs. Dokploy
Dokploy is an admirable platform, and scontrol draws conceptual inspiration from Dokploy’s intuitive deployment experience. However, our underlying architectures, resource constraints, and security models are diametrically opposed:
+-------------------------------------------------------------------------------+
| DOKPLOY |
| Node.js 24 + Next.js + Traefik Container + Docker Swarm + In-Memory Queue |
| (High RAM consumption, 300+ bash shell string executions) |
+-------------------------------------------------------------------------------+
VS
+-------------------------------------------------------------------------------+
| SCONTROL |
| Pure Rust + Host Nginx + Direct Docker Compose + Durable PostgreSQL Queue |
| (15-50 MB RAM, Zero shell execution, Compiler-enforced type safety) |
+-------------------------------------------------------------------------------+Here is a side-by-side technical breakdown:
| Feature / Criteria | Dokploy | scontrol |
|---|---|---|
| Core Runtime Stack | Node.js 24 + Next.js 16 + tRPC + pnpm (~100–300+ MB idle RAM for panel alone). | Pure Rust (axum, tokio, #![forbid(unsafe_code)], ~15–50 MB idle RAM). |
| Deployment Mode | Heavy containerized stack (dokploy, traefik, postgres, cAdvisor). | Native host daemons: 2 lean Rust services (panel-api unprivileged + panel-agent root). |
| Reverse Proxy & Routing | Traefik v3 Container (Runs as an extra, always-on container managing certs and labels). | Host Nginx (Uses the host’s existing Nginx vhosts with loopback reverse proxies; zero extra container overhead). |
| Orchestration | Enforces Docker Swarm on every install, even single-node setups. | Native Docker Compose v2 without Swarm overlay networking or task-polling delays. |
| Hosting Scope | Containers / PaaS only. Cannot host native PHP, Node, or Python applications. | Unified Hosting + PaaS: Native PHP-FPM, Python, Node.js, static sites, plus optional Mail & Antivirus and Dokploy-style Compose Git PaaS. |
| Process Execution & Security | Uses shell strings (execAsync, bash -c) with regex blocklists to prevent command injection. | Zero shell execution: Shells (sh, bash) are excluded from ALLOWED_PROGRAMS. All commands use typed Command::new(..).arg(..) vectors (RCE structurally impossible). |
| Secret Management | Credentials may be passed on command-line arguments (ps-visible) or stored unencrypted. | Zero credentials on argv (GIT_ASKPASS, GIT_SSH, 0600 files, stdin). Secrets at rest are sealed with AES-256-GCM (SecretBox). |
| Deployment Queue | In-memory queue. Deployments are lost on restart, and concurrency is effectively serialized. | PostgreSQL-backed durable queue (FOR UPDATE SKIP LOCKED). Survives panel restarts; separate projects deploy concurrently. |
| Cancellation Handling | Cancelling runs a host-wide pkill -f "docker build", killing all builds across the host. | Process-group cancellation (SIGINT → SIGKILL after 10 s) targeted strictly to the specific deployment. |
| AI & MCP Integration | No native Model Context Protocol (MCP) server. | Native built-in MCP server (/api/mcp) for Cursor, Claude Desktop, and AI coding agents. |
| Infrastructure Tracking | Configuration changes are internal to the panel database. | Automated GitHub Pull Requests on host configuration changes (scontrol-git-sync). |
Key Engineering Decisions
1. Zero Shell Invocations (Strict Process Safety)
The fatal flaw of most web control panels is evaluating commands through dynamic shell strings (e.g., format!("systemctl reload {}", service)). A single unescaped parameter can lead to immediate server compromise.
In scontrol, process spawning is restricted to panel-agent/src/adapters/exec.rs, whose ALLOWED_PROGRAMS list explicitly excludes every shell (sh, bash, dash, zsh). Commands are constructed solely with typed argument slices (&[&str]). Shell injection vulnerabilities are eradicated at the compiler level.
2. Durable, Restart-Safe Deployment Queue
If a server reboot occurs during an active build, an in-memory queue drops pending jobs. scontrol uses a durable PostgreSQL queue utilizing FOR UPDATE SKIP LOCKED. Separate projects build in parallel across configurable worker pools (PANEL_DEPLOY_WORKERS), and active jobs survive API restarts.
3. Bounded Disk Growth by Design
Unbounded Docker logs and build artifacts often crash production VPS instances. scontrol enforces strict resource bounds: every deployment log is capped at 5 MiB, and only the last 20 deployment logs are retained per project (deployment_log_max_bytes = 5242880, deployment_logs_retained = 20).
4. Built for the AI Era: Model Context Protocol (MCP)
Modern software engineering relies on autonomous AI coding agents (Claude, Cursor, Copilot). scontrol implements native MCP server endpoints (/api/mcp). An AI assistant can inspect system capabilities, provision staging environments, deploy updated Git commits, and report container statuses via typed RPC calls.
Current Status: Private Dogfooding Phase
I want to emphasize an important point regarding availability:
Important: scontrol is not yet publicly released.
I am currently running scontrol across my own production VPS instances and live workloads (dogfooding phase). I am rigorously verifying real-world edge cases: long-running queue resilience, Nginx TLS reload stability under zero downtime, ACME challenge automations, and GitOps synchronization.
Once end-to-end integration testing and stability benchmarks are fully satisfied, I will open-source scontrol for the broader DevOps and engineering community.
If you are interested in following development progress, discussing architectural ideas, or exchanging thoughts on modern server management, feel free to connect via umutbey.com or LinkedIn!
If you are evaluating a Dokploy alternative for your own servers, stay tuned for upcoming technical benchmarks and release announcements!