Mediawiki Hosting Guide
Choosing the wrong hosting environment for MediaWiki is one of the most common reasons a wiki installation performs poorly, becomes difficult to maintain, or ends up insecure within a year of launch. The software itself is capable and well-documented, but it has specific technical requirements - around PHP versions, shell access, and caching - that not every hosting environment actually meets in practice.
This guide covers what MediaWiki genuinely needs from a server, how different hosting types compare against those requirements, how to size infrastructure for different traffic levels, and what to watch for before committing to a provider.
For background on installing MediaWiki once the right hosting environment is in place, see "How to Install MediaWiki on Ubuntu Server".
What MediaWiki Needs From a Hosting Environment
Before evaluating specific hosting types or providers, it helps to be clear about what MediaWiki actually requires. These requirements come directly from MediaWiki's official installation documentation.[1]
| Component | Minimum | Recommended for Production |
|---|---|---|
| PHP | 8.2.0 | 8.3.x (latest stable) |
| Database | MariaDB 10.3.0+, MySQL 5.7.0+, PostgreSQL 10.0+, or SQLite 3.24.0+ | MariaDB 10.6+ or MySQL 8.0+ (Wikimedia Foundation uses MariaDB) |
| RAM | 256 MB (single-computer site, no uploads) | 1–2 GB minimum for any real production wiki; 4 GB+ for high-traffic or large content wikis |
| Storage | 85 MB for MediaWiki software itself | Additional storage proportional to uploaded file volume; SSD-backed storage recommended |
| Web server | Any web server that can invoke a compatible PHP version | Apache 2.4+ with mod_rewrite, or Nginx with PHP-FPM |
| Shell access (SSH) | Not strictly required to install | Strongly recommended; required for maintenance scripts, upgrades, and database operations |
| Image processing | ImageMagick or GD library | ImageMagick preferred; required for image thumbnailing |
| Object caching | None required (but performance suffers without it) | APCu for single-server setups; Memcached or Redis for multi-server or high-traffic deployments |
A few of these deserve more explanation, since they're frequently misunderstood or overlooked.
RAM: The officially documented minimum of 256 MB is specifically noted by MediaWiki's own documentation as insufficient for a busy public site or any site with file uploads enabled. A realistic baseline for a production wiki - even a small internal one - is 1 GB, with 2 GB or more recommended for anything with active editing and real readership. A database server and web server sharing the same machine compete for RAM on busy installations, which is an important consideration when choosing a single-server plan.
Shell access: MediaWiki's official FAQ states directly that without shell access, taking a proper backup is more difficult, upgrading to a new version is harder, and some maintenance tasks are simply not possible. Shell access is not optional for a responsibly maintained wiki - it is a practical requirement. This matters significantly when evaluating shared hosting plans.
Caching: MediaWiki's official performance tuning documentation recommends bytecode caching for PHP (OPcache), APCu as a local object cache on single-server setups, and Memcached for the main cache - noting that this is the configuration the Wikimedia Foundation itself uses for Wikipedia and its sister projects. Without caching, every page request requires MediaWiki to re-parse wikitext and re-query the database, which is expensive at even moderate traffic levels.[2]
Types of Hosting and How Each Compares
| Hosting Type | PHP Version Control | Shell Access | Caching Availability | Suitable For | Notable Limitation |
|---|---|---|---|---|---|
| Shared hosting | Limited; often provider-controlled | Restricted; may not match server PHP version | Typically unavailable or limited | Personal or test wikis only | No root access; Memcached/Redis usually unavailable; PHP version control limited |
| Virtual Private Server (VPS) | Full control | Full SSH root access | Full control; install anything | Most production MediaWiki deployments | Requires self-management or managed add-on; single-server resource contention on small plans |
| Dedicated server | Full control | Full SSH root access | Full control; dedicated resources | High-traffic public wikis; large enterprises | Higher cost; requires system administration expertise |
| Cloud (AWS, GCP, Azure, DigitalOcean, etc.) | Full control | Full SSH access | Full control; managed cache services available | Scalable or variable-traffic wikis | More complex to configure and cost-estimate than a straightforward VPS |
| Managed MediaWiki hosting | Provider-managed | Varies by provider | Provider-managed | Teams without in-house server administration | Less flexibility; vendor dependency; verify what version and extension support is actually included |
Shared Hosting
Shared hosting - plans where many websites share the same physical server, managed through a control panel like cPanel - is the most common starting point for people who've never managed a server before, and it's genuinely the most problematic option for MediaWiki specifically.
The core issues are straightforward. PHP version upgrades on shared plans are typically controlled by the provider rather than the account holder, which means a host that hasn't updated to PHP 8.2 leaves a MediaWiki installation unable to upgrade to current releases. Shell access on shared plans is frequently limited or restricted from running server-side PHP at the correct version. Most shared plans provide no access to Memcached or Redis, which are important for performance beyond trivial traffic levels.
MediaWiki's own FAQ notes this directly: without proper shell access, some maintenance tasks cannot be performed at all, and upgrading the wiki becomes significantly harder. For a personal wiki with a handful of pages and no real traffic, shared hosting may work. For any wiki expected to grow, serve real users, or stay maintained and secure over the medium term, shared hosting creates friction at every step.
VPS Hosting
A Virtual Private Server gives a dedicated allocation of CPU, RAM, and storage on a physical server, with full root access to a Linux environment. This is the standard and most practical choice for most MediaWiki deployments.
With a VPS, the administrator has complete control over the PHP version, database configuration, caching setup, and every other aspect of the software stack. Maintenance scripts can be run from the command line. Backups can be scripted and automated properly. Security updates can be applied promptly and without waiting for a hosting provider to act.
VPS plans from established providers such as DigitalOcean, Linode (Akamai Cloud), Hetzner, Vultr, and major cloud platforms are widely used for MediaWiki installations. The appropriate plan size depends on the specific wiki, discussed below in the sizing section.
Dedicated Servers
A dedicated server provides the same full-control environment as a VPS, but on hardware that isn't shared with any other customer. This matters for high-traffic, read-heavy wikis where consistent, predictable performance under load is important, and where there's enough content and traffic to justify the cost difference over a VPS.
For most internal corporate wikis, departmental knowledge bases, and moderate-scale public wikis, a well-sized VPS provides sufficient performance at lower cost. Dedicated hardware becomes relevant when traffic regularly saturates VPS resources or when regulatory requirements restrict data from being hosted on shared infrastructure.
Cloud Hosting
Cloud platforms - AWS EC2, Google Cloud Compute Engine, Microsoft Azure, DigitalOcean Droplets, and similar - are functionally equivalent to VPS hosting for a MediaWiki deployment in most respects: full Linux control, SSH access, and the ability to install and configure any software. The additional capabilities cloud platforms offer (auto-scaling, managed databases, managed cache services, CDN integration) can be valuable for larger or variable-traffic wikis but add configuration and cost complexity that smaller deployments rarely justify.
For organizations already standardized on a cloud platform for other infrastructure, deploying MediaWiki there is a reasonable choice. For organizations choosing a hosting environment from scratch primarily for a wiki, a straightforward VPS is generally simpler to configure and operate.
Sizing a VPS for Your Wiki
| Wiki Scale | RAM | CPU | Storage | Notes |
|---|---|---|---|---|
| Small internal wiki (under 500 pages, few editors, low traffic) | 1–2 GB | 1–2 vCPU | 20–40 GB SSD | Adequate for a departmental knowledge base; APCu provides sufficient caching |
| Medium wiki (500–5,000 pages, regular editors, moderate public traffic) | 2–4 GB | 2 vCPU | 40–80 GB SSD | Memcached or Redis recommended; CirrusSearch/Elasticsearch may require a separate instance |
| Large wiki (5,000+ pages, many concurrent editors or high readership) | 4–8 GB | 4 vCPU | 80 GB+ SSD | Consider separating database onto its own server; Varnish or Nginx reverse proxy recommended in front of MediaWiki |
| High-traffic public wiki (Wikipedia-scale) | Multiple servers, load balancing | Distributed | Distributed | Well beyond single-server territory; Wikimedia Foundation's own architecture uses dozens of application servers |
These are practical guidelines, not authoritative specifications - real-world performance depends on how many extensions are installed, how heavy those extensions are, how write-intensive editing is, and whether caching is properly configured. A MediaWiki installation with many complex extensions will consume more resources than one running only core. CirrusSearch with Elasticsearch in particular is resource-intensive and is best run on a separate instance rather than on the same VPS as the wiki application.
Caching: The Most Important Performance Variable
Caching deserves specific attention in a hosting guide because it's the single biggest performance lever available on a MediaWiki installation - and it's something that a hosting environment either supports or doesn't, depending on configuration.
MediaWiki uses several distinct caching layers:
PHP OPcache (bytecode caching). OPcache stores compiled PHP bytecode in memory, eliminating the need to re-parse and re-compile PHP files on every request. This is enabled by default in PHP 8.x and should be confirmed active on any production server.
APCu (local object cache). APCu stores PHP objects in shared memory on a single server. It is MediaWiki's recommended local cache backend for single-server setups. The php-apcu package must be installed separately from PHP itself, but it is available in standard repositories on Ubuntu and other common Linux distributions.
Memcached (distributed main cache). For multi-server setups or high-traffic installations, Memcached provides a shared cache that all application servers can access. The Wikimedia Foundation uses Memcached as the main cache backend for Wikipedia. On a single-server setup, Memcached is useful but APCu is simpler.
Redis (alternative to Memcached). Redis provides similar functionality to Memcached but supports larger objects (up to 512 MB versus Memcached's 250-byte key limit), persistent storage, and additional data structures. Redis is a viable and in some cases preferable alternative to Memcached, particularly on wikis using Semantic MediaWiki, which can benefit from Redis's larger object capacity.
Parser cache. MediaWiki caches parsed wikitext output so that an article doesn't need to be re-rendered from wikitext markup on every page view. This is stored in the database by default and in the configured cache backend if one is set up.
Reverse proxy / CDN (HTTP caching). A reverse proxy such as Varnish or an Nginx FastCGI cache can serve complete HTML pages to unauthenticated readers without invoking PHP at all. This is the highest-impact caching layer for public wikis with significant readership, but it adds infrastructure complexity.
For most production MediaWiki installations, the practical starting point is to confirm OPcache is active, install and configure APCu, and consider Memcached if the wiki has more than moderate traffic or if CirrusSearch is in use.
Step-by-Step Guide: Evaluating a Hosting Provider for MediaWiki
- Confirm the PHP version available and how it's managed. Ask or check the provider's documentation: what is the current PHP version, and can the account owner control when it's updated? The provider must be able to run PHP 8.2.0 or later, and the upgrade path to future PHP versions should be clear and account-holder-controlled.
- Confirm full SSH access with the correct PHP version on the shell. This is a specific requirement: some shared hosts provide SSH access but the PHP version available on the command line differs from the version serving web requests. Maintenance scripts must be run with the same PHP version the wiki uses. Test this by logging in via SSH and running:
php -v
The version reported should match what the web server is running.
- Confirm root or sudo access. On a VPS or dedicated server, verify that root or sudo access is available, so software packages (PHP extensions, Memcached, MariaDB, ImageMagick) can be installed and configured as needed.
- Confirm MariaDB or MySQL availability and version. The database must be MariaDB 10.3.0+ or MySQL 5.7.0+. Confirm the version available and whether the account has permission to create databases and database users, or whether a database must be pre-provisioned by the provider.
- Check whether Memcached or Redis is available or installable. On a shared host, this is often unavailable. On a VPS, these can be installed from standard package repositories.
- Check storage type. SSD-backed storage is strongly preferable over spinning disk for a database-backed application like MediaWiki. Most modern VPS providers use SSD storage by default.
- Assess backup capability. The hosting environment should permit automated database backups (
mysqldumpor equivalent) and file-level backups of the wiki directory, ideally to an off-site location. Some shared hosts restrict outbound tools likersyncor access to off-server storage. - Check data center location relative to your users. Hosting in a region geographically closer to the majority of the wiki's editors and readers reduces latency and improves perceived performance.
Best Practices
Choose a VPS over shared hosting for any wiki that is expected to serve real users, grow over time, or stay properly maintained - the operational limitations of shared hosting accumulate and create real problems. Select a Linux distribution with a long-term support release cycle (Ubuntu LTS is a common choice) rather than a cutting-edge or short-lifecycle distribution, since stability and predictable package availability matter more for a long-lived wiki than having the newest kernel. Configure OPcache and APCu on initial setup rather than retrofitting them after performance problems arise. Leave enough headroom in the VPS plan to accommodate database growth and extension requirements without immediately saturating memory - it's much easier to monitor usage and upgrade a plan than to recover from a crash caused by an overloaded server. Keep the software stack lean: install only the PHP extensions MediaWiki actually needs, and avoid running unrelated applications (a WordPress site, a forum, a mail server) on the same server as a production wiki, since resource contention will eventually cause problems.
Common Mistakes
Starting on shared hosting with the intention of migrating later is a common and avoidable decision - migrations take real effort, and the problems with shared hosting appear gradually rather than immediately, so they tend to get deferred until they become urgent. Choosing a VPS plan based on price alone and then discovering the RAM is insufficient for the database and PHP to coexist comfortably is another recurring issue, and the fix (upgrading to a larger plan) is simple but disruptive if it wasn't planned from the start. Enabling file uploads on a wiki without accounting for storage growth is common on wikis that start as text-only reference content and gradually accumulate large numbers of images or PDFs. Failing to configure OPcache and APCu on initial setup, then concluding that MediaWiki is "slow" without investigating the caching situation, is a very common performance complaint with a straightforward resolution. And conflating "the wiki is installed and responding" with "the wiki is production-ready" often means skipping the backup configuration step, which matters enormously if a server failure or accidental content loss occurs before any backup has ever been taken.
Comparison of Hosting Types
| Factor | Shared Hosting | VPS | Dedicated Server | Cloud (IaaS) |
|---|---|---|---|---|
| PHP version control | Limited (provider-controlled) | Full | Full | Full |
| SSH/shell access | Restricted or limited | Full root access | Full root access | Full root access |
| Memcached / Redis availability | Typically unavailable | Installable | Installable | Installable or managed service |
| RAM scalability | Fixed by plan; not upgradeable on demand | Resize plan or add RAM | Add physical RAM | Scale on demand |
| Technical skill required | Low | Moderate | Moderate to high | Moderate to high |
| Relative cost for equivalent resources | Lowest | Low to moderate | Higher | Variable; can be higher at scale |
| Recommended for MediaWiki? | Personal or test only | Yes - most deployments | Large or high-traffic wikis | Yes, especially for existing cloud users |
Frequently Asked Questions
Can I run MediaWiki on shared hosting?
Technically yes, but it comes with significant practical limitations: restricted PHP version control, limited or restricted shell access, and typically no access to Memcached or Redis. MediaWiki's own documentation notes that without proper shell access, some maintenance tasks cannot be performed at all. For a test or personal wiki, shared hosting may work. For any wiki intended to grow or stay properly maintained, a VPS is the more reliable choice.
How much RAM do I actually need?
MediaWiki's official documentation states 256 MB as the minimum for a single-computer installation, but explicitly notes this is not sufficient for a busy public site or a site with file uploads enabled. A practical production baseline is 1–2 GB for a small to medium wiki, with 2–4 GB appropriate for a wiki with regular active editing and real readership.
Does MediaWiki work on Windows Server?
MediaWiki can run on Windows with IIS or Apache, but the overwhelming majority of production deployments use Linux. The official documentation is primarily written for Linux environments, and the community support base for Linux-based deployments is substantially larger. Unless there is a specific organizational requirement for Windows hosting, Ubuntu Server LTS or another mainstream Linux distribution is the practical choice.
Is cloud hosting (AWS, DigitalOcean, etc.) different from a VPS for MediaWiki?
Functionally, a cloud compute instance (EC2, Droplet, Compute Engine) is similar to a VPS: full Linux control, SSH access, and the ability to install any software. The primary differences are billing model (often hourly), additional managed services (databases, caching, CDN) available on the same platform, and the scaling options available. For a simple, single-server MediaWiki deployment, a cloud compute instance and a traditional VPS are practically equivalent.
Does MediaWiki require a dedicated database server?
No - for most deployments, the database runs on the same server as the web application. A separate database server becomes beneficial for high-traffic wikis where the database and PHP are competing for the same RAM and CPU, or for deployments requiring high availability with database replication. For most organizations, a single, properly sized VPS running both components is appropriate.
What Linux distribution is best for a MediaWiki server?
Ubuntu Server LTS (Long Term Support) is the most commonly used distribution for MediaWiki deployments and the one used in SolidWiki's installation guide. Debian Stable is another well-suited option with similar package availability and a long support cycle. Either provides a stable, well-supported environment with straightforward package management. Distributions with shorter support lifecycles or less predictable package repositories are generally less suitable for long-lived production wikis.
Do I need a CDN?
For most small to medium wikis - internal knowledge bases, departmental documentation, moderately sized public wikis - a CDN is not required. A well-configured single VPS with proper caching handles this scale comfortably. CDN integration becomes relevant for high-traffic public wikis where serving static assets (images, CSS, JavaScript) from edge nodes closer to the user meaningfully reduces load times and offloads bandwidth from the origin server.
Conclusion
The right hosting environment for MediaWiki is the one that matches the wiki's actual scale, gives the administrator the control needed to maintain it responsibly, and doesn't create technical friction every time an update, backup, or configuration change is needed. For most organizations, a Linux VPS with 2–4 GB of RAM, full SSH access, SSD storage, and the ability to install Memcached or Redis covers that description well. Shared hosting is workable in limited circumstances but creates real operational problems for any wiki expected to grow or stay properly maintained over the long term.
The hosting decision is worth getting right at the start, since migrating a running wiki to a new server is entirely possible but takes real effort and shouldn't be done under pressure after a performance or availability problem has already become urgent.
If your organization needs help selecting the right infrastructure, configuring the server environment, or taking over maintenance of an existing wiki, that's the specific work described on SolidWiki's MediaWiki Development Services page.
See Also
- How to Install MediaWiki on Ubuntu Server
- MediaWiki Security Hardening Guide
- MediaWiki Performance Optimisation
- MediaWiki SEO Best Practices
- What Is MediaWiki?
References
- ↑ MediaWiki.org, "Manual: Installation requirements", https://www.mediawiki.org/wiki/Manual:Installation_requirements
- ↑ MediaWiki.org, "Manual: Performance tuning", https://www.mediawiki.org/wiki/Manual:Performance_tuning