26 KiB
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