DEV Community: shirish rai

Composer Install or Update? Best Practices for Safely Updating Composer in Production

shirish rai — Wed, 27 Aug 2025 19:18:33 +0000

When managing PHP applications especially in production Composer can be both a lifesaver and a potential pitfall. Used carelessly, it can introduce bugs or even bring your app down. This post walks you through how to safely update Composer dependencies, explains why composer update should never be used on production, and outlines the right way to manage frequent package upgrades.

🚫 Drawbacks of Running `composer update` on Production

One of the biggest mistakes developers make is running composer update directly on a production server.

Here’s why this is dangerous:

It updates all packages to the latest versions permitted by composer.json, potentially introducing breaking changes.
It modifies both composer.json and composer.lock, which can cause your production environment to become out of sync.
There’s a risk of app downtime, as new versions may cause HTTP 500 errors or other critical failures.
The install process is resource-intensive.
If the update fails midway, you could be left with a broken or inconsistent dependency state.

Other risks include:

Unintended package upgrades.
Lack of staging environment testing.
Skipping the standard CI/CD pipeline.
Possible download from untrusted sources.

✅ The Correct Approach: Use `composer install` on Production

When deploying code to production, always use:

composer install --no-dev --optimize-autoloader

This command ensures a clean, performant, and safe deployment.
Let’s break down why these flags matter:

🔍 Why `--no-dev` Is Critical

The --no-dev flag tells Composer to skip installing packages listed under the require-dev section of composer.json. These are typically tools used only during development and testing.

Why it's important in production:

Avoids exposing unnecessary tools that could pose a security risk.
Reduces disk space and speeds up deployment.
Ensures a lean, minimal footprint optimized for production performance.

🚀 Why `--optimize-autoloader` Matters

Composer's autoloader can be optimized to improve performance by converting PSR-4/PSR-0 mappings into a class map. When you use --optimize-autoloader, it:

Pre-generates a class map of all classes.
Reduces filesystem lookups at runtime.
Improves request performance and boot time, especially for larger apps.

📦 Safely Updating a Specific Package

Sometimes you might need to update a frequently patched package, like aws/aws-sdk-php. In that case, follow this safer approach:

Step-by-Step Guide:

1> Create a new branch from master:

git checkout -b update-aws-sdk

2> Run the update command locally:

composer update aws/aws-sdk-php

This will:

Only update the specified package.
Respect version constraints in your composer.json.
Avoid touching unrelated dependencies.

3> Test thoroughly in your local or staging environment.
4> Commit and merge the changes back to master.
5> Deploy the updated branch to production.
6> On the production server, run:

composer install --no-dev --optimize-autoloader

🧪 Reminder: Keep All Composer Updates in Source Control

All version upgrades should:

Be performed locally or in a CI/CD pipeline.
Be committed to source control.
Go through a proper deployment workflow.
Never originate from the production server.

Restarting Laravel Queue Workers Safely

shirish rai — Tue, 06 May 2025 18:57:30 +0000

When managing background processes or queue workers in a production environment, Supervisor is often the go-to process control system. But if you’ve ever worked with Supervisor on a Linux server, you've likely come across these two commands:

sudo service supervisor restart
sudo supervisorctl restart [program_name]

They might look similar at a glance — both contain the word restart — but they operate at very different levels and are used in very different situations. Let’s break down what each command does, when to use it, and what to avoid in a production environment.

🔍 1. sudo service supervisor restart

✅ What it does

This command restarts the Supervisor daemon itself — not just the programs it manages. Think of it as turning Supervisor completely off and then back on.

When you run this:

Supervisor stops all processes it’s managing.
It re-reads your main config file (/etc/supervisor/supervisord.conf) and any included .conf files.
Then it restarts itself and everything it controls.

⚠️ Why it can be risky

This method is disruptive, especially in production environments. All processes — queue workers, background services, long-running jobs — are stopped and restarted. If any job is mid-processing, it could be lost.

✅ When to use it

You've made changes to Supervisor's configuration files and need them to take effect.
The Supervisor daemon is unresponsive or has crashed.
You want to restart all managed processes at once and you're okay with downtime.

🧠 Pro Tip

Use this during scheduled maintenance windows or in development/staging environments.

🔍 2. sudo supervisorctl restart [program_name]

✅ What it does

This command is much more targeted. It allows you to restart a single program without restarting the entire Supervisor service.
Example:

sudo supervisorctl restart laravel-worker

This stops just the laravel-worker process and starts it again — leaving other services untouched.

✅ Why it's safer

Because it doesn’t restart the Supervisor daemon itself, this command is less disruptive and far more appropriate for production use.

You can also use:

sudo supervisorctl restart all

To restart all managed processes, without restarting Supervisor itself.

✅ When to use it

You’ve updated your application code (like deploying a new Laravel version).
You want to restart just one service/worker.
You want to minimize disruption while keeping services running.

🔃 3. php artisan queue:restart

✅ What it does

Gracefully tells Laravel to stop and restart all queue workers, by updating a timestamp in the cache. Running workers detect this and shut themselves down after finishing their current job.
This command does not stop the underlying process — Supervisor or another process monitor will automatically restart the worker afterward.

📦 How it works

Laravel stores a timestamp (in the cache) for the last restart request.
Each worker checks this before picking up a new job.
If the cache timestamp is newer than when the worker started, it exits.
Supervisor (or systemd) sees that it exited and starts a new one.

✅ Why it’s safe and graceful

It allows in-progress jobs to finish before shutting down, preventing job loss or data corruption.

✅ When to use it

During deployment after code changes
When updating environment variables or job logic

🧠 Example Deployment Snippet

If you're using Laravel queues (and you should be using Supervisor to manage them), it's best to restart your workers using Supervisor commands rather than manually killing and starting workers.

php artisan queue:restart
sudo supervisorctl restart laravel-worker

This combo ensures Laravel gracefully restarts workers, and Supervisor brings them back up cleanly.

🔚 Conclusion

Both sudo service supervisor restart and sudo supervisorctl restart are valuable tools — but like any powerful tool, use them wisely.

Use supervisorctl restart [program_name] for safe, minimal-disruption restarts.
Use service supervisor restart when you're updating Supervisor itself or fixing a broader issue.

Understanding the difference can help you avoid unintentional downtime and keep your production services running smoothly.

DEV Community: shirish rai

Composer Install or Update? Best Practices for Safely Updating Composer in Production

🚫 Drawbacks of Running composer update on Production

✅ The Correct Approach: Use composer install on Production

🔍 Why --no-dev Is Critical

🚀 Why --optimize-autoloader Matters

📦 Safely Updating a Specific Package

🧪 Reminder: Keep All Composer Updates in Source Control

Restarting Laravel Queue Workers Safely

🔍 1. sudo service supervisor restart

🔍 2. sudo supervisorctl restart [program_name]

🔃 3. php artisan queue:restart

🧠 Example Deployment Snippet

🚫 Drawbacks of Running `composer update` on Production

✅ The Correct Approach: Use `composer install` on Production

🔍 Why `--no-dev` Is Critical

🚀 Why `--optimize-autoloader` Matters