**ALORIG SYSTEMS** **Infrastructure & Platform Master Plan** Multi-App Centralized Server Architecture IGNY8 Phase 2 Development Roadmap Complete Execution Sequence with File References Version 1.0 \| March 2026 Confidential --- Alorig Systems *For use with Claude Code Desktop & Cowork* **1. Executive Context** This document is the single operational reference for building and deploying the Alorig multi-app ecosystem on a centralized KVM 4 VPS, and for executing the IGNY8 Phase 2 development roadmap. It is designed to be loaded into Claude Code Desktop or Cowork as the primary instruction document, alongside the referenced project files. **1.1 What This Document Covers** - New VPS setup: shared infrastructure for 7 apps on Hostinger KVM 4 (4 vCPU, 16GB RAM, 200GB NVMe) - DNS migration from hosting middleman to Cloudflare (free tier) - IGNY8 production migration from old server to new clean architecture - IGNY8 staging environment for Phase 2 development - IGNY8 Phase 2 complete execution sequence (SAG implementation through all modules) - Container pruning: removing 6 unnecessary containers from legacy setup - Subsequent app deployment order for Psydge, Snapify, Observer OS, Alorig Site Builder, AstroTiming, ASMS **1.2 The 7 Long-Term Resident Apps** -------- ------------------------- -------------------------------------------------------------- ---------------------- **\#** **App** **Description** **Stack** 1 **IGNY8** AI-powered SEO content automation SaaS (flagship) Django + React 2 **Psydge** AI trading platform with real-time WebSockets (heaviest app) Django + Channels 3 **Snapify** E-commerce platform for Pakistani sellers Django + React 4 **Observer OS** Consciousness/behavioral awareness app (migrates when heavy) Django + React 5 **Alorig Site Builder** AI-powered multi-tenant website platform Django + Payload CMS 6 **AstroTiming** Planetary hour timing engine Django/FastAPI 7 **ASMS** School management system Phase 1 Django + React -------- ------------------------- -------------------------------------------------------------- ---------------------- **1.3 Reference Files Index** All IGNY8 development plans exist as separate documents. This is the complete index with their role in the execution sequence: ---------------------------------------------------- ---------------------------------------------------------------------------------------- --------------------- **Filename** **Scope** **Used In Phase** **IGNY8-Current-State.md** Complete platform state, tech stack, all modules All phases **SAG-Master-Document.md** Pure SAG methodology and clustering rules Phase 3 reference **SAG-IGNY8-Implementation.md** Three-layer SAG architecture, Case 1/Case 2 flows, data models, 9-phase implementation Phase 3 primary **DocA-SAG-Architecture-Dev-Guide.md** Developer implementation guide for SAG backend Phase 3 code ref **DocB-Platform-Modules-Dev-Guide.md** Developer guide for all platform modules Phases 3-5 code ref **DocC-WordPress-Ecosystem-Dev-Guide.md** Plugin, theme, toolkit developer guide Phases 4-5 code ref **DocD-Business-Services-Dev-Guide.md** Managed services and business layer guide Phase 6 code ref **IGNY8-Consolidated-Module-Plans.md** Content Types, Taxonomy, Optimizer, GSC, Socializer, Video plans Phase 3B parallel **SAG-Doc3-Interlinking-Specification-PLAN.md** Linker module evolution with SAG-aware linking Phase 4 **SAG-Doc4-External-Backlink-Campaign-PLAN.md** External backlink campaign generation and tracking Phase 4 **IGNY8-Plugin-Build-Plan.md** Full standalone SEO plugin (free + connected) Phase 5 **Theme-Build-Plan.md** Premium WordPress theme with CPTs, taxonomies, WooCommerce Phase 5 **IGNY8-Rich-Schema-SERP-Enhancement-Module.docx** Rich schema / structured data module Phase 5 **IGNY8-Industry-Sector-Master-List.md** 50+ industries with sector classifications Phase 3 data **SAG-Niche-Definition-Process.docx** Niche definition production workflow Phase 3 reference **SAGIndustry01HealthcareMedical.xlsx** Healthcare sector Excel template (formatting reference) Phase 3 template ---------------------------------------------------- ---------------------------------------------------------------------------------------- --------------------- **2. Infrastructure Setup (Phase 1)** Everything starts here. No app deployment happens until the shared foundation is solid on the new KVM 4 VPS. **2.1 DNS Migration to Cloudflare** Current state: domain nameservers point to hosting provider, hosting provider has A records to VPS, email settings on hosting server. This adds an unnecessary middleman. **Actions:** - Create Cloudflare account (free tier), add all Alorig domains - At each domain registrar, change nameservers to Cloudflare-assigned nameservers - In Cloudflare, create wildcard A record (\*.igny8.com, \*.alorig.com, etc.) pointing to new VPS IP - Add MX, SPF, DKIM, DMARC records for email (same mail server, just managed in Cloudflare now) - Create Cloudflare API token with Edit Zone DNS permission (needed for Caddy SSL automation) - Verify all domains resolve correctly before proceeding **Result:** All DNS managed in Cloudflare dashboard. DDoS protection and CDN caching included. Wildcard SSL via Caddy + Cloudflare DNS challenge. Email routing unchanged. **2.2 Shared Alorig Infrastructure Layer** The foundation that all 7 apps share. Built once, used by everything. **Docker Network:** - Create external Docker network: alorig\_net - All app containers and shared services join this network **Shared Services (alorig-infra docker-compose.yml):** ---------------------- -------------- ------------------------ ----------------------------------------------------------------- **Container** **Image** **Purpose** **Notes** **alorig\_postgres** postgres:16 Primary database Separate database per app, shared instance **alorig\_redis** redis:7 Cache + Celery broker App-specific key prefixes (igny8:, psydge:, etc.) **alorig\_caddy** caddy:2 Reverse proxy + SSL Cloudflare DNS challenge for wildcard certs, routes all domains **portainer** portainer-ce Docker GUI management Keep for managing 25+ containers visually **flower** mher/flower Celery task monitoring On-demand later; essential during multi-app setup ---------------------- -------------- ------------------------ ----------------------------------------------------------------- **2.3 Container Pruning (Legacy Cleanup)** The current IGNY8 server runs 14 containers. Six must be removed permanently: ------------------------- ------------------------------------------------------------------------ --------------- **Container to Remove** **Why** **RAM Freed** **igny8\_frontend-dev** Vite dev server on production. Build static, serve via Caddy. \~250 MB **igny8\_marketing** Entire Django instance for marketing site. WordPress replaces this. \~400 MB **igny8\_pgadmin** Redundant. psql CLI + Django manage.py dbshell cover everything. \~250 MB **gitea** Self-hosted Git server. GitHub free tier handles private repos. \~400 MB **igny8\_filebrowser** Web file manager. VS Code Remote SSH or Claude Code SSH replaces this. \~150 MB **setup-helper** Alpine container running sleep infinity. Dead weight. \~0 MB ------------------------- ------------------------------------------------------------------------ --------------- **Total RAM recovered:** \~1.5 GB --- equivalent to one additional app's worth of headroom. **2.4 Per-App Container Pattern** Every Django app follows an identical container structure: - appname\_backend --- Django + Gunicorn (WSGI) or Daphne (ASGI for Psydge) - appname\_celery\_worker --- Background task processing - appname\_celery\_beat --- Scheduled task scheduling - React frontend built as static files, served through alorig\_caddy (no separate frontend container) **Exception:** Psydge adds a 4th container for Django Channels (ASGI/WebSocket). Alorig Site Builder adds a Node.js/Payload CMS container alongside its Django containers. **2.5 Resource Budget** -------------------------------------------------------- ----------------------- ------------------------------------------------------------- **Component** **RAM Estimate** **Notes** Shared infra (PG + Redis + Caddy + Portainer + Flower) \~2.5 GB PostgreSQL serving 7 databases is the biggest consumer IGNY8 (prod + staging) \~1.8 GB Heaviest AI processing but I/O-bound (external APIs) Psydge \~1.75 GB WebSockets hold memory per connection; heaviest at 30 users Snapify \~700 MB Standard CRUD with image processing tasks Observer OS \~700 MB AI pattern detection is external API calls Alorig Site Builder \~1.25 GB Django + Payload/Node.js dual runtime AstroTiming \~400 MB Lightest app. Brief CPU bursts for ephemeris calculations ASMS Phase 1 \~600 MB Pilot scale, basic modules only OS + Docker overhead \~1.0 GB **TOTAL STEADY STATE** **\~10.7 GB / 16 GB** **\~5 GB headroom for spikes and growth** -------------------------------------------------------- ----------------------- ------------------------------------------------------------- **Upgrade trigger:** Steady-state RAM consistently above 13 GB, or OOM kills on any container. Options: upgrade to KVM 8, or split Psydge to its own KVM 1. **3. IGNY8 Migration & Stabilization (Phase 2)** Before any new development begins, IGNY8 must be running cleanly on the new server with both production and staging environments. **3.1 Production Migration** - Build clean Docker Compose for IGNY8 on new VPS: igny8\_backend, igny8\_celery\_worker, igny8\_celery\_beat - Build React frontend (vite build), output static files to Caddy-served directory - Configure Caddy routes: app.igny8.com → static React, api.igny8.com → Django backend - pg\_dump from old server, pg\_restore to alorig\_postgres on new server (database: igny8\_db) - Migrate any media files not on S3/DO Spaces - Update plugin distribution URLs if applicable - DNS cutover: point app.igny8.com and api.igny8.com to new VPS IP in Cloudflare - Caddy auto-provisions SSL certificates via Cloudflare DNS challenge - Verify all functionality: login, content pipeline, WordPress plugin connectivity, automation runs *📄 IGNY8-Current-State.md --- Section 28 (Deployment) for architecture reference* **3.2 Staging Environment** - Identical 3-container setup: igny8\_staging\_backend, igny8\_staging\_celery\_worker, igny8\_staging\_celery\_beat - Separate database: igny8\_staging\_db on same PostgreSQL instance - Separate Redis key prefix: igny8\_staging: - Caddy routes: staging-app.igny8.com and staging-api.igny8.com - Seed with copy of production data (anonymized if needed) - All Phase 2+ development happens here first, then merges to production **3.3 Fix Known Limitations Before Phase 2** These are documented bugs and gaps in IGNY8-Current-State.md Section 26 that should be resolved before SAG development begins: - Backend API gaps: Content generation settings save, publishing settings save, profile settings save, password change - Module guard: Extend beyond sidebar to block direct URL access to disabled modules - Missing SaaS API endpoints: /system/ping/, /system/sites/{id}/status/, and others needed for plugin automation - Stripe/PayPal production credentials: Complete payment processing setup *📄 IGNY8-Current-State.md --- Section 26 (Known Limitations & Pending Items)* **4. IGNY8 Phase 2: SAG Implementation (Phase 3)** This is the core transformation: IGNY8 evolves from a keyword-driven content tool into a structure-first site architecture engine powered by the Semantic Authority Grid methodology. This is the largest and most complex development phase. **4.1 SAG Data Foundation (Weeks 1--3)** Build the new data layer that SAG depends on. Backend only, no UI. - Create SAGBlueprint, SAGAttribute, SAGCluster models - Create SectorAttributeTemplate model - Blueprint CRUD API endpoints - Add nullable SAG fields to existing Cluster, Tasks, Content, ContentIdea models - Basic blueprint viewer in Site Settings (read-only) *📄 SAG-IGNY8-Implementation.md --- Section 16 (Data Models & Schema)* *📄 DocA-SAG-Architecture-Dev-Guide.md --- Phase 1 implementation details* **4.2 Sector Attribute Templates (Weeks 4--6)** Build the attribute intelligence layer that makes SAG possible. - Manually create attribute templates for top 5--8 sectors with highest user base - AI-assisted template generation for remaining sectors - Template loading, merging (multi-sector), and validation logic - API: given industry + sectors → return attribute framework *📄 SAG-IGNY8-Implementation.md --- Section 5 (Layer 1: Attribute Framework)* *📄 IGNY8-Industry-Sector-Master-List.md --- Complete sector classifications* *📄 SAGIndustry01HealthcareMedical.xlsx --- Excel template reference* **4.3 Cluster Formation & Keyword Generation (Weeks 7--9)** Core SAG intelligence: turning attributes into clusters and auto-generating keywords. - AI prompt for forming clusters from attribute intersections - Cluster type classification logic (Product, Condition, Feature, Brand, Informational, Comparison) - Keyword auto-generation engine (templates per sector type, 300--500+ keywords per site) - Blueprint assembly from attributes → clusters → keywords *📄 SAG-IGNY8-Implementation.md --- Section 7 (Layer 3: Cluster Formation)* *📄 SAG-Master-Document.md --- Clustering rules and methodology* *📄 SAG-Niche-Definition-Process.docx --- Production workflow reference* **4.4 Setup Wizard --- Case 2: New Site (Weeks 10--12)** First user-facing SAG feature. New site setup generates full architecture automatically. - Add Site Structure step to wizard (Step 3) - Attribute review UI --- user confirms or adjusts AI-proposed attributes - Business details input forms (per site type) - Blueprint preview UI - Quick mode vs detailed mode - Blueprint confirmation and storage *📄 SAG-IGNY8-Implementation.md --- Section 9 (Case 2: New Site from Scratch)* **4.5 Blueprint-Aware Content Pipeline (Weeks 13--15)** Enhance the existing 7-stage pipeline to use SAG blueprints for content generation. - Idea generation reads blueprint context (correct Sector, Structure, Type, Cluster) - Task creation with blueprint context and content type mapping - Type-specific prompt selection in Writer (hub pages, product pages, service pages, etc.) - Auto taxonomy assignment on content creation - Blueprint execution priority drives automation queue ordering *📄 SAG-IGNY8-Implementation.md --- Section 14 (Integration with IGNY8 Pipeline)* *📄 IGNY8-Consolidated-Module-Plans.md --- Section A (Content Types Writing Plan)* **4.6 Taxonomy Creation Flow (Weeks 16--17)** Push SAG-generated taxonomies from IGNY8 to WordPress. - Taxonomy creation payload generator from blueprint - Plugin endpoint to create WordPress taxonomies - Existing taxonomy detection and mapping (for Case 1 sites) - Taxonomy sync status tracking *📄 SAG-IGNY8-Implementation.md --- Section 13 (Taxonomy Creation Flow)* *📄 IGNY8-Consolidated-Module-Plans.md --- Section B (Taxonomy & Term Content Plan)* **4.7 Case 1: Existing Site Analysis (Weeks 18--21)** AI extracts SAG structure from existing site data --- the reverse-engineering path. - Plugin sends site data (products, categories, taxonomies, content) to IGNY8 - AI attribute extraction from unstructured site data - Gap analysis engine: what the site has vs what SAG recommends - User confirmation UI for discovered attributes and proposed structure - Product auto-tagging based on discovered attributes *📄 SAG-IGNY8-Implementation.md --- Section 8 (Case 1: Existing Site Intelligence)* **4.8 SAG Health Monitoring (Weeks 22--24)** - SAG Health Score calculation per blueprint - Weekly health check automation via Celery Beat - Blueprint evolution triggers (when to recommend adding clusters/attributes) - Dashboard SAG Health widget - End-to-end testing of both Case 1 and Case 2 flows *📄 SAG-IGNY8-Implementation.md --- Phase 8 details* **4.9 Parallel Track: Module Development** These modules can be developed alongside SAG phases 4.5--4.8 since they have independent or lighter dependencies. **GSC Integration (10 weeks, parallel with SAG Phases 4.3+)** - Google Search Console OAuth + site connection - URL inspection queue and status tracking - Auto-indexing hooks for newly published content - Plugin status sync and performance metrics *📄 IGNY8-Consolidated-Module-Plans.md --- Section F (GSC Integration)* **Content Types Writing (parallel with SAG Phase 4.5)** - Extend Writer pipeline: pages, products, services, company pages, taxonomy terms - Type-specific idea templates, writer prompts, and publishing mappings *📄 IGNY8-Consolidated-Module-Plans.md --- Section A (Content Types Writing Plan)* **5. Post-SAG Module Development (Phase 4)** With SAG foundation in place, these modules activate in sequence. **5.1 Interlinking Specification (Linker Module)** Evolve the existing (inactive) Linker module into a SAG-aware internal linking engine. - 7 link relationship types: vertical upward, vertical downward, horizontal sibling, cross-cluster, taxonomy contextual, breadcrumb structural, related content - Pre-computed links generated at review stage (before publish) - Link density rules per page type - WordPress plugin integration for link injection *📄 SAG-Doc3-Interlinking-Specification-PLAN.md --- Complete specification plan* **5.2 External Backlink Campaign Module** Auto-generate backlink campaigns from SAG blueprints. - Page tier assignment from cluster types (T1--T5) - Country-specific campaign generation (PK, UK, USA, CA templates) - FatGrid marketplace integration for link ordering - Monthly execution roadmap automation - Tipping point detection via GSC data *📄 SAG-Doc4-External-Backlink-Campaign-PLAN.md --- Complete specification plan* **5.3 Optimizer Module** Content optimization based on cluster mapping and performance data. *📄 IGNY8-Consolidated-Module-Plans.md --- Section E (Optimizer Module Plan)* **6. WordPress Ecosystem Build (Phase 5)** The complete WordPress product suite that makes SAG visible on client sites. **6.1 IGNY8 Plugin (Standalone SEO + Connected Premium)** Full replacement for Yoast/RankMath as a free standalone plugin, with premium connected features when linked to IGNY8 SaaS. - 14 modules across 9 phases - Standalone: SEO meta, schema, sitemap, redirects, analytics, site intelligence, linking suggestions - Connected: content sync, SAG blueprint sync, taxonomy creation, automation triggers - WordPress.org distribution as free plugin *📄 IGNY8-Plugin-Build-Plan.md --- Complete build plan* *📄 DocC-WordPress-Ecosystem-Dev-Guide.md --- Developer implementation guide* **6.2 Companion Theme** Premium WordPress theme providing SAG-optimized site structure. - 7 custom post types, 9 custom taxonomies - 5 site-type starter templates (Blog, SaaS, E-Commerce, Corporate, Portfolio) - 50+ block patterns, section-based landing page builder - Full WooCommerce template overrides - Interlinking display components reading data from IGNY8 plugin *📄 Theme-Build-Plan.md --- Complete build plan* **6.3 Rich Schema / SERP Enhancement** *📄 IGNY8-Rich-Schema-SERP-Enhancement-Module.docx --- Module specification* **7. Business & Services Layer (Phase 6)** - Managed services add-on: Lite (\$100/site/mo), Pro (\$399/site/mo) - White-label reporting for agency clients - Client onboarding automation - Plan pricing increase timed to new feature release *📄 DocD-Business-Services-Dev-Guide.md --- Complete developer guide* **8. Other App Deployment Sequence (Phase 7)** Once IGNY8 is stable on the new server, apps are added one at a time. Each follows the per-app container pattern from Section 2.4. **8.1 Deployment Order** -------- ------------------ ----------------------------------------------------------------------------- --------------------- **\#** **App** **Why This Order** **Trigger** 1 **Psydge** Most complex (WebSockets). Deploy early to validate server under real load. After IGNY8 stable 2 **Snapify** Standard Django stack. Good validation that multi-app pattern works. After Psydge stable 3 **Site Builder** Dual runtime (Django + Payload). Tests Node.js alongside Django stack. After Snapify 4 **Observer OS** Standard Django stack. Light resource requirements initially. When ready 5 **AstroTiming** Lightest app. Minimal containers needed. When ready 6 **ASMS Phase 1** School management MVP. Basic modules for pilot deployment. When ready -------- ------------------ ----------------------------------------------------------------------------- --------------------- Each app gets its own Docker Compose file that joins alorig\_net, its own database on shared PostgreSQL, its own Redis key prefix, and its own Caddy routes. Monitor actual RAM usage after each deployment. **9. Development Tooling** **9.1 Claude Code Desktop** Primary development interface. Use the Code tab with SSH connection to VPS for all server-side work. Visual diff review for code changes. Parallel sessions for working on multiple apps simultaneously. **9.2 Claude Web Interface (claude.ai)** Continue using for strategic planning, document generation (Word/Excel via skills), SAG methodology discussions, and project knowledge queries. Project knowledge and memory sync between web and desktop. **9.3 GitHub** All repos hosted on GitHub (free private repos). Replaces self-hosted Gitea. Each app gets its own repository. **10. Execution Summary** The complete sequence at a glance: ----------- -------------------------- ----------------------------------------------------------------------------- **Phase** **What** **Key Deliverable** **1** **Infrastructure Setup** New VPS with shared Alorig infra, Cloudflare DNS, clean Docker architecture **2** **IGNY8 Migration** Production + staging running on new server, known limitations fixed **3** **SAG Implementation** IGNY8 transforms from keyword tool to site architecture engine (24 weeks) **3B** **Parallel Modules** GSC Integration + Content Types Writing (parallel with Phase 3) **4** **Post-SAG Modules** Linker, Backlink Campaigns, Optimizer activated with SAG awareness **5** **WordPress Ecosystem** Plugin (free + connected), Companion Theme, Rich Schema module **6** **Business Layer** Managed services, pricing increase, white-label reporting **7** **Other Apps** Psydge → Snapify → Site Builder → Observer OS → AstroTiming → ASMS ----------- -------------------------- ----------------------------------------------------------------------------- **Key Principles** - Nothing currently working breaks. All new features use nullable fields and feature flags. - SAG methodology is attribute-first, not keyword-first. Keywords emerge from attribute intersections. - Every app on the shared server follows the same container pattern. No snowflakes. - Staging first, production second. Always. - Monitor real resource usage after each deployment. Upgrade decisions are data-driven. - This document is the single source of truth. All referenced files contain the implementation details. *End of Document*