by Vitaly NikitinMost deployment tools assume you start with a cloud account. You pick a region, provision a managed cluster, wire up a registry, and eventually — after an hour and three IAM policies — you deploy a container.
Simple Container now works the other way. If you have a machine you can SSH into, that is enough.
The “I have a VPS” path
The new vm resource type and byo driver let you point Simple Container at any host — an address, a username, and an SSH key. From there, SC builds your image in CI, ships it over SSH as a compressed archive, renders a Docker Compose stack on the host, and puts Caddy
in front for automatic TLS. Blue-green deploys happen via caddy reload. The old container keeps serving until the new one passes its health check.
We ran the smoke on a plain VPS and measured the update gate: 3,092 probe requests across a full deploy window — 3,092 × HTTP 200, zero errors. The blue-green flip itself was atomic between two probes 194 milliseconds apart. A second independent re-smoke on the merged code ran 853 requests across two flips, zero non-200 responses.
One honest caveat: the current proof uses nginx as the workload. Forge services are not yet adapted to run on the VM target — that work is next. What’s shipped is the delivery mechanism: any image you build can go on any machine you own, with a working TLS certificate and a zero-downtime update gate.
The image transfer step is also idempotent: sc image ship checks the image id against what’s already on the host and refuses to re-upload if it’s the same build. It also validates architecture before transferring — no silent SIGILL at runtime.
k3s on a bring-your-own host
The second new delivery target goes further: SC can now install k3s — the lightweight Kubernetes distribution — over SSH onto any host you point it at, then export a kubeconfig and use it the same way it uses a GKE Autopilot cluster.
That’s the part worth pausing on. The new k3s-cluster resource exports its kubeconfig under the same stack-output name the GKE target has always used. Everything above that seam — the Kubernetes deploy path, Caddy routing, the Helm operators — is reused completely unchanged. Adding a new cluster type meant writing one new resource, not rebuilding half the platform.
The live smoke result: kubectl get nodes returned Ready on k3s v1.36.5+k3s1, a cloud-compose stack deployed through the unmodified Kubernetes code path, the LoadBalancer Service got an EXTERNAL-IP, and curl returned HTTP 200 in 48 ms.
One scoping note: destroying a k3s-cluster resource does not currently uninstall k3s from the host — the Delete lifecycle hook is not yet implemented, so the process stays on the machine. Something to know before you provision into a box you want to fully reclaim.
The debugging story worth telling
The k3s smoke found six bugs in already-merged code — which is exactly what smokes are for. The most instructive one: a reflection helper deep in the configuration parser was normalising every nil slice and map to an empty value. That destroyed the nil-vs-empty distinction for every flag in every parsed config.
The practical result: --disable traefik was never rendered. Every k3s cluster kept Traefik running on ports 80 and 443, so the first LoadBalancer Service sat <pending> indefinitely — with no error message anywhere in the logs. The unit test for the flag-rendering logic passed the entire time, because the test never ran through the affected code path.
Green does not mean correct. The smoke caught it. The fix is shipped.
What this changes
Until now, every Simple Container deployment target required either a managed Kubernetes cluster or a Yandex Cloud account. Both are good answers for a lot of workloads. Neither is the right answer for “I have one VPS and I want my app on it with a valid certificate and zero-downtime deploys.”
That path now exists. Bring your own machine. sc provision, sc deploy, done.
The k3s path goes a step further: if you want the full Kubernetes surface — Helm, operators, LoadBalancer Services — on hardware you own, SC will install the cluster, wire the registry, and hand you a kubeconfig that works with every SC deployment primitive that exists today. No cloud account, no hosted control plane.
The release is tagged 2026.10.24
in the public repository, with a CycloneDX SBOM, SLSA in-toto attestation, and cosign bundle attached.
If you’re running workloads on a VPS today and the existing cloud-first deployment story hasn’t fit, this is the path we built for you .