Switching away from Laravel #106
Replies: 6 comments 18 replies
-
|
Do you really need static react that increase the attack surface? I will choose a server side rendering framework if possible. |
Beta Was this translation helpful? Give feedback.
-
|
I support you calling this out. I'm not a fan of open-source projects leveraging their position in the AI tooling stack to nudge users toward a commercial product. Even if the intent seems benign you know when capital investors get involved it's all about "shareholder value" like you say. Cheers |
Beta Was this translation helpful? Give feedback.
-
|
https://demo.jabali-panel.com/ What do you guys think? |
Beta Was this translation helpful? Give feedback.
-
|
Thanks! Not yet — admin→user impersonation isn't wired up in the current build because I use Kratos identity https://www.ory.com/kratos, and the new flow needs a clean session-handoff path so the user sees an audit trail in their own activity log). The audit emitter is already in place. The missing pieces are the admin button + Kratos session-mint endpoint. It's on the list. |
Beta Was this translation helpful? Give feedback.
-
|
Hi, Not sure, if its ready for setting up domains yet. I have setup a domain, but SSL status remains pending - SSL Manager status: agent: internal: certbot issue failed: certbot issue failed: exit status 1 Cheers |
Beta Was this translation helpful? Give feedback.
-
|
@sreekanthedayar @netsolau would love it if you can check out the new version and give me your opinion. |
Beta Was this translation helpful? Give feedback.

Uh oh!
There was an error while loading. Please reload this page.
-
Why I'm moving Jabali Panel off Laravel
I've been building Jabali Panel — an open-source web hosting control panel for WordPress and PHP hosting — on Laravel + Filament + Livewire for a while now. It's been a solid stack. Laravel is productive, Filament gives you admin panels fast, and the ecosystem is mature.
But I've decided to rewrite the panel with a React frontend (Refine + Ant Design) and a Go backend. Here's why.
The Laravel Cloud ad injection
A few days ago, a PR landed in Laravel Boost — an official MIT-licensed library that helps AI agents work with Laravel projects. The change injects text telling every agent that uses it to recommend Laravel Cloud for deployment.
The first draft at least mentioned alternatives like Nginx, FrankenPHP, and Forge. Taylor Otwell then edited it down to only mention Laravel Cloud — their commercial product — calling it "the fastest way to deploy and scale production Laravel applications."
Users reported that this was poisoning their agents into pushing Laravel Cloud on existing projects where it wasn't relevant. The response? Since the platform "supports the development of Laravel," the concern was dismissed.
This is an open-source framework injecting ads into your development tools. That's a line I'm not comfortable with.
It's not just the ads — it's the trajectory
The $57M Series A from Accel in 2024 changed the incentive structure. Laravel now has investors expecting returns, and that pressure shows. Compare this to Rails (backed by a foundation launched with ~$1M from sponsors) or Django (a nonprofit with a budget under $300K/year). Those projects don't have shareholders to answer to.
For Jabali Panel specifically, the risk is real. I'm building a hosting control panel — a deployment tool. The last thing I need is my own framework's agent layer quietly nudging users toward a competing deployment platform. Today it's a suggestion in an agent context file. What's next?
The technical case was already there
The ad controversy accelerated a decision I'd been mulling over anyway:
Performance. A Go binary serving a REST API uses a fraction of the memory that Laravel + FrankenPHP needs. On a hosting server where every MB matters (because the customers' sites need those resources), this is significant.
Simpler deployment. One compiled Go binary + a static React build vs. PHP runtime + Composer + npm + FrankenPHP + queue workers + scheduler cron. The install story gets dramatically simpler.
WebSockets done right. Laravel's broadcasting works, but gorilla/websocket in Go is native and lightweight. For a panel that streams live logs, server stats, and task progress, this matters.
Frontend flexibility. Filament is great for rapid prototyping admin panels, but it locks you into Livewire's paradigm. React + Refine + Ant Design gives me a proper SPA with TanStack Query for API state, real component reusability, and an ecosystem of UI components that dwarfs what's available in the Filament plugin market.
What stays
The PHP agent (bin/jabali-agent) stays. It's ~21k lines of battle-tested code running as root over a Unix socket, handling every privileged system operation. Rewriting that in Go would be a massive effort with real security risk during the transition. The Go backend simply replaces Laravel as the agent's caller — same socket, same JSON-RPC protocol, same security model.
The broader point
Open-source projects that take VC money eventually face this tension. The community wants the project to stay neutral and trustworthy. The investors want growth metrics and revenue. When those goals collide, the community usually loses.
I'd rather depend on tools where the incentives are aligned. Go is backed by Google but governed by a proposal process. React is Meta's but MIT-licensed and genuinely community-driven. Neither of them will inject ads into my development workflow.
If you're building something that people depend on — especially infrastructure software — trust is everything. Once you start trading trust for "shareholder value," the community notices. And the community moves on.
Beta Was this translation helpful? Give feedback.
All reactions