Multi-Site Options and Scaling

The simplest layout gives each site its own database and database user on one server. Each configuration.php has its own $db, $user and $password, so a leaked credential exposes one site only. The Tallpine club runs three sites this way.

Source: Joomla User Guide: Backup

The installer asks for a table prefix, and several installations can share one database when their prefixes differ. The prefix must start with a letter and contain only letters, digits and underscores, it may be at most 15 characters, and on PostgreSQL it must be lower case. This suits hosting plans that grant a single database, but it couples the sites: a dump or restore of the database affects all of them, and one database user can read every site’s tables. Prefer one database per site whenever the host allows it. A prefix is not a way to share users: the user, ACL and session tables of each prefix are independent tables, and Joomla offers no supported way to point two installations at one #__users table.

Source: Joomla source: SetConfigurationCommand (prefix validation)

The User Guide describes the opposite approach in "Multiple Domains and Web Sites in a single Joomla! installation": add the domains as add-on domains in the hosting panel, build separate articles, menus and modules per site, give each site its own template through the template styles, and send each domain to its own start page with a rewrite or a small PHP redirect. The guide itself calls separate installations the best practice and presents this as an exception for special cases, and the page states that it was last updated in 2012. Its limits matter:

It is acceptable for two near-identical brand sites run by the same team, and a poor fit for sites with different owners, different security levels or different update windows.

Source: Joomla User Guide: Multiple Domains and Web Sites in a single Joomla! installation

Because every site is its own installation, the work is repetition, and repetition is scripted. The console already covers the repeated tasks (core:update:check, update:extensions:check, config:get, config:set, cache:clean, database:export; see Command Line Interface). A loop over the site roots gives a fleet-wide check:

Source: Joomla User Guide: Using the CLI

Keep the three installations on the same release line (see Versions, Release Cycle and Support), and use the same PHP image for all of them so that one set of server settings and one OPcache configuration apply.

The Web Services API includes a users endpoint. A script, or the membership system the club already has, can create and update the same member on each site with an API token of a Super User or of a user allowed to manage users. This is a copy, not a share: each site keeps its own password hash, so a password change does not propagate unless the same script handles it. It needs no extension and no change to the login flow.

The group id 2 is the stock Registered group; the Trail Warden group of the club has a different id on every site, so read the ids from GET /api/index.php/v1/users/groups rather than hard-coding them. The API itself, tokens and the default plugin states are covered in Web Services API.

Source: Joomla source: com_users API controllers

Joomla’s authentication plugins decide who may log in. The core ships Joomla, Cookie and LDAP authentication plugins, and the LDAP plugin lets several installations check credentials against one directory server (a user record is created in each installation at first login). Single sign-on through OpenID Connect, SAML or an OAuth provider is available only through third-party extensions listed in the Joomla Extensions Directory, which Joomla 6.2 does not include; evaluate them like any extension (maintenance, update-server security flag, supported Joomla version) and see Security Hardening, MFA and Passkeys for how they interact with multi-factor authentication. In every case the groups and access levels are still local: map the directory group to a Joomla group on each site (see Users, Groups, Access Levels and ACL).

Setting a $cookie_domain of .tallpine.example does not make a login valid on the sibling sites. The cookie name is derived from each site’s $secret, and the session lives in each site’s own store, so a cookie from one installation is simply an unknown session for another. "Shared Sessions" in Global Configuration, a toggle in the Session fieldset, is unrelated: it shares one session between the front end and the administrator of the same installation. It is also unavailable when Force HTTPS is set to "Administrator Only", and changing it invalidates all existing sessions.

Source: Joomla source: session service provider

Every node must run the same configuration.php. The value that bites first is $secret, because Joomla derives names from it:

The installer generates the secret on the first node; copy that file to the others (or, better, build it into the image), and never regenerate it per node. Install every node at the same path, which a container image guarantees. Give every distinct site its own secret and, on a shared Redis, its own database number or instance.

Source: Joomla source: CacheStorage (cache id)

The Session Handler in the Session fieldset of the System tab chooses where session data lives. In Joomla 6.2 the list holds Database, Filesystem, Redis, Memcached (labelled "Experimental") and APC User Cache (APCu), and the handler is created from session_handler in configuration.php.

The session Lifetime (minutes) setting accepts 1 to 16383 and defaults to 15. Redis uses it as the key time to live, the database handler as the age after which garbage collection deletes the row. Two more switches influence cost: "Track Session Metadata" writes the username, user id and application into the session table (the session table then records who is logged in where), and "Track Guest Session Metadata" does so for guests as well; turn the guest tracking off on a busy public site because every anonymous visitor otherwise creates a metadata row.

