feat: Add patches functionality

[ivanpadavan]

What is this PR about?

This PR introduces a new Patches system for Applications and Docker Compose services — a powerful way to customize deployments directly from the dashboard without maintaining complex forks.

While there are many "ready-to-work" repositories available, most require slight modifications to run correctly on a self-hosted instance. This feature dramatically improves the user experience by making it easy to apply small, persistent fixes to any service.

How It Works:
Users can apply persistent modifications (Git patches) to source code or configuration files (like docker-compose.yml) directly from the Dokploy UI. These patches are automatically applied before every build or deployment.

Key Features:

• Persistent Customization: Changes survive redeployments and updates from the upstream repository.
• In-Browser Editor: A new "Patches" tab allows users to browse files, edit content, and generate patches automatically without leaving the browser.
• Safety: Uses standard git apply mechanics; if the source file changes drastically, the patch fails safely, preventing silent breakages.

Implementation Details:

• Backend: introduced a Patch entity and a PatchService to handle git operations (clone, diff, apply).
• Deployment Pipeline: Integrated a patch application step into the deployment workflow for both Applications and Compose services.
• Frontend: Added a file browser and code editor for managing patches.

I understand that the UI/UX and test coverage are open points for discussion. If you are open to including this feature in the product, I am ready to polish it further based on your feedback.

You can preview the implementation here: https://github.com/ivanpadavan/dokploy-patches

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.

Issues related (if applicable)

