ContentFlow CMS
An open-source, multi-tenant, API-first CMS I designed and built for website owners, agencies, and developers who need a self-hostable content platform with visual editing, REST APIs, integrations, backups, and production deployment tooling.
Overview
Purpose: Build a modular CMS that combines no-code content management with an API-first architecture and real multi-tenancy.
Target users: Website owners; agencies managing multiple client sites; developers consuming CMS content through APIs and webhooks.
- Multi-tenant site management
- Block-based page building
- REST API access
- Authentication and OAuth
- API key management
- Backups
- Integrations
- CI/CD
- Open-source release discipline
Tech Stack
Monorepo: root package.json orchestrates `Client/` (Next.js) and `Server/` (Express) via `concurrently`. Root also owns cross-cutting perf/quality scripts (k6, TTFB check, an explicit-`any` linter with a baseline file).
Frontend
- Next.js 16
- React 19
- TypeScript
- Tailwind CSS 4
- Radix UI
- Sonner
- React Hook Form
- Zod
- Framer Motion
- Recharts
- Embla Carousel
- cmdk
- vaul
Backend
- Express 4
- Mongoose 8
Database
- MongoDB
- 19 Mongoose models
Auth
- JWT access + refresh tokens
- express-session
- bcrypt/bcryptjs
- Google OAuth
- Facebook OAuth
- Passport
DevOps
- Redis
- PM2
- GitHub Actions
- Ubuntu VPS
Libraries
- Jest
- mongodb-memory-server
- Supertest
- fast-check
- Playwright
- k6
Features
Multi-Tenant Site Builder
A single deployment can manage multiple independent tenant sites: page builder, blog, forms, menus, footer management, media, SEO, themes, templates, users, integrations, backups, activity, notifications.
How: Tenant-scoped data and slug constraints preserve separation between sites.
Benefit: This turns ContentFlow into more than an admin interface; it can act as a content platform for other frontends.
External Content API
I built a dedicated external API for applications that consume CMS content.
How: API-key authentication, Redis-backed rate limiting, domain extraction, tenant-aware content access, published-content filtering.
Authentication, OAuth & CSRF Protection
Email/password authentication, Google OAuth, Facebook OAuth, access/refresh tokens, session cookies, explicit CSRF protection for cookie-authenticated write operations.
Automated Backups
Backup models, routes, and scheduler services support automated backup workflows and restore operations.
Operational Tooling
/metrics Prometheus-style endpoint, TTFB smoke checks, k6 load tests, CI validation, health-check-driven deployments, automatic rollback behavior.
Architecture
Folder structure: Monorepo with independent Client/ and Server/ applications plus shared quality, deployment, and documentation tooling.
App flow: Redis is used for API-key rate limiting.
Database Design
- Tenant & Publishing — Tenant, Page, Version, Blog, Menu, Footer, Form, Field, Theme, Seo, Media
- Platform & Integration — Client, ApiKey, Webhook, Integration
- Operations — ActivityLog, Notification, Feedback, Backup
Tenant and slug relationships are designed to support multiple independent sites from one installation.
API Documentation
The application exposes versioned REST routes under /api/v1/*, with route ownership documented in the repository's API route map. Primary API surfaces cover authentication, tenant content, pages, blog, menu, footer, forms, themes, media, backups, API keys, integrations, webhooks, and external content access.
Authentication Flow
login: Email/password or OAuth → Passport / JWT issuance → access + refresh session → role/tenant validation → protected operation.
middleware: CSRF protection applies to cookie-authenticated state-changing requests.
Screenshots
Challenges
Problem: Tenant Isolation — one platform serves multiple client websites without allowing cross-tenant content collisions.
Solution: I built tenant-scoped persistence and compound uniqueness rules such as { tenantId, slug }.
Problem: Public Content Safety — public APIs must expose published content without leaking drafts.
Solution: I centralized publication filtering across external content reads before the v1.0.0 release.
Problem: Production Readiness — a self-hostable CMS needs more than functional screens.
Solution: I added CI, automated deployment, health checks, rollback, load testing, performance smoke gates, operational metrics, documentation, release process, and security guidance.
Problem: OAuth & Security Integration — required several iterations because the system combines JWT, sessions, third-party identity providers, and multi-tenant application behavior.
Solution: The final architecture keeps these concerns explicit rather than hiding them behind UI-only access rules.
Performance
- TTFB smoke gate
- k6 load testing
- Redis-backed rate limiting
- Server-side content caching / revalidation
- Prometheus-style metrics endpoint
- Next.js server rendering
Security
- JWT access and refresh tokens
- bcrypt password hashing
- Google/Facebook OAuth
- CSRF middleware
- Redis-backed rate limiting
- SHA-256 API-key lookup
- CORS allowlist
- Published-content enforcement
- HSTS/security headers
- Dedicated SECURITY policy
- Private vulnerability reporting process
Deployment
hosting: Ubuntu VPS
cicd: PM2 process manager, GitHub Actions CI/CD. Deployment flow: CI builds and validates the project → release artifact packaged → uploaded over SSH → release directory created → current symlink switches atomically → PM2 reloads → health check runs → failed health check triggers automatic rollback.
Future Improvements
- Deeper observability dashboards
- More tenant-level authorization policies
- Expanded accessibility verification
- Additional deployment/database migration automation
- Broader cross-browser regression coverage
Lessons Learned
- Open-source infrastructure projects are judged by operational maturity as much as feature count.
- Tenant isolation needs to exist in the data model, not only in UI routing.
- Release, rollback, security, and contribution processes should be designed alongside the application.
- Public APIs require explicit publication and authorization boundaries.
- Written architecture and route maps significantly reduce maintenance cost in a monorepo.
Project Metrics
Timeline
- December 2025 — Project initialized
- February 2026 — Security and pre-launch hardening
- February 2026 — v1.0.0 release
- February 2026 — CI, deployment, OAuth, and production workflow refinement
Ask about this project
Depends on the /api/chat orchestrator and MCP tool server — not built yet (see plan.md).
Recruiter Summary
Role: Solo Full-Stack Developer / Open-Source Maintainer
- Built a multi-tenant CMS monorepo with Next.js and Express
- Designed a 19-model MongoDB content architecture
- Implemented JWT/session authentication with Google and Facebook OAuth
- Built an API-key-authenticated external content API
- Added Redis rate limiting
- Implemented automated backup functionality
- Built CI/CD with automatic rollback
- Added Jest, Playwright, property-based, and k6 testing
- Created open-source contribution, security, changelog, release, deployment, and QA documentation
- Released a publicly accessible v1.0.0 CMS
- Demonstrated multi-tenant application architecture and API design
- Built deployment and rollback infrastructure appropriate for a self-hosted platform
- Produced an open-source project that can be operated and extended by developers other than the original author