Category: Web and apps
PHP applications with Laravel or Symfony: managed deployment, queues and server
Your team writes the code; we make sure it reaches production without downtime, that the queues never stall and that the server holds up on your busiest day.
- Where it runs
- In your account, in your name
- Backups
- With tested restores
- Updates
- Planned and documented
- Licence
- Open source: Laravel and Symfony, MIT
In short
Laravel and Symfony are the two most widely used PHP frameworks for web applications and APIs. We prepare the server or containers in your account, set up automated deployments from Git without downtime, keep the queue workers and scheduler alive, tune PHP-FPM and OPcache, and monitor errors, queues and response times. The code remains your team's.
What do we take care of?
A Laravel or Symfony application in production is more than the website: there are workers processing queues, scheduled tasks, a database, often Redis, and a PHP configuration nobody has reviewed since it was installed. This is what we keep under control:
Deployments
From Git, without downtime, with migrations and caches built and immediate rollback.
Queues
Workers supervised with Supervisor or systemd, or Horizon; orderly restarts and failed jobs in plain sight.
Scheduler
Scheduled tasks that run once, on time, even across several servers.
PHP-FPM and OPcache
Processes, memory and PHP version tuned to your application and your traffic.
Data
MySQL, MariaDB or PostgreSQL, and Redis or Valkey, with off-site backups and tested restores.
Monitoring
Errors, growing queues, failed workers, response time, disk and certificates.
What does a deployment look like?
We follow the release-folder model used by tools such as Deployer, or a new container image per release if the application already runs in containers:
Prepare
The code for the tag or branch is fetched, dependencies are installed with Composer without the development ones and the frontend assets are built.
Optimise
The configuration, route and view caches are built in Laravel, or the container cache in Symfony.
Migrate
Database migrations are run, with a backup first if they touch large tables.
Activate
The link to the active release switches, PHP-FPM is reloaded to clear OPcache and the workers are restarted.
Environment variables and secrets live outside the repository, on the server or in the provider’s secrets manager. If you want to set up the whole continuous integration pipeline, we cover it in infrastructure as code, GitOps and CI/CD.
What problems do we come across most often?
- Workers running old code: a new release is deployed, but the queue processes still hold the previous one in memory.
- Duplicated scheduler: several servers run the same scheduled task at once.
- Queues growing silently: the processes are alive but cannot keep up, and nobody watches the queue size.
- Unsupported PHP: the application is still on a PHP version with no security patches.
- Debug mode on in production: errors with paths, variables and queries visible to anyone.
- Manual deployment over SSH: a git pull on the server and a cache left unrebuilt.
How do we handle queues and the scheduler?
In Laravel, each queue connection has its own workers with a time and memory limit per job; if you use Redis, Horizon provides a dashboard with the state of each queue, and we keep it protected. In Symfony, Messenger consumers run the same way, supervised and with a maximum number of messages before they restart so memory does not build up. The scheduler is launched from the system cron or as its own process, and if there are several servers we make sure each task runs on only one. When messaging grows to the point of needing its own broker, we set it up as in managed RabbitMQ.
How do we handle backups and PHP upgrades?
The database is backed up with the method that suits its engine, and files uploaded by users, if they are not already on object storage, also leave the server. We run test restores regularly. To change PHP version, we prepare an environment with the new version, your team runs its tests there and we review the deprecation warnings; then we switch production over server by server. PHP and operating system patch releases are applied as soon as they come out. If the database needs replicas or recovery to a specific minute, we run it as in managed PostgreSQL or managed MySQL and MariaDB.
Containers or servers?
Both options work. Servers with Nginx and PHP-FPM are the simplest to operate for an application with steady traffic. Containers make sense if you already use them in development, if you want the same environment everywhere or if you plan to scale the web tier separately from the workers. If you would rather have a panel where your team deploys on its own, it fits with managed Coolify and Dokploy. If you want someone to answer for the application in production every month, that is covered by SRE as a service.
- GitPush or tag
- NginxHTTPS
- PHP-FPMLaravel or Symfony
- WorkersQueues and scheduler
- DatabasesMySQL or PostgreSQL, and Redis
Where do we set it up?
In your account, with the provider you already use or the one that fits best. If the data has to stay in the EU, Hetzner and OVHcloud are the European options.
Providers we set it up on
- Hetzner
- AWS
- Google Cloud
- Azure
- DigitalOcean
- OVH
- Own server
| Provider | How we set it up | Things to bear in mind |
|---|---|---|
| Hetzner | Cloud servers with Nginx and PHP-FPM, a separate server for workers when the load calls for it and backups in Hetzner Object Storage. | Hetzner offers no managed database: we set it up and look after it ourselves. |
| AWS | EC2 or containers on ECS, with RDS, ElastiCache for Redis or Valkey and SQS if your queues already use it. | |
| Google Cloud | Compute Engine or Cloud Run for the web tier, Cloud SQL and Memorystore. | On Cloud Run, long-running queue workers need somewhere else to live; we plan for that up front. |
| Azure | Virtual machines or App Service, with Azure Database for MySQL or PostgreSQL. | |
| DigitalOcean | Droplets with PHP-FPM and DigitalOcean managed databases. | |
| OVH | Public Cloud instances and OVHcloud managed databases. | |
| Own server | The application on your own servers or virtual machines, with the same deployment system. |
What is included
- Servers or containers with Nginx, PHP-FPM and the PHP version your application requires, in your account.
- Automated deployment from Git with releases in separate folders and rollback in seconds.
- Database migrations as part of the deployment, with a backup first when they touch large tables.
- Queue workers supervised with Supervisor or systemd, restarted on every deployment, or Laravel Horizon if you use Redis.
- Laravel or Symfony scheduler run only once per minute, even across several servers.
- PHP-FPM and OPcache sized to memory and traffic, with the configuration and route caches built during deployment.
- Backups of the database and uploaded files off the server, with a test restore.
- Monitoring of errors, stuck queues, failed workers, response time and disk, with alerts.
Frequently asked questions
Is there downtime on every deployment?
There should not be. Each release is prepared in its own folder: dependencies are installed, caches are built and, when everything is ready, the link to the active release switches over in one go. If something fails, you go back to the previous one by switching the link again. The only thing that may need a window is a migration that locks a large table, and we look at that beforehand.
What happens if a queue worker hangs?
Supervisor or systemd start it again if the process dies, and workers are restarted in an orderly way after every deployment so they do not keep running the old code. We also monitor queue size and failed jobs: if a queue keeps growing without going down, an alert fires even if the processes look alive.
Laravel Forge, Vapor or our own server?
Forge provisions servers and Vapor runs Laravel on AWS functions; both are good if they suit you. We set up the application without them when you want a configuration described in your repository, another provider such as Hetzner, or someone who also monitors and responds. If you already use Forge, we can work on the servers it manages.
Do you write or fix the application code?
That is not what we do. If an error comes from the code, we hand it over with the log, the request that triggers it and what we have seen on the server, so your team can fix it quickly. We do take care of everything around the code: PHP versions, extensions, configuration, deployment and infrastructure.
Do you also manage other PHP applications?
Yes, with the same approach: CodeIgniter, Slim, applications without a framework or old versions that need to be brought up to a supported PHP. WordPress and WooCommerce have a page of their own.
Tell us about your case
In a free 20-minute call we look at where you are and where to start. No commitment.
Official documentation consulted
The technical details on this page are based on:
Reviewed on