Skip to content

Restart after a fix

After a fix is applied, Python and Node.js apps often need a process reload or restart. PHP apps may need a cache clear, OPcache reset, or worker restart. You can restart manually, or use optional app restart automation on plans that include it (Python, Node.js, and PHP sites only - not WordPress).

Manual restart

The dashboard may show Restart Required or Hot Reload Available. Prefer hot reload when suggested.

Stack Typical commands
Node.js (PM2) pm2 reload your-app or pm2 restart your-app
systemd systemctl reload your-service or systemctl restart your-service
Gunicorn kill -HUP $(cat /path/to/gunicorn.pid)
Docker docker restart your-container
Supervisor supervisorctl restart your-app
PHP php artisan config:clear, systemctl reload php-fpm, composer dump-autoload

Development servers with auto-reload often need no action. After you restart, confirm the error looks fixed in the dashboard. See Rollback.

App restart automation

Optional. After a successful apply, the connector can run shell commands you define in a YAML manifest - reload a process, clear a cache, or run a smoke test.

Check Pricing for which plans include it. On Sites, look for App restart on Python / Node.js / PHP sites.

Typical uses: systemctl reload myapp, pm2 reload api, php artisan config:clear, systemctl reload php-fpm, composer dump-autoload --optimize --no-dev, or a short smoke test command.

Set it up

  1. Open Sites, select a Python, Node.js, or PHP site.
  2. Use the App restart On/Off toggle to pause or resume without deleting your YAML.
  3. Open Configure, read the risk notice, edit or upload the manifest, then Save.

Commands run as the same user as the connector. Do not put passwords or API keys in the YAML - use environment variables already on the server.

  • On/Off toggle - intentional pause; manifest stays saved.
  • Automation disabled after a failed run - safety lock until you fix the YAML and Save again.

Manifest example

version: 1
when: on_fix_success_if_restart_required   # or on_fix_success to always run after a patch
working_directory: /opt/myapp              # optional
dry_run: false                             # optional preview-only
steps:
  - name: reload_app
    run: systemctl reload myapp
    timeout_seconds: 120
    ignore_failure: false
  • when: on_fix_success_if_restart_required runs only when the fix needs a restart; on_fix_success runs after every successful patch (useful for PHP cache clears).
  • Prefer one command per step. Avoid chaining with && or pipes.
  • Successful automated runs are capped per site per hour (At limit on Sites).

Safety and limits

Party Responsibility
You Write and confirm the manifest (risk acknowledgment before save).
Patcherly Stores the manifest, signs API responses, enforces plan limits and hourly caps, audit logs.
Connector Verifies signature and hash, runs steps, reports success or failure.

Key safeguards:

  • Signed, verified manifests (HMAC + content hash)
  • Opt-in, plan-gated; steps only after a successful apply
  • String-form run cannot chain with &&, pipes, or similar; only common program names allowed
  • Hourly rate limit on successful automated restarts
  • Auto-disable after failed steps (unless ignore_failure: true) until you re-save
  • No secrets in YAML

Known disable reasons

Common disable reasons: unsafe_command (split steps or use array-form run), binary_not_allowed, step_failed, step_timeout, content-hash mismatch (re-save from the dashboard), or plan / site-type lock.

Anyone who can edit the site in the dashboard can change commands - restrict site settings to trusted admins.

After a run

Successful, failed, or skipped restarts appear on the error timeline as App Restart events. See Notifications and Audit logs.

WordPress

The WordPress plugin does not run restart commands. Use the restart tip on the error, or run commands yourself. For automation on the same host, add a standalone PHP connector and configure the manifest there.