VPS deployment automation · Independent builder
SimpliCD
Simple Deployment Automation
Continuous deployment for VPS and bare-metal servers. Point it at a repository and it builds, starts, health-checks, and rolls back a release that doesn't come up healthy. No Docker, Kubernetes, or agents.
- Stack
- PythonLinuxGitYAML
Simple continuous deployment for VPS and bare-metal servers. No Docker, no Kubernetes, no agents. Point it at a repository and it deploys, keeps the process alive, and rolls back a release that doesn't come up healthy.
01The Problem
A lot of deployment tooling assumes the target environment is already complex: container orchestration, dedicated CI runners, multiple environments, and a team large enough to support that machinery. But many real deployments are much simpler. They are one or two servers, a handful of apps, and a need for reliable rollouts without ceremony.
That gap matters. When the deployment story is too heavy for the actual environment, teams end up with brittle shell scripts, manual SSH workflows, or a pile of tooling whose operational cost is higher than the application it exists to deploy.
02The Solution
SimpliCD is a self-hosted deployment daemon written in Python. A working config can be two lines, a project name and a repository, because SimpliCD detects the framework (Next.js, FastAPI, Django, Go and others) and derives the build command, start command, port and health check from it. You only write down what differs from the default.
03How a Deploy Works
- Lock - A per-project lock, so two deploys of one project can't race.
- Fetch - A shallow, single-branch clone, or a snapshot of a local folder.
- Build - Detect the framework, run the build, and refuse to promote a build that produced no output.
- Swap - Stop the old process and confirm it exited, wait for the port, then switch the version pointer.
- Verify - The new PID is alive, running from the new directory, and its health endpoint answers. Any failure rolls back and restarts the previous version.
04Key Features
- Three sources - Any git remote (SSH key or token), GitHub connected in one click through its own GitHub App, or a plain folder that still gets versioning and rollback.
- Push to deploy - GitHub pushes arrive by webhook, with the signature verified before anything runs.
- Rollback and supervision - Health-verified starts, automatic rollback, and crash monitoring of deployed apps.
- Dashboard - Server-rendered, no build step and no CDN, so it works on a machine with no outbound internet: deploy, roll back, logs, history and an environment editor.
- Secrets handled honestly - Deploy logs are redacted of known secret values; environment edits are atomic from the CLI and the dashboard alike.
- Diagnostics -
simplicd doctorfinds drift, orphaned processes and port conflicts. - Boot integration - Generates a systemd unit (or a Windows scheduled task) without installing it for you.
- Self-contained install - The
.debcarries its own Python, so it runs on distributions whose system Python is too old.
05Technical Stack
- Python 3.11+ - The daemon, CLI and deploy pipeline.
- Jinja2 - The server-rendered dashboard.
- Git - Sources, from any remote or the GitHub App.
- YAML - A short, strict config where unknown keys are an error.
- Linux (and Windows) - systemd on Linux; most features work on Windows too.
06The Rewrite
The first SimpliCD was written in Go. It worked, but too much of it was almost-finished, and its deploy pipeline had a race that could report success while still serving the previous release. That bug report became the specification for the new deployer: every finding in it has a regression test. The rewrite is still in progress, and simplicd migrate translates an old config, naming anything it could not carry across rather than dropping it.
07What This Shows
SimpliCD is probably the clearest expression of the kind of platform work I want to do. It focuses on deployability, runtime control, failure handling, and reducing operational drag for small teams. It is built from the perspective that infrastructure should match the scale and reality of the team using it.
08Why I Built This
I kept running into the same mismatch: my actual deployment environments were small and straightforward, but the common advice pushed me toward tooling designed for much larger systems. I wanted something that respected the reality of "a VPS with a few apps" while still behaving like real deployment infrastructure. SimpliCD came out of that need, and it deploys my own services today.
09Source
SimpliCD's source is private. It deploys the services on my own servers, and I'd rather not publish a map of the thing that runs them.
Next project
expo-yt-dlp
yt-dlp Inside React Native Apps