In this lesson, you will learn how to decouple your application’s environment-specific settings from your container images by using Docker Swarm Configs to inject configuration files directly into your running services.
Why Decouple Configs from Images?
Previously, we learned how to use .env files and Docker Secrets. While Secrets are perfect for sensitive data like passwords, they aren't meant for general configuration, like application settings, feature flags, or custom Nginx templates. If you bake these files directly into your Docker image, you have to rebuild and push a new image every time you change a single line of config. Docker Swarm Configs solve this by allowing you to manage these files externally from your images.
Injecting Configs into Services
A Swarm Config is an object stored within the Swarm raft database. Because it is managed by the orchestrator, it is available to every node in the cluster, regardless of where the service container happens to be running.
To use a config, you first create it from a local file:
docker config create app_config ./my-app-settings.json
Once created, you map it to your service in your deployment configuration. When the service starts, the Swarm manager mounts this config as a file inside the container (typically at / or /config by default).
services:
web:
image: my-app:latest
configs:
- source: app_config
target: /etc/app/settings.json
When your application launches, it reads the file at /etc/app/settings.json exactly as if it were part of the filesystem. If you need to update the configuration, you update the config object in Swarm and trigger a rolling update. The containers will be redeployed with the fresh settings without you ever needing to touch the original image.
This approach creates a clean separation of concerns: your image contains the logic, while the Swarm Config holds the specific behavior for that environment. This makes your application truly portable across staging, development, and production clusters.
Key Takeaway: Docker Swarm Configs allow you to inject non-sensitive configuration files into containers at runtime, enabling environment-specific behavior without modifying or rebuilding your application images.