A running container
is only the start.

Review what you are deploying

Start with the application’s own installation documentation and release notes. Confirm the supported operating system or container architecture, minimum resources, dependencies, licence, and maintenance status. A copied Compose file is a starting point to inspect, not an assurance that it fits your environment.

Record the version you deploy. A version tag makes intent clearer than a floating tag such as latest; an image digest identifies exact image content. Pinning helps repeatability, but it does not supply security updates for you. You still need a process for reviewing and deliberately installing newer releases.

Read the configuration before starting it. Look for published ports, bind mounts, environment variables, required databases, privileged mode, and host networking. If you cannot explain a requested permission, find out why the application needs it before granting it.

Locate the data that must survive

A container’s writable layer should not be the only home for data you need to keep when that container is replaced. Identify the application’s persistent paths and map them to appropriate named volumes or bind mounts, following the application’s instructions.

Keep an inventory of the database, uploaded files, configuration, and required secrets. A volume makes data persistent; it does not automatically back it up. A database may need a logical dump or another database-aware procedure rather than a simple copy of its live files.

Check access from both sides

Decide whether a service is local to the host, available on the LAN, or deliberately reachable remotely. With Docker Compose’s port syntax, omitting a host IP normally publishes on all host interfaces. That can make a service more widely reachable than intended, depending on the surrounding network and firewall.

ports:
  - "127.0.0.1:8080:80"

This binds host port 8080 to loopback for container port 80 on a typical current Docker setup. It is a mapping example, not a complete application configuration. If a reverse proxy runs in a different container, its loopback address is not the host’s: use the appropriate shared container network and service address instead.

Check access from an intended client and from a network that should not have access. Review IPv4 and IPv6 exposure, router forwarding, firewall rules, and the Docker version’s networking behaviour. Do not assume a host firewall’s default policy alone covers Docker-published ports.

Use appropriate authentication and TLS where traffic crosses networks or carries sensitive information. Avoid exposing database ports and management interfaces publicly merely to make an application easier to connect.

Keep credentials and permissions deliberate

Replace default credentials and use separate accounts where the application supports them. Protect configuration and secret files with suitable filesystem permissions, and keep secrets out of source control. An environment file is still a file containing secrets; naming it .env does not encrypt it.

Grant only the mounts and privileges the application needs. Prefer read-only mounts when the service only reads data. Privileged containers and access to the Docker socket can grant extensive host control; do not add them as generic fixes for a permission error.

Record how you would regain administrative access after losing a device or an authentication factor. Store recovery material securely and separately from the service it unlocks.

Verify behaviour, not just process status

For an existing Compose project you own, these inspection commands are useful starting points. Run them from the intended project directory with the correct Compose files selected.

docker compose config --quiet
docker compose ps
docker compose logs --tail 100

Configuration validation checks whether Compose can interpret the configuration; it does not prove the application is correct or secure. Status and logs help locate problems, but a running process can still have broken authentication, missing storage, or a failed dependency. Logs can contain sensitive data—review and redact them before sharing.

Test the real user path: sign in with a non-admin account, perform the service’s main task, and read the result back. Check permissions between users if that matters to the application. Define what a useful health check should verify instead of assuming that an open port is sufficient.

During a planned maintenance window, test the documented restart behaviour and dependency ordering. Decide how you will notice a failure: an application check, storage-capacity alert, backup alert, or another signal tied to something that matters.

Plan the update and the way back

Before an update, read the migration notes, record the current configuration and version, and create a recoverable backup. Try substantial changes in a separate environment first. Keep the previous configuration available without exposing its secrets.

Rolling an image back is not always enough. If an update changes a database schema or file format, the old application may no longer understand the new data. Your rollback plan may require a compatible pre-update backup, a documented restoration procedure, and a decision about changes made since that backup.

Choose a maintenance window and define an acceptance check. If the updated service fails that check, stop and follow the recovery plan rather than stacking additional unreviewed changes on top.

Before you rely on it

Deployment acceptance checklist

• Source: Official installation guidance reviewed; application and image versions recorded.
• Persistence: Required data paths identified and tested across container replacement in a separate environment.
• Exposure: Intended clients can connect; unintended networks cannot.
• Permissions: Default credentials replaced; secrets, mounts, and host access reviewed.
• Behaviour: A normal user can complete the main task and retrieve the result.
• Operations: Restart behaviour, failure detection, updates, and recovery ownership documented.
• Recovery: A backup can be restored, and rollback accounts for data migrations.