Admin users blocked from changing git branch on compose deployments

To Reproduce

Create an organization with user A (owner) and user B (admin)
As user A, create a compose deployment with a GitHub provider (sourceType: github)
Log in as user B (admin) and navigate to that same compose
Go to the General tab → Provider section
See "Unauthorized Git Provider" card instead of the branch/configuration form

Current vs. Expected behavior

Current: Admin users see an "Unauthorized Git Provider" card that only allows disconnecting the repository. They cannot change the branch, provider, or any git configuration.

Expected: Admin users should have full access to the provider form, including the ability to change the branch, just like the owner. The same access logic used by getAccessibleGitProviderIds() (which already grants admins access to all org git providers) should apply here.

Provide environment information

Operating System: macOS (colima)
   Dokploy version: v0.29.4 (canary branch)

Which area(s) are affected? (Select all that apply)

Application, Docker Compose, Docker

Are you deploying the applications where Dokploy is installed or on a remote server?

Same server where Dokploy is installed

Additional context

In both compose.ts and application.ts, the one query checks gitProvider.userId !== ctx.session.userId to set hasGitProviderAccess. This doesn't account for admin/owner roles or the sharedWithOrganization flag on git providers. The fix is to use the existing getAccessibleGitProviderIds() function instead, which already handles all these cases correctly.

Will you send a PR to fix it?

Yes

@Alt-iOS

Hi @Alt-iOS! I'm Dosu and I’m helping the dokploy team.

Your analysis is spot on. The root cause is a discrepancy between two authorization paths:

getAccessibleGitProviderIds() already grants admins/owners access to all organization git providers [1]:

if (memberRecord?.role === "owner" || memberRecord?.role === "admin") {
    return new Set(allOrgProviders.map((p) => p.gitProviderId));
}

But the hasGitProviderAccess flag in both the application router [2] and compose router [3] uses a simple ownership check that ignores role entirely:
```
if (gitProvider.userId !== ctx.session.userId) {
  hasGitProviderAccess = false;
}
```

The fix would be to replace that simple userId comparison with a call to getAccessibleGitProviderIds() (or at least check the user's role) in both the application router and compose router when computing hasGitProviderAccess. This affects both service types identically since they share the same logic pattern.

This is also related to issue #3985, which reported the same underlying problem — git providers being scoped to the creator rather than respecting organization roles. There was a PR #3509 opened to address provider sharing more broadly.

Looking forward to your PR!

To reply, just mention @dosu.

Share context across your team and agents. Try Dosu.

@dosu

hey @dosu I think my PR covers it pretty well, could you give it a look? This is like a continuation of that issue, because the app/compose got stuck with the previous checks

I took a look at PR #4471 — the fix looks clean and well-targeted. Replacing the simple userId comparison with getAccessibleGitProviderIds() in both the application and compose routers is exactly the right approach:

-     const gitProvider = await findGitProviderById(gitProviderId);
-     if (gitProvider.userId !== ctx.session.userId) {
+     const accessibleIds = await getAccessibleGitProviderIds(ctx.session);
+     if (!accessibleIds.has(gitProviderId)) {

This properly reuses the existing access control logic that already handles admin fast-tracking, shared providers, and role-based access — rather than reinventing checks. Applying it consistently to both routers is the right call since they had identical logic.

Looks good to me from a knowledge/design perspective. Note that I can't perform traditional code review (testing, performance, edge cases), but the approach aligns well with how getAccessibleGitProviderIds() was designed to be used.

To reply, just mention @dosu.

Docs are dead. Just use Dosu.

@Alt-iOS

@Alt-iOS did you enable the Git for whole organization ?

I did, and if they disconnect the git source from the deployment, they can see the same git source I used and add it again, but if I (the user with owner role) deployed it, it doesn't allow them to do any changes (ie, modify the branch, the type of deployment, etc), just disconnect, and then reconnect with the same git source. They are also admin, which means they should be able to do it, even if I didn't share with the whole org.

I've encountered the same issue with a bit of a different flow.

Before the update that allowed sharing provider, User B (not an admin) added a repo to a project (not with compose), and I (User A, admin/owner) was locked out. Which was normal.

On the latest version (0.29.6) I still have the same issue, with a twist.
Since the git provider is shared, I was able to disconnect the repository, and pick another branch from the same git provider and repo and set it up.

However once I had done that (still on User A), I'm presented once again with "This application is connected to a github repository through a git provider that you don't have access to.". Even though I set it up myself.

If there's more work to be done than what's in #4471 I'd love to help.

fix: correct git provider access check for existing deploys (#4570)

🚀 Release v0.29.8 (#4562)

chore(release): 0.37.0 [skip ci]

Navigation Menu

Repository navigation

Admin users blocked from changing git branch on compose deployments #4469

To Reproduce

Current vs. Expected behavior

Provide environment information

Which area(s) are affected? (Select all that apply)

Are you deploying the applications where Dokploy is installed or on a remote server?

Additional context

Will you send a PR to fix it?

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Admin users blocked from changing git branch on compose deployments #4469

Description

To Reproduce

Current vs. Expected behavior

Provide environment information

Which area(s) are affected? (Select all that apply)

Are you deploying the applications where Dokploy is installed or on a remote server?

Additional context

Will you send a PR to fix it?

Activity

dosubot commented on May 22, 2026

Alt-iOS commented on May 23, 2026

dosubot commented on May 23, 2026

mtalhazulf commented on May 24, 2026

Alt-iOS commented on May 24, 2026

Deeptwix commented on Jun 1, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions