Introduction

You can use a secrets section in Docker Compose without running Swarm, but the behavior is not the same as Swarm-managed secrets. In a regular Compose setup, the secret usually comes from a local file and is mounted into the container as a file. That is useful for development and small deployments, but it does not provide the same orchestration-level secret management guarantees that Swarm does.

What Compose Secrets Mean Without Swarm

In Swarm mode, Docker has a built-in secrets subsystem with distribution and runtime handling integrated into the orchestrator. Outside Swarm, Compose can still model secrets in the Compose file, but they are generally backed by local files on the host.

So the practical meaning becomes:

• keep secret values out of the image,
• mount them as files instead of baking them into environment variables or source code,
• manage the source file yourself on the host.

That is still useful. It is just not the same security model as Swarm.

A Basic Compose Example

A common pattern looks like this:

1services:
2  app:
3    image: nginx:latest
4    secrets:
5      - db_password
6
7secrets:
8  db_password:
9    file: ./secrets/db_password.txt

Inside the container, the secret is typically available as a file under a path such as /run/secrets/db_password.

Reading The Secret In The Container

Applications should read the mounted file instead of hardcoding the value.

1with open('/run/secrets/db_password', 'r', encoding='utf-8') as f:
2    password = f.read().strip()
3
4print(password)

This keeps the secret out of the image and out of many command histories, although the host file still has to be protected.

Why This Is Better Than Plain Environment Variables

Environment variables are easy, but they also tend to leak into:

• shell history,
• process inspection,
• logs,
• debug output.

File-mounted secrets are often cleaner because the app can read them from a path and you do not have to inject the raw secret value into the process environment.

What You Do Not Get Without Swarm

This is the critical limitation. In non-Swarm Compose, you usually do not get the full Swarm secret lifecycle model such as cluster-wide managed distribution. The secret still starts as a normal file you must secure yourself.

So this pattern is helpful for:

• local development,
• single-host deployments,
• lightweight compose-based environments.

It is not a substitute for a real secret-management strategy in a larger distributed production environment.

A Good Development Workflow

A practical local pattern is:

• store the secret in a local file outside the image,
• keep the file out of version control,
• mount it through Compose,
• read it from /run/secrets/... in the application.

Also add the secret directory to .gitignore.

secrets/

That at least prevents accidental source-control exposure.

Compare With Other Options

You have several choices:

• environment variables: easy but leak-prone,
• Compose file-backed secrets: better separation for local setups,
• external secret stores: stronger for serious production systems.

The right answer depends on scale and threat model. Compose secrets without Swarm are often a pragmatic middle ground, not an end-state security architecture.

Common Pitfalls

• Assuming Compose secrets without Swarm provide the same guarantees as Swarm-managed secrets.
• Committing the source secret file into version control.
• Mounting the secret as a file but then printing it in logs during debugging.
• Treating local file-backed secrets as a complete enterprise secret-management solution.
• Forgetting to update application code to read from the mounted secret path.

Summary

• You can use Compose secrets without Swarm, typically as host file-backed mounted secret files.
• This is useful for keeping secrets out of the image and out of many environment-variable workflows.
• The secret usually appears in the container as a file such as /run/secrets/name.
• Without Swarm, you still manage and protect the source secret file yourself.
• This is a practical local and single-host pattern, not a full replacement for production secret orchestration.