Skip to content

Restarting Your Application After Fixes

After Patcherly applies a fix on your server, Python and Node.js apps often need a process reload or restart before the change is live, and PHP apps may need a cache clear, OPcache reset, or a worker restart. This guide explains when and how to do that - manually, or automatically with the optional App restart automation feature.

If your plan supports it, you can also use App restart automation so approved shell commands run on the server after a successful patch (instead of only following manual steps). Availability and limits depend on your plan - see the Pricing page.

When Do I Need to Restart?

After a fix is applied, Patcherly will automatically detect if your application needs to be restarted. You'll see clear notifications in your dashboard:

  • 🔄 Restart Required: Your application needs to be restarted for the fix to take effect
  • ⚡ Hot Reload Available: Your application supports automatic reload - follow the suggested command

How to Know If Restart Is Required

In the Dashboard

  1. Error Status Badge: Errors that need a restart will show a "Restart Required" badge
  2. Fix Preview: When reviewing a fix, you'll see a warning if restart is needed
  3. Success Notification: After a fix is applied, you'll receive clear instructions about restarting

What You'll See

✅ Fix Applied Successfully

⚠️ Restart Required: Your Python application needs to be restarted 
for this fix to take effect.

Suggested command: systemctl restart your-app

Or if hot-reload is available:

✅ Fix Applied Successfully

ℹ️ Hot Reload Available: Your application supports automatic reload.

Suggested command: pm2 reload your-app

How to Restart Your Application

The restart method depends on how your application is deployed:

Development Environments

If you're running in development mode:

  • Django: Usually auto-reloads - no action needed
  • Flask: Usually auto-reloads - no action needed
  • Node.js with nodemon: Usually auto-reloads - no action needed

Production Environments

Using PM2 (Node.js)

pm2 reload your-app-name

Or for a full restart:

pm2 restart your-app-name

Using systemd (Linux Services)

sudo systemctl restart your-app-service

Or for a graceful reload:

sudo systemctl reload your-app-service

Using Gunicorn (Python)

Send a HUP signal to reload:

kill -HUP $(cat /path/to/gunicorn.pid)

Or restart the service:

sudo systemctl restart gunicorn

Using Docker

Restart the container:

docker restart your-container-name

Or if using docker-compose:

docker-compose restart your-service

Using Supervisor

supervisorctl restart your-app

Following the Suggested Command

Patcherly will suggest the best restart method based on your application setup. The suggested command appears:

  • In the success notification after fix application
  • In the error details page
  • In the fix preview modal

Simply copy and run the suggested command in your terminal.

Verifying the Fix

After restarting your application:

  1. Check the Error Status: The error should show as "Fixed" in your dashboard
  2. Monitor Health: A basic health check runs for all plans after apply (site reachable, not 5xx). On plans that include Agent Testing, enhanced health and test results are also available (see Pricing page).
  3. Test Functionality: Verify the fix resolved the original error
  4. Check Logs: Review your application logs to ensure everything is working

What If I Don't Restart?

If you don't restart when required:

  • ❌ The fix won't take effect
  • ❌ The error may continue to occur
  • ❌ Health checks may show issues
  • ⚠️ The system may suggest rolling back the fix

Always restart when Patcherly indicates it's required.

Hot Reload vs Full Restart

Hot reload is faster and doesn't interrupt service:

  • Graceful: Doesn't drop active connections
  • Fast: Usually completes in seconds
  • Safe: Only reloads code, keeps process running

Use hot reload when available - Patcherly will suggest it if your setup supports it.

Full Restart

Full restart is required when:

  • Hot reload isn't available
  • The application doesn't support graceful reload
  • You're using a process manager that requires full restart

Troubleshooting

Fix Applied But Error Still Occurs

  1. Check if restart is required: Look for the "Restart Required" badge
  2. Restart your application: Use the suggested command
  3. Wait a few moments: Allow the application to fully restart
  4. Check again: Verify the error is resolved

