VoltexaHubDocumentation1.8.0Install the beta
Browse documentation

Operations

Update VoltexaHub

Release safely with a consistent backup, migrations and matching rollback state.

On this page

Plan the update#

Read release notes, confirm PHP/MySQL requirements and review third-party theme/plugin compatibility. Rehearse the update against an isolated restored copy with the matching prior release. Keep the previous code and full backup together. Schedule a maintenance window and account for writes after the backup.

1. Freeze writes and back up#

Put the community in maintenance mode, stop workers and all other writers, then create a consistent recovery bundle. Keep writes frozen during the database dump and uploads copy. php artisan down does not stop queue workers by itself.

2. Prepare the new release#

Extract into a different directory. Retain the existing private .env values, especially the original APP_KEY, database and persistent uploads path. Install production dependencies from the new release directory:

composer install --no-dev --optimize-autoloader --no-interaction
php artisan migrate --force
php artisan forum:plugins:upgrade-bundled
php artisan optimize:clear

The bundled-plugin command upgrades installed bundled plugins while preserving installed/enabled state. It does not install missing bundled plugins or upgrade external packages. Review and upgrade third-party extensions separately through their documented lifecycle.

3. Restart and verify#

Switch the host to the new release/public directory, restart supervised workers after migration, and check the canonical URL and /up. Inspect migration status and logs. Verify login, ordinary member permissions, search, posts, private attachments, avatars/branding and relevant billing/mail workflows.

php artisan migrate:status
php artisan queue:restart
php artisan up

Ensure your host supervisor actually restarts workers. Resume traffic and other writers only after checks pass. Source installs also require compiled assets; release archives include them.

If verification fails#

Stop writes. Do not point old code at the newly migrated database. Restore the matching pre-update bundle into a new empty database/uploads directory and use the previous code release with the original key. Verify that combination before switching traffic. Writes after the backup are absent from rollback; preserve failed state for diagnosis. Never use migrate:fresh or migration rollback on a live community.

See operations reference and release reference.