Can Laravel Be Used for Big Enterprise Apps? [Summary of Laravel Podcast]

Yesterday I’ve listened to a new Laravel Podcast episode with Taylor Otwell, Jeffrey Way and Matt Stauffer – and they (finally) talked about creating big apps with Laravel, lately this question is asked a lot by everyone. So is Laravel “fit” or “mature enough” for big projects? Since the podcast guys don’t provide a transcript, and listening to 50 minutes can be an overkill, I decided to write a summary, quoting the conversation and dividing the answers into more readable format like Q&A and bullet points, also relevant links. So, let’s dive in!

Topic 1. What is a big app?

Matt: Before we dive in, what is the definition of enterprise app? Is it about lines of code, is it about dependencies, is it about security, is it about traffic?

Jeffrey: I have the same question. What specific features/functions some frameworks have that make them suitable for enterprise that Laravel doesn’t? Is it related to the fact that Zend has big company behind it, whereas in Laravel everyone keeps creating threads like “What happens when Taylor dies”?

For those who don't know, here's the plan.
For those who don’t know, here’s the plan.

Taylor: I think most people mean lots of classes, I guess, lots of code.

Topic 2. So can Laravel be used for big apps?

Taylor: Obviously, I’m gonna say yes, it can be used for big apps, because:

  1. It has been used for big apps in the past, so we already know it’s true.
  2. Also I think Laravel is good for any app that PHP is good for. And it’s really up to you – once you’re passed the Controller, you have total freedom to do whatever you want to do.
  3. And also I think Laravel is kind of uniquely qualified and better at making big apps than other PHP offerings right now, for a few reasons. One, because there’s dependency, complexity, and Laravel’s Dependency Injection Container is really good. When you’re talking about complex apps, you’re also talking about background jobs processing, and Laravel has the only baked-in queue system out of any major framework in PHP. And then there’s, of course, Event Broadcasting feature and others that are more on the big app side.

So not only can it be used for big apps, it’s uniquely better for big apps than other alternatives in PHP, for those reasons.

And I think it’s a little misleading because Laravel is easy to get started with. But at the same time it also scales up with your needs.

Topic 3. People are irrational

Taylor: And, by the way, people don’t choose frameworks in a rational way. Some of it is personality things. Maybe, they don’t like the way certain framework is marketed, maybe they don’t like Laravel friendly style, so they choose something more “suit & tie” like Zend. Sometimes they don’t like me, personally!

Topic 4. Enterprise world

Matt: Speaking of enterprise, there is a distinction between big and enterprise projects. We have clients all the time say “CEO, or The Board, or CFO, or The Lawyers, or whatever – of our multi-billion dollar company are very worried that we’re gonna invest a whole bunch of money and time into something and X”, so a lot of developers are getting non-developer input, so I do wonder if there are some constraints like this, to not use Laravel.

Topic 5. Any examples of big Laravel apps?

Matt: So let’s step away from enterprise and talk about big projects.
I know that we can’t say a lot of the names of big sites running on Laravel. I know several of them, cause I’m under NDAs with several of them, and there are hundreds of millions of pageviews sites, running on Laravel – like Alexa 500, multiple Fortune 500 companies. Can we share more?

Taylor: Various video game sites like Fallout 4 had their landing page on Laravel, but there’s underlying question why people need proof it can work. It’s never enough.

Topic 6. It’s not about the framework

Taylor: People probably want to know that “if I build my big app on Laravel, will it be infinitely maintainable and clean.. and..” No, Laravel won’t automatically make your app amazing to maintain for 10 years.

The Framework is gonna be a much smaller concern in your actual code. Framework is gonna be routing, session, some caching, some database calls, but you’re the one that’s gonna have to figure out the domain problem of your app, which is gonna be way more complicated than any framework problem.

Matt: Bad developer can write bad app with any framework.

Topic 7. Ok, so how to build big apps?

Matt: Ok, so let’s say people agree that Laravel is good. How to build big apps, what are some considerations for apps with millions of views per week?

Taylor: Simple things, make sure you’re using a good cache or session driver like Memcached or Redis, on a server like Elasticache if you’re on AWS.

You’re probably gonna use a load balancer, PHP is really easy to deploy and scale this way.

At Laravel level, make sure you’re using config:cache, route:cache, make sure you’re using composer dump-autoload –optimize.

