# GoDaddy Linux cPanel deployment

GoDaddy plan limits and cPanel features vary. Complete the [hosting compatibility checklist](hosting-compatibility.md) against the actual account before importing production data.

## Directory arrangement

1. Extract the private application ZIP in the account home directory, outside `public_html`. It creates `dims-private/`. Create the private `.env` there; do not upload a local `.env`, logs, stored records or photos.
2. Extract the public web ZIP directly into `public_html/`. It contains only the front controller, rewrite rules and public assets. Never extract the private ZIP into `public_html`.
3. The public front controller automatically looks for `../dims-private/app/bootstrap.php` when `DIMS_PRIVATE_PATH` is not set. If using another directory name, configure `DIMS_PRIVATE_PATH` in the hosting environment or public `.htaccess` with the account's exact private path, for example `SetEnv DIMS_PRIVATE_PATH /home/ACCOUNT/dims-private`. Do not guess the account path.
4. Set `DIMS_STORAGE_PATH` to an absolute writable path outside `public_html`, such as `/home/ACCOUNT/dims-private/storage`. Keep documents, student photos, transcripts, receipts, exports and logs private there.

## Database and environment

1. In cPanel **MySQL Databases**, create a database and a dedicated database user. Grant only the privileges needed by the running application. Use a separate migration/admin account for schema changes where the plan permits.
2. For a new database, import all migrations `database/migrations/001_foundation.sql` through `029_lecturer_workspace.sql` in numeric order, then import `database/seeders/001_foundation_seed.sql`. Open `/setup` over HTTPS and create the initial Super Administrator. After setup, run seeders `002_daniel_institute_catalog.sql` through `008_additional_divinity_programme_structures.sql` in numeric order to load the institute catalogue, public OCW catalogue and programme content. For an existing installation, apply every missing migration in numeric order through 029, then rerun the foundation seeder to add or refresh permissions. Run any catalogue/content seeders that are still needed; back up the database first.
3. Create the private `.env` from `.env.example`. Set `APP_ENV=production`, `APP_LOCAL_MFA_BYPASS=false`, `APP_FORCE_HTTPS=true`, `APP_URL=https://di.icgchead-office.com`, an empty `APP_BASE_PATH` for the domain root, and `SESSION_COOKIE_PATH=/`. Generate separate random secrets for `APP_KEY` and `APP_SETUP_KEY` (generate locally with XAMPP's `php -r "echo bin2hex(random_bytes(32)), PHP_EOL;"`), and set the cPanel database name/user/password and `MAIL_FROM`. Never copy the local `.env` or use the example secrets.
4. Keep `.env` and all credentials outside `public_html`. Use cPanel's PHP selector to choose the newest secure PHP release available to the account. Enable PDO MySQL, OpenSSL, fileinfo and GD; review other required extensions in diagnostics. Permit the 5 MB student photo upload cap in PHP's `upload_max_filesize` and `post_max_size` without exceeding the hosting plan's limits.
5. If the private directory is not writable by PHP, create storage subdirectories using cPanel File Manager and set the least permissive working permissions supported by the host (typically directories `750` or `755`, files `640` or `644`). Never use `777`. Confirm the actual account's PHP user/group behavior.
6. Set `APP_FORCE_HTTPS=true` only after SSL is active and the site's HTTPS URL is confirmed. Enable and test the cPanel SSL certificate/HTTPS redirect. Secure cookies are set when HTTPS is detected or this flag is enabled.
7. Open `/setup` over HTTPS, create the first administrator and complete TOTP enrollment. Then remove or rotate `APP_SETUP_KEY`; setup is also permanently unavailable once a user exists.
8. Test sign-in, MFA, password reset email, logout, CSRF rejection and the health page in production before importing personal records.
9. After initial login, authorized staff can configure academic structure and admissions, including an open intake for the applicant portal, operate academic records and final grades, invite enrolled students to the Phase 6 student portal, review grade appeals, manage the self-hosted OCW library, and use Phase 7 student billing and the general ledger. Applicants register without email verification, submit when an intake is open, and monitor their own application status. Registration and application submissions are each limited to five attempts per IP per hour. OCW PDFs are stored in private storage and streamed only when both the resource and its course page are published. Student portal invitations use PHP `mail()` and require verified mail delivery; authorized staff must configure the institutional appeal window before accepting appeals. Configure periods and finance roles before posting any transactions. HR and other ERP modules remain future work; gateway and online payments are not included. Complete the hosting compatibility checklist against the actual plan before production use.

## cPanel Cron Jobs

Use the PHP CLI binary path shown by cPanel and schedule `dims-private/cron/maintenance.php` once daily. Example command (replace the account path and PHP binary with the values shown by the account):

```text
/usr/local/bin/php /home/ACCOUNT/dims-private/cron/maintenance.php
```

The script rejects web requests and only removes expired login throttling, reset-token and old session records in bounded SQL statements. Confirm Cron Jobs are available on the specific plan and inspect `storage/logs/application.log` after its first run.

## Backups and recovery

- Schedule encrypted database and private-file backups using available cPanel backup features or an approved off-host backup destination.
- Keep backups access-controlled and separate from `public_html`; do not serve backup archives over HTTP.
- Before restoration, suspend application writes, restore the database and private storage from the same recovery point, verify `APP_KEY`, reapply schema changes as needed, and test login/MFA and representative records.
- Restore a backup to a separate test database periodically. Do not claim recovery readiness until the restore has been tested.

Shared hosting may limit PHP runtime, memory, CPU, mail delivery, database concurrency and scheduled-job frequency. If measured workloads exceed the account limits, bound work with smaller batches or move to a GoDaddy VPS before enabling high-volume reporting or integrations.
