Kamal injects `--log-opt max-size=10m` without checking the server’s logging driver
- Dominant language
- Ruby
- Stars
- 14.6k
- Forks
- 752
- Avg merge
- 4d 23h
- Merged PRs (30d)
- 8
Description
**Kamal version:** 2.8.2
When deploying with `kamal deploy` **without specifying any logging driver or log options**, I expect Kamal to follow the server’s Docker daemon defaults.
I understand that Docker’s default logging driver is `json-file`, and it seems the intention behind auto-injecting `--log-opt max-size=10m` for both the app container and `kamal-proxy` is to help prevent logs from filling up disk space. That makes sense and is generally helpful.
However, it looks like this logic doesn’t check which logging driver the server is actually using. The option gets added whenever nothing is configured in `deploy.yml`, which assumes the server is still on the `json-file` default.
In my case, I recently changed the server’s logging driver to **`fluentd`**, and after that both my app container and `kamal-proxy` failed to start because the `fluentd` driver doesn’t support the `max-size` option. This made deployments fail unexpectedly.
Right now my workaround is to explicitly set the logging driver to `fluentd` in each app’s Kamal config. This works, but becomes a maintenance issue since I have many apps deployed to the same VM. Any time I want to adjust logging behavior, I would need to update every app config individually.
### Proposal / Discussion
Would it make sense for Kamal to detect the server’s logging driver before injecting log options?
For example:
- Only inject `--log-opt max-size=10m` when the server is actually using the `json-file` driver.
- Otherwise, defer completely to the server’s configured default.
This would keep the current safety behavior for most users, but also allow setups that rely on alternative drivers (like `fluentd`, etc.) to work without extra configuration in every app.
I’d love to hear your thoughts. Happy to help test or provide more info if needed.
Contributor guide
Research direction
Start with the kamal deploy path that injects Docker logging options for the app container and kamal-proxy. Reproduce the behavior with a server using fluentd, compare it with the json-file case, and verify that deployments defer to the server default when no logging configuration is given.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, ruby
- Domain
- devops, infrastructure
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100