PHP Deployment on Cloud Platforms
debt(d9/e7/b7/t7)
Closest to 'silent in production until users hit it' (d9). The detection_hints note automated=no and the code_pattern describes manual SSH deployments with no rollback mechanism. Tools listed (aws-codedeploy, ecs, ecr, terraform) are infrastructure provisioning tools, not detectors of misuse. Session loss, container ephemeral storage issues, and cold-start cost surprises only manifest under real traffic or production conditions — no linter or SAST catches these architectural choices.
Closest to 'cross-cutting refactor across the codebase' (e7). The quick_fix (ECS Fargate with CodeDeploy blue/green) is not a one-liner — it requires building Docker images, pushing to ECR, rewriting task definitions, configuring CodeDeploy pipelines, migrating sessions to Redis, moving file storage to S3, and tuning PHP-FPM workers. This touches infrastructure, application code, and deployment pipeline across the entire system.
Closest to 'strong gravitational pull' (e7). The deployment model (EC2 vs ECS vs Lambda/Bref) shapes every scaling, cost, and operational decision. Common mistakes listed (sessions, ephemeral storage, FPM tuning, long-running processes on Lambda) show how this choice bleeds into application architecture. The applies_to covers both web and CLI contexts, meaning the burden is felt across multiple workstreams. Every future change — autoscaling, queue workers, file uploads — is constrained by the original deployment model.
Closest to 'serious trap (contradicts how a similar concept works elsewhere)' (t7). The misconception is explicit: developers assume serverless PHP is always cheapest, but cold starts add latency and consistent traffic is cheaper on containers. This directly contradicts the general serverless cost narrative common in the industry. Additional traps around session handling (multi-instance EC2), ephemeral container storage, and Lambda timeouts for long-running processes represent multiple serious gotchas that contradict reasonable assumptions from non-cloud PHP backgrounds.
Also Known As
TL;DR
Explanation
PHP cloud deployment options: EC2/VMs (full control, nginx + PHP-FPM, manual scaling), ECS/Fargate (containerised PHP-FPM, auto-scaling, no server management), Cloud Run/GCP (container on demand, scales to zero), Lambda + Bref (serverless PHP, pay per invocation, cold starts), Elastic Beanstalk/App Engine (PaaS, abstracts infrastructure). For most PHP web apps: ECS Fargate or Cloud Run offer the best balance — containers provide reproducibility, auto-scaling handles traffic spikes, and no server management is needed.
Common Misconception
Why It Matters
Common Mistakes
- PHP sessions on multiple EC2 instances without sticky sessions or Redis — session data lost on each request.
- Local file storage on containers — containers are ephemeral; use S3 for file storage.
- Not setting PHP-FPM worker count for container memory — match pm.max_children to available RAM.
- Bref for long-running PHP processes — Lambda has a 15-minute timeout; use ECS for queue workers.
Code Examples
// PHP on EC2 with local file storage — breaks on scale:
$uploadPath = '/var/www/html/uploads/' . $filename;
move_uploaded_file($_FILES['file']['tmp_name'], $uploadPath);
// Works on single server
// Behind load balancer: uploaded file only on one server
// User request may hit different server — file not found// PHP on ECS Fargate with S3 for files:
// Dockerfile: FROM php:8.3-fpm-alpine
// Files go to S3, not local filesystem:
$s3->putObject([
'Bucket' => getenv('S3_BUCKET'),
'Key' => 'uploads/' . $filename,
'Body' => fopen($_FILES['file']['tmp_name'], 'r'),
]);
// Sessions in Redis — shared across all containers:
// session.save_handler = redis
// session.save_path = tcp://redis.internal:6379
https://aws.amazon.com/ecs/