The Architecture

JekCMS runs 12 production sites from a single codebase. Not 12 installations — one codebase with shared core files and site-specific configurations. This approach means a security fix deployed once protects all 12 sites immediately. A new feature developed once is available everywhere.

The directory structure:

jekcms/
├── classes/           # Shared PHP classes (Auth, Database, Media, Post...)
├── includes/          # Shared helpers, bootstrap, security
├── config/            # Shared default config
├── sites/
│   ├── _template/     # Base template for new sites
│   ├── kriptogetiri/  # Site-specific overrides
│   │   ├── config/    # DB credentials, site URL, theme
│   │   ├── themes/    # Custom theme files
│   │   └── uploads/   # Site-specific uploads
│   ├── livecub/
│   ├── earthofpet/
│   └── ... (12 sites total)

Shared Core vs Site-Specific

The shared core includes: all PHP classes (Auth, Database, Media, Post, Session, Security, Cache), helper functions, the admin panel UI (header, sidebar, footer), API endpoints, and security middleware.

Site-specific includes: database credentials, SITE_URL, theme selection, custom CSS overrides, uploads directory, and optional feature toggles (like content queue or auto-linker).

The bootstrap loads the site-specific config first, then the shared core. If a site needs to override a shared behavior, it can define a constant or configuration value before the shared code loads.

Database Isolation

Each site has its own MySQL database. No shared tables, no multi-tenant queries. This means: one site's data breach does not expose other sites, database migrations can be tested on one site before rolling to all, and each site can have different schema versions during a gradual rollout.

Session Isolation

The critical security requirement: logging into Site A must not give access to Site B, even though they share the same PHP session storage directory. We solve this with unique session names per site and a site hash stored in the session data (verified on every request).

Deployment Workflow

When we release a new version (like v1.5.0), the deployment updates 5-6 files per site across all 12 sites. That is 60-80 file operations per release. We use a simple deployment script that: copies shared core files to each site's include path, runs database migrations per site, clears each site's cache, and verifies each site responds with 200 OK.

A typical deployment takes 15-20 minutes for all 12 sites. The script runs sequentially (not parallel) so we can catch errors before they affect all sites.

Version Management

Each site has a version.json that tracks the installed version. The admin panel checks against the update server to show available updates. Sites can be at different versions during a gradual rollout — we typically deploy to 2-3 sites, monitor for 24 hours, then deploy to the remaining sites.

Real Numbers

12 sites, 11 unique themes, combined 200,000+ monthly pageviews. Average deployment time: 18 minutes. Average time to deploy a security fix to all sites: 25 minutes (including testing). Zero cross-site data leaks in 14 months of operation. Total hosting cost for all 12 sites: $68/month on Hostinger VPS.