Portainer log access for auto-removing failed containers: persistent logging driver or disable auto-remove?

Goal

Capture container logs in Portainer when a deployment fails immediately and the container is configured with --rm or a restart policy that removes it on failure.

Constraints

Portainer retrieves logs through the container engine's logging driver. If a non-standard driver (e.g., fluentd, gelf) is used, the UI may show no output. When auto-remove is enabled, the container and its default json-file logs disappear before the Logs tab can load. Real-time WebSocket streaming only works while the container exists.

Uncertainty

Two documented workarounds exist: configure a persistent logging driver that writes outside the container lifecycle, or disable auto-remove so the stopped container remains inspectable. The trade-off is between preserving the original deployment semantics (auto-remove) and guaranteeing log visibility in Portainer without CLI fallback.

Which approach reliably preserves logs for Portainer inspection? Does switching to json-file or journald guarantee UI parity with docker logs? Are there driver-specific limitations in Portainer's log viewer that would still require CLI access?