Preview deployment

[weyert]

What problem will this feature address?

I would be interested in having a feature that allow preview deployment based on pull requests

Describe the solution you'd like

When a pull request is raised it will start a deployment to a temporary domain, e.g. pr15-<app>.dokdeploy.com. Potentially, consider allowing a different wildcard domain for the preview deployments, e.g. *.dokdeploy.app

The deployment will always have predefined set of dokdeploy environment variables defined, similar to how Vercel does it: https://vercel.com/docs/projects/environment-variables/system-environment-variables

Describe alternatives you've considered

Non yet

Additional context

In some projects you need to know the domain the project is hosted on at build-time and not only at runtime

[weyert]

I am happy to try to implement this functionality, if anyone could point to the right places in the code, where I should I start

[Siumauricio]

Hi @weyert , I like the idea we have the following:

We have 3 different ways to define a service

1. Application ( Simple application )
2. Databases
3. Docker compose

According to github docs this is the implementation we should follow https://docs.github.com/en/rest/deployments/deployments?apiVersion=2022-11-28

I'm thinking if we should only provide preview deployments only for applications, since for databases and docker compose could be kinda different and more complicated to handle it

[sangdth]

I'm looking forward to this feature. If you don't mind please loop me in, I would like to give a hand as well as learn more about Dokploy development.

[UfukUstali]

My 2 Cents on the matter

1. Ability to Opt Out of Automatic Preview Deployments for every branch

Instead of requiring automatic preview deployments, allow users to opt in via CLI. This approach gives users more control and avoids unnecessary builds.

Suggested CLI Command:

dokploy preview <optional-branch-name> <--enable|--disable>

2. Securing Preview Deployments with Forward Authentication

Preview deployments should be restricted to authorized users only, utilizing Traefik’s forward authentication middleware to enforce access controls. Here’s a potential flow using a backend server that manages the auth flow, let's call it auth service:

Forward Authentication Flow

Prerequisites

• Traefik middleware configured for forward auth
• Auth service hosted at authservicedomain.com

User Flow

1. User Attempts Access: User tries to access mydomain.com.

2. Traefik Forwards Request Headers: Traefik forwards cookies to the auth service, initiating the authentication flow.

   • user is not authenticated

     • auth service gets the request and saves the original URL
     • auth service generates a token and a corresponding otp
     • otp is short lived and is one time use as the name suggests
     • auth service responds with a redirect to authservicedomain.com/login/${otp} and a set-cookie header with the token on mydomain.com
     • user logs in with their credentials and the url embeded otp and authenticates the token
     • auth service redirects user to the original URL
     • refer to token is valid

   • token is valid

     • auth service gets the request and checks if the token is valid
     • user is allowed to access mydomain.com

Integration with Dokploy

The auth service could be embedded within Dokploy, incorporating group and user permission management to streamline access to preview deployments and any other services that use the Traefik middleware.

Notes

• If the auth service gets embeded in dokploy and if the user is already logged in to dokploy the token can be automatically authenticated using the existing dokploy session rather then requiring a separate login every time, essentially SSO
• Subdomains can set cookies for parent domains and cookies on parent domains are also sent along with subdomains. This means that a user has to authenticate for a root(not tld but the right down below it) domain once. authenticate != login
• Forward Authentication can and probably should become it's own issue/feature not only because of it's general size but also because it has uses outside of preview deployments.

3. Handling Preview Deployment Domains

• Wildcard Domains: Support for wildcard domains simplifies deployment URLs. This is already supported through Traefik. or
• Automatic DNS Record Creation: This was also mentioned as it's own feature in #610 but there are many providers other than cloudflare that provide an api for DNS record automation, so this might become a rather big burden rather quick.

[CedericPrivat]

Would love to see this! I could also see a feature like the Vercel Toolbar, which would enable feedback, like comments, on preview deployments.

I would also consider to disable search engine indexing, because you probably don't want your preview deployments under another domain to have a negative impact on your main sites ranking.

Should be as easy as adding a X-Robots-Tag HTTP header set to noindex for all preview deployments.

I'd be happy to help implement such a feature!

