Laravel web application development in Somerville

A Laravel application usually has a handful of scheduled commands. Send the daily digest, clear expired carts, sync prices from a supplier, generate invoices at the end of the month. They sit in the schedule definition, one cron entry on the server calls the scheduler every minute, and for a long time nobody thinks about them.

Then a customer receives two invoices for the same month. Or the digest goes out twice. The cause is almost always one of three things. All of them can be prevented.

The first is overlap. A command scheduled every five minutes normally takes one minute. One day the supplier API is slow and it takes seven. The scheduler starts a second copy while the first is still running, and both process the same records. The withoutOverlapping option on the schedule entry places a lock, so a new run is skipped while the old one continues. Give the lock an expiry that fits the job, or a crashed run blocks it for a long time.

The second is more than one server. When the application grows to two or three web servers, each often gets the same cron entry. Now every scheduled command runs on each machine. The onOneServer option takes a lock in a shared cache store such as Redis, so only the first server to claim the run executes it. That needs a cache driver shared by all servers. A file cache on each machine will not do.

The third is a manual rerun after a partial failure. A command sends invoices to a list of customers and crashes halfway. Someone runs it again by hand, and the first half receive a second copy. The defence is to make the job record its own progress. Mark each invoice as sent in the database the moment it goes out, and have the command skip anything already marked.

That last principle is worth applying everywhere. Write scheduled commands so that running them twice gives the same result as running them once. Query for work that still needs doing, instead of assuming the last run finished. A timestamp column such as processed_at is often all it takes.

Heavy commands should hand work to the queue. The scheduled command finds the records and dispatches a job for each. The command finishes in seconds. Workers do the rest.

Keep an eye on whether commands ran at all. A scheduler that silently stopped because the cron entry vanished after a server rebuild is as bad as one that ran twice. Laravel can ping a heartbeat address before and after a task, and an external service raises an alarm when the ping does not arrive.

Finally, keep time zones explicit. A command scheduled for midnight runs at midnight in the time zone of the application config, which may differ from the one the business works in. Set the zone on the schedule entry itself when it matters.

The simplest way to deploy a Laravel application is to log in to the server, pull the latest code, install dependencies and run migrations. It works. Yet for a minute or two the site runs a mix of old and new files, and a visitor can hit an error page. For a busy application that minute matters.

The standard fix is atomic releases. Each deployment goes into a new directory on the server, named by timestamp or commit. Dependencies are installed there, assets built or copied, configuration cached. Only when everything is ready does a symbolic link called current switch from the old release to the new one. The web server always points at current, so visitors move from one complete version to the next in an instant.

Some things must survive between releases. Uploaded files, logs and the environment file live in a shared directory, linked into each release. Forgetting this is the classic first mistake. It shows up as missing user files after a deploy.

PHP keeps compiled code in OPcache, and after the link switches it may go on serving old files. A graceful reload of PHP-FPM after the switch clears it without dropping requests in progress.

Database migrations need the most thought. During the switch, old and new code briefly run against the same database. A migration that renames or drops a column the old code still reads will break those requests. The safe pattern spreads such a change across two deployments. First add the new column and write to both. Later, once the new code is live everywhere, remove the old one.

Queue workers are long-running processes that hold the old code in memory. After a release they must be restarted, or they will keep processing jobs with outdated logic. The queue restart command tells each worker to finish its current job and exit. The process supervisor then starts fresh ones.

Keep the last few releases on disk. If the new version misbehaves, pointing the link back at the previous directory is a rollback that takes seconds. A code rollback cannot undo a migration, which is one more reason to keep migrations backward compatible.

Tools such as Envoyer, Deployer or a CI pipeline automate these steps. The tool matters less than the sequence being scripted, identical every time, and never typed by hand at the end of a long day.

With more than one server, the release goes out to each in turn behind the load balancer, or the build happens once and is copied to all of them. Either way the principle holds. A new version appears only when it is complete.

Every Laravel application reads its settings from environment variables, usually through a file named .env in the project root. Database passwords, API keys, mail credentials and feature flags all live there. It is convenient. It is also where many security problems begin.

The first rule is that the environment file never enters version control. The repository should hold an example file with every variable name and a safe placeholder, so a new developer knows what to set. Real values stay outside. If a secret was ever committed, treat it as leaked: rotate it, then clean the history.

Each environment gets its own values. Local development, staging and production should use different database credentials, different API keys and, where the vendor allows, sandbox accounts. A staging site that emails real customers because it shares the production mail key is an easy mistake and an embarrassing one.

Code should read environment variables only inside config files. Everywhere else, it calls the config helper. This matters because production runs with a cached configuration for speed, and once config is cached, direct calls to env from application code return null. Bugs from this rule appear only in production. That makes them hard to trace.

Where the values live on a server depends on the setup. A single server can hold the file with strict permissions, readable only by the user that runs PHP. Larger setups pull secrets at deploy time from a secrets manager offered by the cloud provider or a vault service. That adds a step, and in return gives an audit trail of who read what and rotation without logging in to each machine.

Laravel also supports encrypted environment files. The file is committed in encrypted form and decrypted during deployment with a key held elsewhere. This suits small teams who want secrets versioned alongside the code without running a separate service.

Keep configuration and secrets apart in your thinking. A timeout, a page size or a feature flag is configuration and can be visible to the whole team. A payment key is a secret and should be seen by as few people as possible. Mixing both in one file is normal. Access to the production copy is what needs limiting.

Validate settings when the application boots or deploys. A missing variable should fail the deployment loudly. Otherwise it surfaces hours later as an obscure error in a customer request.

When someone leaves the team, list the secrets they could see and rotate the important ones. With every secret in one known place, that list stays short.