DevOps, Domains & Infrastructure Standards

DevOps, Domains & Infrastructure Standards

Complete standards for deployment infrastructure, CI/CD pipelines, domain management, monitoring, and the subdomain branding strategy. The operational backbone for every shipped project.

Overview

This standard covers the operational infrastructure behind every project — how code moves from commit to production, how domains and subdomains are managed, how services are monitored, and the overarching brand/subdomain strategy.

Prerequisites: General Standards (Git workflow, security).

What this covers:

  • CI/CD pipeline configuration
  • Deployment platforms (Vercel, Cloudflare, GitHub Actions)
  • Domain & subdomain strategy (centralized branding)
  • DNS configuration
  • Error monitoring (Sentry)
  • Performance monitoring (Lighthouse CI)
  • Environment and secrets management

CI/CD Pipeline

Universal Pipeline

Every project follows this CI/CD pattern:

Local → Commit → GitHub → CI (check, test, build) → Deploy (production)

GitHub Actions Workflow Template

name: CI/CD
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  quality:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '22'
          cache: 'npm'
      - run: npm ci
      - run: npm run check
      - run: npm test
      - run: npm run build
        env:
          PUBLIC_SENTRY_DSN: ${{ secrets.SENTRY_DSN }}
          SENTRY_AUTH_TOKEN: ${{ secrets.SENTRY_AUTH_TOKEN }}

Pipeline Steps Explained

Step Command What it catches
Check npm run check TypeScript errors, Astro config issues
Test npm test Unit/integration failures, regressions
Build npm run build Production build errors, asset issues
Lighthouse lhci autorun Performance regression (Core Web Vitals)
Deploy Vercel/GitHub Automatic on main branch

Pre-Commit Hooks (Husky)

// .husky/pre-commit
npm run check
npm test
npm run build

All three must pass before a commit is created. This catches issues at the earliest possible point.


Deployment Platforms

Primary: Vercel

Feature Configuration
Framework Auto-detected (Astro, Next.js)
Build command npm run build (or build:fast for quick iteration)
Output directory dist/ (Astro) / .next/ (Next.js)
Node version 22.x
Environment variables Set in Vercel Dashboard per project
Preview deployments Auto-generated for every PR
Production domain {project}.vercel.app (temporary) → custom subdomain

When to Use Alternatives

Platform When
Vercel Default — best DX, fastest cold starts for SSR
Cloudflare Pages Edge-heavy workloads, lower egress costs at scale
GitHub Pages Static-only, open source project docs
Self-hosted Only when compliance or data residency requires it

Domain & Subdomain Strategy

The Principle

One domain. Unlimited subdomains. Zero extra cost.

Instead of buying dozens of custom domains (labelkit.com, xcelerate.app, sounds.io), centralize everything under a single personal brand domain. This:

  • Saves $10–20/year × dozens of projects
  • Builds a single strong brand identity
  • Makes management trivial (one DNS zone)
  • Creates memorable, professional URLs

Brand Domain Options (Non-Exhaustive)

Domain Pros Cons
byjtt.com Full name, professional Long
thirkle.dev Short, dev-branded Less personal
thirkle.app Short, app-branded Less common TLD
jthirkle.com Short, initials Less memorable

Recommendation: Purchase the full name .com for professionalism. Add a short .dev variant for subdomain-only use if desired.

Subdomain Naming Convention

{project}.byjtt.com

Examples:

Project Subdomain
LabelKit (Chrome extension) labelkit.byjtt.com
ARC Raiders Loadout Planner arc-planner.byjtt.com
Sounds (web app) sounds.byjtt.com
Xcelerate (SaaS) xcelerate.byjtt.com
Arc Optimizer (desktop) arc-optimizer.byjtt.com
Resources/Standards resources.byjtt.com or /resources
API endpoints api.byjtt.com
Status/Monitoring status.byjtt.com

DNS Configuration

Per-project setup on Vercel:

  1. Deploy project to Vercel (gets {project}.vercel.app)
  2. Go to project → Settings → Domains
  3. Add {project}.byjtt.com
  4. Vercel provides a CNAME record — add it to your DNS provider
  5. Wait for DNS propagation (5–30 minutes typically)

DNS Provider: Cloudflare (recommended) or your registrar's default DNS.

On Vercel Hobby (free) plan: Up to 50 domains per project — more than enough.

Decision Tree: Subdomain vs Path vs Separate Domain

