ArylLabsArylLabs/Docs
Docs›Page

ArylHive GitHub CI/CD Infrastructure

This document reveals the in-depth architectural breakdown of the GitHub Deployment System within ArylHive. It explains how raw Git repositories are transformed via secure tokens into globally distributed edge applications in seconds.

1. Core Pipeline Architecture

The deployment pipeline is an orchestration between GitHub webhooks, Cloudflare Workers acting as the CI/CD controller, a dedicated remote Build Server, and highly-available Backblaze B2/R2 storage.

flowchart TD subgraph GitHub GitRepo["Git Repository"] App["ArylLabs GitHub App"] end subgraph Edge Controller CF_Worker["Cloudflare Worker\n(CI/CD Orchestrator)"] Turso["Turso DB\n(Deployment Meta)"] end subgraph Build Fleet Builder["Build Server Pool\n(hive-build.aryl.app)"] end subgraph Origin Storage B2["Backblaze B2\n(ZIP Archives)"] end App -- "1. Webhook (Push to main)" --> CF_Worker CF_Worker -- "2. Generate JWT / Get Token" --> App CF_Worker -- "3. Dispatch Build Job" --> Builder Builder -- "4. Clone via Installation Token" --> GitRepo Builder -- "5. Run Build (npm run build)" --> Builder Builder -- "6. Upload Zipped Output" --> B2 Builder -- "7. API Response (Success/Hash)" --> CF_Worker CF_Worker -- "8. Update Active Deployment" --> Turso

2. The Deployment Execution Flow

A. Secure Authentication via GitHub Apps

Unlike basic OAuth flows that give overarching access to a user's account, ArylHive uses a deeply integrated GitHub App.

  • The Edge Controller utilizes its Private Key (`PKCS#8`) loaded via Cloudflare WebCrypto to securely sign a JWT.
  • This JWT is sent to GitHub to exchange for a short-lived Installation Access Token.
  • This ephemeral token is strictly scoped only to the specific repositories the user has selected, guaranteeing minimal blast radius.

B. The Build Server Execution (`hive-build`)

The Edge Controller instructs the external Build Server (a scalable VM or container cluster) to begin execution by passing the repo details and the scoped Installation Token.

  1. Clone: The builder securely clones the repository securely via HTTPS using the token.
  2. Dependency Resolution: Executes `npm install`, `yarn`, `pnpm`, or `bun install` depending on lockfiles detected.
  3. Build Generation: Executes the user-defined build command (e.g., `npm run build`).
  4. Archive: The generated static `out` or `dist` directory is compressed into an optimized `.zip` archive.
  5. Storage: The archive is transferred directly to the B2 origin storage buckets over a private network.

C. Edge Data Plane & Active Shift

Once successfully built, the Edge Controller atomically updates the deployment status in Turso DB to READY. It shifts the primary routing hash so that traffic on [domain].aryl.app instantly points to the new deployment ZIP hash, completing an atomic zero-downtime rollover.

3. How Requests Are Served at the Edge

The most innovative part of the system is how files are served from a `.zip` file on-the-fly globally.

sequenceDiagram participant User participant Worker as CF Worker Edge participant Turso as Turso (Routing DB) participant Cache as Cloudflare Tiered Cache participant B2 as B2 Storage (Zipped App) User->>Worker: GET https://project.aryl.app/image.png Worker->>Cache: Check Cache for /image.png alt Cache HIT Cache-->>User: 200 OK (from Edge RAM) else Cache MISS Worker->>Turso: Lookup active deployment hash Turso-->>Worker: Return B2 Object Key (e.g., "deploy_abc123.zip") %% The actual extraction logic Worker->>B2: Range Request (Fetch specific file offset) B2-->>Worker: Compressed Bytes Worker->>Worker: On-the-fly fflate memory unzip Worker->>Cache: Cache Extracted File (TTL: 1 Year) Worker-->>User: 200 OK (File payload + correct MimeType) end

4. Advanced Engineering Considerations

On-the-fly Unzipping (Stream Extraction)

Rather than unpacking millions of tiny files into an S3 bucket (which incurs massive PUT/GET request costs and extremely slow upload times), the entire website is stored as a single `.zip` file.

When a user requests `index.html`, the Cloudflare Edge Worker reads the ZIP's Central Directory locally via memory, executes a precise HTTP Range request to B2, downloads only the exact bytes correlated to that specific file, decompresses it on the edge using fflate, and serves it to the browser.

Tiered Edge Caching

Extracting bytes from a zip file on every single request would consume vast CPU cycles. Therefore, once a file is extracted and served once, it is injected directly into Cloudflare's Global Cache. Every subsequent request globally is served straight from Cloudflare's RAM in <10ms, entirely bypassing the unzipping logic and the B2 database.

Next: Learn about The Edge Network →