Overview
What VAC is, what it isn't, and the mental model behind it.
VAC is a self-hosted Platform-as-a-Service for a single VPS. You connect a Git repository; VAC clones it, builds it as a Docker Compose stack, fronts it with Caddy for automatic HTTPS, and shows it all on a real-time dashboard — live logs, deploy timeline, container health, and CPU/RAM. One operator, one box, no Kubernetes.
The target footprint is under 200 MB of RAM at idle (excluding the database). VAC is meant to disappear into the background and leave the machine's resources for your apps.
What you get
- Git → live. Point VAC at a repo; it clones, builds the Compose stack, and routes traffic.
- Automatic HTTPS. Caddy provisions Let's Encrypt certificates on demand. Every app gets an
{app}.{domain}subdomain, and you can attach custom domains. - Real-time dashboard. Build and runtime logs, deploy history, container health, per-service and host CPU/RAM — all streamed over WebSocket.
- Safe deploys. Rollouts are health-gated through Caddy. A failed deploy never tears down the running version; failure is recorded as state, not a rollback.
- Secrets encrypted at rest. Environment variables, SSH deploy keys, TOTP secrets, and notification webhook URLs are sealed with AES-256-GCM.
- Auth with 2FA. Operator login with TOTP, plus step-up confirmation for destructive actions.
- Optional managed add-ons. Managed databases, scheduled backups, and an add-on catalog — all behind a single feature flag, zero footprint when off.
- Notifications. Deploy and health events to Discord or Slack.
What VAC is not
VAC deliberately stays small. Understanding the boundaries up front saves disappointment later.
- Not multi-node. There's no cluster, no scheduler spreading work across machines. One host runs the control plane and every app.
- Not Kubernetes. No CRDs, no operators, no service mesh. The unit of deployment is a Docker Compose stack.
- Not a build farm. Builds run on the same box that serves traffic. That's fine for the single-VPS target; it's not a CI system.
- Not a managed cloud. You own the machine, the data, and the master key. VAC is software you run, not a service you rent.
The mental model
Three concepts carry most of the system:
| Concept | What it is |
|---|---|
| App | One Git repository (or add-on template), with a branch, build configuration, environment variables, and domains. The unit you create in the dashboard. |
| Service | One container in the app's Compose stack — a web, a worker, a db. Services that expose an HTTP port get routed and health-checked; others run as background workers. |
| Deployment | One attempt to take a commit live: clone → build → up → health-check → running. Deployments are recorded with their commit, status, and logs. |
Routing is by DNS alias, not host ports: each HTTP service joins the vac-edge network
under the alias {app}--{service}, and Caddy routes {app}.{domain} to it. Your apps never
publish ports on the host — Caddy owns :80 and :443.
Open source
VAC is open source under the Apache 2.0 license, developed in the open at github.com/vojir-mikulas/vac. You own the software the same way you own the box it runs on — read the code, audit it, fork it, or run a patched build.
- Contribute — issues and pull requests are welcome; start with
CONTRIBUTING.mdin the repo. - Report a vulnerability — follow
SECURITY.mdinstead of opening a public issue.
VAC is usable but early — expect rough edges, and expect them to be filed down quickly. Bug reports and feedback genuinely shape where it goes.
Where to look first
Quick start
Install VAC and ship your first app in about fifteen minutes.
Architecture
How the control plane, proxy, worker, and database fit together.
Deploy a repository
Connect a repo, pick a branch, and run your first deploy.
Installation
Every installer option, flag, and configuration knob.