deployment and operations

Platform As A Service Orientation

A platform as a service, commonly shortened to PaaS, packages common deployment operations behind a provider workflow. The platform may build a Git revision or container image, start web processes, attach managed services, collect logs, and replace unhealthy instances. That removes server administration work, but it does not remove application-level deployment decisions.

Map The Application Processes

A PHP web app often has more than one process type. HTTP traffic goes to web processes. Queued work belongs in workers. Database migrations should run once as part of a release step, not once per web instance. Scheduled commands need a scheduler feature or an external trigger.

web: serve HTTP traffic
worker: consume queued jobs
release: apply migrations once
scheduler: trigger recurring commands where platform supports it

Local filesystem writes require special attention. Many platforms replace instances during deploys and do not promise that files written inside one instance will remain available. Store durable uploads in object storage or another persistent service rather than treating the application filesystem as permanent.

Check Build And Runtime Separately

Identify the build command, start command, runtime PHP version, required extensions, and Composer installation mode. The build environment may not be identical to the serving runtime. A successful build does not prove that the web process starts, migrations are safe, or worker processes have the same configuration.

Create a staging environment before production. Inject staging secrets through platform configuration, attach isolated services, run migrations, exercise one web request and one background job, inspect logs, and confirm the rollback procedure. Automatic deploys are still deployments; they need evidence and recovery steps.

Practice

Practice: Plan A PaaS Deployment

Sketch the PaaS process model for a PHP shop that serves web requests, sends receipt emails from a queue, and applies database migrations during deployment.

Requirements

  • Identify build command, start command, runtime PHP version, and extensions.
  • Configure web and worker processes separately when needed.
  • Attach managed database and cache services deliberately.
  • Deploy one staging environment.
  • Inject secrets through platform configuration.
  • Run migrations safely and inspect logs.
Show solution

Define a web process for HTTP traffic, a separate worker process for receipt-email jobs, and one release command for migrations. Configure the runtime PHP version and required extensions explicitly. Database credentials, mail credentials, and other secrets belong in platform configuration, not source code or image layers.

Deploy the same setup to staging first. Prove that a web request works, a receipt job is consumed, a migration runs once, and logs can be found. Record how the platform rolls back a bad release and keep durable uploads outside the instance filesystem.