Set up shared hosting

◆TL;DR

Objective — Make a shared-hosting account ready for app deploys (Admin-Server scripts, cron, SSH, alerts) before you run an app-specific deploy playbook.

For beginners and agents

This setup is per hosting account, not per app. Use this guide for the mental model, then run the executable shared-hosting setup playbook. If ~/Admin-Server/scripts/status.sh already works on that account, verify and skip.

Why this is separate from app setup

An app setup playbook walks one app from source to production. Shared-hosting setup walks one Hostinger/cPanel account from empty (or shared) to operational — the Admin-Server toolkit, backup cron, and alert webhooks that every app on that account will reuse.

graph LR
  A["New hosting account"] --> B["Shared-hosting setup<br/>(this guide)"]
  B --> C["App setup<br/>one app"]
  C --> D["Continuous-deploy · ongoing"]

If you already run other projects on the account and ~/Admin-Server/scripts/status.sh exists, choose verify existing instead of reinstalling — but still run the log-freshness probe. Scripts on disk do not prove Hostinger cron jobs are still firing.

What this delivers

Outcome	How you know it is done
Admin-Server toolkit on the account	status.sh exits 0 and the log-freshness probe has no STALE rows
Cron documented in Hostinger API/hPanel	Six cron entries match the status script output, use absolute /home/<user>/Admin-Server/... commands, and each expected log is fresh within cron interval ×2
Discord (or Slack) ops alerts wired	Synthetic test ping from ops channel config; deploy/backups/heartbeat slots can stay blank but are explicit no-ops
SSH alias in your ~/.ssh/config	ssh staging / ssh production work without passwords

Three paths in

Situation	Action
Brand-new hosting account	Full shared-hosting install (Admin-Server + cron + alerts)
Account already runs other Zaj apps	Verify-only — run status script + log freshness, fix gaps
Shared portfolio server	Same as verify — never duplicate Admin-Server

Where to execute

The executable version now lives on the Build shelf:

• Shared-hosting setup playbook — once-per-account Admin-Server setup, cron, webhooks, MD5 baselines, and the verified skip path
• Your app-specific deploy playbook — the consumer that assumes server prerequisites are met before deploy work

Do not skip on a fresh account

Deploying before shared-hosting setup completes means missing backups, broken cron, and silent deploy failures — fix the server once, then clone apps onto it.

Related

Shared-hosting setup playbook Run this when a hosting account needs the Admin-Server toolkit, cron, and alert webhooks.

All playbooks Choose the app-specific workflow that consumes this server setup.