The Logs view reads two different things: what your deployments write, and what the host's own services write. Both use the same viewer, so search, follow, and download work identically.
Deployment logs
Pick a deployment and the viewer shows its container output. Four controls sit above the log:
- Follow: streams each line as the container writes it, over a websocket, instead of re-reading a tail.
- Source: container output, or a file the application writes on disk.
- Service: all services, or one. A deployment with a web container and a worker no longer forces you to read both at once.
- Tail: the last 100, 500, or 1000 lines, or everything.
Filtering happens on the agent, not in the browser. A container writing a line a millisecond does not push all of it down the socket for the page to throw away.
Log sources
Container output is always available. On top of it, FlatRun knows where common applications write their own logs and offers those as sources automatically:
| Application | Source |
|---|---|
| Laravel | storage/logs/laravel.log |
| WordPress | wp-content/debug.log |
| nginx | logs/access.log and logs/error.log |
Anything else, use Point at a file on the deployment's Logs tab and give it a name and a path relative to the deployment directory. The path is resolved inside that directory, so a source cannot be pointed at the rest of the host. Because a file is written by the deployment as a whole, the service filter does not apply to one and is disabled while a file source is selected.
System logs
The System tab reads the host's shared services rather than a deployment. It needs the
infrastructure:read permission and offers whichever services are running:
- nginx access: every request through the proxy, taken from the container's standard output.
- nginx error: the proxy's own errors, taken from its standard error.
- database and redis: the shared infrastructure containers, when enabled.
Access and error are separate entries because nginx writes them to different outputs, and reading one should not mean scrolling past the other.
Access log by deployment
One proxy fronts every deployment, so its access log interleaves all of them. Each line records the host the request asked for, and picking a deployment keeps only the lines whose host is one of that deployment's domains. The host is a field of its own, so a domain that merely appears in a referer or a user agent does not produce a false match.
This applies to the access log only. An error log line says nothing about which site it belongs to, so the filter is disabled for it rather than returning an arbitrary subset.
Reading the output
The viewer has two modes, and the toggle sits at the top right:
- Structured: one row per entry with its timestamp, service, and level. Stack traces and other continuation lines fold into the entry above them. Chips along the top filter to errors, warnings, info, or debug, and each carries a count.
- Raw: a terminal that preserves the original bytes, including colour. Search with Ctrl+F, then Enter and Shift+Enter to move between hits.
Auto-scroll keeps the newest line in view and turns off when you scroll away. The toolbar also downloads what is on screen as a text file and expands the viewer to full screen.
Deleting a log
The trash button empties the log on the server, so it frees the disk the log was using. A file source is truncated in place, which leaves the application writing to the same file; a container source empties what Docker stored for that container. Either way a confirmation names exactly what is about to be emptied, and the action is not recoverable. Refresh, not delete, is what you want to clear your own view.
Deleting a deployment's logs needs deployments:write on that deployment; deleting a system log needs
infrastructure:write. A container that ships its output somewhere other than a file Docker owns cannot be
truncated from here, and says so.
Ask the assistant
The sparkle button hands the visible logs to the AI assistant and asks it to summarize them and report problems with possible fixes. It reads what you are already looking at rather than going hunting, so the answer covers the same window you filtered down to.
API
| Endpoint | Purpose |
|---|---|
GET /api/deployments/:name/logs | Tail, with tail, source, service, and filter |
GET /api/deployments/:name/logs/stream | Websocket follow, same parameters |
GET /api/deployments/:name/log-sources | The sources offered for a deployment |
PUT /api/deployments/:name/log-sources | Add or replace custom file sources |
GET /api/system/logs/sources | The system sources available on this host |
GET /api/system/logs | Tail, with source, tail, filter, and deployment |
GET /api/system/logs/stream | Websocket follow, same parameters |
Websocket endpoints authenticate with the token as their first message, since a browser cannot set headers on a websocket.