Replies: 10 comments 15 replies
-
|
I propose creating a separate fork based on this project—I've already started doing something like this for myself. If you'd like, we can develop our own branch together, separate from this one. This will allow us to more quickly release the necessary functionality and fix bugs and security issues. To implement this, we need 2-3 developers who can constantly help push the code implementation forward. I can contribute ideas, tests, and some coding. So you understand, I've been trying for about a month to get the admin of this repo to say anything or accept my PRs. He's only accepted 1) I'm disillusioned with this admin and started doing my own thing, because you can't expect anything good from him. |
Beta Was this translation helpful? Give feedback.
-
You won't get anything from the admin—there's not even a basic roadmap—there's simply no vision or understanding of when all user requests will be resolved. There are definitely about 10 people here who do PR and are also concerned about this project, so we could easily implement a fork and demonstrate separately that our product will be better than the original Dokploy product. Then, perhaps the admin will back off due to competition, but then we won't care anymore since we'll have our own team. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Personally, I don't think going outside the project or creating a fork should be the first solution. I'd rather see an official contributor/experimental branch within Dokploy (other than canary) where active contributors can collaborate and test changes. Any decision should be based on what's best for Dokploy's growth and taken with the involvement of the maintainers. The goal isn't to go against the project's license, terms, or community, but to strengthen it. The whole intent of this discussion is to speed up Dokploy's growth, improve collaboration, and build a better contributor community. Let's first hear what the maintainers and other contributors think before planning anything outside the project. |
Beta Was this translation helpful? Give feedback.
-
|
I understand. I also have a local development build where I test pending PRs, experiment with fixes, work on things like messy roles and permissions, security improvements, and overall application experience. It's purely for local testing at a faster pace, not something public or intended to compete with Dokploy, just understanding the codebase and playing around and finding bugs. That said, I'd rather wait and see what the other contributors and the maintainers think. Personally, I think a better long term solution would be an official experimental branch within Dokploy instead of creating a separate fork. A few active contributors could help maintain that branch, where new features, fixes, audits, and code quality improvements could be reviewed and tested before being merged into the development (canary) branch. I also think the project has simply reached a stage where one person can't realistically manage everything. Having 4–5 active maintainers or reviewers with clearly defined responsibilities would help a lot. The same goes for Discord, having a few dedicated moderators and contributor channels would make collaboration much easier instead of everything happening in general chat. I'd love to see all of this happen under Dokploy's official umbrella. The project is growing quickly, and with a better contributor workflow and planning, I think we could add even more value without fragmenting the community. As far as I know, the team is bust rn, so I'd like to wait for their response before jumping to conclusions. I've been using Dokploy for a long time and have watched it grow through many releases. I've also tried other open source deployment platforms, but I still keep coming back to Dokploy again and again because its interface, speed, and overall experience stand out. I have several upcoming PRs planned, and a few are still waiting for review. I also understand that maintainers have to be careful about what gets merged, especially when it comes to code quality and long term maintenance. At the same time, I think it's fair to say that a project of this size needs a larger team and a better review process. If we ever decide to build or publish anything outside the official project, it should be done with full respect for the project's license, guidelines, and after having an open discussion with the maintainers. For now, I'd rather continue this discussion, hear everyone's perspective, and hopefully find a solution that helps Dokploy grow even further. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the ping. Agreed with @imrja8 — official experimental branch over a fork. Happy to help on the frontend lane (Next.js / React / TS). I contribute upstream to Put me down for that lane if a triage list happens. |
Beta Was this translation helpful? Give feedback.
-
Personally, I’m also not a big fan of the current UI |
Beta Was this translation helpful? Give feedback.
-
Respect. I'll ping you for sure. Since you're part of this discussion, you'll get updates. Stay active until we reach a good conclusion for the project. |
Beta Was this translation helpful? Give feedback.
-
Worth discussing for sure. I still think it's better than most alternatives, but the recent shadcn update was a bit of a step back in terms of the UI. |
Beta Was this translation helpful? Give feedback.
-
I'll keep you in the loop as this discussion moves forward. If we end up organizing things a bit better, your frontend experience will definitely be valuable. |
Beta Was this translation helpful? Give feedback.
-
|
To be honest only reason I stopped contributing to this project is almost no feedback for a long time from the maintainer (@Siumauricio). Few my branches with lot of upvotes (and tbh basic feature which should be available ASAP for such project) are being ignored for a long time with no feedback. I likely agree to have separate fork with continuous support from active members, but it still requires to have leadership from some (or few) members who gonna take responsibility for that fork (if leaders are inactive then that fork will die soon as well). If such fork will exist in near future I'd like to help with that because I don't think experimental branch will give you any benefits since the maintainer won't merge it probably. Current problems I see in this project:
|
Beta Was this translation helpful? Give feedback.
-
|
Sharing my perspective:
That said, I also understand it's hard for a single maintainer to keep up with a project of this size. That's exactly why I think improving the contributor and review workflow is becoming more important than ever. |
Beta Was this translation helpful? Give feedback.
-
|
I’m wondering what would actually be better here: creating a separate feature or experimental branch inside Dokploy, or making a community fork and working there. An official branch would be better for keeping everything under Dokploy, but it would still depend on the maintainers for access, reviews, merges, CI/CD, and management. If that process stays slow, we may face the same issue again. A separate fork would give us more freedom and control over development, CI/CD, releases, issue management, UI/UX changes, and other features. I already maintain a personal fork for my own customizations, so I’d be open to working on a shared one with other contributors. |
Beta Was this translation helpful? Give feedback.
-
|
I'd strongly prefer the official branch over a fork. A fork is essentially taking the project outside, separate repo, separate community, separate everything. Even if it starts well, you're building in parallel instead of building together, and that split rarely heals. An official branch keeps everything inside Dokploy where it belongs. The concern about slow reviews is real, but that's a process problem, and process problems are fixable without fragmenting the community. Here's what I think makes the branch model actually work: Branch structure:
How the review process actually flows:
The key is that Discord is for discussion, GitHub is for the record. Every decision ends up as a comment or review on the PR itself, visible to the contributor, searchable, and permanent. Nothing gets buried in a chat that the contributor can never see. Discord channels:
What @Siumauricio keeps:
This is still a very early and rough proposal, there's a lot to refine. How should board members be nominated? What's the right board size? Should voting be time-boxed so PRs don't stall waiting for quorum? How do we handle disagreements between board and contributor? Would love to hear thoughts from anyone who's been through something similar or can see gaps in this. |
Beta Was this translation helpful? Give feedback.
-
|
Hi everyone. I've been following this discussion with interest. I agree that timely feedback and a clearer contributor workflow would make it much easier for new contributors to stay involved. As someone looking to contribute to Dokploy, I'd prefer strengthening the official project rather than fragmenting the community. An experimental branch, regular PR triage, and more community reviewers seem like practical first steps. I'd also be happy to help where I can—whether that's testing, reproducing bugs, documentation, or reviewing changes as I become more familiar with the codebase. I think there are many contributors willing to help if there's a structured process. Looking forward to hearing the maintainers' thoughts and hopefully working together to make Dokploy even better. I'd also like to appreciate @imrja8 for keeping this discussion constructive and solution-oriented. It's easy for conversations like this to become emotional, but you've consistently acknowledged both the contributors' concerns and the challenges maintainers face. I especially like the focus on improving Dokploy through better collaboration, clearer contributor workflows, and practical ideas like an experimental branch and community-driven triage before considering alternatives. Discussions like this are valuable because they encourage people to work together toward improving the project rather than creating unnecessary division. Thanks for taking the initiative to start this conversation. |
Beta Was this translation helpful? Give feedback.
-
|
I'd like to keep contributing to this repo instead forking it, but it still depends on whatever the maintainer decides to do with it |
Beta Was this translation helpful? Give feedback.
-
|
I completely agree. I'd prefer to keep contributing to Dokploy rather than seeing the community split across multiple forks. I think the project has reached a point where a stronger contributor workflow, more active reviewers, and better communication could make a significant difference. There are many experienced contributors here who are willing to help, and it would be great if that energy could be directed into strengthening the official project. Ultimately, the maintainers' vision and decision will shape the path forward, and I'm looking forward to hearing their perspective. |
Beta Was this translation helpful? Give feedback.
-
|
If you're looking for a community fork, one already exists here, seemingly maintained by @AminDhouib: That said, I'd remain with the official Dokploy project for the time being unless this fork (or any other) gains significant traction. Personally would prefer not to fragment the community with forks as others have mentioned, especially where changes are not contributed back upstream. |
Beta Was this translation helpful? Give feedback.
-
|
Agreed, staying here makes more sense. A fork just splits everyone up -> contributors, issues, everything and fixes rarely make it back to the main project. Better to sort out the process here before people start drifting away. |
Beta Was this translation helpful? Give feedback.
-
|
Hello, thank you very much for the feedback. It’s understandable that people want us to move faster, particularly with the use of AI (we really should be moving faster). Dokploy has been developed by just one person for over two years, and of course, with our growing expansion into the enterprise sector, my time is becoming increasingly limited. For that reason, we have hired a new person who will start in approximately 1–2 weeks, and I will personally be delegating the following tasks to them:
It’s also understandable that they want us to add more features; personally, I like to analyse features thoroughly before adding them, however cool or impressive they may seem. For many people, adding a feature means thinking about just one thing, but for me it means thinking about many things – the cloud version, the hundreds of thousands of instances using Dokploy that I have to support so that nothing breaks, or at least prevent issues to a large extent – because the bigger the software gets, the greater the responsibility of adding something, and it also means more code that we have to maintain. In addition to this, we have other repositories, such as the templates, mcp, cli and sdk repositories, which we also need to maintain, because it is difficult to focus on just one thing |
Beta Was this translation helpful? Give feedback.
-
|
First of all, congratulations on hiring your founding engineer, that's genuinely exciting news and a big step for the project. A few thoughts, if you're open to them: 1. Community reviewers: Looking at other successful OSS projects, a lot of review and triage work is handled by people who simply love contributing in their spare time, no salary, no obligation, just passion for the craft. Several people in this thread have already offered to help with reviews, bug reproduction, and triage. That's a willing pool worth tapping into. Not suggesting more hires, just that there may be ready hands already here. 2. A lightweight SLA for new PRs: The biggest pain point in this thread wasn't old PRs, it was contributors not knowing if anyone will ever respond. Even a simple commitment like "every new PR gets an acknowledgment within a week" would change the contributor experience significantly. It doesn't have to mean a full review, just a signal that it's been seen. 3. What "fits Dokploy's scope", making that public: You mentioned that not all PRs can be merged due to the direction you want to take. That makes complete sense. But if contributors don't know what that direction is, they'll keep building things that can't be merged. A short public document, even a paragraph, outlining what Dokploy is and isn't trying to be would save everyone a lot of wasted effort. 4. Structured contributor roles: For people who are consistently active, closing issues, reproducing bugs, reviewing PRs, a formal role with their name on a contributors page or OSS team listing gives them recognition and a reason to stay engaged. Many projects run entirely on this model and it scales really well. 5. Roadmap with a timeline: A public roadmap on GitHub Projects sounds great. Even a rough "we'll have something visible within 30 days" would set expectations and show momentum. The community has been patient, a concrete date would go a long way. 6. The 180+ open PRs: Contributors with upvoted, working PRs that have been waiting for months deserve a direct answer, even if that answer is "not planned" or "needs changes." Closing with a clear reason is far better than silence. It lets people move on or improve their work instead of waiting indefinitely. As both a user and someone who wants to contribute, I genuinely enjoy Dokploy and want to see it keep growing. The project has incredible potential, better communication and a clearer contributor structure could be the thing that takes it from great to exceptional. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you, @Siumauricio, for taking the time to respond and explain the situation clearly. First, I want to apologize for the personal and overly harsh tone of some of my earlier comments. My frustration about long periods without feedback was real, but making it personal and talking about competition in that way was neither constructive nor fair. I should have criticized the process without attacking the person carrying most of the responsibility. My goal is not to harm Dokploy or divide its community. I want Dokploy to grow, remain secure, and become easier for contributors to support. The plan you described addresses several important concerns: reviewing older pull requests, reducing the issue backlog, publishing a roadmap, improving communication, and updating the documentation. Hiring another person is a meaningful step, and I am willing to give this new process a fair chance. Why I believe the core team should eventually include at least three peopleEven after the new person joins, the list of responsibilities you described is extremely broad. PR reviews, approximately 500 issues, roadmap management, contributor communication, documentation, enterprise work, cloud compatibility, and the maintenance of MCP, CLI, SDK, and template repositories are too much for one or two people to handle sustainably. I understand that staffing and budget decisions belong to you, and people outside the company do not know all the financial details. Nevertheless, I strongly encourage you to consider a minimum of three active people in the core team, including yourself. The responsibility areas could look approximately like this:
These do not need to be rigid silos. Responsibilities can overlap, and you should retain the final decisions concerning product direction, security, breaking changes, and merges. The important part is having visible ownership so that every critical area does not depend on the same person. A volunteer community can reduce the workload, but volunteers cannot completely replace stable core ownership, especially for security, releases, and long-term maintenance. I know that asking a company to invest in another team member is easy from the outside. However, I believe Dokploy has reached a stage where underinvestment may become more expensive than additional staffing. The costs appear in security debt, support load, contributor attrition, duplicated work, abandoned pull requests, and multiple forks created because contributors cannot obtain a decision upstream. The contributor feedback problemIf I had to rate only the current contributor feedback loop, not Dokploy as a product and not the amount of work you have personally done, my honest personal assessment would be approximately 10 out of 100. This score describes the experience of submitting work and then receiving no signal for weeks or months. A complete review does not have to happen immediately, but contributors need to know whether their work has been seen. Even a short response such as:
is much better than silence. Several people in this discussion have said that they maintain personal forks or stopped contributing because of the lack of feedback. A rejected PR with a clear explanation is still useful. Months of silence leave people unable to improve their work, move on, or understand the project’s direction. I therefore strongly agree with @imrja8’s suggestion of a lightweight acknowledgment target. For example, every new PR could receive an initial status within seven days, even if the complete technical review happens later. AI-assisted development makes it possible for contributors to prepare fixes and tests faster, but it also increases the amount of code requiring human review. AI does not replace ownership, security review, or regression testing. The contribution process needs to scale alongside the speed at which patches can now be produced. Security and technical modernizationI also want to make the technical part of my proposal precise. I checked the official At the time of writing, the official branch declares [pnpm 10.22.0](https://github.com/Dokploy/dokploy/blob/canary/package.json), [TypeScript 5.8.3 and React 19.2.7](https://github.com/Dokploy/dokploy/blob/canary/apps/dokploy/package.json), and [Traefik 3.6.7](https://github.com/Dokploy/dokploy/blob/canary/packages/server/src/setup/traefik-setup.ts). For the specific recent React Server Components advisory I was concerned about, React 19.2.7 is already newer than the fixed 19.2.4 release. Therefore, I do not want to incorrectly imply that the current canary branch still uses the vulnerable React version from that advisory. [The React advisory lists the affected and fixed versions here.](https://react.dev/blog/2025/12/11/denial-of-service-and-source-code-exposure-in-react-server-components) However, Traefik releases after 3.6.7 include additional CVE fixes. Whether a particular vulnerability is exploitable through Dokploy depends on the actual configuration and should be investigated rather than assumed, but this demonstrates why dependency and infrastructure security should have dedicated ownership. [Traefik publishes these fixes in its release history.](https://github.com/traefik/traefik/releases) I would not recommend updating every dependency in one enormous change before fixing any other bugs. That would create a difficult-to-review migration and could introduce new regressions. A safer modernization process would be:
I would also like Dokploy to evaluate a migration from pnpm to Bun, but this should be an evidence-based engineering decision rather than a change made only because Bun is newer. The evaluation should compare deterministic installs, workspace support, lockfile migration, lifecycle-script behavior, Docker and CI compatibility, install and build performance, and long-term maintenance cost. If Bun produces measurable benefits without breaking the existing workflow, an experimental migration branch or focused RFC would be worthwhile. [TypeScript 7 has now been officially released](https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/) and offers substantial compiler performance improvements. At the same time, TypeScript 7.0 does not yet provide a stable programmatic API, and some tools may still require TypeScript 6 to run alongside it. Since Dokploy currently uses TypeScript 5.8.3, I suggest first resolving TypeScript 6 compatibility and deprecations, then testing TypeScript 7 through CI or an experimental branch before making it the only compiler. The point is not to chase every new technology immediately. The point is to establish a visible process for evaluating security updates and technical modernization before the project accumulates more difficult-to-remove debt. How the community can help##How I can realistically contribute My strongest area is analytical and implementation-focused work. I use AI-assisted development tools to explore the codebase, compare possible approaches, develop technical proposals, and implement scoped changes. I understand that AI-generated conclusions can be incorrect. I therefore treat them as hypotheses rather than proof and clearly document what was verified, which checks were performed, and what still requires review by maintainers or other contributors. I can realistically help with:
I also want to be transparent about what I should not promise. I am probably not the right person to take permanent ownership of routine issue triage, duplicate classification, continuous manual testing of the entire PR backlog, general documentation maintenance, or ongoing community coordination. I may still help with those tasks when they are directly connected to a feature, security fix, or modernization change I am working on, but I do not want to promise recurring responsibilities that I may not be able to perform consistently. I would still support the creation of a small community triage group. My most useful role within such a group would be technical analysis, implementation, security remediation, and modernization. Other contributors with stronger experience in routine triage, documentation, broad manual testing, or community management could take ownership of those areas. Other contributors in this discussion have already offered help with frontend work, reviews, testing, reproductions, documentation, and implementation. This capacity should be organized, but it should supplement the core team rather than replace it. Would you be open to a small community triage group working alongside the new team member as a limited pilot? For example, contributors could help maintain statuses such as:
Community members could provide reproduction steps, test results, duplicate checks, and preliminary non-binding reviews. GitHub would remain the permanent record, and you would retain final authority over scope, security, and merges. A practical first step could be a 30-day pilot using GitHub Projects, followed by a short assessment of what reduced the workload and what did not. My concrete requests are:
I am not asking you to merge every contribution, surrender control of the project, or rush unsafe changes. I am asking for a reliable feedback loop. If a PR does not fit, explain why. If it needs changes, tell the contributor. If it is accepted in principle, state the next step. I would prefer to help strengthen official Dokploy before discussing a separate community fork. If the upstream collaboration process works, personal forks can become useful testing environments instead of competing and fragmented projects. I care about Dokploy, and my criticism comes from wanting to see it develop faster and more sustainably. Thank you again for responding and for giving the community an opportunity to participate constructively. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
First of all, I just want to say that I love Dokploy. I've been using it for more than a year and a half, and it's become one of my favorite self hosting projects. This discussion comes from someone who genuinely cares about the project and wants to see it continue growing.
Recently, I went through more than 50 open pull requests. Many of them seemed like valuable contributions, but a large number had little or no feedback from reviewers. As a contributor, it's difficult to know whether a PR is:
I completely understand that maintainers are busy and can't review every PR immediately. However, even a short response can make a huge difference. A simple "not planned," "needs changes," "duplicate," or "waiting for..." gives contributors clarity and helps them decide what to do next.
The same applies to issues. With 500+ open issues and 180+ open PRs, it can be overwhelming for both new and existing contributors to understand what is still relevant and what isn't. Regular triaging or closing outdated issues and PRs would make the repository much easier to navigate.
I also think the community could help more. There are experienced contributors who would likely be happy to assist with reviewing PRs, reproducing bugs, triaging issues, improving documentation, or mentoring new contributors if there were a structured way to do so.
Some questions I'd love to hear everyone's thoughts on:
This isn't about pointing fingers or criticizing anyone. Open source is hard, and maintaining a project of this size takes a huge amount of effort. I simply believe that better communication and contributor feedback would encourage more people to stay involved and continue contributing.
I'd especially love to hear the thoughts of @Siumauricio and @agentHits, as well as other contributors who have opened PRs or issues. I'm hoping this can become a constructive discussion where we share ideas on making the contributor experience even better.
Beta Was this translation helpful? Give feedback.
All reactions