Introduction

Docker is built around applications writing logs to stdout and stderr, not directly to host files. If you want one file on the host, the usual solution is to read the container log stream on the host and redirect it there, while still letting Docker handle the container normally.

Redirect The Stream On The Host

If the container already logs to stdout and stderr, you can follow that stream and append it to a single file:

docker logs -f my-container >> /var/log/my-container.log 2>&1
docker logs --timestamps -f my-container >> /var/log/my-container.log 2>&1
docker compose logs -f api >> ./api.log 2>&1

-f keeps following the stream, >> appends instead of truncating, and 2>&1 sends stderr into the same file as stdout. This is the fastest answer when you need a simple host-side log file for debugging or support.

Know What Docker Actually Captures

docker logs only shows what the container writes to stdout and stderr through Docker's logging driver. If your application writes only to an internal file such as /app/logs/server.log, redirecting docker logs will not capture it unless the application also mirrors those messages to stdout. That is why containerized apps are usually configured to write structured logs to stdout and let the platform collect them.

If you genuinely need a real file rather than a redirected stream, another option is to bind-mount a host directory and make the application write its own file there. That gives you a stable file path, but it also couples the application to host storage details. For most container setups, stdout plus collection is cleaner.

Handle Rotation And Long-Running Use

A redirect command solves the immediate problem, but it does not rotate or compress the file automatically. If the container is noisy, the file can grow very quickly. Docker's own json-file driver can be configured with size limits even if you still choose to redirect the stream externally:

1services:
2  api:
3    image: my-api:latest
4    logging:
5      driver: json-file
6      options:
7        max-size: "10m"
8        max-file: "3"

That setting manages Docker's native log storage. Your redirected file still needs its own lifecycle, usually through logrotate, a wrapper process, or a collector that writes and rotates files safely.

Prefer A Collector For Durable Logging

For long-lived environments, a dedicated collector is usually better than a plain shell redirect. Tools such as fluent-bit or vector can read container logs, add metadata, rotate files, and forward the same data to another system. The shell redirect remains useful for development and for small operational tasks, but it is intentionally simple and has no built-in reliability features beyond the shell process itself.

Common Pitfalls

One common mistake is trying to create a host log file by redirecting inside the Dockerfile. That only affects processes inside the container and does not give the host a reliable logging strategy. Another issue is forgetting 2>&1, which leaves stderr out of the file and makes failures harder to diagnose. Teams also get surprised when the redirect stops after a container is recreated, because the command was attached to a specific running instance. Finally, if the app logs only to an internal file, docker logs will appear incomplete because Docker never saw those file writes in the first place.

Summary

• Use docker logs -f container >> file 2>&1 for a quick single host file.
• 'docker compose logs -f service works the same way for Compose projects.'
• Docker only captures stdout and stderr, not arbitrary files inside the container.
• Add timestamps and plan for rotation if the file will live longer than a short debug session.
• For durable production logging, prefer a collector or structured logging pipeline over an ad hoc redirect.