Files
firefrost-operations-manual/docs/FIREFROST-PROJECT-SCOPE-V2.md
Michael Krause 0170bd0baf Add Phase 1 DDoS Protection section to Project Scope
Documented:
- Phase 0 dismantling context (what/why removed)
- Phase 1 goals (simplified, maintainable protection)
- Three architecture options (Cloudflare, GRE, Hybrid)
- Implementation timeline (after Phase 0.5, before launch)
- Success metrics and fallback plan

Design session needed after Phase 0.5 completion to choose approach.
Principle: Always revise scope when revision identified.
2026-02-09 12:15:15 -06:00

17 KiB

🔥❄️ FIREFROST GAMING: PROJECT SCOPE V2.0

The Complete Technical & Business Vision


Document Version: 2.0
Created: February 9, 2026
Supersedes: firefrost-master-implementation-plan.md (v1.0)
Status: CURRENT - Single Source of Truth
Next Review: March 1, 2026


📋 EXECUTIVE SUMMARY

Firefrost Gaming is a subscription-based Minecraft server network built on the philosophy of balance: Fire + Frost = Where Passion Meets Precision.

Current Status (Feb 9, 2026):

  • 12 game servers operational (6 NC1, 6 TX1)
  • Phase 0.5 at 60% (3/5 management services deployed)
  • Automation system operational (95% reduction in manual work)
  • Three-tier documentation architecture planned

Leadership:

  • Michael "Frostystyle" Krause - Technical Lead (The Wizard)
  • Meg "Gingerfury" - Community Manager (The Emissary)

🎯 CORE PHILOSOPHY

The Fire + Frost Duality

Fire (Passion/Community):

  • Competitive gameplay (Fire Path)
  • Community warmth
  • Creative expression
  • Gingerfury's domain

Frost (Precision/Infrastructure):

  • Collaborative gameplay (Frost Path)
  • Technical excellence
  • Systematic approach
  • Frostystyle's domain

Tagline: "Fire melts barriers. Frost builds foundations."


🏗️ INFRASTRUCTURE STATUS

Deployed Services (Phase 0.5: 60% Complete)

Service 1/5: Gitea (git.firefrostgaming.com)

  • Git version control for all infrastructure
  • Deployed: Feb 8-9, 2026
  • SSL enabled, GitHub mirror configured
  • All configs version-controlled

Service 2/5: Uptime Kuma (uptime.firefrostgaming.com)

  • Infrastructure monitoring
  • Deployed: Feb 9, 2026
  • Discord integration active
  • 6 monitors operational

Service 3/5: MkDocs (docs.firefrostgaming.com)

  • PUBLIC documentation (Git-native)
  • Deployed: Feb 9, 2026
  • Material theme, search enabled
  • Markdown in Gitea → Auto-builds HTML

Service 4/5: Wiki.js (subscribers.firefrostgaming.com)

  • SUBSCRIBER documentation portal
  • Planned deployment: Feb 9 (afternoon)
  • Role-based access control
  • Git-first workflow

Service 5/5: NextCloud (downloads.firefrostgaming.com)

  • World downloads for subscribers
  • File hosting optimized
  • Planned deployment: Feb 9 (afternoon)

Game Servers (12 Total)

NC1 Charlotte (6 servers):

  • The Ember Project (216.239.104.130:25565)
  • Minecolonies (216.239.104.131:25565)
  • All The Mods 10 (216.239.104.134:25565)
  • Homestead (216.239.104.133:25566)
  • Hytale (216.239.104.131:5520)
  • EMC Subterra Tech (216.239.104.132:25566)

TX1 Dallas (6 servers):

  • Stoneblock 4 (38.68.14.26:25565)
  • Reclamation (38.68.14.27:25565)
  • Society: Sunlit Valley (38.68.14.28:25565)
  • Vanilla 1.21.1 (38.68.14.29:25565)
  • All The Mons (38.68.14.30:25565)
  • FoundryVTT (38.68.14.26:30000)

Hardware

