Staff Augmentation
Add PHP developers with serverless experience to your team for a migration, a new API, or a backlog of event jobs.
Does PHP really belong on serverless platforms?
Many developers assume PHP and serverless don't mix. They do. Serverless PHP means running PHP on a platform that starts it on demand, scales it for you, and bills only while it runs. Servers still exist. You just don't patch, size, or babysit them, because the cloud provider does.
PHP fits this model better than its name suggests. Each PHP request already starts clean and shares nothing with the next, which is just how a function platform expects code to behave. Most of the real work sits elsewhere, in sessions, files, and database connections.
Each major cloud handles it differently. AWS Lambda has no built in PHP runtime, so teams use a custom one, most often through Bref. It's an open source project that packages PHP for Lambda and supports Laravel and Symfony. Container platforms such as Google Cloud Run run any PHP image you build and scale to zero when traffic stops. Laravel Vapor offers a managed path for Laravel apps on AWS.
Whichever route you take, the PHP code changes less than people fear. Controllers, models, and templates mostly stay put. What changes is everything around them, like where uploads go, how logs ship, how config loads, and how the app reaches its database.
Three questions to answer first
- Does traffic swing widely across the day or season, or is it flat?
- Can the app run without writing to local disk or keeping state in memory between requests?
- Will the database accept bursts of short lived connections, or does it need a pool in front?
If traffic is flat and the other two answers are no, a regular server or container cluster will likely serve you better. The sections below explain why, and how to test the choice on one workload before you commit the whole app.
What actually happens when a PHP request hits a function?
People picture a server waiting for requests. A function works differently. An event arrives, the platform starts or reuses an execution environment, and PHP handles the event. For a web app, the event is usually an HTTP request passed through an API gateway or a function URL. Other events include a file landing in storage, a queue message, or a timer.
Every new environment pays a cold start on its first request, the time it takes to load the runtime and your code. Later requests reuse that warm environment until the platform retires it after a quiet spell.
Web requests and events take different paths
Tools such as Bref offer two styles of runtime. A web style runtime runs PHP behind a FastCGI process manager. A Laravel or Symfony app sees an ordinary HTTP request and needs few code changes. An event style runtime calls a PHP handler directly with the event payload, which suits queue messages, storage events, and timers.
Memory is the main dial you tune. On AWS Lambda, CPU power scales with the memory you choose, so a slow function sometimes gets faster and cheaper with more memory. Depending on the runtime, a warm environment may also keep the PHP process alive between events. Code should never rely on global state carrying over or being reset.
How does serverless PHP compare with traditional hosting?
- Scaling. Serverless adds environments on its own as requests arrive. A server or VM scales only as far as your planned capacity or autoscaling rules allow.
- Billing. Serverless charges per request and run time. Servers bill for every hour they run, busy or idle.
- State. Serverless environments can vanish at any moment, so sessions, uploads, and caches must live in outside services. A server can keep files and memory between requests.
- Long tasks. Function platforms cap how long one call may run. Servers can run workers and long jobs for as long as needed.
- Operations. Serverless removes OS patching and capacity planning. Servers give you full control over extensions, PHP settings, and the network.
Cold starts get blamed for more than they cause. For PHP they're often modest, because the runtime is fairly small, but they grow with the framework and the vendor folder. Leaving dev dependencies out of the package and caching config and routes at build time both help.
Measure before you worry. Many teams find cold starts barely register once real traffic keeps a few environments warm. Where they do matter, like a checkout call that must answer instantly, platforms offer ways to keep capacity ready. That costs extra, so weigh it against the delay.
Does serverless PHP always cost less?
No, and that's the myth worth killing early. Serverless saves money when traffic is spiky or low on average. An internal tool used during office hours, a marketing site that surges after a campaign, or an API called a few thousand times a day costs very little when you pay only for run time. Idle time costs nothing.
The savings stop when traffic is high and steady. A busy app that keeps functions running around the clock can cost more than a right sized server or container cluster. An API gateway in front adds its own per request charge too. Model both cases before you migrate.
The usual pitch is that serverless always cuts infrastructure costs. That's the wrong frame. The bigger saving is usually people time. Nobody patches servers, rebuilds OS images, or plans capacity for peak season. Weigh that time against the bill, rather than comparing one invoice with another.
Watch for hidden line items too. Log ingestion, NAT gateways for functions inside a private network, and data transfer can add up faster than compute, and they rarely show up in early estimates. Tag every function by team and product from the start. Then the monthly bill traces back to the feature behind it, and a surprise takes minutes to explain.
Does the cloud provider handle serverless security for you?
Only partly, which surprises many teams. The provider secures the underlying servers. Your code, dependencies, configuration, and data stay your job under the shared responsibility model.
Start with permissions. Give each function its own role with only the access it needs, such as read on one storage bucket or write to one queue. Avoid one broad role shared by everything. Secrets belong in a secrets manager or an encrypted parameter store and get fetched at startup. Never bake them into the deployment package or commit them to the repo.
Input validation matters as much as ever. Use prepared statements through PDO or your framework's query builder to block SQL injection. Escape output to prevent cross site scripting. Validate every event payload, not only HTTP requests, since a queue message can carry hostile data as easily as a form can.
Which security checks belong in every release?
- Scan Composer dependencies for known flaws with composer audit or a similar tool.
- Encrypt data at rest in databases and storage, and require TLS for all traffic.
- Authenticate API calls with OAuth or signed JSON Web Tokens, and check scopes inside the function.
- Send authentication failures and permission errors to a central log with alerts.
- Review function roles on a schedule and remove permissions nobody uses.
Moving to functions doesn't move your compliance duties. Rules such as HIPAA and standards such as PCI DSS still apply. Confirm that each managed service you rely on is covered by the provider's compliance programs before regulated data touches it.
Logs need their own care. Function logs often capture request bodies by default, which can put personal or payment data into a store with wider access than the database it came from. Mask sensitive fields before they're written.
Should every PHP workload move to serverless?
No. Event driven work fits best. APIs with uneven traffic, webhooks, scheduled jobs, file processing, and queue consumers all suit serverless PHP. Each is triggered by an event, finishes fast, and keeps no state between runs. Think of resizing an image after upload, a nightly export, or a payment webhook that fires a few hundred times an hour.
Long running workers, WebSocket servers, apps that write to local disk, and heavy CMS installs with many plugins fit poorly. They outlast the time limit, need persistent connections, or assume a filesystem that vanishes between requests.
The Function Fit Test
We run every candidate workload through a five stage test before moving it. Each stage is a yes or no question. Two or more noes mean the workload should stay where it is for now.
- Trigger. Is the work started by a clear event, such as a request, an upload, a message, or a schedule?
- Duration. Does each run finish well inside the platform's time limit, with room to spare on a slow day?
- State. Can sessions, files, and caches live in outside services such as Redis, object storage, or a database?
- Connections. Can the database absorb bursts of new connections, or can a proxy such as Amazon RDS Proxy pool them?
- Traffic shape. Is demand uneven enough that paying per request beats paying for idle servers?
Keep the app whole at first
Many guides say to break a PHP app into dozens of small functions on day one. For most teams, that's a mistake. It multiplies deployments, permissions, and cold starts, and it turns readable code into a map of triggers. Bref and similar tools can run a whole Laravel or Symfony app as one HTTP function, with separate functions only for queue workers and scheduled commands. Start there.
Split a route out later, and only when it has a different scaling or security profile from the rest. Migration works best one slice at a time. Route a single endpoint or job to the serverless version, compare errors, latency, and cost against the old path for a few weeks, then move the next slice. Rollback stays a routing change, not a redeploy.
How Pattem Digital helps with serverless PHP
Pattem Digital's PHP engineers run the Function Fit Test on your current app, prepare the code for a stateless runtime, and set up deployment, monitoring, and cost alerts on the cloud you already use.
Parts of the estate that belong on regular hosting get the same care through our PHP app development services. Both setups can share one codebase and one release pipeline.
What to watch in the first month
The first weeks after a move show whether the test got it right. Track a short list of signals and compare them with the old hosting.
- Error rate and timeouts per function, split by cold and warm starts
- Response time at the slow end, not just the average, since cold starts hide there
- Database connection counts during traffic peaks
- Cost per thousand requests, including the gateway, logs, and data transfer
If any of these drift the wrong way, you can move that one workload back without touching the rest. Usually the fix is smaller, like a connection pool, more memory, or a cache in front of a slow query.
Hire Serverless PHP Developers
Our PHP developers move Laravel, Symfony, and custom PHP apps onto serverless platforms and make them stateless. They also set up the deployment, monitoring, and cost alerts that keep those apps predictable.
Build Operate Transfer
We build a serverless PHP team, run it until your platform is stable, then transfer that team to your company.
Offshore Development Center
A dedicated offshore PHP team builds and maintains your functions, pipelines, and cloud setup under your lead.
Product Outsource Development
We deliver a complete serverless PHP product or API, from architecture and code through deployment and handover.
Managed Services
Ongoing monitoring, cost tracking, dependency patching, and incident response for your serverless PHP workloads.
Global Capability Centre
A PHP and cloud engineering center of your own that sets serverless standards across all your product teams.
Capabilities of Our Serverless PHP Team
Laravel and Symfony apps packaged for Lambda with Bref
Container builds for platforms like Google Cloud Run
Stateless rework for sessions, uploads, and caches
Least privilege roles, secrets handling, and cost alerts
PHP engineers who know when serverless helps and when a plain server is the better call.
Is Your PHP App Ready for Serverless?
Share your app's traffic pattern and stack, and we'll run the Function Fit Test with you before any code moves.
Share Blogs
Authored By
Related Blogs
CMS Solutions
CMS technology gives quick updates, improves workflow, and keeps content organized, for a smooth user experience.
