An image is a packaged artifact. A container is a running instance of it.
A build makes an artifact
Your repository contains source code and instructions for building it. A build resolves dependencies and produces something that can run. For a container deployment, that artifact is an image: application files, runtime dependencies, and metadata such as the startup command.
A Dockerfile or a buildpack can describe that process. Building an image is separate from running it. A successful build does not prove that the application starts with the configuration and resources in your deployment environment.
A registry stores images
A container registry distributes image artifacts. A tag, such as a release name, is a convenient label. Depending on the registry’s policy, a tag can be moved to another image. A digest identifies the content of a particular artifact.
When diagnosing a deployment, record the source commit and image digest. “We deployed main” describes a moving reference. It does not identify exactly which files a running service received.
A container starts a process
A container runs a process using an image, configuration, resource limits, and networking supplied by the platform. Multiple containers can use the same image with different settings. A frontend, worker, and migration job may share code while using different startup commands.
Configuration belongs outside the image when it varies by environment. Credentials belong in explicit secret bindings, not source code or a public image. Do not print them while debugging.
Keep durable data separate
A container’s writable layer is temporary. Replacing a container can discard it. Databases and uploaded files need an explicitly configured durable storage destination, and that destination needs a recovery plan.
An image must also fit the platform: CPU architecture, permissions, startup behavior, filesystem paths, and required resources all matter. An image existing in a registry does not prove it runs successfully under a non-root policy.
In Hakopod
You can start from a registry image or connect a Git source and review its build configuration. The application definition records services, resource settings, ports, and storage. Review the proposed deployment, then inspect the result. The template catalog makes prerequisites visible; prerequisite guides are not deployable presets.
Try the idea
For one service, identify its source commit, image digest, startup command, listening port, and durable data location. Those five facts give you a much stronger debugging starting point than a green build badge.
Does rolling back an image also roll back the database?
Reveal the answer
No. A previous image changes the application code that runs. Database changes and external side effects require their own compatibility and recovery plan.