[Feature Request] Retain application (container) logs across deploys — built-in persistence/retention

[ramazansancar]

Problem

Application container logs in Coolify are ephemeral. Every new deploy/build creates a new container, so the previous container's stdout logs are lost. When something fails on a deploy, I can't go back and inspect the logs from the previous container — they're already gone.

This makes post-mortem debugging hard: by the time I notice an issue and want to look at what happened, a redeploy (or auto-deploy on push) may have already replaced the container and wiped its logs.

What I'd like

A built-in way to persist/retain application runtime logs across deploys, without having to wire up an external stack myself. For example, any of:

• A per-application log retention setting (e.g. keep last N deploys' logs, or keep logs for X days), surfaced in the Logs tab.
• An option to persist the container stdout/stderr to a managed location that survives container recreation, viewable from the same Logs UI.
• Clear first-class documentation/UX for "I want my app logs to outlive a deploy".

What exists today (and why it's not enough)

• Drain Logs (external sink: BetterStack/Loki/etc.) works, but requires standing up and maintaining a separate log stack. For small/self-hosted setups this is heavy just to keep yesterday's logs.
• Persistent Storage volume + app-side file logging also works, but it pushes the responsibility into each app's logging config and a manual volume mount,
  rather than being a platform feature. It's also single-host (lost if the server dies).
• Docker log driver max-size/max-file increases in-container retention but a new container still starts empty, so it doesn't solve cross-deploy persistence.

Why built-in would help

Keeping the last deploy's logs available in the Coolify UI — even briefly — would massively help debugging failed/rolled-back deploys, without every user having to build their own log pipeline.

Environment

• Coolify: v4.1.2 (self-hosted)
• Build Pack: Docker Compose

Related discussions

Related existing discussions (overlapping but not the same request):

• Rework logs #2618 "Rework logs" — proposes a broader log UI/UX rework and mentions centralized log storage; this request is narrower and specifically about retaining a previous deploy's logs.
• large "Application Logs" #332 "large 'Application Logs'" — about pagination/limits for huge logs (dashboard crash), not about persistence across deploys.
• Logging stack #2229 "Logging stack" — discusses external logging stack approaches (aggregation), which is the external-sink workaround rather than a built-in feature.
• Step-by-step guide to monitor logs with Grafana, Loki, and FluentBit #5317 "Monitor logs with Grafana, Loki, and FluentBit" — community guide for an external pipeline; useful today but requires self-managed infrastructure.

This request is specifically about a first-class, built-in way to keep the previous deploy's application logs available in the Coolify UI, without standing up an external log stack.

[CraigBurden]

I completely agree, this would be a really helpful feature!

Possibly an extension to this feature, it is very frustrating that there isn't a log of deploys when using Docker Based applications like "Docker Compose Empty". In other application types like the Git based, there are historical logs showing that a deploy happened, when and what triggered it.
I don't see why that isn't possible for Docker based apps

As per the original feature request, if each of these retained the actual deploy logs too, that would be ideal

[NotDemonix]

Yeah I agree for example if the app crashes you can't see the logs as to why it crashed within coolify ui

[svallory]

Even a simple text file, created to store the logs in case of a crash, overwritten on new crashes, deleted when the app successfully starts would be a huge help in debugging!