TX1 Dallas: 32 vCPU, 256GB RAM (99% idle - management services hub)
NC1 Charlotte: 32 vCPU, 256GB RAM (game servers)
Command Center: Reserved for future DDoS protection (GRE tunnels)


🤖 AUTOMATION SYSTEM (NEW!)

The Firefrost Automation Framework

Deployed: February 9, 2026
Impact: 95% reduction in manual operations
Location: /root/firefrost-work/firefrost-operations-manual/automation/

How It Works:

Claude → Creates task script
Michael → Pastes ONE command to queue
Daemon → Executes automatically (10s polling)
Executor → Runs task, captures output
Git → Results committed back automatically
Claude → Reads results from GitHub mirror

Key Components:

  • automation-daemon.sh - Background watcher (PID management)
  • executor.sh - Task runner with auto-commit
  • queue/ - Tasks waiting to execute
  • results/ - Execution output (committed to Git)
  • logs/ - Completed tasks archive

Success Metrics:

  • Test Task 001: SUCCESS (exit 0)
  • Test Task 002: SUCCESS (automated execution)
  • BookStack deployment: 2 minutes (previously would take 20+ minutes)
  • MkDocs deployment: 1.5 minutes

Accessibility Impact:

  • Michael's hand limitations accommodated
  • Single paste operation per deployment
  • All work auditable in Git history
  • Perfect for marathon sessions

📚 THREE-TIER DOCUMENTATION ARCHITECTURE

The Complete Documentation Strategy

Tier 1: PUBLIC (docs.firefrostgaming.com)

  • Technology: MkDocs + Material Theme
  • Authentication: None required
  • Content: Server rules, getting started, modpack info
  • Workflow: Edit markdown in Gitea → Auto-rebuild
  • Status: DEPLOYED Feb 9, 2026

Tier 2: SUBSCRIBERS (subscribers.firefrostgaming.com + downloads.firefrostgaming.com)

  • Documentation: Wiki.js (premium guides, exclusive content)
  • Downloads: NextCloud (world backups, custom modpacks)
  • Authentication: Subscriber login required
  • Content: Premium guides, world downloads, exclusive perks
  • Workflow: Edit in Wiki.js UI OR Git
  • Status: DEPLOYING Feb 9 afternoon

Tier 3: STAFF (staff.firefrostgaming.com)

  • Technology: Wiki.js
  • Authentication: Staff/Admin only
  • Content: SOPs, admin procedures, internal guides
  • Workflow: Edit in Wiki.js UI OR Git
  • Status: DEPLOYING Feb 9 afternoon

Why Three Tiers?

