Completely agree with Jaspreet Singh.
This project seems to be dead, as we have not received any updates since Nov 2024, and there is no support on the forum either.
Some time ago, I contacted the CWP team, and they said they were working, but they blocked me then. There are a few members who are running the forum by just saying "CWP Team is working, CWP is not dead, blah blah, etc.." and a few of them are sharing their article users, but the actual CWP team doesn't bother looking at the forum.
It's time to move on
Project is NOT DEAD. Not sure why you keep posting that line...
CWP pushed an update today (2026-02-18) 0.9.8.1222.
And before that 0.9.8.1221 was pushed on 2026-02-02
It's personal preference if you want to stop using CWP and 'move on'
I've tested other panels, and they all have CVEs and can not be kept updated as easily as CWP can be.
Some don't even have the features CWP has, and cost $$$ more.
Can CWP do better with some things, yes.
Clarifying “dead” vs “production-viable” (and what I’m asking for)Nobody is saying “no code ever ships” or “the installer stops working.” The point is
operations reality : predictable maintenance, transparent communication, and accountable support.
Right now, what’s missing (for me, and for others replying here) is
official clarity :
- Release notes / changelog transparency:
Version numbers being pushed is not a changelog. A serious production panel needs release notes that answer:
- What changed?
- What was fixed?
- What was removed/broken?
- What security issues were addressed (with references)?
If there is an official changelog for 2025–2026, please link it. If not, that’s exactly the problem. - Security cadence & accountability:
“All panels have CVEs” is true and irrelevant. The question is: how fast are fixes shipped and communicated?
Please provide:
- The last 5 high/critical CVEs that affected CWP’s stack
- For each: disclosure date → patch date → where it was documented
Without that, admins are forced into DIY patching and custom scripts to stay safe which is not acceptable for client workloads. - Roadmap (missing or opaque):
This is the biggest gap. A roadmap isn’t “talk.” It’s a public commitment with dates (even if approximate) and scope.
Examples of what operators need to know:
- PHP cadence: When are 8.4 and 8.5 planned, and what is the official method (repo/channel) and support window?
- OS support: Which distro versions are officially supported today, and until when? What is the plan for newer major OS releases?
- Core components roadmap: web stack changes, mail stack changes, kernel/openssl compatibility, DB stack changes what is planned and what is not?
- Breaking changes policy: How are breaking changes communicated and how are rollbacks handled?
- EOL policy: What is the official end-of-support policy for older stacks?
If the answer is “use a community guide” or “you can DIY it,” that’s precisely confirming the ops problem: we’re building the missing roadmap ourselves. - Support reality:
Community help is appreciated but it is not the same as official support.
If the official support channel exists, please share:
- Where to file issues
- Expected response time
- What’s covered vs not covered
Forum replies and unofficial “help hubs” can’t replace accountability when clients are paying and uptime/security matter. - Production-grade features (example: DNS cluster):
If DNS clustering is considered production-ready, please link the official documentation/design and the supported failure modes (sync model, consistency, recovery, monitoring).
If it requires custom scripts to be stable and predictable, then it’s not production-grade.
So my position stays simple:If someone wants to argue “Project is NOT DEAD,” that’s fine but then please answer with links and specifics:
- Official changelog/release notes (2025–2026)
- CVE fix timelines (disclosure → patch → documentation)
- Official roadmap (PHP + OS support + core stack + policy)
- Official support channel + expectations
On the “but it’s cheaper” argument (price vs total cost)Cost is not the point being debated
predictable operations are.
Yes, other panels can be more expensive up-front. But the real comparison for anyone running client workloads is
TCO (Total Cost of Ownership):
- Admin time: Hours spent firefighting, writing custom scripts, applying workarounds, and reverse-engineering changes.
- Security exposure: Slow fixes + unclear advisories increases risk, and one incident costs more than years of license fees.
- Downtime cost: Outages, mail issues, broken updates your time + customer churn + reputational damage.
- Opportunity cost: Time wasted on panel survival is time not spent growing the business.
So “it’s cheaper” is not a rebuttal to missing changelogs, missing roadmap, slow security response, or support gaps.
It only proves this: some users accept those risks because their use-case is static and price-sensitive. That’s fine.
But for production hosting where accountability matters,
cheap without transparency becomes expensive.If a “cheap” panel costs even 2–3 extra hours/week in babysitting, that alone can exceed the license price difference before counting downtime or security incidents.Until those exist publicly and consistently, calling it “alive” doesn’t help the people running production.
That’s why I moved on. No drama just operational facts.
Topic: Goodbye CWP — I’m done for good (Read 342 times)
