feat/container filesystem all service types

[VijinV]

What is this PR about?

This PR extends the container filesystem browser (browse, download, and upload files inside a running container) from application services to every other service type: postgres, mysql, mariadb, mongo, redis, and compose (which also covers deployed templates, since a template becomes a regular compose entity once deployed).

Previously this feature (packages/server/src/services/container-filesystem.ts, the application-only filesystemContainers/filesystemList/filesystemReadFile procedures, and the ShowContainerFileSystem component) only worked from the Application service page. This PR:

• Adds getComposeFilesystemContainers/getComposeFilesystemContainer for compose's multi-container discovery, since compose containers are labeled differently depending on deploy mode (com.docker.compose.project=<appName> for plain docker compose, vs a <appName>_<service>-prefixed swarm service name for docker stack deploy) — unlike the other service types, which are always a single swarm service.
• Replaces the application-only application-filesystem.ts auth util with a generic service-filesystem.ts that dispatches to the right entity finder (findApplicationById, findPostgresById, etc.) based on a serviceType, while preserving the same per-service containerFilesystem permission check and accessedServices scoping.
• Introduces a single shared filesystem tRPC router ({ serviceType, serviceId } inputs) instead of duplicating the same three procedures across seven routers, and updates the /api/filesystem/download and /api/filesystem/upload routes to take serviceType/serviceId instead of being application-specific.
• Adds a containerFilesystem write permission (previously read-only) so uploads can be permission-gated separately, with owner/admin granted by default and an opt-in toggle for custom roles.
• Adds a "Files System" tab to the postgres, mysql, mariadb, mongo, redis, and compose dashboard pages, matching the existing tab pattern and permission gating already used on the Application page.
• Fixes an unrelated bug found along the way: browsing a directory whose recursive Docker archive exceeded the safety byte cap used to hang forever instead of erroring, because destroying the stream without an error never fired the finish/error listeners the code was waiting on. It now returns a partial, truncated: true listing instead.
• Defaults the file browser to the container's WORKDIR instead of / when a container is selected.
• The "Running" state badge in the container selector now renders green instead of the default gray/secondary style.

Checklist

Before submitting this PR, please make sure that:

• You created a dedicated branch based on the canary branch.
• You have read the suggestions in the CONTRIBUTING.md file https://github.com/Dokploy/dokploy/blob/canary/CONTRIBUTING.md#pull-request
• You have tested this PR in your local instance. If you have not tested it yet, please do so before submitting. This helps avoid wasting maintainers' time reviewing code that has not been verified by you.

Issues related (if applicable)

Screenshots (if applicable)

Greptile Summary

The PR generalizes container filesystem browsing, downloading, and uploading across applications, Compose workloads, and managed databases, with shared authorization and new write permissions.

• Adds shared tRPC and HTTP filesystem endpoints with bounded archive and upload handling.
• Adds Compose container discovery and filesystem tabs across supported service dashboards.
• Extends custom-role permissions with separate container filesystem read and write actions.
• Adds filesystem ownership, archive-safety, upload, and permission tests.

Confidence Score: 3/5

The PR should not merge until Compose stack discovery handles worker-node tasks and oversized uploads can return their intended error response.

Multi-node Compose stacks can hide valid running containers from the filesystem browser, while exceeding the upload limit destroys the connection and prevents the browser from receiving the structured rejection.

Files Needing Attention: packages/server/src/services/container-filesystem.ts; apps/dokploy/pages/api/filesystem/upload.ts

_{Reviews (1): Last reviewed commit: "feat: extend container filesystem browsi..." | Re-trigger Greptile}

Greptile also left 2 inline comments on this PR.

Context used (4)

• Knowledge Base — API boundary
• Knowledge Base — Identity, permissions, and audit
• Knowledge Base — Infrastructure runtime
• Knowledge Base — Managed data services

[greptile-apps]

Swarm tasks stay hidden

If a Compose stack has tasks scheduled on worker nodes, this single-daemon listContainers call omits them, causing the filesystem selector to show missing or no containers and reject access to those tasks.

Knowledge Base Used: Infrastructure runtime

[greptile-apps]

Upload response socket destroyed

When an upload exceeds the size limit, req.destroy() closes the shared connection before the catch handler sends its 413 JSON response, causing the browser to receive a generic network failure instead of the upload-limit message.

Knowledge Base Used: API boundary