“It works on my computer” describes a common problem in software development. Certain libraries, settings and tools are available locally, but others are available on the server. Containers can help reduce these differences. However, they neither replace an operating concept nor the technical examination of an application.

Docker is a popular platform for building and running containers. What is particularly interesting for companies is how applications can be provided in a reproducible manner. The decision should be based on maintainability, infrastructure and team knowledge. Not every small website needs containers, and not every containerized application is automatically scalable or secure.

Distinguish image and container

An image is a template with the components intended for an application. A container is a running instance started from it. The official Docker documentation describes this connection as the basis of the operating model. Multiple containers can rely on the same template without sharing the same runtime state.

Linux containers use host kernel functions to isolate processes. This distinguishes it from a complete virtual machine with its own guest operating system. On other development platforms, a virtual Linux environment can also be used for this purpose. So containers provide a form of isolation, but not automatically the same security boundary as any virtualization solution.

Build the application in a comprehensible way

A declared construction manual records which base and dependencies are used. This turns a series of manual installation steps into a repeatable process. The prerequisite is that the entries are sufficiently checked. Changing tags or unspecified dependencies can cause the same build to produce a different result later.

In practice, traceable version statuses and a controlled build are helpful. A successfully built image should be checked and then adopted into other environments as unchanged as possible. If the product is rebuilt for production under different conditions, the previously tested variant may differ from the one actually delivered. Reproducibility must therefore be considered throughout the entire process.

Separate configuration from template

Database address, mail server and environment settings differ between development and production. They should not be carelessly incorporated into a commonly used image. Secrets such as passwords or access tokens in particular belong in designated, protected provision procedures. Even a secret that is deleted later can be retained in an earlier image layer.

The application must also understand missing or incorrect configuration. An automatic start is of little help if the wrong database is then accessed unnoticed. Clear checks and separate environments make sense for important settings. Production data should not serve as a convenient default basis for a local development environment.

Persistent data needs its own plan

The writable state of a container is not the same as permanent data storage. Docker provides volumes for this, among other things. Your data can outlast the replacement of a container. The official documentation describes volumes as independent of the lifecycle of individual containers. However, this property does not mean a backup.

Database and uploaded files still require consistent backups. Simply copying while writing is not suitable for every database. Depending on the system, special security procedures or coordinated times are required. It must also be checked whether restored data matches the application version used.

A typical thinking error

A fictitious portal stores documents directly in the container. After an update, a new instance is started and the old one is removed. Without intended permanent storage, documents may be missing. The error lies not in the update itself, but in an unclear data life cycle. Before introduction, each type of data should therefore be assigned to a storage and backup procedure.

Operate services together

An application can consist of web service, database and background processing. Tools like Docker Compose describe how to start and connect multiple services together. This can be helpful for manageable environments. Such a description must still consciously specify networks, storage and configuration.

The start order alone does not guarantee that a service is already technically operational. For example, a database can still be initialized. Applications should take temporary connection problems into account and allow for a controlled restart. A distinction must also be made between whether a process is technically running or whether it actually answers queries correctly. This requires appropriate health checks.

Consciously set safety boundaries

Containers should only be given the rights they need. Unnecessary privileged execution, additional host access, and exposed management endpoints increase risks. The Docker management interface is particularly sensitive. Depending on the configuration, whoever controls them can have far-reaching effects on the host.

Images and their base require regular updating. Containers also contain libraries with possible security vulnerabilities. The packaging does not eliminate this. Origin, dependencies and checks therefore belong in the build and release process. A smaller scope can make maintenance easier, but does not replace an assessment of the components actually used.

Organize updates and returns

One advantage of container-based deployment can be the exchange of a clearly identified application version. To go back, the previous template and its configuration must remain available. It becomes more difficult if the new version also changes database structures. An older application may no longer be able to work with the new data status.

Therefore, data migration and application change should be planned together. Gradual compatible changes may be necessary. A return procedure must be technically tested and take into account what new data has emerged since the change. Simply booting into the old image is not a complete recovery plan.

Operation remains visibly required

Logs, resource consumption and memory levels must be monitored. A restart mechanism can restart a failed instance, but cannot correct a faulty order. Error messages should be able to be linked to the application status and business processes. At the same time, confidential data in protocols must be limited.

To get started, we recommend a limited application with clearly documented dependencies. The team should be able to independently understand the setup, backup and restore. A complex orchestration platform is not automatically the next sensible step. The type of operation must match the actual needs and available capabilities.

Consciously practice changing containers for the first time

Before productive use, an application should be able to be started on a fresh environment from its documented components. This checks whether dependencies are really described or just happen to exist on the development computer. The test includes configuration, storage connection and a complete technical process.

The container is then replaced while the intended persistent data is retained. This shows whether files are in the right place and whether permissions continue to apply after the change. Temporary data is allowed to disappear, but binding business data is not. This separation should also be documented in a way that is understandable for new team members.

A second test uses a previously created backup on a separate target. The application must start with this copy and show the expected documents and data relationships. Only then can the statement be made that the security procedure fits the containerized application. Successfully archiving a directory alone is not enough.

For the handover, the image identifier, required configuration, storage locations and test procedure are recorded. This means that operations remain traceable if the original development environment no longer exists. Containers are particularly useful when this repeatability is demonstrated in practice and not just assumed as a feature of the tool.

When containers make a good contribution

Containers are particularly useful when reproducible environments and a controlled deployment process are needed. Your benefits come along with established dependencies, separated data and responsible operations. Without these fundamentals, the complexity just shifts to other files and tools.

GRITTMANN can check for individual applications whether container-based operation makes sense. Hosting, data storage and maintenance are considered together. The contribution to IT security in medium-sized businesses supplements the organizational foundations that remain necessary even with a modern container architecture.

Sources and further documentation

Technical basics and additional information from the respective editors. Links last checked on 28.08.2026.