The three-tier admin model

Where your ops files live

Running a CodeCanyon app is not just code — it’s also ops: deploy logs, backups, monitoring scripts, secret webhook URLs. The three-tier admin model answers one question for all of it: which of these files belongs to the project, which belongs to one domain, and which is shared across the whole server?

Get this map right once and you never again wonder where a deploy log or a Discord webhook should live.

The three tiers

graph TD
  subgraph Laptop["Your laptop (project repo)"]
    Local["Admin-Local/<br/>guides · vault · customizations registry"]
  end

  subgraph Server["The hosting account (one server)"]
    Domain["Admin-Domain/<br/>per-domain runtime: deploy logs, backups, monitors"]
    ServerWide["Admin-Server/<br/>account-wide: shared scripts, webhooks, baselines"]
  end

  Local -->|deploys to| Domain
  ServerWide -->|provides defaults to| Domain

The diagram shows the flow: you author in Admin-Local on your laptop, deploy to a per-domain space on the server, and the server-wide tier supplies shared defaults to every domain.

Tier	Lives at	Scope	In git?	Examples
Admin-Local	Project repo: Admin-Local/	This one project	Yes — except 2-ProjectVault/ (gitignored secrets)	Phase guides, ProjectCard, vault, customizations registry
Admin-Domain	Server: ~/domains/<domain>/Admin-Domain/	One domain (e.g. staging.x.com, x.com)	No — runtime state	Deploy history, per-domain backups, monitor scripts, tmp
Admin-Server	Server: ~/Admin-Server/	The whole hosting account	Yes — its own repo	Monitoring scripts, shared webhooks, MD5 baselines, server environment

The mnemonic

Local → in your laptop’s project folder. Domain → on the server, scoped to one domain. Server → on the server, scoped to the whole hosting account.

Why three tiers and not one

The natural instinct is to put everything in the project’s .env. That breaks the moment one hosting account runs several Laravel apps (a common shared-hosting setup).

graph TD
  Account["One hosting account"]
  Account --> P1["Project A"]
  Account --> P2["Project B"]
  Account --> P3["Project C"]

  Shared["Admin-Server<br/>shared webhook + scripts"]
  Shared -.->|one URL, all inherit| P1
  Shared -.->|one URL, all inherit| P2
  Shared -.->|one URL, all inherit| P3

• Why not just .env per project? If a Discord webhook lives in every project’s .env, rotating it means editing N projects. Put it in Admin-Server once and every project inherits the new URL.
• Why not put everything in Admin-Server? Per-domain runtime state — deploy logs, monitor crons specific to one domain — belongs to that domain, not to a shared account-wide repo. That’s what Admin-Domain is for.

The git question — why one tier is tracked and one isn’t

The cleanest way to remember which tier goes in git: authoring state is tracked, runtime state is not.

• Admin-Local is in git because it’s authoring state — the guides and vault you write before you deploy.
• Admin-Domain is never in git because it’s runtime state — logs and timestamps that change every minute while the app runs. Runtime state in git is just noise: it bloats the repo and breaks reproducible deploys.
• Admin-Server has its own repo because the shared scripts are authored too, but they belong to the account, not to any single project.

How shared settings resolve — the cascade

When a task needs a shared setting (like a webhook URL for deploy notifications), it doesn’t guess — it checks each tier in order and uses the first one it finds:

graph TD
  Need["Task needs a webhook URL"]
  Need --> S1{"Set in the project's<br/>shared/.env?"}
  S1 -->|Yes| Use1["Use it (per-project override)"]
  S1 -->|No| S2{"Set in Admin-Server's<br/>server.env?"}
  S2 -->|Yes| Use2["Use it (server-wide default)"]
  S2 -->|No| Skip["Skip the task with a<br/>logged note — never block the deploy"]

The order matters: a per-project value wins when set (useful for a project that needs its own community channel), the server-wide value is the preferred default, and if neither is set the task simply no-ops with a “skipped” log line rather than failing the deploy.

One naming rule

The convention is the Admin- prefix everywhere — Admin-Local, Admin-Domain, Admin-Server. The inverted form Domain-Admin/ is legacy from an older convention; if you see it in an old guide or on a server, it should be migrated to Admin-Domain/.

Caution

When renaming a live server folder from the old form to the new one, leave a compatibility symlink so any deploy script still pointing at the old name keeps working until everything is updated. Remove the symlink only once nothing references the old path.

When to use which tier

Putting a file somewhere? Ask…	Then it goes in
Is it a guide, the vault, or a per-project record?	Admin-Local
Is it a log, backup, or monitor for one domain?	Admin-Domain
Is it a script, webhook, or baseline shared by all domains?	Admin-Server

Where to go next

Schema management Extending vendor tables safely with additive _zaj migrations and zajm_ tables.

Modules vs customizations The core split that decides where a code change lives.