4.3 KiB
Wiki.js Deployment - Staff & Subscriber Wikis
Deployed: February 10, 2026, 9:30pm - 11:15pm CST
Server: Ghost VPS (64.50.188.14)
Services: Staff Wiki + Subscriber Wiki
Duration: ~1h 45min (including troubleshooting)
Services Deployed
1. Staff Wiki (staff.firefrostgaming.com)
Purpose: Staff-facing documentation, SOPs, content creation resources
Configuration:
- Domain: staff.firefrostgaming.com
- SSL: Let's Encrypt (active)
- Storage: Git backend
- Repository: git.firefrostgaming.com/firefrost-gaming/firefrost-staff-wiki
Structure:
firefrost-staff-wiki/
├── founders/ (Michael + Meg only)
├── social-media/ (Meg + Social Media Manager)
├── builders/ (Michael + Builders)
├── moderation/ (Future moderators)
├── shared/ (All staff)
├── community/ (Community resources)
└── branding/ (Brand assets)
Access Control: Role-based via Wiki.js permissions
2. Subscriber Wiki (subscribers.firefrostgaming.com)
Purpose: Premium subscriber content, guides, exclusive tutorials
Configuration:
- Domain: subscribers.firefrostgaming.com
- SSL: Let's Encrypt (active)
- Storage: NOT YET CONFIGURED (pending decision)
- Status: Deployed but awaiting content strategy
On Hold Until:
- Paymenter billing integration complete
- Welcome page finalized
- Subscriber tier content defined
Issues Encountered
SQLite3 Native Module Error
Problem:
Error: Cannot find module '/opt/wikijs/node_modules/sqlite3/lib/binding/napi-v6-linux-glibc-x64/node_sqlite3.node'
Timeline:
- Error began: ~20:00 CST
- Service crashed repeatedly (10-second restart loop)
- Lasted approximately 4+ minutes
- Resolved by: ~20:04 CST
Root Cause: Wiki.js attempting to use SQLite3 database, but native Node.js bindings were missing/broken.
Resolution: Exact fix not documented at time of deployment. Likely solutions:
- Switched to Git storage backend (for Staff Wiki - confirmed)
- Rebuilt sqlite3 module:
npm rebuild sqlite3 - OR switched to different database (PostgreSQL/MySQL)
Services recovered and operational by 20:07 CST.
Lessons Learned
LESSON #1: Avoid SQLite3 for Wiki.js
Problem: SQLite3 requires compiled native bindings that frequently break across Node.js versions and system architectures.
Recommendation for Future:
- Preferred: Git storage (simple, version-controlled, no database needed)
- Alternative: PostgreSQL or MySQL (if database required)
- Avoid: SQLite3 (native module dependency hell)
LESSON #2: Document Immediately
What We Lost: Due to late-night deployment and not documenting immediately:
- Exact troubleshooting steps taken
- Specific fix applied
- Time spent on each solution attempt
- Configuration decisions made under pressure
Protocol Moving Forward: After ANY deployment (successful or not), create immediate 5-minute note:
nano ~/deployment-note.txt
Capture: What deployed, what broke, how fixed, when finished.
Next session: Formalize into proper documentation.
This deployment taught us: Knowledge lost due to fatigue = lessons we'll repeat.
Current Status (Feb 11, 2026)
Staff Wiki:
- ✅ Operational
- ✅ SSL active
- ✅ Git backend configured
- ✅ Department structure created
- ✅ Consultant profiles added to social-media/
Subscriber Wiki:
- ✅ Deployed
- ✅ SSL active
- ⏸️ Storage backend TBD
- ⏸️ Awaiting Paymenter integration
- ⏸️ Content strategy in progress
Next Steps
Subscriber Wiki:
- Decide on storage backend (Git vs database)
- Configure chosen backend
- Create content structure
- Integrate with Paymenter for access control
- Populate with initial premium content
Staff Wiki:
- ✅ Structure complete
- Continue adding department-specific content
- Configure Wiki.js permissions per role
- Train Meg on Wiki.js editing
- Add remaining staff documentation
Technical Details
Wiki.js Version: (Not documented - check via Wiki.js admin)
Node.js Version: 20.20.0
Nginx Configuration: Reverse proxy on Ghost VPS
Firewall: Frostwall rules (ports 80/443 to Ghost IP)
Deployment Method: Automation script (specifics not preserved)
Fire + Frost = Documentation That Survives Midnight Deployments 🔥❄️📚