Installation reference

Install VoltexaHub#

The supported databases for this release are MySQL 8.4 and 9.7 LTS. The full test suite, migrations, full-text search and scoped permissions are checked against both versions. MariaDB and other MySQL releases are not certified. SQLite is used by development tests; it is not a production target.

Use PHP 8.4 with PDO MySQL, GD/WebP, mbstring, fileinfo, OpenSSL, tokenizer, XML, ctype, session and ZIP; Composer 2; and a supported MySQL database. Set the web document root to public/. Keep storage/, bootstrap/cache/, .env and the private uploads directory writable or readable as appropriate by the PHP service account, never web accessible.

1. Extract the release ZIP into a new directory. It contains public/build, so Node is unnecessary on the destination. In that directory, run composer install --no-dev --optimize-autoloader --no-interaction.
2. Copy .env.example to .env and set APP_URL, DB_HOST, DB_PORT, DB_DATABASE, DB_USERNAME, DB_PASSWORD, and UPLOADS_ROOT to a private persistent directory outside the release and web root. Set APP_ENV=production, APP_DEBUG=false, and secure session cookies behind HTTPS. Keep .env private.
3. Run php artisan key:generate once for a new community. Never replace APP_KEY during an upgrade or restore. Run php artisan forum:install [email protected] --name=Admin and enter a unique administrator password. This runs core and plugin migrations, installs the default data, and refuses to replace an existing administrator.
4. Point the web server to public/. Check /up, log in, visit /admin, create a discussion and check search. Configure outbound mail before relying on verification or password resets.

For source installs, run npm ci && npm run build before serving. The release archive is built from tracked source by php scripts/build-release.php, with a SHA-256 sidecar; see release gates and support. Keep releases separate from the database and uploads volume. See operations for backup, restore, upgrade and rollback drills.

Signup spam prevention#

Turnstile starts disabled. In Community settings → Spam prevention, configure inherited TURNSTILE_SITE_KEY / TURNSTILE_SECRET_KEY deployment values or encrypted administrator overrides. Keep APP_KEY stable and backed up: losing it makes encrypted overrides unreadable. Configure APP_URL with the canonical HTTP(S) community hostname and register that hostname in Cloudflare. Each sensitive operation requires the administrator's current password. Blank replacement values keep existing credentials; Inherit removes an override. Complete a current real-key challenge test before enabling protection. Official dummy keys preview the widget only; they cannot verify the canonical hostname or enable signup protection.

Changing keys or canonical hostname invalidates verification. If protection was enabled, signup remains blocked until retested or explicitly disabled; login and recovery are unaffected. Siteverify uses the fixed Cloudflare HTTPS endpoint with an eight-second timeout and no redirects or retries. Failed challenges require a fresh token. Only token digests are retained for five minutes, with expired entries cleaned on subsequent verification attempts.

Allow outbound HTTPS to challenges.cloudflare.com. If your proxy adds Content Security Policy, allow https://challenges.cloudflare.com in script-src and frame-src for signup and the administrator test page; do not add unsafe-eval. See Cloudflare server validation and CSP guidance. No live keys are needed for installation or tests.

Protected email delivery#

Community settings → Email delivery inherits the existing deployment mail configuration until an administrator explicitly saves an override. Overrides support SMTP with required STARTTLS or implicit TLS, and Resend using its existing SDK. SMTP accepts a hostname, port, sender and optional authentication; it does not accept a URL or executable command. Timeout is limited to 1–10 seconds. Resend overrides use the fixed HTTPS API host, a connection timeout of at most three seconds and the selected request timeout of at most ten seconds without redirects. Existing deployment transports remain unchanged when inherited.

Credentials are encrypted with APP_KEY, masked, never placed in generic Settings or audit context, and never repopulated after a validation error. Blank credentials retain an existing credential for the same provider; switching provider requires its own credential. Removing the override restores the captured deployment configuration. Keep APP_KEY backed up: unreadable overrides block delivery until explicitly replaced or removed rather than silently using inherited credentials.

Every protected save and deliberate test requires the current administrator password. A rate-limited test sends only to that administrator's verified address. Provider acceptance and inbox confirmation are separate: use the test message's signed link within 30 minutes, while logged in as that administrator. Configuration/address changes, expiry and replay invalidate the link. Log, array and fallback transports cannot claim external delivery evidence. This test does not subscribe members or send bulk mail.

Guided launch review#

Open Administration → Setup guide after installation. It links current identity/branding, forums, member-access inspection, registration/rules, email evidence and moderation tools. Review these settings before inviting members. Rehearse signup, verification and a first post as an ordinary member; rehearse staff recovery and an isolated restore. Queue, scheduler and backup checks are manual and are never marked complete by visiting the page. Hiding the dashboard prompt is a per-administrator presentation preference; the guide remains in the sidebar and can restore the prompt.

Optional official-community access requests#

Version 1.7 adds an optional private software-access workflow and anonymous daily marketing activity. Both are disabled by default. Enable MARKETING_ENABLED only on the official community after migrations; set MARKETING_ORIGIN to the exact HTTPS product-site origin (default https://voltexahub.com). Other self-hosted communities inherit the disabled default and expose no request queue or marketing counters. Local/testing environments may explicitly configure a loopback HTTP origin for isolated previews; production rejects HTTP origins.

Verified, non-banned members use /software-access to submit one current request per account. They see their own community details, status and staff response, and may update requests in new/needs-information states or delete their request. Administrator review is under Access requests. Approval is only a recorded decision, not a repository grant or download. Version 1.8 adds separate manual fulfillment tracking, private in-app notifications and optional queued email alerts; arrange actual access separately. Existing community signup, verification and authorization remain unchanged.