LORE+CAIRNET Deployment Topology & Service Map

ELI5

LORE and CAIRNET live on different websites but share the same power source (Pebble) and security guard (Airlock). They’re deployed the same way, to the same cloud, with the same branding. Think of them as two shops in the same mall — different addresses, different products, but the same building management.

Technical Deep Dive

Deployment Map

Network Flow

flowchart TB
    USER["End User / Agent"]

    subgraph Vercel["Vercel (frontend)"]
        LORE["lore.devarno.cloud\nNext.js 14"]
        CAIRN["cairn.devarno.cloud\nNext.js 14"]
    end

    subgraph Railway["Railway (backend)"]
        MCP["mcp.devarno.cloud\nPebble Gateway · FastAPI"]
        AIRLOCK["airlock.devarno.cloud\nAirlock Auth · Hono"]
        subgraph DB["Shared Postgres (Railway addon)"]
            PG["proof_* tables\ncairn_* tables"]
        end
    end

    USER -->|"browser / API"| LORE
    USER -->|"browser / API"| CAIRN

    LORE -->|"cookie: .devarno.cloud\n/api/knowledge/*"| MCP
    CAIRN -->|"cookie: .devarno.cloud\n/api/cairn/*"| MCP

    LORE -->|"session validation"| AIRLOCK
    CAIRN -->|"session validation"| AIRLOCK

    MCP --> PG
    AIRLOCK --> PG

The topology groups services by platform rather than by application so the shared infrastructure (Airlock, Pebble, Postgres) is visually distinct from the application-specific frontends. Both LORE and CAIRNET converge on the same Railway cluster, making it clear that a Railway outage affects both apps simultaneously and that Airlock is a single point of trust for all cookie validation.

Build Configuration

Both LORE and CAIRNET share near-identical Vercel deployment configs:

// lore/vercel.json, cairnet/vercel.json — identical structure
{
  "framework": "nextjs",
  "buildCommand": "next build",
  "outputDirectory": ".next"
}

Both use standalone output mode in next.config.mjs:

output: "standalone"

Environment Variables

Airlock Trusted Origins

Both subdomains must be registered in Airlock:

// airlock/src/index.ts — CORS origins
"https://lore.devarno.cloud",
"https://cairnet.devarno.cloud"

// airlock/src/lib/auth.ts — trustedOrigins for cookie validation
"https://lore.devarno.cloud",
"https://cairnet.devarno.cloud"

Note: The CAIRN dashboard URL is cairn.devarno.cloud but the CORS entry is cairnet.devarno.cloud — this naming inconsistency is a known quirk (the repo is named cairnet but the deployed subdomain is cairn).

Pebble Feature Flags

class CairnConfig(BaseModel):
    enabled: bool = False                    # PEBBLE_CAIRN__ENABLED
    auto_graduation_enabled: bool = False    # PEBBLE_CAIRN_AUTO_GRADUATION
    auto_graduation_fossil_threshold: int = 5
    auto_graduation_distinct_org_threshold: int = 3
    stone_decay_days: int = 30               # fade threshold
    stone_archive_days: int = 90             # archive threshold

These flags control whether CAIRNET’s MCP tools and API routes are active. LORE has no equivalent feature flag — it’s always on.

Key Terms

• Vercel → Deployment platform for all Next.js dashboards (LORE, CAIRNET, hubble, hatch, pebble-web)
• Railway → Deployment platform for backend services (Pebble, Airlock) with managed Postgres + Redis addons
• Standalone output → Next.js build mode producing a self-contained deployment
• Airlock trusted origins → CORS + cookie validation allowlist — both LORE and CAIRNET must be registered
• PEBBLE_CAIRN__ENABLED → Feature flag controlling CAIRNET’s MCP provider and API routes — defaults to false

Q&A

Q: Why Vercel for dashboards and Railway for backends? A: Vercel optimises for Next.js SSR/edge rendering. Railway provides managed Postgres + Redis and is better suited for long-running Python/Rust/Go services.

Q: What happens if Railway is down but Vercel is up? A: LORE and CAIRNET will serve cached/stale pages or show the DegradedBanner (outage variant). The Result<T> contract surfaces the 502/503 from the proxy layer.

Q: How are secrets managed across deployments? A: Environment variables in Vercel dashboard (per-project) and Railway service variables. No .env files in the repo — the committed .env.example files are templates only.

Examples

The deployment topology is like a shopping mall — Vercel is the storefront (customer-facing shops), Railway is the back office (inventory, security, staff rooms). Airlock is the mall security desk that checks everyone’s ID once. LORE and CAIRNET are two different stores that share the same back office and security.