Why should a containerized service write its logs to stdout instead of a file inside the container?

### The container log stream is a definition, not a convention When the engine starts a container it does not attach a debugger or tail a directory. It creates pipes for the main process's file descriptors 1 and 2 -- stdout and stderr -- and reads them. Everything downstream is built on that: `docker logs` replays what was captured, and a managed platform's log view is fed from the same stream. So "log to stdout" is not a style preference borrowed from twelve-factor dogma; it is the only channel the surrounding machinery is defined to read. Two consequences follow immediately. First, only the **main** process's descriptors are captured. A background process your entrypoint script forks off, writing to its own file, is outside the stream unless its output is redirected into the parent's. Second, the stream is untyped bytes plus a timestamp -- the engine does not know what a log record is, which is why formatting is entirely the application's problem. ### What actually goes wrong with a file Consider a Spring Boot photo-thumbnail service whose Logback configuration writes a rolling file appender to `/var/log/thumbnailer.log`. Four separate problems appear the moment it runs on a managed platform. **It is invisible.** `docker logs` shows nothing and the platform's log pane is empty, because neither reads the container's filesystem. The first symptom is usually an engineer insisting the app "isn't logging", when in fact it is logging enthusiastically into a place nobody watches. **It is per-replica.** The file lives in that container's writable layer, which is private to that container. Six replicas of the thumbnail service produce six files, each holding a random sixth of the traffic. Answering "what happened to this one upload" now means finding the right replica first, and the replica may already be gone. **It is unrotated.** Inside a container there is normally no cron and no rotation daemon -- the image ships one process, and that is the point. A rolling appender configured inside the app can cap its own file, but anything else that writes (a startup script, a library dumping a heap report) grows without bound and eventually consumes the container's ephemeral storage allowance, at which point the platform kills the container for a disk reason that looks nothing like a logging problem. **It dies with the container.** The writable layer is discarded when the container is removed, and a managed platform removes containers constantly: every deploy, every scale-in, every restart after a crash. The logs you most want are the ones written by the instance that just went away. ### Doing it properly Configure the application's logging framework with a console appender and delete the file appender. For a JVM service that is a one-line change; Spring Boot's default configuration already logs to the console, so the usual fix is removing a `logging.file.name` setting someone added to make local development tidier. For a third-party component you cannot reconfigure, the classic Docker trick is to symlink its log path to the container's stdout at build time -- the official Nginx image does exactly this for its access and error logs. The symlink resolves at runtime through `/dev/stdout` to `/proc/self/fd/1`, so writes land in the captured stream. Its one caveat is that a process which truncates or reopens the file rather than appending to it can break the trick. ### Two details that separate a middle answer from a senior one **Buffering.** When stdout is a pipe rather than a terminal, some runtimes switch from line buffering to block buffering, so output appears in kilobyte-sized bursts or, worse, is lost entirely when the process is killed. Python needs `PYTHONUNBUFFERED=1` or `python -u` for exactly this reason. If your logs arrive minutes late or stop just before a crash, suspect buffering before you suspect the collector. **Multi-line records.** The stream is line-oriented, so a Java stack trace arrives as forty independent lines and a downstream collector will happily index it as forty unrelated records. Structured logging -- one JSON object per line, with the exception rendered into a field -- solves this at the source and is far more reliable than asking every collector to reassemble multi-line events with a regular expression. ### Where the boundary sits The image's contract stops at "emit one well-formed record per line on stdout, with stderr reserved for genuine errors". What happens to the stream afterwards -- which collector consumes it, how much is buffered on the host, how long it is retained -- is the platform's or the engine's configuration, not the image's. That separation is the point: the same image writes the same lines in local development, in a test run and in production, and only the destination changes.