Does this project need its own domain for branding or trust?
├── YES, and budget allows separate domain
│   → Buy a specific domain (e.g., xcelerate.app)
├── YES, branding matters but budget is tight
│   → Use subdomain (xcelerate.byjtt.com)
└── NO, it's part of the main site
    → Use path (byjtt.com/projects/xcelerate)

Monitoring & Observability

Error Tracking: Sentry

Every production project gets Sentry:

// Initialization (lazy-loaded, non-blocking)
const dsn = import.meta.env.PUBLIC_SENTRY_DSN;
if (dsn) {
  const Sentry = await import('@sentry/browser');
  Sentry.init({
    dsn,
    integrations: [Sentry.browserTracingIntegration()],
    tracesSampleRate: 0.1,  // 10% sampling to stay within free tier
  });
}

Configuration:

  • Lazy load Sentry — never block page render for monitoring
  • Sample rate: 0.1 (10%) for browser tracing
  • Error grouping by environment and release version
  • Source maps uploaded for readable stack traces (Vercel integration)

Performance Monitoring: Lighthouse CI

# lighthouserc.json
{
  "ci": {
    "collect": {
      "numberOfRuns": 3,
      "staticDistDir": "./dist"
    },
    "assert": {
      "assertions": {
        "categories:performance": ["error", { "minScore": 0.95 }],
        "categories:accessibility": ["error", { "minScore": 0.95 }],
        "categories:best-practices": ["error", { "minScore": 0.95 }],
        "categories:seo": ["error", { "minScore": 0.95 }]
      }
    }
  }
}

Run in CI on every PR to catch regressions before they reach production.

Health Checks

  • Uptime monitoring: Vercel built-in (Hobby plan includes basic monitoring)
  • Synthetic checks: GitHub Actions cron job hitting /api/health endpoints
  • Real user monitoring: Sentry performance traces (sampled)

Environment & Secrets Management

Environment Variables

Variable Scope Example
PUBLIC_* Client-side (exposed) PUBLIC_SENTRY_DSN
* (no prefix) Server-side only SENTRY_AUTH_TOKEN
DATABASE_URL Server-side PostgreSQL connection string

Secret Management Rules

  1. Never commit secrets.env files are in .gitignore
  2. Use .env.example — committed to repo with placeholder values
  3. Vercel Environment Variables — set in project dashboard
  4. GitHub Secrets — for CI/CD tokens (SENTRY_AUTH_TOKEN, VERCEL_TOKEN)
  5. Rotate regularly — if a secret is compromised, rotate immediately
  6. Principle of least privilege — each token has the minimum scope needed

Environment Setup Checklist

  • [ ] .env.example created with all variables (no values)
  • [ ] Production variables set in Vercel/Cloudflare dashboard
  • [ ] CI/CD secrets added to GitHub repository secrets
  • [ ] Local development environment documented in README
  • [ ] No secrets in source code, compiled output, or build logs

Lighthouse CI Configuration

Local Assertion Targets

Category Minimum Score
Performance 95
Accessibility 95
Best Practices 95
SEO 95
PWA 80 (if applicable)

The only acceptable score for production is 100 across all categories. The 95 minimum is a CI gate — if it drops below 95, the build fails. Aim for 100 and diagnose any regression immediately.


Review & Shipping Checklist

  • [ ] CI/CD pipeline configured and passing
  • [ ] Preview deployment verified (all features work)
  • [ ] Custom domain/subdomain added in Vercel
  • [ ] DNS records configured and propagated
  • [ ] Sentry configured with DSN and source maps
  • [ ] Lighthouse CI assertion file committed
  • [ ] Environment variables set in production
  • [ ] .env.example committed to repo
  • [ ] GitHub repository secrets configured
  • [ ] Production build tested locally
  • [ ] SSL/HTTPS verified (auto via Vercel/Cloudflare)

Trends to Watch (2026+)

  • Edge infrastructure — More workloads shifting to edge compute for lower latency
  • GitOps — Infrastructure defined in Git, deployed via PRs
  • AI-assisted operations — LLMs analyzing logs, suggesting fixes, automating incident response
  • Observability convergence — Merging logs, traces, and metrics into unified platforms (OpenTelemetry)
  • Zero-downtime deployments — Becoming standard expectation even for small projects
  • Serverless maturation — Reduced cold starts, lower costs, broader language support

References