Migrate a Laravel app to AWS: architecture, queues, the scheduler and the cutover.

IWhy teams move Laravel onto AWS, and what changes

Most Laravel apps start on Forge driving one VPS, a managed PHP host or a single EC2 instance. Teams move when that box becomes the bottleneck, the single point of failure, or fails a security review.

Scale and availability. One VPS runs web, queue workers, the scheduler and often MySQL and Redis. On AWS the web tier runs as stateless containers across Availability Zones, the database is managed with Multi-AZ failover, and workers scale on their own.

Compliance. Audits want encrypted databases, secrets that are not in a plaintext .env, network isolation, audit logs and least-privilege access. AWS provides these as building blocks (RDS encryption, Secrets Manager, VPC, CloudTrail, IAM).

The counterpoint: Forge on a VPS is simpler to run, and AWS asks you to own more. That is why many teams have a partner run the move.

IIThe target architecture

Separate the three runtime roles (web, queue workers, scheduler), pick a compute target, and the data services map almost one-to-one.

Compute. Amazon ECS on Fargate is the usual home: web and Horizon as separate services, VPC control and autoscaling, no host to patch. The web task runs nginx and PHP-FPM side by side, with nginx proxying to 127.0.0.1:9000 and the load balancer terminating TLS with an ACM certificate. EC2 suits a lift-and-shift of an existing server layout. (App Runner closed to new customers on April 30, 2026; ECS Express Mode is AWS's simpler container option now.)

Data. RDS for MySQL (like-for-like) or Aurora MySQL (storage that grows on its own, faster failover, up to 15 readers). You change DB_HOST and move the data. ElastiCache covers cache (CACHE_STORE=redis), sessions (SESSION_DRIVER=redis) and queues (QUEUE_CONNECTION=redis) in one cluster. Files go to S3; anything written to local disk must move to Storage::disk('s3'), because container disks are ephemeral.

IIIDockerizing Laravel, and moving .env into AWS

You reproduce what Forge did invisibly in a Dockerfile, and supply the same environment variables without shipping a .env file.

A build stage runs composer install --no-dev --optimize-autoloader and your asset build; a runtime stage on a slim php-fpm image installs the extensions you use (often pdo_mysql, bcmath, gd or imagick, redis, intl, zip, opcache) and runs config:cache, route:cache, view:cache and event:cache. The same image serves every role: PHP-FPM for web, php artisan horizon for workers, php artisan schedule:run for the scheduler task.

Run migrate --force as a one-off task at deploy time, never on container boot. Put real secrets (APP_KEY, DB_PASSWORD, API keys) in AWS Secrets Manager and plain config (APP_ENV, APP_URL, drivers) in SSM Parameter Store; the ECS task definition injects both as environment variables.

IVHorizon and the scheduler, the AWS way

Background work is set up casually on a VPS and breaks quietly after a migration. Give each part its own home.

Horizon becomes a dedicated ECS service running php artisan horizon against ElastiCache, scaling on queue depth and restarted by ECS if it crashes, as Supervisor did. Laravel also supports Amazon SQS as a managed queue connection if you do not need Horizon's dashboard.

The scheduler must run schedule:run exactly once a minute. The AWS-native answer is one EventBridge Scheduler rule that starts a one-off ECS task each minute. Baking cron into the web image fires every scheduled job once per web task. Long-running scheduled work should dispatch a queued job.

VThe MySQL cutover: DMS, DNS and a short window

Containers, the landing zone and S3 can be built and tested without touching production. The database cutover is the one moment that touches live data.

AWS DMS does a full load into RDS or Aurora MySQL, then streams ongoing changes from the binary log, so at cutover you switch to an already-current copy. CDC needs binary logging enabled in row format on the source; check that early. Without it, or for a small database, use mysqldump and restore inside a maintenance window and time a test run first.

The cutover: maintenance mode, let DMS drain, pause the scheduler rule and let Horizon finish, switch DB_HOST and Redis settings, update Route 53 (TTL lowered a day ahead), check that writes land in RDS, leave maintenance. Keep the old server as a rollback until you are confident.

VIWho runs the move, and who can fund it

You can do this yourself with the steps above. Many teams have a partner run the landing zone, the containers and the cutover.

Partner-filed funding: AWS says the Migration Acceleration Program (MAP) helps offset initial migration costs. It is built for migrations with meaningful ongoing AWS spend, so a single small Laravel app may not qualify. When the migration does qualify, your matched partner files it and AWS approves: typically $50K to $150K for startups. Depends on the workload; AWS approves. Activate credits are separate, and you apply for those yourself.

CloudRoute matches you with one vetted AWS partner. Startups pay CloudRoute nothing; partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding.

VIILaravel-specific gotchas

The small set of things that turn a clean migration messy.

• Local-disk writes break across tasks: Uploads, generated PDFs and temp exports written to local disk disappear or diverge across containers. Move them to S3 before cutover.
• APP_KEY mismatch: Different keys across tasks break sessions and signed URLs. One key, from Secrets Manager, everywhere.
• The scheduler runs N times: Cron inside the web image fires once per task. Use one EventBridge Scheduler rule.
• Missing PHP extension: An extension Forge installed and your Dockerfile did not shows up as a runtime error. List extensions from the old server first.
• MySQL binary logging off: DMS change data capture needs row-format binary logging on the source. Without it, plan a dump and restore window.
• Forgetting to shut the old box down: Keep it as a fallback for a defined short window, then turn it off.