# NixiHost shared-hosting preparation

Target confirmed by the owner on 17 October 2026: NixiHost shared hosting, launching both Free and paid Premium. On 19 October 2026 the owner selected [www.swedenstart.com](https://www.swedenstart.com) as the production domain. No account has been accessed and nothing has been deployed or enabled for live payments.

## Confirm host compatibility first

NixiHost documents cPanel, SSL, SSH and backups on its [shared-hosting page](https://www.nixihost.com/public/index.php/hosting/shared). Its [SSH knowledgebase](https://billing.nixihost.com/index.php?rp=/knowledgebase/10/SSH-or-Shell) says SSH must be enabled through support. These public pages do not verify this account's actual PHP version or extensions.

Its [cron policy](https://billing.nixihost.com/index.php?rp=/knowledgebase/68/What-Is-A-Cron-Job.html) asks customers not to schedule jobs more often than every 15 minutes. The template in `deploy/crontab.example` respects that interval. Paid activation, queued confirmations, refunds and reminders can wait for the next tick, and longer under backlog or retry. This is a material launch decision: confirm a one-minute exception/managed worker with support or explicitly accept the 15-minute processing interval before launch. Do not work around the policy with external HTTP pings or web-triggered cron endpoints.

Ask NixiHost support these questions (draft only; not sent):

- Can this account run PHP 8.5 (the verified runtime) or at least PHP 8.4.1 (the locked production dependency minimum) for both web requests and cron/SSH, with PDO MySQL, curl, mbstring, intl, XML/DOM, sodium and Argon2id? What is the absolute CLI binary path? Does the CLI allow `pcntl_alarm` and `pcntl_signal`? Any different runtime must pass the platform and application checks on the host before approval.
- Which MySQL/MariaDB version is provided? SwedenStart has been tested on MySQL 8.4; another engine/version needs its own migration, feature and concurrency verification.
- Can the domain's document root be `/home/ACCOUNT/swedenstart/public`, with the rest of the application and `.env` outside `public_html`? If not, can support configure the equivalent safely without exposing the project root?
- Are outbound HTTPS connections to Stripe and the password-screening service allowed, and can Stripe reach `/stripe/webhook` without a browser challenge or WAF block?
- Is a managed/background queue worker or one-minute scheduler exception available? If not, can a 15-minute cron invocation run for up to roughly 135 seconds, using the bounded queue mode described here?
- What authenticated SMTP host, port, encryption, sending limits and sender-domain authentication apply? Can TLS SMTP connections be made from PHP?
- What are the account's actual data/backup locations, retention, restore process and log controls? Are token-bearing URLs excluded from access/error logs or redacted? Who receives cron failures and resource-limit alerts?

## Prepared configuration

- `sh scripts/package-release.sh`: builds frontend assets and an isolated production Composer installation, then writes a versioned `dist/releases/swedenstart-*.tar.gz` and SHA-256 checksum. The archive includes a `RELEASE.json` and per-file `SHA256SUMS`; it excludes local environment files, databases, logs, sessions, Git history, Node dependencies and development PHP dependencies. It does not change the developer's `vendor/`. Verify the checksum before extracting outside the web root, then run the platform and launch checks with the actual hosting PHP binary. Building this artifact does not approve or enable launch.
- `deploy/production.env.example`: non-secret settings, HTTPS cookies, shared database sessions/cache/queues, TLS SMTP and closed launch/payment gates.
- `deploy/crontab.example`: one cPanel cron entry every 15 minutes; replace the account directory and the PHP binary with support-confirmed values. Enable cron error notifications and rotate the private scheduler log.
- `QUEUE_WORKER_MODE=cron`: schedules a bounded database queue drain. No root access or Supervisor configuration is assumed. Maintenance/reconciliation run before queue draining. Production must support the timeout functions and process budget; do not deploy this mode if they are unavailable.

`QUEUE_WORKER_MODE=supervised` remains available if the host provides a managed worker. In that case run the worker and scheduler as documented in `deployment.md`, using the interval approved by the host.

## Deployment sequence after access and decisions

1. Configure DNS/SSL for `www.swedenstart.com` and enable the necessary SSH/cPanel access. Use `https://www.swedenstart.com` as the canonical origin. Configure HTTPS and apex-domain redirects at the host before requests reach Laravel, whose production host validation accepts only the configured hostname. Keep staging access-controlled with its own database and sandbox credentials. Keep staging distinct from the public production environment.
2. Build frontend assets locally or in CI with the lockfile; the web server does not need a Node process. Install production Composer dependencies compatible with the server. Run Composer's platform check with the actual hosting PHP binary.
3. Upload the application outside the public document root and expose only `public/`. Use narrowly scoped writable permissions for `storage/` and `bootstrap/cache/`; never use world-writable permissions. Keep secrets and backups outside public access. The server must not serve `public/hot` or the repository root.
4. Create the separate durable production database and least-privilege database user. Configure SMTP and a verified sender. Set real operator/contact details and reviewed policy versions/text. Generate new production encryption and independent deletion keys on the server; preserve them for future releases and restores.
5. Back up before `php artisan migrate --force`; then `php artisan db:seed --force`. Install the approved scheduler/queue arrangement. Check the queue and mail delivery with controlled test accounts.
6. Complete genuine sandbox hosted checkout, signed webhook delivery, duplicate/retry handling, confirmation mail, withdrawal and refund on staging. Use the actual approved inclusive SEK 499 Price and cards/wallets configuration. Review tax treatment; leave automatic tax disabled until active registrations are confirmed if it is to be used.
7. In the production secret store set the separate restricted live key, live Price, live `pmc_` configuration and live webhook secret. Only after sandbox verification and owner review set `STRIPE_MODE=live`, `STRIPE_LIVE_APPROVED=true` and the other approval flags. Keep new checkout and public traffic gated while completing the protected release checks.
8. Run `php artisan optimize`, then `php artisan swedenstart:launch-check --with-billing --check-database` using the real hosting PHP binary and final cached configuration. Verify public-domain acceptance, rejection of unrelated hosts, HTTPS cookies, private-page headers, an actual backup restore and monitoring. Restart managed workers after a release if that mode is used.
9. Enable public access and paid checkout only when those checks and decisions are complete. Observe canonical Stripe state, delivery, queue age and refund exceptions after launch. Configuration checks alone cannot verify actual payment delivery or host policies.

## Owner information still needed

- Access to the domain's DNS and the existing NixiHost plan/account through an approved secure connection, not passwords pasted in chat.
- Support's compatibility answers and the accepted queue/scheduler arrangement.
- Legal operator name, business address, support email, final reviewed Terms/Privacy/Cookies/refunds, retention/processor details, launch territory and tax treatment. The current offer is 499 SEK once for 12 months, initially SE; confirm it or provide the revised offer before live Price setup.
- Stripe sandbox and live account configuration, restricted keys, environment-specific Price and payment-method IDs, and webhook endpoint secrets, installed securely on the appropriate environments.
- Verified mail sender/SMTP access, an alert recipient, backup/restore ownership and the actual legal/privacy review decisions.

NixiHost's public shared-hosting page describes Texas datacenters. Confirm the actual account and backup locations so the final privacy policy reflects the real processing setup; this runbook does not supply legal approval for it.