## Description
> [!TIP]
> _Add a TL;DR when the description is longer than 500 words or
extremely technical (helps the content, marketing, and DevRel team)._
>
> _Please also include relevant motivation and context. List any
dependencies that are required for this change. Add links to Notion,
Figma or any other documents that might be relevant to the PR._
Addresses at least a couple of issues in a number of support tickets
about logs volume:
- we were double-logging all messages via Supervisor's
eventlistener:stdout configuration. Once to the sub-process's logs, and
once to another file in the logs/supervisor directory. The purpose of
this listener is to send logs to stdout/stderr so they can be picked up
by log aggregation services, no need to write again.
- we had debug logs enabled for Caddy which was creating quite a bit of
log volume in `logs/editor/<hostname>-stderr.log`
- bonus fix: in a multi-container deployment, all containers were trying
to write to `logs/supervisor/supervisord.log` making trying to
troubleshoot those deployments more difficult.
> [!WARNING]
> _If no issue exists, please create an issue first, and check with the
maintainers if the issue is valid._
## Automation
/ok-to-test tags="@tag.Sanity"
### 🔍 Cypress test results
<!-- This is an auto-generated comment: Cypress test results -->
> [!TIP]
> 🟢🟢🟢 All cypress tests have passed! 🎉🎉🎉
> Workflow run:
<https://github.com/appsmithorg/appsmith/actions/runs/18222964844>
> Commit: 54b5a1a1c52408ae30472d1b5f25a157603fd626
> <a
href="https://internal.appsmith.com/app/cypress-dashboard/rundetails-65890b3c81d7400d08fa9ee5?branch=master&workflowId=18222964844&attempt=1"
target="_blank">Cypress dashboard</a>.
> Tags: `@tag.Sanity`
> Spec:
> <hr>Fri, 03 Oct 2025 13:38:52 UTC
<!-- end of auto-generated comment: Cypress test results -->
## Communication
Should the DevRel and Marketing teams inform users about this change?
- [ ] Yes
- [x] No
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Simplified logging to route process output to standard output with
hostname tagging, reducing per-file logs and disk usage.
* Improved reliability of log capture with a dedicated stdout event
handler.
* Reduced log noise by disabling debug logging in the web server
configuration.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Instead of downloading it from the github repo on every build (in
`base.dockerfile`), we vendor the supervisor extension so we can look to
fix the buffer overflow problem in supervisor logs.
After this is merged, after a day/two, we'll be removing `git`,
`python3-pip` and the supervisor-stdout extension from
`base.dockerfile`.
This is part of supporting running Appsmith with readonly root FS. This
moves the supervisord configuration, and runtime files, like the unix
socket file, and the PID file, to `$TMP`.
This is moving the cleanup script to delete old log files, from being a
cron job, to being a scheduled task in the backend server. Why?
1. We want to support running Appsmith with readonly root, which is a
request from security teams at enterprise companies.
2. Cron doesn't play nice. It wants to save a `.pid` file under
`/var/run`, so it fails to start when running with readonly root. This
is not configurable.
3. Since our use of cron is minimal only, we're moving away from it,
especially since the backend server is already capable of running
scheduled tasks.
4. This moves one job, there's still another. Based on experience from
this, we'll work on the other.
Another advantage to doing this is that since this job is now running in
the backend server, which has access to MongoDB and Redis, we can
coordinate when running as a cluster, that only _one_ backend is running
the clean up job. This is for much later though.
---------
Co-authored-by: Nidhi <nidhi@appsmith.com>
Move the files that are copied into the Docker image, into an `fs`
folder, that reflects the folder structure of that in the image. This
means two things right away:
1. A single `COPY` instruction in `Dockerfile` is enough to copy all the
files to their places.
2. The structure of files in the repo reflects that in the Docker image.
This makes working with the files/folders and troubleshooting with them
much easier.
❗ Note: **There's actually only 3 files changed, rest are just moved.**
