SERVER 345 ALLIANCE NETWORK

DEPLOYMENT MODEL
Each alliance gets a separate copy of this application under its own subdomain.
Each copy has an independent MySQL/MariaDB database, dedicated database user,
private configuration, storage directory, session files, R5 leader, and cron job.
This is deliberately not a shared-database multi-tenant app or a central SSO system.

Confirmed base domain: lastasylum345.com
Example layout (ABC is an example alliance, not an existing participant):
  fop.lastasylum345.com -> /home/ACCOUNT/alliances/fop/public
  abc.lastasylum345.com -> /home/ACCOUNT/alliances/abc/public

The base domain can later have a directory of participating alliances. This
package does not create that separate directory or register domains/change DNS.

FOR EACH NEW ALLIANCE
1. Add its subdomain and HTTPS certificate in cPanel. Give it its own document
   root pointing only to that installation's public/ folder.
2. Extract a fresh copy of this package into a new private directory.
3. Create a NEW database and a NEW database user, permitted to access only that
   alliance's database. Never reuse FOP's database or copy FOP's live member data.
4. Copy config.example.php to config.php and edit name, code, brand_line1,
   brand_line2, hero_line1, hero_line2, hero_accent, monogram, base_url, server,
   database settings, and mail sender. Keep names as plain text, not HTML.
5. Give it a separate Discord application/bot and register its exact OAuth
   redirect URL. If intentionally sharing an application, register every exact
   redirect URL individually; do not use wildcard OAuth redirects.
6. Run bin/install.php, then bin/leader.php for that alliance's first R5.
7. Add a cPanel cron entry pointing to THAT installation's bin/update.php.
8. Add only that alliance's selected Discord channels and approved feeds.

ACCESS BOUNDARIES
R5/R4 website access applies only to that installation. There is no cross-alliance
administrator screen or shared member access. A player joining two alliances has
separate memberships and separate approvals. A host-only cookie and a separate
private session directory prevent sign-in sessions crossing installations.
Production requests are rejected if the hostname does not match base_url.

Do not set a cookie domain such as .BASE_DOMAIN, share session save paths, point
several subdomains at one configured installation, or reuse a database. Each of
those would undermine the intended separation.

The owner of the hosting account can administer its files and databases. R5/R4
website admins should not receive the shared cPanel password. If alliance owners
need their own hosting/file access, provision separate cPanel accounts through
WHM or your host for operating-system-level isolation.

MAINTENANCE
Apply reviewed code updates to every installation while preserving each private
config.php and storage/ directory. Back up databases independently. Keep an
inventory of alliance code, subdomain, installation path, database, R5 contact,
Discord application, and cron job. The inventory must not contain passwords.
Content is not automatically shared between alliances; public source feeds can
be configured independently in each site.