Redis sessions are the usual choice once a second node exists, with one rule from the Redis side: the session store must not evict keys under memory pressure, because an evicted session is a visitor who is silently logged out. Evicting a cache entry costs one recomputation, while evicting a session costs a login. Run two Redis instances, or at least two databases with a policy you can defend, instead of one shared store.

Source: Joomla source: SessionFactory (handler creation)

The Redis session handler throws a RuntimeException ("Redis is not supported on this system") when the extension is missing, which presents as a blank page or a 500 error on every request, the administrator included. Always confirm the extension in System, System Information, PHP Information before switching the handler, and keep a way to edit configuration.php by hand. Redis itself (persistence, replication, passwords, eviction policies) is covered in Redis architecture, keyspace and eviction, Redis replication, Sentinel and Cluster and Redis security; the Joomla form has only a single password field, so a Redis ACL user name cannot be supplied from the screen.

Session garbage collection for the database and filesystem handlers is a scheduled task ("Session GC") or the console commands session:gc and session:metadata:gc (the first takes --application with site as the default); Redis and Memcached expire keys by themselves.

System caching has three settings: Off, "ON - Conservative caching" and "ON - Progressive caching". The Cache Handler offered by 6.2 is File, Redis, Memcached (experimental) or APC User Cache, with Cache Time in minutes and the "Platform Specific Caching" switch that gives mobile browsers their own cache entries. The older User Guide page "Cache" still lists APC, Eaccelerator, Memcache and XCache; those handlers no longer exist, and the 6.2 source offers the four above. Older books, such as the 2023 Joomla! 4 Masterclass, also date from before these changes and do not discuss multi-node operation at all.

For several nodes the File handler has a practical drawback: Clear Cache in the administrator only empties the cache of the node that served the click. Redis gives one cache that every node reads and clears.

Source: Joomla User Guide: Cache

The Redis cache handler writes each entry with an expiry (SETEX), so a policy such as allkeys-lru or volatile-lru suits the cache instance. Pages for logged-in users are not cached by the Page Cache plugin, so the cache absorbs anonymous traffic and the database still carries editors, members and searches. An edge cache or CDN in front (see Caching and Performance) removes most of that anonymous load before it reaches any node.

The Media Manager reads files through filesystem plugins. Joomla 6.2 ships one, "Filesystem - Local", whose directory list defaults to images and files; other adapters are not part of core. Uploaded files are therefore written to the disk of the node that handled the upload, and a second node returns a 404 for them. Two solutions exist:

Whichever is chosen, the same upload limits apply on every layer: the Media component’s Maximum Size (10 MB by default), PHP upload_max_filesize and post_max_size, and the load balancer’s body limit (client_max_body_size on nginx). The lowest of them decides, and the symptom is a vague upload error in the Media Manager. See Media Manager for the component settings.

Source: Joomla User Guide: Media File Locations

Behind a load balancer that terminates TLS, Joomla must still generate https:// links. The URI code recognises an HTTPS request from $_SERVER['HTTPS'] or from an X-Forwarded-Proto header whose value is not http, so the proxy must send that header (or set HTTPS), and Force HTTPS in Global Configuration should be set to the entire site. Only the protocol is read from the header; Joomla does not use X-Forwarded-For for the client address on its own, so extensions that log or rate-limit by IP see the proxy address unless the web server rewrites it (for example the Apache mod_remoteip module or the nginx real_ip module restricted to the proxy’s network). The Enable Outbound Proxy setting in the Proxy fieldset is unrelated: it routes the site’s own outgoing requests, for example update checks, through a proxy. The full proxy configuration is in Web Server, Reverse Proxy and HTTPS.

Source: Joomla source: Uri (HTTPS detection)

Joomla’s scheduler can be started by the Lazy Scheduler (a script injected into visitor requests, enabled by default with a 300-second interval), by a web-cron URL, or by the CLI. With several nodes, the lazy scheduler makes every node a candidate runner. Disable it in the Scheduled Tasks options, and run the CLI from one place, such as a cron job on one host or a Kubernetes CronJob:

Task locking, timeouts and exit codes are explained in Scheduled Tasks. Do not start a second runner for resilience without reading that page first: two runners racing on the same task is exactly what the single-runner design avoids.

Source: Joomla source: com_scheduler options

On several nodes, a change made through the administrator is made on the disk of one node. Installing an extension from the Extensions: Install screen, updating the core with the Joomla Update component, or an Automated Core Update triggered by the joomla.org service writes files on the node that served the request; the other nodes keep the old code, and the database, which is shared, now describes software they do not have.

Treat the code as an artifact: