Start with separate decisions
A virtual machine is a place to run software. A container image is a packaged runtime artifact. CI/CD describes how changes are integrated, verified, and delivered.
These are compatible choices. A team can deploy container images to a virtual machine through an automated pipeline.
| Decision | Examples |
|---|---|
| Compute platform | Virtual machine, managed application service |
| Runtime form | Python process, application container |
| Release artifact | Source revision, Python wheel, container image |
| Automation | Manual procedure, deployment script, pipeline |
| Process lifecycle | Operating-system service manager, container platform |
Describing a deployment along these axes is more useful than asking whether it uses “Docker or CI/CD.”
Deploying source to a virtual machine
A source-based release can fetch a selected revision, prepare its dependencies, and restart an operating-system service. The application runs in the machine’s Python environment, often behind a reverse proxy.
Select revision
↓
Prepare source and pinned dependencies
↓
Restart or switch the application service
↓
Verify readiness and a representative request
This is direct to operate, especially for an established service. Reliability still requires identifying the deployed revision, controlling manual changes, and understanding what happens if installation or restart fails.
Updating a running environment in place can leave it partially changed. A source deployment can instead prepare separate releases and switch traffic or the active release reference once verification passes.
Restoring an earlier source revision does not automatically restore its dependencies, configuration, or database compatibility.
Deploying a container image
An image-based workflow packages the application and its user-space dependencies before deployment. The runtime platform receives the tested artifact rather than resolving the application environment from scratch.
Source + dependency resolution + image definition
↓
Build and test an image
↓
Store and identify the release artifact
↓
Deploy that same image
↓
Verify readiness and application behavior
An image digest identifies a specific image; a mutable tag alone can point to different contents over time. Promote the tested artifact across environments when possible.
An image does not package every aspect of the service. Host kernels, secrets, external databases, and persistent data remain separate concerns.
Compare the operational work
| Concern | Source-based release | Image-based release |
|---|---|---|
| Environment preparation | Often on the target machine or a release builder | Primarily during image build |
| Release identity | Source revision plus dependency and runtime information | Image digest plus runtime configuration |
| Recovery | Restore a compatible application environment | Select a compatible previous image |
| Continuous operation | Requires a restart or traffic-switch strategy | Requires a restart or traffic-switch strategy |
| Data changes | Need a compatibility plan | Need a compatibility plan |
Replacing a single application container can interrupt service. Zero-downtime rollout requires additional design around replicas, readiness, traffic switching, and graceful shutdown.
Where CI/CD fits
Continuous integration validates changes as they are integrated. Continuous delivery keeps validated changes ready for release and can include a human production approval. Continuous deployment automatically promotes changes that pass the required checks.
Either release model can be manual or automated. A pipeline should select a release, verify it, deploy it, check its behavior, and define a recovery path.
Start by making the existing release procedure explicit and repeatable. Add image packaging when it addresses a concrete environment or artifact-management requirement. Automation improves a defined process; it does not substitute for one.