Most teams pick a VM because the runtime is simple. Then they spend a week paying for that choice in firewall rules, SSH key rotation, a certbot cron job, and a DNS ticket. The VM was never the problem. The ops tax was.
ZopDay, shipped in ZopNight v1.15.0, removes that tax. You push code, it builds, and your service runs behind a managed L4 load balancer with TLS-terminated ingress. The VM sits in a private subnet with no external IP and no open management ports. We call this shape the managed-edge VM architecture: a plain virtual machine where every job that normally exposes it to the internet has been lifted off the box and onto a managed edge.
The management plane moves off the network and onto identity
A VM gets attacked through the ports it leaves open. The classic culprit is port 22. Credential-stuffing and brute-force only work because something is listening for them to reach.
ZopDay closes that path by design. The VM runs in a private subnet with no external IP. No inbound management port is open. There is no SSH daemon facing the internet, so there is no listening service for an attacker to target.
Operators still need in. So the control plane moves off the network and onto identity. Access is brokered through Google IAP, AWS SSM, or Azure Run-Command, depending on your cloud. You authenticate as a person with cloud permissions, not as a key on a laptop. This works because the broker checks identity before any session opens. It breaks if your cloud IAM is sloppy, because a broker only enforces the roles you actually scoped.
The only thing the public reaches is the managed edge.
One managed edge is what lets one VM host many services
The load balancer is L4, so it forwards transport connections rather than parsing every request. TLS is terminated at that edge with certificates issued through Let’s Encrypt. Renewal is the platform’s job, not a cron job you forget until the cert expires at 2am.
Custom domains attach from the UI, and DNS is configured automatically. You name the domain, it points the records, and the certificate follows. There is no DNS ticket and no hand-managed infrastructure config to fat-finger.
This is also why one VM can host many services. Because TLS and routing live at the managed edge, the box itself stays simple at its network boundary. Each service gets its own ingress without each service needing its own machine. You stop paying for one VM per app, which is the same density argument behind per-workload cost breakdown on Kubernetes, applied to plain VMs. For teams already watching non-prod VM waste, that consolidation is the point.
Kubernetes and the managed VM solve different problems
ZopDay deploys to VMs alongside Kubernetes, not instead of it. They are different tools, and the choice should be deliberate, the same way ECS, Fargate, or bare VMs each win in different situations.
Kubernetes earns its complexity when you need orchestration: rolling updates across replicas, autoscaling under bursty load, and per-pod scheduling. The managed-edge VM earns its place when you want a long-running service with a public endpoint and none of the cluster overhead.
| Concern | Kubernetes target | Managed-edge VM |
|---|---|---|
| Control surface | Cluster, nodes, pods, manifests | One VM, pushed from git |
| Ingress and TLS | Ingress controller you configure | Managed L4 LB, Let’s Encrypt TLS |
| Operator access | kubectl through cluster auth | Google IAP, AWS SSM, Azure Run-Command |
| Open inbound ports | Cluster API and node networking | None on the VM |
| Service density | Many pods per node | Many services per VM |
| Best fit | Orchestration, autoscaling, replicas | Long-running services, public endpoint, low overhead |
The decision rule is plain. Need orchestration and elastic replicas, take the cluster. Need a service online behind TLS without running a cluster, take the managed-edge VM. Picking the cluster for a single always-on service is the same mistake teams make when they over-provision Kubernetes resource requests: paying orchestration cost for a workload that never needed it.
When push-to-VM is the right call, and when it breaks
Stack detection reads environment variables from your codebase and .env, recognizes Node.js, Python, Go, Java/Kotlin, Ruby, and PHP, and pre-fills the deploy wizard. The mechanism is simple: it reads what your code already declares, so the wizard starts with values you would otherwise type by hand.
This works when your runtime is one of those six and your config lives in env vars and .env. It breaks when your service hardcodes config in a non-standard file, because detection has nothing to read and the pre-fill comes back empty. It also assumes a service that listens on a port and runs long. A batch job that exits is the wrong shape for a managed-edge VM.
Use it for a public-facing service you want online today without standing up a cluster. Skip it when you need pod-level orchestration or your stack falls outside the detected six. The managed-edge VM is not a smaller Kubernetes. It is the VM you always wanted, with the ops tax removed.
