Switching away from Laravel

[shukiv]

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.

[sreekanthedayar]

Do you really need static react that increase the attack surface? I will choose a server side rendering framework if possible.

[shukiv]

I guess your right but switching to SSR isn’t automatically “more secure,” and for a control panel it often adds complexity without clear security wins.

I would love to hear what you would recommend.

[netsolau]

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

[shukiv]

https://demo.jabali-panel.com/

What do you guys think?

[netsolau]

Hi SHukiv,

To me, it looks great, practically it has all the major features the big players have.

1. Will the ability to "switch to user" while you are logged in as "admin" be implemented?

So my interest is peaked.
Cheers

[shukiv]

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.

[netsolau]

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

[shukiv]

Don't worry, it won't send anything sensitive in this form.

[johnnyq]

yeah im getting the same

[shukiv]

What do you mean your getting the same? Send me a diganostic report so I can see what you mean.

Don't forget to jabali update before you send me.

I think it will be easier if you open an issue about it.

[johnnyq]

Hey @shukiv I will I just skimmed through the install and UI so ill be opening bug reports shortly
The big ones I experience so far is with Mail and Getting Lets Encrypt SSL Certs.

[shukiv]

Yeah, expect breakage in the beginning . Please bare with me. :-)

[shukiv]

@sreekanthedayar @netsolau would love it if you can check out the new version and give me your opinion.

[netsol-dev]

Shukiv

Have sent the logs via diagnostic screen

[shukiv]

@netsolau cert fail because no DNS for mail.r.nospam.xyz + autoconfig.r.nospam.xyz. Panel auto-adds those to cert SAN list. Fix: add A record mail.r + autoconfig.r on nospam.xyz zone → your box IP. Wait DNS propagate. Then SSL Manager → retry. Should issue.

[netsol-dev]

Hi,

That did work, thanks for your help.
So the mail. and autoconfig records are mandatory.

Will this remain that way?
As we don't always use those records and our DNS is centrally managed offsite. In the previous release of Jabali, installing DNS server was optional at install time which suited us for this purpose.

[shukiv]

jabali update --force now, and you can see I have added this:

Let me know if it works for you.

[netsol-dev]

Excellent, works great!