[prasannamestha]

I'm also craving this feature rn. Would be happy to extend a hand in the development

[R44VC0RP]

I think that for if I have an application X and the domain for that application is xapp.com inside of the application Settings on Dokploy UI you should be able to enable preview builds for <prev>.xapp.com and have the subdomain be like the first letter for hashes or something.

I am going to work to attempt to start on this later this week.

Thanks for the above input as I will try to honor the correct traefik config @UfukUstali

[Siumauricio]

I like the idea of @UfukUstali , however many people might not be familiar with CLI, and I think it would be ideal to start with the UI, and then make some small changes to be able to do it through the CLI.

If you have a proposal of how you plan to do it or ideas it would be great @R44VC0RP !

[R44VC0RP]

Preview Builds | Implementation

If I understand correctly, in Vercel, you can assign a commit or pull request hash as the prod branch and save that as a milestone. Since instant rollbacks and preview branches are tightly wound together, I think they should be developed together.

Preview Domain placement

I did some quick mockups on my service. Still, under each service under domains, there should be a separate Preview Domains section; that way, if you want to connect a different preview deployment domain different from your primary one, you can attach it here. It will be used as a root domain for the preview deployments. We will get into the actual naming scheme of the preview deployments later.

Preview Deployments Logic

The Deployments tab is primarily where this change and function is going to live, and I believe the implementation should look somewhat similar to this:

So, as you can see, there is a timeline effect @Siumauricio. You could use v0.dev to generate a horizontal timeline like this:

https://v0.dev/chat/DVmf3cSjbl5?b=b_AGnkE9ssX5S

But back to the logic, ideally, every successful build-up to production could be eligible for instant rollback. Upon clicking instant rollback, it would not wipe the other deployments from the history but convert the build into a production build, and all builds after that production build that is deployed (if configured) would be deployed as preview deployments, as you can see in the picture.

Logging Improvements

Now, with the addition of production and preview deployments, the logging interface also needs a facelift.

Honestly, that dropdown kind of tells me nothing. Sure, I can see the running containers, but I don't know if those are the correct running containers.

When preview and production branches are being deployed in parallel, it could get confusing fast, so I propose adding a tab at the top that lets you know if you are looking at the production or preview containers.

Hopefully, this wasn't too demanding. I just wanted to get my 2 cents contributed for a more precise road map, as this is probably my most anticipated feature.

[R44VC0RP]

Also, I saw in #610 the Cloudflare integration. I think that is good, but I just don't know if enough people use Cloudflare for it to be rational.

vote here so I can see

https://x.com/ryandavogel/status/1854457011762512365

[laem]

Feature previews are quite essential for my workflow. Meanwhile, I'll make too deployments, prod and dev, but one per PR with auto-close is essential ! Thanks for bringing the subject.

[matteobad]

This is a very important feature in many workflows nowadays. I just wanted to add a note on the preview environment variables. This feature is already (kinda) supported in Coolify, but they are missing the ability to set different ENVs per branch like Vercel does. Without it, it's very difficult to integrate with external services that also offers "ephemeral envs" like NeonDB or Planetscale with their branching model for the DB.

Screenshot for context:

[Siumauricio]

Thanks for the ideas, I will start working on this feature this week!

I will keep you posted

[TheOnlyWayUp]

I'm moving from Coolify and this is a feature I'm missing.

Preview deployments would be awesome to see here!

A tab on the UI ("Monitoring Logs Deployments Domains Previews Advanced") would be great, CLI would be too cumbersome imo.

Separate environments is a must-have, else it risks a credential leak.

I can test when you're done :)

[MrSnoozles]

Will it be possible to clone the live database when the preview environment is created and automatically provide the database connection credentials via environment variables?

[TheOnlyWayUp]

I think that would be out of the scope of this PR, but maybe Database services could have a "Clone instance" or such as a part of another PR.

I personally wouldn't want my DBs to be duplicated/envs to be modified automatically during a preview deployment, aside from using a staging env I define during setup.

• Dumps slow down throughput on your production db
• Storage can become an issue, especially with multiple preview deployments

So on, it's scope creep.