Meza is MediaWiki EZ Administration

For the past couple years, we've been the primary maintainer and have successfully pushed our contributions upstream to NASA.

Meza - the Multi-Tenant SaaS Platform for wiki edit

Meza is a multi-tenant SaaS platform for MediaWiki in several key ways:

Multi-Tenancy Architecture edit

1. Multiple Wiki Instances Per Environment edit

Meza allows you to run multiple independent wikis ($wikiId) within a single MediaWiki installation:

# Create multiple wikis in the same environment
meza create wiki wiki1
meza create wiki wiki2
meza create wiki clientA

Each wiki gets:

Separate database (e.g., wiki_wiki1, wiki_wiki2)
Isolated configuration via LocalSettings.php per wiki
Shared codebase (MediaWiki core + extensions)
Shared infrastructure (web servers, Elasticsearch, etc.)

2. Environment Isolation edit

Meza supports multiple environments (dev, staging, production) with complete separation:

/opt/conf-meza/
├── secret/
│   ├── prod/           # Production environment secrets
│   ├── staging/        # Staging environment secrets
│   └── dev/            # Development environment secrets
└── public/
    ├── prod/           # Production public config
    ├── staging/        # Staging public config
    └── dev/            # Development public config

Each environment can host multiple wikis with different:

Inventory files (different servers)
Secrets (passwords, API keys)
Configuration overrides

3. Configuration Hierarchy (Tenant Customization) edit

The configuration system allows per-wiki customization while sharing common defaults:

# From LocalSettings.php generation
1. Core defaults: config/defaults.yml
2. OS-specific: config/RedHat.yml or config/Debian.yml  
3. Public environment: /opt/conf-meza/public/<env>/public.yml
4. Secret environment: /opt/conf-meza/secret/<env>/secret.yml
5. Per-wiki overrides: /opt/conf-meza/secret/<env>/<wikiId>/override.php

This means each wiki tenant can have:

Custom logo, colors, skin
Different enabled extensions
Unique user permissions
Custom namespaces
Separate access controls (Lockdown extension)

4. Shared Infrastructure with Isolated Data edit

Shared:

Web servers (Apache/Nginx)
PHP-FPM pools
Elasticsearch cluster (with per-wiki indices)
MediaWiki codebase and extensions
File storage (GlusterFS for multi-server)

Isolated per wiki:

MySQL/MariaDB databases
User accounts and permissions
Content pages
File uploads (/opt/data-meza/<env>/wikis/<wikiId>/)
Search indices (CirrusSearch creates wiki_<wikiId>_* indices)

5. API and REST Access Per Tenant edit

Each wiki gets its own API endpoint:

https://yourdomain.com/wiki1/api.php
https://yourdomain.com/wiki2/api.php
https://yourdomain.com/clientA/api.php

And REST API:

https://yourdomain.com/wiki1/rest.php/v1/
https://yourdomain.com/wiki2/rest.php/v1/

6. Resource Management edit

Meza provides deployment locks to prevent resource conflicts:

# Deploy locks prevent concurrent deployments
/opt/data-meza/env-{env}-deploy.lock

# Check if environment is deploying
meza deploy-check <env>  # 0=available, 1=deploying

7. Scalability Features edit

Horizontal scaling:

Multi-server support via inventory files
Load balancing with HAProxy
Distributed file storage with GlusterFS
Elasticsearch cluster for search

Vertical scaling:

Configurable PHP memory limits per wiki
Database connection pooling
ResourceLoader caching

SaaS Characteristics edit

Characteristic	Status
Multi-Tenancy	✅ Multiple wikis (tenants) on shared infrastructure
Isolation	✅ Separate databases, configs, and data per tenant
Self-Service	✅ `meza create wiki` command for instant provisioning
Centralized Management	✅ Single CLI (`meza`) manages all wikis
Shared Updates	✅ Deploy once, all wikis get updates
Elastic Resources	✅ Add/remove wikis without affecting others
Access Control	✅ Per-wiki authentication and authorization

Example: Hosting Multiple Clients edit

# Client A gets their own wiki
meza create wiki clientA

# Configure Client A's custom branding in:
# /opt/conf-meza/secret/prod/clientA/override.php

# Client B gets their own wiki  
meza create wiki clientB

# Both share the same MediaWiki installation, extensions, and servers
# But have completely isolated data, users, and customization

What Makes It Different from Traditional Hosting? edit

Approach	Description
Traditional	Each wiki = separate VM + separate MediaWiki installation + separate maintenance
Meza SaaS	Multiple wikis = shared infrastructure + centralized updates + isolated data

This is true multi-tenancy - the defining characteristic of SaaS platforms like Salesforce, GitHub, or Slack, where many customers share the same application infrastructure but have isolated data and customization.

Benefits edit

Cost Efficiency: Shared infrastructure reduces server costs
Easy Management: Single deployment updates all wikis
Rapid Provisioning: New wikis created in seconds
Scalability: Add capacity without disrupting existing wikis
Consistency: All wikis run the same tested MediaWiki version
Flexibility: Per-wiki customization without affecting others

Use Cases edit

Department Wikis: Each department gets their own wiki with custom permissions
Client Portals: Separate wiki for each client with isolated data
Project Spaces: Individual wikis for different projects or teams
Multi-tenant Hosting: Offer MediaWiki hosting to multiple organizations
Development Environments: Separate dev/staging/prod wikis for testing

Meza

Contents