Upgrading Senddera safely means backing up first, applying either a patch (small delta) or full package (major jump), running migrations, and restarting queue workers. Skipping backups is the most common cause of painful rollbacks.
Before you upgrade
- Database backup —
mysqldumpor your host’s snapshot. See Automated Database Backups. - Files backup — archive
.env,storage/(uploads, user data), and any custom plugins. - Read the changelog — Senddera changelog for breaking changes, new PHP requirements, or manual steps.
- Maintenance window — pause large campaigns; note active automations will resume after workers restart.
- PHP version — confirm the server still meets the minimum in the release notes (8.2+ for current lines).
Patch upgrade (.bin) vs full zip
| Type | When to use | Size |
|---|---|---|
| Patch .bin | Minor version within same major (e.g. 4.2.3 → 4.2.4) | ~100–150 MB |
| Senddera-latest.zip | Fresh install or large jump / corrupted tree | ~270 MB |
Use the in-app Upgrade wizard when available (Admin → Settings → Upgrade). It validates purchase code, extracts the patch, and runs migrations. Ensure upload_max_filesize and post_max_size exceed the patch size (300M recommended on VPS).
Standard upgrade steps (wizard or manual)
- Enable maintenance mode (optional):
php artisan down - Upload patch via admin UI or extract zip over the install (preserve
.envandstorage/) - SSH into the server:
cd /var/www/senddera
composer install --no-dev --optimize-autoloader
php artisan migrate --force
php artisan config:clear
php artisan cache:clear
php artisan view:clear
php artisan queue:restart- Restart Supervisor workers:
sudo supervisorctl restart senddera-worker:* - Smoke test: login, send test campaign, check automation trigger
php artisan upif you used maintenance mode
Custom plugins and themes
Third-party plugins may need updates for new Senddera API hooks. Disable non-critical plugins before upgrade, upgrade core, then re-enable one at a time. SaaS / white-label customizations: review White-label guide.
Rollback if something fails
- Restore database from dump taken before upgrade
- Restore file tree from backup (or redeploy previous zip from CodeCanyon downloads)
php artisan config:clear && php artisan cache:clear- Do not run migrations on a downgraded codebase against a newer schema — always restore DB + files together
Post-upgrade checklist
- Cron still firing:
grep schedulein logs - Queue processing: send test email, watch
storage/logs/laravel.log - DNS/sending unchanged — no action unless release notes say otherwise
- Run post-install hardening if this is a fresh server migration