How to Configure TYPO3 for a Multisite Setup With Shared Codebase

Running several TYPO3 websites from one codebase can simplify maintenance, security updates and deployment. A shared installation is especially useful when brands, departments or regional sites use the same custom extensions and design system while retaining separate domains, content trees and editorial permissions.

The arrangement still needs a clear boundary between common application logic and site-specific configuration. For an organisation operating across Sydney, Melbourne and Brisbane, for example, a single TYPO3 project can serve each regional website while allowing different navigation, languages, campaigns and publishing workflows.

Plan the Shared TYPO3 Architecture

A practical multisite installation normally contains one Composer project, one TYPO3 core, one public document root and several site roots in the page tree. Each website receives its own root page and Site Configuration. TYPO3 uses the incoming host name and the site configuration’s base URL to select the correct site.

Keep the shared codebase responsible for reusable behaviour: content elements, Fluid templates, backend modules, middleware, integrations and common styling. Keep business-specific decisions in site configuration, TypoScript, Page TSconfig, environment variables or clearly separated data records. This prevents a change made for a Queensland campaign from unexpectedly altering the Victorian website.

A shared database is common when the sites belong to the same organisation and require central administration. Separate databases can provide stronger operational isolation, although they increase deployment and maintenance work. Before choosing, assess editorial permissions, compliance obligations, backup requirements and whether a failure in one site must be prevented from affecting the others.

Use Composer to lock the TYPO3 version and extensions in one place. The deployment pipeline should install the exact lock file, build assets, run database migrations and clear caches consistently. Avoid manually adding extensions in production, since an apparently small difference between environments can create difficult-to-reproduce failures.

Configure Site Roots and Domains

Create a root page for every website and place its content beneath that page. In the TYPO3 backend, mark each root correctly and assign a Site Configuration. A typical configuration lives in a directory such as config/sites/brand-au/config.yaml, with comparable directories for other brands or regions.

Each YAML file should define the site identifier, root page ID, base URL, language setup, error handling and routing information. Use complete HTTPS URLs, including the correct host name and path when a site is served from a subdirectory. Host matching should be deliberate rather than relying on a broad fallback that could send an unknown domain to the wrong website.

For example, a site serving https://www.example.com.au/ should have a matching base, while a campaign site at https://events.example.com.au/ should have its own root page and configuration. Check canonical URLs, hreflang values, sitemap output and redirects for every domain. Australian organisations frequently operate .com.au, .org.au and state-specific campaign domains, so these details should be tested independently.

Languages can be shared conceptually without being identical in implementation. One site may need English only, while another may support English and Mandarin for a Sydney audience. Define language records and fallbacks per site rather than assuming every root page has the same language structure.

Share Extensions, Templates and Assets

Shared custom extensions should expose reusable content elements and services while accepting site-specific settings. A common pattern is to read configuration from TypoScript constants, Site Settings or environment variables, then provide sensible defaults. Avoid hard-coding a single brand name, logo path, analytics identifier or contact address inside PHP or Fluid templates.

Fluid layouts can be shared through a design-system extension, with each site selecting its own logo, colour palette and navigation rules. Asset collections should be organised so editors can find the correct material for each website. Restrict access to file collections and backend records when several teams work in the same installation.

A shared codebase does not mean every file should be globally writable. Store public assets in the expected public directory and use TYPO3’s file abstraction layer for managed media. Keep secrets, API credentials and private exports outside the web root. Custom upload handlers must validate paths carefully; the guidance on directory traversal attacks is relevant when an extension reads or writes files based on request input.

Site-specific integrations belong behind configuration boundaries. Payment providers, CRM endpoints and analytics services should be selected through environment-aware settings rather than conditional code scattered across templates. This makes local development safer and allows a staging site to use test services without changing application files.

Separate Environments and Troubleshoot Methodically

Use the same repository structure for local, staging and production environments, but provide different values through environment variables or deployment secrets. A developer might run several sites on local host names, while staging uses subdomains and production uses public Australian domains. The host-to-site mapping should be documented and tested in all three environments.

TYPO3 caches can make a configuration change appear ineffective. After editing Site Configuration, TypoScript or extension settings, clear the appropriate caches and check the generated URL again. Review the system log, web server log and PHP log together. A wrong root page, invalid YAML value or missing environment variable can otherwise look like a routing problem.

For local development, use a consistent convention such as brand-one.ddev.site and brand-two.ddev.site, or equivalent entries in the hosts file. Confirm that HTTPS, trusted hosts and reverse-proxy headers behave as they will in production. This matters when a load balancer terminates TLS before forwarding requests to TYPO3.

The same disciplined separation helps when investigating tooling outside the CMS. For example, a developer documenting platform-specific event handling may consult notes on Cocoa tracking areas, then apply the same principle of isolating operating-system behaviour from shared application code. Keeping diagnostic notes close to the project’s deployment documentation makes future support faster.

Choose an Operational Model

There are two broad patterns for a TYPO3 multisite installation. A single instance with multiple root pages is usually efficient for closely related sites. Multiple TYPO3 instances sharing a repository can provide stronger database and cache isolation, though each instance needs its own configuration, deployment process and monitoring.

Operating model	Strengths	Trade-offs	Suitable use
One TYPO3 instance, multiple site roots	One deployment, shared users and extensions, central updates	Shared database and cache boundaries	Related brands or regional sites
Separate instances from one repository	Better isolation, independent releases and databases	More infrastructure and maintenance	Sites with different risk or release cycles
One codebase with environment-specific builds	Clear production separation and repeatable releases	More complex configuration management	Larger teams with formal DevOps practices

Choose the simplest model that meets the organisation’s risk and governance requirements. A group of related Australian service sites will often benefit from one instance, while an independently managed financial or healthcare site may justify a separate database and release path.

Document the root page IDs, domain names, deployment variables, scheduled tasks, cache strategy and ownership of each site. If an agency manages several clients from one platform, use explicit access groups and avoid giving editors permissions to unrelated root pages. For a public-sector project, also record accessibility checks, privacy requirements and the location of backups.

A short runbook is valuable during an incident. Include commands for deploying the locked Composer dependencies, clearing caches, checking database migrations and confirming that each domain returns its own homepage. Record rollback steps as well, because a shared deployment can affect every site at once. If a promotional campaign or seasonal event is being prepared, keep its launch notes separate from technical configuration; an external example such as this campaign story can be referenced as editorial material without mixing it into TYPO3 settings.

For a reliable shared setup:

• Define one root page and one Site Configuration for every domain.
• Keep reusable PHP, Fluid and asset logic in Composer-managed extensions.
• Store secrets and site-specific values in environment-aware configuration.
• Test routing, languages, redirects, caches and permissions per website.
• Maintain a deployment and rollback runbook that covers the entire installation.

A well-separated TYPO3 project gives editors a coherent backend while preserving the identity of each website. Start by mapping domains, root pages and ownership, then build the shared extension layer around those boundaries. With repeatable Composer deployments and deliberate site configuration, a single codebase can support multiple Australian websites without turning every change into a cross-site risk.