Somewhere between the Hacker News front page and a Reddit thread with a few hundred upvotes, we managed to convince ourselves that Laravel had crossed a line. A pull request on laravel/boost added a sentence recommending Laravel Cloud for deployment. Fifty four thumbs down on the PR. A HN headline reading "Laravel raised money and now injects ads directly into your agent." Comments invoking Black Mirror, neural implants, and the inevitable enshittification of everything touched by venture capital.
I want to make a boring argument. I think Taylor is right, the sentence should be there, and the reaction tells us more about our anxieties around Laravel's funding round than it does about Boost.
PR #758 added a deployment section to the Laravel core guideline shipped by Boost. The guideline gets injected into the context of your coding agent (Claude, Cursor, whatever) so the agent knows how Laravel apps typically get deployed. The initial version of the PR mentioned several options including Nginx, FrankenPHP, and Laravel Forge. Taylor then committed a revision that trimmed this down and centered Laravel Cloud as the recommended path.
That is the full crime. One sentence, in a guideline file, in an optional package, telling the agent to recommend Cloud for deployment if the developer needs somewhere to deploy.
Boost is not installed by default when you run laravel new. You choose to install it. When you install it, you choose which agents to configure. The guidelines are .blade.php files in your project that you can edit, override, or delete. One commenter in the PR thread pointed out that dropping a .ai/guidelines/laravel/core.blade.php file in your project replaces the core guideline entirely with whatever text you want.
That is the shape of the thing. Now let's look at the argument against it.
The concern, fairly stated, goes like this. When a framework team ships instructions that live inside an agent's context window, those instructions do not behave like a banner in the documentation. The developer does not read them and evaluate them. The agent reads them and acts on them. Which means the framework team has a new kind of surface, one where the distinction between "recommendation" and "advertisement" collapses into whatever the agent decides to emphasize.
Laravel raising 57 million in venture capital in 2024 makes this look like exactly what investors would want. Normalize the LLM context window as a monetization channel, ship one sentence pointing new developers at the commercial offering, collect the delta in conversion. The slippery slope argument is that once this is normal, every framework vendor with an MCP server has a business reason to do the same thing, and before long your agent is carrying a pocketful of paid recommendations without marking them as such.
This is a real concern. I want to take it seriously before I dismiss the specific framing of this particular case.
Taylor posted a response on Reddit that is worth reading carefully because most people commenting have not read it. The short version is that Boost's guidelines used to direct new developers toward configuring Nginx or FrankenPHP manually, and the data Laravel has on who is picking up the framework now includes a large and growing number of people who have never deployed a web application in their lives. For those people, "go configure Nginx" is not guidance, it is a cliff. Cloud is an on-ramp.
He also made a demographic argument that deserves more attention than it got. PHP grew roughly 5% year over year on GitHub. JavaScript and TypeScript grew close to 90%. If Laravel wants to matter in five years, it needs new developers entering the ecosystem, not just the existing population of professionals distributing themselves more efficiently across projects. The pipeline problem is real and it is not solved by lecturing experienced developers about FrankenPHP.
The part of his response that landed for me is this. A teenager vibe coding their first Laravel app does not know what Forge is. They do not know what Nginx is. They do not want to know. They want their app on the internet so they can show it to someone. If Boost's guideline sends the agent down a path that ends in an SSH key and a sudo apt install command, that kid is gone. They will not become the Laravel developer who buys Nightwatch in three years. They will be the React developer who never looked back.
Two things have to be true for something to be an advertisement in the problematic sense. First, it has to be placed where the user did not consent to receive it. Second, it has to recommend the product without regard for whether the product serves the user's interests.
Boost fails the first test because Boost is opt-in, the guidelines are editable, and Laravel ships an actual documented override mechanism. If you do not want the deployment recommendation, you delete four lines. This is not the same as a pop-up on the GitHub repository page that you cannot dismiss.
Boost fails the second test because Laravel Cloud actually is, by any sensible definition, the path of least resistance for a beginner deploying a Laravel app. If the Laravel team believed their own users would be better served by DigitalOcean App Platform, and they shipped a Cloud recommendation anyway, that would be an ad. They don't believe that. They built Cloud specifically to be the answer to this question. Recommending your product because it is the right answer is not the same as recommending it because it pays the bills.
The meme response to this is "we should fund open source, but not like that." Fine. Then tell me how. Laravel employs 90 people. The framework is MIT licensed. The commercial products subsidize the framework work. If we rule out telling new developers that the commercial products exist, inside the tooling new developers actually use, we have ruled out the one mechanism that lets the open source part stay open source.
There are real things to worry about in the MCP-plus-guideline era. I am worried about them too. I am worried about guidelines that quietly degrade recommendations for competitors. I am worried about sponsored package suggestions that look identical to unsponsored ones. I am worried about the long tail of framework vendors who will be less scrupulous than Taylor about what they inject and how clearly they mark it.
None of those worries describe what happened in PR #758. What happened in PR #758 is that the maintainers of a framework wrote a sentence recommending their own deployment product inside their own optional tooling, and then, when the community pushed back, moved it to a separate file so it could be overridden more cleanly. That is the process working. PR #774 resolved the specific complaint within about a week.
The HN commenter who wrote "this is not a good sign" is responding to the category, not the instance. Which is understandable. We have watched enshittification happen enough times to recognize the early signals. But pattern matching on early signals has a cost, which is that you start attacking moves that look like the bad thing without being the bad thing, and you make it harder for the teams you actually want to succeed to make moves that keep them sustainable.
The thing Laravel did wrong here, if anything, was PR hygiene. The original guideline text mentioned alternatives. The revised version trimmed them out. Keeping the alternatives in would have cost nothing and would have blunted the "erasing options" read of the change by 90%. That is a lesson worth taking. The part of agent guidelines that recommends products should be transparent about being a recommendation, should mention alternatives where they exist, and should live somewhere the developer can find and edit without archaeology.
Laravel did all of that eventually. They could have done it from the start.
But the structural critique, the one that says the Boost deployment guideline is evidence that Laravel has entered its enshittification era because of the Accel round, does not survive contact with the details. Boost is opt-in. The guidelines are overridable. The product being recommended is actually good. The people being recommended to are genuinely served by the recommendation. The framework team has been more responsive to feedback on this one file than most commercial vendors are to paying customers.
I use Forge for most of my deployments. I do not use Cloud. None of this applies to me, which is the point. The Boost guidelines were written for people who are not me, who I would like to eventually be me, who need a working deployment before they need opinions about deployment. The sentence Taylor added helps those people. It does not cost me anything because I know how to delete it.
Sometimes the correct response to a framework team funding their open source work by pointing new users at their commercial deployment product is "yes, good, that is how this works, thank you for being boring enough about it to write it into a guideline file I can see and edit." The alternative we appear to prefer, collectively, is a world where the commercial incentives exist but get hidden more carefully. I would rather have the sentence.
If you enjoyed this article, please consider supporting our work for as low as $5 / month.
Sponsor
Written by
Writing and maintaining @LaravelMagazine. Host of "The Laravel Magazine Podcast". Pronouns: vi/vim.
Get latest news, tutorials, community articles and podcast episodes delivered to your inbox.