[Improvement]: Option to require maintainer approval before preview deployments

[andrasbacsai]

Discussed in #6508

^{Originally posted by TheDanniCraft August 31, 2025}
Currently, preview deployments are triggered automatically for all pull requests.
This can be a security concern when non-maintainers open PRs, since preview builds may expose environment variables (e.g., if a contributor intentionally outputs process.env values on a api route).

Proposed behavior:

• If a maintainer opens a PR → preview deployment runs automatically.
• If a non-maintainer opens a PR → preview deployment is paused until a maintainer explicitly approves it.

This would help prevent accidental or malicious exposure of sensitive data while still keeping previews convenient for trusted maintainers.

Use case example:

1. External contributor opens a PR.
2. The code contains logic that dumps environment variables.
3. Without approval gating, a preview deployment would run and expose those variables.
4. With approval gating, the deployment is paused until a maintainer reviews and approves it.

This feature would add a valuable layer of security for projects that rely on preview deployments.

[andrasbacsai]

Adding this to the next version with 3391185

[TheDanniCraft]

@andrasbacsai Thanks a lot for picking this up so quickly and for the work you put into Coolify 🙏

I had a look at your PR and really appreciate the effort. If I understand it correctly, the current implementation (only triggering preview releases for maintainers) is a good first step, but it is unfortunately not very practical for open source projects where many PRs come from non-maintainers, since in those cases preview builds would not be generated.

What I had in mind was something more like this:

1. A non-maintainer can still trigger a preview build.
2. The deployment then gets paused until it is explicitly approved.
3. For approval, Coolify could post a link (or a similar mechanism) that a maintainer can click to continue the deployment. Ideally, approval could happen via GitHub OAuth so maintainers do not need direct access to Coolify itself but can still prove that they are maintainers on the repository.
4. Once approved, the deployment continues as it works now.

I think this would give open source maintainers more flexibility while still keeping things secure.

By maintainers I mean the repository owner and manual added collaborators. Maybe later there could also be an option to define them directly in Coolify’s UI independently from GitHub.

[djsisson]

Could you use labels instead? e.g, add a list of approved labels in coolify for the github app.

Then:

On pull request webhook with action: opened -> check the PR author as you currently do.

On pull request webhook with action: labeled -> if the label matches one from the list, allow the preview deployment.

GitHub sends a pull_request event with action: labeled when a label is added, so i think that might work better.

That said, I still think preview deployments triggered by PRs in public repos are risky by default. But if the preview branch is only a test environment, where it's fully isolated and mocks all external services, then there shouldn’t be anything sensitive to leak anyway.
What i mean by that is, the preview deployments should not be the same project as the production, but kept apart.

[gltched-usr]

@djsisson I disagree. The idea behind preview deployments is to see how the app works/behaves. And this also means interacting with external/internal APIs. And yes, some things can be mocked but not all. Like you cant mock a conversion with an ai bot for example.

Could you use labels instead?

Not a big fan of this, labels are always add to the pr history making it cluttered by:
Coolify added preview-waitng-for-maintainer
Maintainer removed preview-waitng-for-maintainer
Coolify added preview-waitng-for-maintainer
Maintainer removed preview-waitng-for-maintainer
Coolify added preview-waitng-for-maintainer
Maintainer removed preview-waitng-for-maintainer

The link would use the same comment coolify already uses for deployment status making it less cluttered.

[andrasbacsai]

@andrasbacsai Thanks a lot for picking this up so quickly and for the work you put into Coolify 🙏

I had a look at your PR and really appreciate the effort. If I understand it correctly, the current implementation (only triggering preview releases for maintainers) is a good first step, but it is unfortunately not very practical for open source projects where many PRs come from non-maintainers, since in those cases preview builds would not be generated.

What I had in mind was something more like this:

1. A non-maintainer can still trigger a preview build.
2. The deployment then gets paused until it is explicitly approved.
3. For approval, Coolify could post a link (or a similar mechanism) that a maintainer can click to continue the deployment. Ideally, approval could happen via GitHub OAuth so maintainers do not need direct access to Coolify itself but can still prove that they are maintainers on the repository.
4. Once approved, the deployment continues as it works now.

I think this would give open source maintainers more flexibility while still keeping things secure.

By maintainers I mean the repository owner and manual added collaborators. Maybe later there could also be an option to define them directly in Coolify’s UI independently from GitHub.

Patching the security bug is the main focus now (I will release the new version on Monday).

Regarding a new approval flow, something like this could work:

1. Non-maintainer opens a PR.
2. Coolify (through your GitHub App) adds a comment to that PR, that it needs a maintainer's approval.
3. If the maintainer clicks on that button, it will check your privileges on the repo by going to your Coolify instance (special route), that will just redirect to the Github App, get a token (I don't go into details yet), and check the user's access through Github API with the token.

This could work, in theory, but I have to test it.

If this does not work, the only way is left is to redirect to Coolify itself, where you need an admin (or more) privilege to approve the PR, but in this case every maintainer needs access to that Coolify instance.

I prefer the Github App way, but as I said, it needs to be tested.