How to Deploy Laravel on AWS: A Production Architecture That Scales

I have deployed Laravel to AWS for startups doing a few hundred users a day and platforms handling millions of requests. The architecture below is the shape I keep coming back to, because every piece scales independently and nothing is exotic.

The core architecture

• Application Load Balancer terminating TLS and health-checking instances
• EC2 instances (or ECS Fargate containers) running PHP-FPM + Nginx in an Auto Scaling Group
• RDS MySQL or PostgreSQL with Multi-AZ for failover
• ElastiCache Redis for cache, sessions, and queues
• S3 for user uploads, served through CloudFront
• A small dedicated worker instance (or ECS service) for queue workers and the scheduler

Make the app stateless first

Before anything scales horizontally, the application must hold no local state: sessions in Redis, files in S3 via the s3 filesystem driver, and cache in Redis. Once that is true, adding or removing instances is a non-event, and deploys stop being scary.

Separate web and worker workloads

Queue workers and cron (the Laravel scheduler) should not run on web instances. Auto-scaling kills instances; a terminated worker mid-job is a corrupted import. A small dedicated worker tier with Supervisor keeps background processing predictable, and you can scale it on queue depth instead of web traffic.

Deploys without downtime

My pipeline builds a release artifact (composer install, npm build, config:cache), ships it, runs migrations with --force, and switches a symlink — or, on ECS, rolls a new task definition. Either way the rollback story is 'point back at the previous release', which has saved me more times than I can count.

Cost notes from real projects

Most teams over-provision EC2 and under-provision RDS. Start with smaller app instances behind the ALB (they scale out), put the budget into the database, and turn on RDS Performance Insights — it is the best money-saver AWS gives you for free.