Opsy now deploys to Docker hosts too

Not every team runs Kubernetes. Often services live on one or two VMs with Docker, and a deploy means ssh, docker compose pull and hoping nothing breaks. Opsy can now deploy there too: to a plain Docker server, with the same form, permissions, environments and audit as for a cluster.

One command to connect

The server gets the same Opsy agent as Kubernetes, just as a container: the Opsy admin panel gives you a ready docker run command. The security model stays the same: the agent reaches Opsy over outbound HTTPS for tasks, there are no inbound connections to the server, and we never get SSH access or server keys. For domains, the agent runs Traefik on the host.

Deploy like to a cluster

In Opsy a Docker host is just another target next to clusters. An app ships from the same form or automatically on push to a branch, and dev → stage → prod environments work with promotion between them. During a deploy you see live steps: image pull, start, health check. If the service fails to start, Opsy rolls it back to the previous version by itself, and from history a rollback is one action.

Service catalog

Databases, brokers and storage from the catalog install in a couple of clicks - 12 services today (listed below). Versions are pinned, passwords are generated and stored encrypted, data lives in a named volume. You can adjust the template (for example, pull the image from your own registry) or paste your own docker-compose.yml. A service can be marked shared so other apps on the same host can use it.

Domains and TLS

You set the domain in the form, and a Let's Encrypt certificate is issued and renewed automatically: all it takes is an A record pointing to the server and port 80 open. For closed perimeters with no inbound internet, you plug in your own certificate from "Deploy defaults" - the same one used for clusters.

Compose under control

An agent with Docker access on a server is effectively root, so Opsy checks every compose file before it runs: privileged, host network, host pid and ipc, cap_add, host path mounts, docker.sock and devices are rejected. Data goes only to named volumes. Permissions on apps and environments and the action audit are the same as for Kubernetes.

Observability

Containers, logs and host resources open in the same interface as for a cluster: the same log window with search and live updates, CPU and memory per container, volumes and images.

What stays Kubernetes-only for now

Autoscaling, resource recommendations, canary and blue-green deploys remain cluster features. On a Docker host compose up recreates the container, so a deploy can cause a short downtime.