← knowledge.oriz.in

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

decision decisionsubdomainsdnsnamingflat-namespace

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

Type Repo Subdomain
App oriz-roam-journal-app journal.oriz.in
App oriz-paisa-finance-tools-app finance.oriz.in
npm package astro-shell-npm-pkg astro-shell.oriz.in
npm package auth-core-npm-pkg auth-core.oriz.in
npm package oriz-ui-npm-pkg oriz-ui.oriz.in
Book learn-frugality learn-frugality.oriz.in
Book warren-buffett-essays buffett.oriz.in
Skill playwright-cli playwright-cli.oriz.in
Skill grill-me grill-me.oriz.in
Extension fork Ai-rewrite ai-rewrite.oriz.in
API oriz-flow-fii-dii-activity-api fii-dii.api.oriz.in (grandfathered 2-level)

Why flat

  1. CF SSL — Free Universal SSL covers *.oriz.in (one level only). Paid Advanced Cert needed for *.<sub>.oriz.in.
  2. Memorabilityjournal.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)

What this kills

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