Health Check Failing After Fix

If health checks show issues after applying a fix:

  1. Restart if required: Make sure you've restarted when prompted
  2. Wait for restart: Health checks may fail until restart is complete
  3. Monitor results: Health should improve after restart
  4. Consider rollback: If issues persist, consider rolling back the fix

Don't Know How to Restart

If you're unsure how to restart your application:

  1. Check the suggested command: Patcherly provides the best command for your setup
  2. Contact your system administrator: They can help with restart procedures
  3. Review deployment documentation: Check your deployment setup documentation
  4. Contact support: Patcherly support can help identify the correct restart method

Best Practices

Before Applying Fixes

  • Plan for restart: Know how to restart your application before applying fixes
  • Schedule maintenance: Apply fixes during low-traffic periods if possible
  • Test in staging: Test fixes in staging environment first

After Applying Fixes

  • Restart promptly: Restart as soon as possible after fix application
  • Monitor closely: Watch for any issues after restart
  • Verify the fix: Confirm the error is resolved
  • Check health: Review health check results (basic check runs for all; enhanced for Agent Testing plans)

For Production

  • Use hot reload when available: Faster and safer than full restart
  • Schedule during maintenance windows: Plan restarts during low-traffic periods
  • Have rollback plan: Know how to rollback if issues occur
  • Monitor after restart: Keep an eye on application health

Automated post-apply restart (Python, Node.js, and PHP sites)

When your plan includes app restart automation, you can define a YAML manifest per site (under Sites → App restart) so the connector runs approved shell steps after every successful patch - for example systemctl reload, pm2 reload, php artisan config:clear, composer dump-autoload, or a PHPUnit / pytest / npm test smoke suite. Use the On/Off toggle to pause without deleting the YAML. The feature is optional; you can keep using manual restarts and ignore it if you don't need automation.

Site type:

  • Python and Node.js sites - most common use is process reload (systemctl reload, pm2 reload).
  • PHP sites - most common use is cache clear, OPcache reset (systemctl reload php-fpm), composer dump-autoload, queue worker restart, or running PHPUnit/Pest smoke tests after the patch. PHP under mod_php / PHP-FPM does not need a literal process restart for code changes to take effect.
  • WordPress sites do not support this automation - the bundled plugin patches files only and never executes shell commands. Use manual restart guidance, or add a standalone PHP connector on the same host if you need automation.

Plan availability is on the Pricing page.

Full guide: App restart automation - dashboard flow, per-language YAML examples (Python, Node.js, Laravel, Symfony), upload, preview, limits, dry run, and notifications.

Summary:

  • Commands run as the same OS user as the agent. Do not put secrets in the YAML; use environment variables on the server.
  • The server stores a hash of your manifest; the connector refuses to run if the content does not match (tamper / cache-bust). A mismatch is a failed run, not a silent skip.
  • String-form run lines are tokenised and checked for shell metacharacters; use multiple steps instead of && or |. Array-form run (YAML list) skips the string denylist but argv[0] must be allowlisted (python, node, systemctl, pm2, supervisorctl, etc.).
  • If a step fails, automation is disabled for that site until you edit the manifest and confirm again (you may see a dedicated confirmation step if automation was auto-disabled). That is not the same as At limit, which means only the hourly restart cap was reached.
  • Rate limits apply per site per rolling hour; you may receive a notification if a restart was skipped while the limit resets.
  • Error History on a fixed error can show App restart completed, App restart failed, or App restart skipped - see App restart automation.
  • Use PATCHERLY_POST_APPLY_DRY_RUN=1 on the agent for a no-exec walkthrough (telemetry only).

See also Connectors: Python, Connectors: Node.js, Connectors: PHP, and the Security overview.

Need Help?

If you're having trouble restarting your application or the fix isn't working after restart:

  1. Check the suggested restart command in the dashboard
  2. Review your application's deployment documentation
  3. Contact your system administrator
  4. Reach out to Patcherly support for assistance