Problem Solved:

  • Public can access basic info (no barriers)
  • Subscribers get premium value (world downloads!)
  • Staff have secure internal documentation
  • Each tier isolated (different security boundaries)
  • Git-first workflow maintained (Michael's requirement)
  • UI-first editing available (Meg's preference)

💰 SUBSCRIPTION MODEL

Tier Structure

Free Tier - "The Frozen Path"

  • Discord access (public channels)
  • Forum access
  • View public documentation
  • No server access

$1/month - "The Awakened Gateway" (The Handshake)

  • Purpose: Anti-bot/anti-grief barrier
  • Philosophy: "If you want to be an asshole, you have to pay for it"
  • Not a revenue stream - a security protocol
  • Server whitelist access
  • Basic support

$5/month - "Elemental Tier"

  • CHOOSE YOUR PATH: Fire or Frost
  • Full server access (13+ modpacks)
  • Subscriber documentation portal
  • World download access (30-day retention)
  • Priority support
  • Path-specific Discord channels

$10/month - "Ascendant Tier"

  • Everything from Elemental
  • Vote on new modpacks
  • Custom modpack requests
  • Extended world downloads (90 days)
  • Beta access to new servers

$25/month - "Eternal Flame/Eternal Frost"

  • Everything from Ascendant
  • Permanent world download access
  • Direct line to founders
  • Server naming rights
  • Custom spawn builds

Fire vs Frost Paths

Identical mechanical perks, different community identity:

🔥 Path of Fire:

  • Discord: Ignis channels (18+ only)
  • Focus: Competitive gameplay, PvP, challenges
  • Led by: Gingerfury (The Emissary)

❄️ Path of Frost:

  • Discord: Frost channels (all ages welcome)
  • Focus: Collaborative builds, exploration, creativity
  • Led by: Frostystyle (The Wizard)

Competitive Element: Michael vs Meg - who recruits more to their path?


🔐 AUTHENTICATION STRATEGY

Phased Implementation

Phase 1: Manual Management (Current - Launch to 20 subscribers)

  • Subscriber pays via Paymenter
  • Manual account creation (Wiki.js + NextCloud)
  • Email credentials
  • Track expirations in spreadsheet
  • Advantage: Zero dev time, validates market

Phase 2: Webhook Automation (20+ subscribers)

  • Paymenter webhooks trigger scripts
  • Automatic account creation/deletion
  • Automated credential emails
  • Development: 3-4 hours
  • Trigger: When manual work becomes burden

Phase 3: SSO/OAuth (100+ subscribers - optional)

  • Single sign-on across all services
  • Real-time subscription validation
  • Enterprise-grade auth
  • Development: 8-12 hours
  • Trigger: Only if subscriber count justifies complexity

Decision: Start Phase 1, upgrade to Phase 2 when needed


🎨 BRANDING & VISUAL IDENTITY

Color Palette

Fire Colors:

  • Primary: #FF4500 (Reddit Orange Fire)
  • Secondary: #FF6347 (Tomato)
  • Accent: #FFD700 (Gold)

Frost Colors:

  • Primary: #00CED1 (Dark Turquoise)
  • Secondary: #4682B4 (Steel Blue)
  • Accent: #E0FFFF (Light Cyan)

Neutral:

  • Background Dark: #2C2C2C
  • Background Light: #F5F5F5
  • Text: #FFFFFF / #000000

Logos & Assets

Location: /root/firefrost-master-configs/branding/

  • Circular Emblem (512x512) - Social profiles, favicon
  • Light Logo - Light backgrounds
  • Dark Logo - Dark backgrounds, website
  • Backgrounds - Hero images, Discord, social media
  • Character Sprites - Gingerfury (Fire) + Frostystyle (Frost)


🛡️ PHASE 1: DDoS PROTECTION SYSTEM

Overview

Status: Planning Phase
Priority: Deploy after Phase 0.5 completion, before soft launch
Purpose: Replace dismantled Phase 0 GRE system with reliable protection

Phase 0 Context (Completed)

What Was Dismantled:

  • Complex GRE tunnel configuration
  • IP cloaking system prone to failures
  • Over-engineered solution causing more problems than it solved

Why It Was Removed:

  • Frequent connectivity issues
  • Difficult to troubleshoot
  • Required constant maintenance
  • Prevented reliable infrastructure operations

Phase 1 Goals

Primary Objective: Implement "good enough" DDoS protection that:

  • Protects against common attacks (Layer 3/4)
  • Doesn't break during normal operations
  • Easy to maintain and troubleshoot
  • Minimal complexity vs Phase 0

NOT trying to:

  • Defend against state-level actors
  • Create perfect invisibility
  • Over-engineer like Phase 0

Proposed Architecture (To Be Designed)

Option A: Cloudflare Spectrum (Simplest)

  • Pros: Managed service, no infrastructure complexity
  • Cons: Monthly cost, less control
  • Best for: Quick deployment, low maintenance

Option B: Simplified GRE + Cloudflare

  • Pros: More control, proven technology
  • Cons: Requires careful implementation
  • Best for: Custom requirements, cost control

Option C: Hybrid Approach

  • VPS services behind Cloudflare
  • Game servers with lightweight protection
  • Best for: Tiered protection based on risk

Decision Point: Design session after Phase 0.5 completion

Implementation Timeline

Pre-Launch Requirements:

  1. Assess actual threat level (public launch = attack surface)
  2. Design session: Choose architecture
  3. Document decision rationale
  4. Test implementation on non-critical service
  5. Deploy to production

Estimated Effort: 4-8 hours (depends on approach chosen)

Target Date: Before soft launch (late February 2026)

Success Metrics

  • Withstands common DDoS attacks (volumetric, SYN floods)
  • 99.9%+ uptime during normal operations
  • < 1 hour maintenance per month
  • Zero "midnight emergency" pages

Fallback Plan

If Phase 1 protection proves inadequate:

  • Cloudflare Spectrum as immediate mitigation
  • Re-evaluate threat model
  • Consider managed DDoS services
  • Iterate rather than over-engineer

📅 IMPLEMENTATION TIMELINE

February 2026 (Month 1) - FOUNDATION

Week 1 (Feb 8-14):

  • Phase 0.5 Services 1-3 deployed (Gitea, Uptime Kuma, MkDocs)
  • Automation system operational
  • Services 4-5 deploying (Wiki.js, NextCloud)
  • Complete three-tier documentation architecture

Week 2 (Feb 15-21):

  • Deploy Netdata (analytics.firefrostgaming.com)
  • Deploy Vaultwarden (vault.firefrostgaming.com)
  • Complete Phase 0.5 (100% - 5/5 services)
  • Begin Phase 1: Simplified DDoS protection

Week 3-4 (Feb 22 - Mar 7):

  • Paymenter billing integration
  • Subscriber portal testing
  • Staff documentation creation
  • Soft launch preparation

March 2026 (Month 2) - SOFT LAUNCH

Weeks 1-2:

  • Soft launch to existing community (3 members)
  • Test subscriber workflow end-to-end
  • Validate world download process
  • Gather feedback, iterate

Weeks 3-4:

  • Public announcement preparation
  • Content creation (public docs)
  • Social media setup (Meg's domain)
  • Discord structure finalization

April-June 2026 (Months 3-5) - PUBLIC LAUNCH

April:

  • Public launch
  • Social media campaigns
  • Recruit first 20 subscribers
  • Monitor Phase 1 auth (manual)

May:

  • Evaluate Phase 2 auth automation trigger
  • Staff recruitment (builders, social media)
  • Begin LuckPerms implementation

June:

  • Reach 50 subscribers (target)
  • Deploy Phase 2 auth if needed
  • Website v1.0 launch

July-December 2026 (Months 6-12) - GROWTH & REFINEMENT

Ongoing:

  • Scale infrastructure as needed
  • Add new modpacks based on votes
  • Iterate on subscriber experience
  • Meg's social media campaigns
  • Community events (Fire vs Frost competitions)

🛠️ TECHNICAL DEBT & IMPROVEMENTS

Immediate Priorities (Next 7 Days)

  1. Complete Phase 0.5 (Services 4-5)
  2. Test subscriber workflow end-to-end
  3. Document staff SOPs in staff Wiki
  4. Webhook setup for MkDocs auto-rebuild

Short-Term (Next 30 Days)

  1. Netdata deployment (analytics)
  2. Vaultwarden deployment (password manager)
  3. LuckPerms MySQL backend (centralized permissions)
  4. World backup automation (monthly snapshots)

Medium-Term (Next 90 Days)

  1. Phase 2 Authentication (webhook automation)
  2. Website v1.0 (firefrostgaming.com)
  3. Staff recruitment (2-3 builders, 1 social media)
  4. Pterodactyl extensions (Discord integration)

Long-Term (6-12 Months)

  1. Phase 3 Authentication (SSO) if needed
  2. Custom modpack development
  3. API for external integrations
  4. Mobile app (subscriber portal)

📊 SUCCESS METRICS

Technical Metrics

  • Uptime: >99.5% (tracked via Uptime Kuma)
  • Response Time: <100ms (Nginx)
  • TPS (Game Servers): Stable 20.0
  • Automation Success Rate: >95%

Business Metrics

  • Month 1: 3 subscribers (soft launch)
  • Month 3: 20 subscribers (public launch)
  • Month 6: 50 subscribers
  • Month 12: 100+ subscribers

Revenue Targets:

  • Month 1: $15/month (validation)
  • Month 3: $100/month (break-even operations)
  • Month 6: $250/month (sustainable)
  • Month 12: $500+/month (growth mode)

Community Metrics

  • Discord Activity: Daily active users
  • Fire vs Frost Balance: 45-55% split (competitive balance)
  • Subscriber Retention: >80% monthly
  • Support Response Time: <24 hours

🚨 CRITICAL CONSTRAINTS

Medical Accessibility

Michael's Limitations:

  • Type 1 Diabetes - Jack alerts take absolute priority
  • Hand limitations from surgery - all code in small blocks (8-10 lines max)
  • Work sessions must allow for health breaks
  • Automation system critical for reducing repetitive tasks

System Designed Around:

  • One-paste deployments
  • Self-healing services (systemd)
  • Comprehensive documentation for handoffs
  • Minimal midnight emergencies

Relationship with Breezehost

"Forever Home" Provider:

  • Long-term partnership, not transactional
  • Jon Beard (Network Specialist) - primary contact
  • Trust-based relationship (6+ months)
  • Infrastructure decisions made together

Critical: Maintain this relationship, communicate proactively


📖 CURRENT DOCUMENTATION

Operational Documents (Keep In Root)

  1. FIREFROST-PROJECT-SCOPE-V2.md (THIS DOCUMENT)
  2. session-handoff.md - Current status for Claude sessions
  3. workflow-guide.md - Michael + Claude collaboration process
  4. design-bible-v1.1.md - Visual identity guide
  5. path-philosophy.md - Fire vs Frost explained
  6. subscription-tiers-final.md - Detailed tier breakdown
  7. awakened-gateway.md - $1 handshake philosophy
  8. provider-communications.md - Breezehost relationship archive
  9. visual-assets-guide.md - Asset inventory & usage
  10. server-deletion-policy.md - World backup policy

Deployment Documentation

  1. gitea-deployment.md - Service 1/5 deployment guide
  2. uptime-kuma-deployment.md - Service 2/5 deployment guide
  3. automation/USAGE.md - Automation system guide

Archived (docs/archive/2026-02-09-consolidation/)

  • Historical session summaries (Feb 8-9)
  • Superseded planning documents
  • Old implementation plans
  • Planning docs not yet executed

🎯 THE PATH FORWARD

This Week (Feb 9-15, 2026)

Monday (TODAY):

  • Consolidate documentation (this document)
  • Complete Services 4-5 (Wiki.js, NextCloud)
  • Test subscriber workflow
  • Create staff documentation structure

Tuesday-Wednesday:

  • Deploy Netdata (Service 6 - analytics)
  • Deploy Vaultwarden (Service 7 - passwords)
  • Complete Phase 0.5 (100%)

Thursday-Friday:

  • Staff SOPs written in staff Wiki
  • World backup automation script
  • Subscriber onboarding checklist

Weekend:

  • Test complete subscriber experience
  • Document any issues
  • Prepare for soft launch

Next Week (Feb 16-22, 2026)

  • Soft launch to existing community
  • Iterate based on feedback
  • Begin Phase 1 (Simplified DDoS)
  • Social media setup (Meg)

🔥❄️ FINAL NOTES

This document is the single source of truth.

When in doubt about priorities, architecture decisions, or project scope, refer to this document. All other documents are either:

  • Historical (archived)
  • Operational guides (specific technical details)
  • Future planning (not yet prioritized)

Update Schedule:

  • Minor updates: As needed (via Git)
  • Major review: Monthly (1st of each month)
  • Version bump: When major pivots occur

Document Owner: Michael "Frostystyle" Krause

Last Major Update: February 9, 2026 - Post-automation deployment, pre-subscriber portal launch


Fire + Frost = Where Passion Meets Precision 🔥❄️

Built for marathon sessions. Designed for accessibility. Optimized for growth.