A fresh EC2 instance is not an environment. It is a Linux box with an IP address and a checklist attached. Someone still has to point a domain at it, terminate TLS, give it pull access
A fresh EC2 instance is not an environment. It is a Linux box with an IP address and a checklist attached. Someone still has to point a domain at it, terminate TLS, give it pull access to a private registry, and decide how code gets onto the disk. Until that work is done, the VM cannot accept a deploy.
ZopNight v1.16.0 closes that gap. ZopDay now provisions a complete AWS VM environment and deploys git- or image-based services onto it, with custom domains, HTTPS, and private registries included. The VM arrives ready to receive a deploy, not ready to be configured. That is the difference between a server and a platform.
This extends ZopDay's push-to-deploy model, which previously targeted Kubernetes, to a single managed virtual machine. The mechanism is the same. The blast radius is smaller.
The provisioned VM target ships ready, because the setup runs before you arrive
Call the new shape a provisioned VM target: a virtual machine that is already a valid deploy destination the moment it exists. The setup steps that normally trail a raw instance happen during provisioning, not after.
When ZopDay creates the environment, it attaches the custom domain, issues and installs the HTTPS certificate, and grants the private registry credentials in the same pass. The VM is reachable on its real hostname over TLS before any service is deployed. Nothing waits on a follow-up ticket.
This matters because the cost of a raw VM is not the instance. It is the drift. A box configured by hand diverges from every other box, because each one is set up under different time pressure by a different person. A provisioned VM target removes that variance: the environment is described once as code and produced the same way every time.
This is the same self-service logic behind internal developer portals, applied to a single machine instead of a fleet.
You deploy from git or an image, so the pipeline does not fork by service type
A provisioned VM target accepts two inputs: a git repository or a container image. ZopDay builds the repo, or pulls the image from your private registry, then places the service on the VM.
This avoids a common split. Teams usually run one path for services with a Dockerfile and another for services that arrive as a prebuilt image from a vendor or an upstream build. Two paths means two sets of failure modes and two things to keep current.
One target that reads both inputs collapses that into a single flow. A service built from source and a service shipped as an image land the same way, on the same machine, behind the same domain and certificate. The two inputs converge before the deploy step, so the rollout logic does not branch. The team reasons about one deploy path, not a matrix of them.
That is the push-to-deploy promise honored on a VM, and it is why the same workflow that drove the Kubernetes target carries over with no new mental model to learn.
Raw EC2 setup is a checklist, a provisioned environment is a result
The contrast is concrete. Here is what stands between a launched instance and a live service under each model.
| Step | Raw EC2 setup | ZopDay provisioned environment |
|---|---|---|
| Launch instance | Manual, choose AMI and security group | Provisioned by ZopDay |
| Custom domain | Edit DNS, wait for propagation | Attached at provision time |
| HTTPS certificate | Install certbot, renew on cron | Issued and installed automatically |
| Private registry access | Configure credentials by hand | Granted at provision time |
| Get code onto the box | scp, git pull, or custom script | Deploy from git or image |
| Repeatability | Diverges per box | Same result every time |
The raw column is six discrete decisions, each a place to make a mistake. The ZopDay column is one provision call. That is why a golden-path environment holds its shape while a hand-built one drifts within weeks.
It works for a managed VM target, and it breaks when you need bespoke networking
A provisioned VM target fits when you want a single managed machine as your deploy destination: a low-traffic service, an internal tool, a staging box, or a workload that does not justify a Kubernetes control plane. It works here because there is one machine to reason about and the platform owns its setup.
It breaks when you need bespoke networking. If the service requires custom VPC peering, specific subnet routing, private link endpoints, or a security posture that the golden path does not express, the managed VM will fight you. The whole value is that the network and certificate setup is decided for you. When you need to decide it yourself, that value inverts.
It also breaks when one machine is not enough. A single VM has no horizontal scaling and no self-healing across nodes. When traffic outgrows a box, you want orchestration. ZopDay's Kubernetes target exists for exactly that, and the choice between a VM and a cluster is now a real one rather than a default.
The release does not publish provisioning time or per-environment cost yet, so do not quote numbers we have not measured. What ZopNight v1.16.0 ships is narrower and more useful than a benchmark: an AWS VM that is a deploy target the moment it exists, with the three boring prerequisites already done.
Frequently Asked Questions
Q: How does the provisioned vm target ships ready, because the setup runs before you arrive apply in practice?
See the section above titled "The provisioned VM target ships ready, because the setup runs before you arrive" for the full breakdown with examples.
Q: How does you deploy from git or an image, so the pipeline does not fork by service type apply in practice?
See the section above titled "You deploy from git or an image, so the pipeline does not fork by service type" for the full breakdown with examples.
Q: How does raw ec2 setup is a checklist, a provisioned environment is a result apply in practice?
See the section above titled "Raw EC2 setup is a checklist, a provisioned environment is a result" for the full breakdown with examples.
Q: How does it works for a managed vm target, and it breaks when you need bespoke networking apply in practice?
See the section above titled "It works for a managed VM target, and it breaks when you need bespoke networking" for the full breakdown with examples.
Drop a comment if you've audited a similar spike. What was the dominant cause for your team? Share what worked or what blew up.
Top comments (0)