Jeffrey: With Laracasts, which is surprisingly high-traffic, I’m not doing that much! A lot of that stuff are fundamentals, like people completely ignore the size of their images!

Taylor: another great thing to do is to separate your database from your web-server. It makes it easier to do the scaling, like if you want to add the second server.

And speaking of caching, I’ve been using Cloudflare a lot recently. The whole Laravel website is on heavy Cloudflare caching, very few requests actually hit the real server, because it’s all static like documentation.

Matt: But with Cloudflare, the problem is that they need to know the rules when things expire, to clear the cache. So it’s not Cloudflare’s problem, it’s yours – check Expires headers.

Overall conclusions

After having listened to these thoughts (thanks a lot, guys!), I came to the same old conclusion – that “big apps” are not about the framework, there’s much more that comes into it: DevOps things, caching mechanism, your unique application logic, database structure etc.

So to ask “is Laravel good enough” is a wrong question. You better ask “Is your code good enough”, and/or “Are you qualified to use Laravel effectively for big apps”.

What do you think? Anything to add to this discussion?
Link to the original podcast again: Laravel Podcast – Episode 53: Bigger & Better

Like our articles?
Check out our Laravel online courses!


  1. I’m glad you did the transcript 🙂

    Personally I don’t agree that framework is some kind of less important thing in the whole stack.

    Using default tools like framework – embedded cache, orm or queue you are not thinking about all these “small” thing like performance, good implementation etc. You are just taking it becuase it is out of the box solution. You are ignoring that using other tool, that probably can cooperate well (thanks to composer, for instance) with your framework of choice, you can save a lot of money becuase the other’s tool implementation is more efficient.

    The devops things should be a cherry on top of well written framework, app logic, database structure and seletced tools.

  2. Nice! Thanks for making this summary.

    The subject behind “Ok, so how to build big apps?” is really intriguing. Most of the things Laravel covers are related to App and Infrastructure layers. The magic happens in the Domain layer.

    I like that Taylor confirms that “No, Laravel won’t automatically make your app amazing to maintain for 10 years.”. I think there is a big gap of knowledge and best practices in designing big apps which are easy to grow and maintain.

    DDD, Clean architecture, Onions, Hexagons and related stuff were meant to solve the designing problems. Yes you can put your sessions in the Memcached, yes you can optimize images and yes you can cache HTTP traffic on Cloudflare.

    I wonder, why no one talks about the guts of the apps – the domain, the best practices to decouple domain from the framework, protect business invariants and the stuff?

  3. `composer dump-autoload –optimize` is plain wrong.

    Optimize is a long option so it have to use double-dash syntax.

    `composer dump-autoload –-optimize`

  4. Hey,

    I totally agree with Matt on the point where he says it all boils down to the domain of your work. Bad developers will write bad code even with a good framework.

    In my opinion Laravel is really great when getting started quickly or maintaining the quality does not matter that much, but for large projects with complex domain models I think even a good developer will struggle.

    Therefore, a framework which enforces particular set of rules and coding standardards could be a better option for that matter. There is actually one PHP framework highly inspired from JAVA Spring and its called Flow

    What Flow really shines at is, it enforces code quality through Domain Driven Design and Aspect Oriented Programming and some advance comcepts. The down side of that framework is its documentation which is not great. However, their community is very responsive on slack.

  5. If you become a really big project it makes no sense to use some framework and deal with all the issues when you can afford to have your own framework made tailored for your needs.

    The given example of large sites such as Fallout 4 using Laravel is just a sad confirmation that Laravel is mostly good for short term throw-away low risk projects such as promotional material.

  6. You know when someone starts learning about Larvel and realizes how easy and fast (specially fast!) it is to develop with, they get excited about it and start talking about it much! and others may start hating that!
    And so things get a bit personal! They don’t wanna hear more about Laravel because they heared much about it! So they’re gonna start to find inefficiencies in Laravel or just make it up! like “Laravel isn’t efficient for big apps!”
    So Laravel can be used to develop big apps faster than other frameworks and whomever says otherwise is a liar.

  7. Thanks for this post. Great to be able to get the goodies out of the podcast without listening to the whole thing.

    It’s interesting to read about the NDA of bigger enterprise websites/ apps, I guess that if the framework was publicly known then it would be easier for bad people to target vulnerabilities?


Please enter your comment!
Please enter your name here