(If there is a feature request issue for this, link it here, e.g. closes #123)

Screenshots

Patches Tab (Empty State)

Creating/Editing a Patch

Patches List

Greptile Summary

This PR adds a Patches system that lets users apply persistent git patches to Applications and Docker Compose services before each build. It introduces a new patch DB table, backend CRUD + git operations services, TRPC router, and a frontend file browser/editor UI.

Critical issues that must be resolved before merging:

• Path traversal vulnerability: The repoPath and filePath parameters in readRepoFile, readRepoDirectories, and saveFileAsPatch endpoints accept arbitrary strings with no validation. Since repoPath is returned to the client by ensureRepo and sent back in subsequent requests, a malicious user can substitute any server path. Combined with unvalidated filePath, this enables reading and writing arbitrary files on the host system (e.g., /etc/passwd, SSH keys, cron jobs).
• Missing authorization on mutation endpoints: The update, delete, toggleEnabled, and one endpoints perform no ownership verification — any authenticated user can modify or read any patch by ID, regardless of organization. Every other router in the codebase verifies organizationId before mutations.
• Command injection risks: filePath from user input is interpolated unsanitized into shell echo strings in generateApplyPatchesCommand. The gitBranch variable is unquoted in the git clone command.
• Silent patch failures contradict safety claims: The || echo "Warning..." pattern in generateApplyPatchesCommand silently swallows git apply failures, allowing builds to proceed with unpatched code. This contradicts the PR description's claim that patches "fail safely, preventing silent breakages."
• SSH key race condition: Private keys are written to a hardcoded /tmp/patch_repo_id_rsa path with no cleanup, creating race conditions for concurrent operations and leaving sensitive keys on disk.
• Missing checkServiceAccess for compose: The create endpoint checks member-level service access for applications but not for compose services.

Confidence Score: 1/5

• This PR has critical security vulnerabilities (path traversal, missing authorization, command injection vectors) that must be addressed before merging.
• Score of 1 reflects multiple critical security issues: arbitrary file read/write via path traversal, missing authorization on CRUD endpoints allowing cross-organization access, unsanitized user input in shell commands, and a hardcoded SSH key path with race conditions. The core feature concept is sound, but the implementation needs significant security hardening.
• Pay close attention to apps/dokploy/server/api/routers/patch.ts (missing auth, path traversal), packages/server/src/services/patch-repo.ts (shell injection, SSH key handling), and packages/server/src/services/patch.ts (command injection, silent failures).

_{Last reviewed commit: 752f90c}

_{(2/5) Greptile learns from your feedback when you react with thumbs up/down!}

[autofix-ci]

Hi! I'm autofix.ci, a bot that automatically fixes trivial issues such as code formatting in pull requests.

I would like to apply some automated changes to this pull request, but it looks like I don't have the necessary permissions to do so. To get this pull request into a mergeable state, please do one of the following two things:

1. Allow edits by maintainers for your pull request, and then re-trigger CI (for example by pushing a new commit).
2. Manually fix the issues identified for your pull request (see the GitHub Actions output for details on what I would like to change).

[Siumauricio]

Hey, can you allow to maintainers can edit the PR? @ivanpadavan

[ivanpadavan]

Hey, can you allow to maintainers can edit the PR? @ivanpadavan

Sure!

[AlexDev404]

Oh wow, this is a really useful feature, actually!

[Siumauricio]

@greptile review

[greptile-apps]

_{24 files reviewed, 9 comments}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

Path traversal vulnerability in user-supplied paths

The repoPath and filePath parameters accept arbitrary strings with no validation. Since repoPath is returned by ensureRepo to the client and then sent back in subsequent requests, a malicious client can substitute any path. Combined with filePath, this enables reading arbitrary files on the server:

filePath: "../../../../../../etc/passwd"

This flows into readPatchRepoFile → cat "${fullPath}" with no traversal check. The same issue exists in readRepoDirectories (line 290) and saveFileAsPatch (line 405), where filePath reaches generatePatch → echo ... | base64 -d > "${fullPath}", enabling arbitrary file writes.

Both repoPath and filePath need strict validation:

• repoPath should be validated server-side against the expected path for the given application/compose (not trusted from the client)
• filePath should reject .. segments and absolute paths (e.g., .refine(p => !p.includes('..') && !path.isAbsolute(p)))

[greptile-apps]

Missing authorization on update, delete, and toggleEnabled

The update, delete, and toggleEnabled (line 209) endpoints perform no ownership/authorization checks — any authenticated user can modify or delete any patch by ID. Every other router in the codebase (e.g., mount.ts, port.ts, domain.ts) verifies organizationId before allowing mutations.

These endpoints should fetch the patch, resolve the parent application/compose, and verify organizationId matches ctx.session.activeOrganizationId before proceeding. For example:

update: protectedProcedure
  .input(apiUpdatePatch)
  .mutation(async ({ input, ctx }) => {
    const existing = await findPatchById(input.patchId);
    if (existing.applicationId) {
      const app = await findApplicationById(existing.applicationId);
      if (app.environment.project.organizationId !== ctx.session.activeOrganizationId) {
        throw new TRPCError({ code: "UNAUTHORIZED", message: "Not authorized" });
      }
    } else if (existing.composeId) {
      const compose = await findComposeById(existing.composeId);
      if (compose.environment.project.organizationId !== ctx.session.activeOrganizationId) {
        throw new TRPCError({ code: "UNAUTHORIZED", message: "Not authorized" });
      }
    }
    const { patchId, ...data } = input;
    return await updatePatch(patchId, data);
  }),

[greptile-apps]

Missing authorization on one endpoint

The one query returns any patch by ID without verifying the caller has access to the parent application/compose. An authenticated user from one organization can read patches belonging to another organization's services. This should include the same ownership verification pattern used in byApplicationId and byComposeId.

[greptile-apps]

Hardcoded SSH key path creates race condition and leaves key on disk

The SSH private key is written to a hardcoded path /tmp/patch_repo_id_rsa. This causes two problems:

1. Race condition: If two patch repo operations run concurrently with different SSH keys, they overwrite each other's key file, causing authentication failures or using the wrong key.
2. Key not cleaned up: The private key remains on disk in /tmp after the operation completes. Unlike ephemeral in-memory usage, this persists until the system clears /tmp.

Consider using a unique temp file (e.g., /tmp/patch_repo_id_rsa_${Date.now()}_${Math.random()}) and adding cleanup with a trap in the shell command:

trap "rm -f ${temporalKeyPath}" EXIT;

[greptile-apps]

Patch filePath interpolated unsanitized into shell echo strings

The p.filePath value (from user input stored in the database) is interpolated directly into the shell command string inside echo statements. If a filePath contains characters like backticks, $(...), or double-quote escapes, it could lead to command injection when the shell evaluates these echo strings.

For example, a filePath like `whoami` or $(cat /etc/passwd) would be executed by the shell.

The filePath should be sanitized when stored (enforce a strict allowlist pattern like [a-zA-Z0-9./_-]+) or these echo statements should use single quotes for the interpolated path.

[greptile-apps]

Unique constraints allow duplicate patches when applicationId/composeId is NULL

The unique constraints (filePath, applicationId) and (filePath, composeId) do not prevent duplicates when the nullable column is NULL. In PostgreSQL, NULL != NULL, so multiple rows with the same filePath and applicationId = NULL are allowed. Since only one of applicationId/composeId should be set, the other is NULL — meaning the constraint on the NULL side provides no protection. This likely matches the intended behavior (one patch per file per service), but it means there's no DB-level enforcement preventing orphaned patches (both IDs null) from being created.

[greptile-apps]

Compose create is missing checkServiceAccess for members

For applications, the create endpoint checks checkServiceAccess when ctx.user.role === "member" (line 132). For compose services, this check is absent — any member in the organization can create patches for any compose service regardless of their service-level access permissions.

[Siumauricio]

Hey, I think this feature is really good. There's a lot to do. I've done quite a bit of refactoring, and I think the next idea is great, but it could be simplified a lot more. I think integrating patches using git commands seems like the right way to go, but it can turn into hell.

I was thinking of a much simpler idea of

saving the file content and path, as well as supporting file creation and deletion.

That way, when the repo is cloned, the patches are applied. If the patch being applied does not exist, then the file or corresponding operation is created. I think this would be simpler and we would prevent a lot of weird synchronisation errors...

[Siumauricio]

Almost all the changes are done, just a few more details and it will work great! I hope to be able to merge this into v0.28.0.

[ivanpadavan]

Wow, that was cool. Thank you, @AlexDev404, for your support, and @Siumauricio for everything :D