Documentation
A self-hostable application deployment platform. One install script turns a fresh VPS into a portal that builds and runs Dockerised web applications behind an automatic TLS reverse proxy.
Sthora turns a plain VPS into a place to deploy web applications — Node and Python backends, React and Next.js frontends, full-stack apps, anything that builds into a container — without touching a terminal after the first install.
Point it at a Git repository, or upload a ZIP. It builds the application, runs it, health-gates it, and puts it behind Traefik with a certificate it issued itself. A push to the deployed branch ships itself.
Start here
Introduction
What the platform does, the two ways to run it, and what is deliberately not included.
Requirements
The machine, the software, and the two things you have to decide before installing.
Install
One script, run as root on a fresh Ubuntu or Debian box.
Deploy your first application
From an empty portal to a running application on a hostname, in order.
What it does
| Deploy from Git or a ZIP | Clone, build, run, health-gate. A signed webhook redeploys on every push to the branch. |
| Compose files, judged before they run | Your file is parsed, checked against a reject list, rewritten, and only the rewritten copy reaches Docker. |
| HTTPS that arrives on its own | Add a hostname, point the record shown to you, and a certificate is issued over HTTP-01 with no DNS API token. |
| Configuration that never touches disk | Environment variables are encrypted at rest, returned by no endpoint, scrubbed from build logs, and passed to Docker through one process's environment. |
| Monitoring of the machine | CPU, memory, disk, network, per-container usage, and steal time — which is how you learn a slow application is a noisy neighbour rather than your code. |
| Alerts | Disk pressure, sustained memory pressure, restart loops, failing health checks, expiring certificates, failed deployments, failed backups. In-app, by email, by signed webhook. |
| Managed data services | PostgreSQL, Redis, and MinIO with scheduled backups to local disk or S3, reachable by name and published on no port. |
| Rollback | Every deployment records the image it produced and the commit that caused it. Rolling back re-applies a previous image with no rebuild. |
The one thing to know first
The control plane holds the Docker socket
Anyone with admin access to the portal has root on the server. Every other design decision follows from that — see the security model before you give anyone an account.
Two ways to run it
Self-hosted. You run the control plane on your own VPS and it manages itself. No account, no subscription, no limits. This is what the installer gives you.
Cloud. Someone else runs the control plane and it manages servers you already own, reached through an agent that dials out from your machine. You open no inbound port and hand over no SSH key.
Both are the same build. The difference is three settings — AGENT_CHANNEL_ENABLED,
BILLING_ENFORCE_LIMITS, and SIGNUP_ENABLED — not a second code path.
Naming
sthora is the operational slug: it names the host paths (/etc/sthora,
/var/lib/sthora), the containers (sthora-api), the Docker network
(sthora-proxy), and the compose project. Every command in these pages uses it verbatim.