Flat subdomain pattern: <slug>.oriz.in for every public-facing repo

Flat <slug>.oriz.in for every public repo, ~85 total

Flat subdomain pattern

Rule

Every repo with a public landing page gets <slug>.oriz.in where <slug> is its short identifier (no oriz- prefix, no -pkg / -app suffix). All one level deep so CF Universal SSL covers them without paid plan.

Examples

Why flat

1. CF SSL — Free Universal SSL covers *.oriz.in (one level only). Paid Advanced Cert needed for *.<sub>.oriz.in.
2. Memorability — journal.oriz.in reads better than pkg.journal.oriz.in or app.journal.oriz.in.
3. No type prefix needed — the URL doesn’t need to encode whether it’s an app, package, or book. The landing page does.

Why not grouped (pkg..oriz.in)

• Violates Rule 16 (one-level subdomain only)
• Requires Advanced Cert ($10/mo per zone) — kills no-card rule
• 19 APIs are already 2-level (<sub>.api.oriz.in) as a grandfathered exception via GH Pages Let’s Encrypt — those work because GH Pages, not CF, terminates SSL there

What this kills

• Type-prefixed subdomains like pkg.astro-shell.oriz.in
• Long-form like package-astro-shell.oriz.in — too noisy

Risk: namespace pollution

We’ll have ~85 entries in DNS. CF allows unlimited records on a free plan. Risk = readability of dig oriz.in any output, which is solvable by sorting + categorizing in knowledge docs.

Cross-refs

• One-level subdomain rule ? [[rules/one-level-subdomain-only]]
• CF Pages apps-only ? [[rules/hosting-split-cf-and-github-pages]]
• API triple-rail ? [[decisions/compute/api-hosting-triple-rail]]

Edit on GitHub · Back to index