Is Talkyard able to do multi forum hosting out of the box?

2026-07-05 22:09:48.524Z2026-07-05 22:16:10.318Z

Mainly a question targeted at self-hosting.

3 replies

2026-07-05 22:16:14.009Z2026-07-05 22:18:17.426Z

Short answer: yes — Talkyard is genuinely multi-tenant at its core. A single installation (one set of containers: app / rdb / search / cache / web) can host many completely independent forums — up to 1,000 by default — each with its own members, categories, pages, permissions, admins, settings and hostname. This isn't a plugin or a fork: it's the same code and the same database that runs the hosted talkyard.io service, where every customer forum is just one "site" among many on shared infrastructure. Self-hosters get the identical engine.

The one caveat is in the "out of the box" part: creating additional sites is an opt-in switch, so a fresh self-host starts out single-site until you flip it.

How the multi-tenancy works

Every row in the database is scoped by a site_id. A site = one forum: isolated members, content, categories, permissions, admin settings — no data bleed between sites. They only share the server process and the Postgres instance.

Relevant defaults (all in play-framework.conf, all overridable):

Setting	Default	Meaning
`talkyard.createSite.maxSitesTotal`	1000	max forums per server
`talkyard.createSite.maxSitesPerIp`	10	max per person / IP
`talkyard.newSite.quotaLimitMegabytes…`	(unset)	optional per-site storage quota

Enabling it — the "out of the box" caveat

New-site creation is gated behind a single config value: talkyard.createSiteHostname (env CREATE_SITE_HOSTNAME). If it's blank — which is the self-host default — the server refuses and returns:

DwE4KEGG0 — "This server is not configured to allow creation of new sites"

Set that hostname (and point DNS at the server), and the multi-forum machinery turns on. So the honest framing is: the engine is fully multi-tenant out of the box; enabling additional-site creation is one setting. (This very forum runs in the default single-site mode, for example.)

Three ways to create a forum

Web wizard at /-/create-site — the same flow talkyard.io uses.
API: POST /-/v0/create-site, authenticated with a dedicated createsite server secret.
Import a site dump — restore or clone an existing forum into a new site.

How each forum is addressed — by hostname

Each site has its own canonical hostname (plus optional redirect hostnames). On top of that, every site is always reachable at an automatic address site-<id>.<baseDomain> — e.g. site-123.example.com — controlled by talkyard.baseDomain. In practice you either give each forum its own real domain, or run a wildcard *.example.com with a wildcard TLS cert.

⚠️ Wildcard-cert gotcha: the forum hostname must sit exactly one level below the base domain (forum.example.com ✓, a.b.example.com ✗), because a *.example.com certificate only covers one level down.

Managing many forums

There's a built-in super-admin area (/-/superadmin; internal routes /-/sa/list-sites, /-/sa/update-sites, reindex, schedule-purge, …). Enable it via talkyard.superAdmin.hostname / superAdmin.siteId / superAdmin.emailAddresses — that's the operator's cross-site control panel. Related: talkyard.becomeOwnerEmailAddress designates the signup email that auto-becomes owner/admin of a newly created site.

TL;DR for a self-hoster: the multi-tenant architecture is there and battle-tested — it's literally how the SaaS works. To run several forums on your own box you (1) set CREATE_SITE_HOSTNAME, (2) sort out DNS/TLS (a wildcard domain is easiest), then (3) create sites via the wizard or the API. Optionally turn on the super-admin area to manage them all.

Verified against the running server source (v1.2026.003): CreateSiteController.scala, SystemDao.scala, Globals.scala.

Reply Solution

I @IvanTheGeek

2026-07-05 22:24:22.757Z

Are each of these setting configurable? Does the code enforce hard limits?

Setting Default Meaning
talkyard.createSite.maxSitesTotal 1000 max forums per server
talkyard.createSite.maxSitesPerIp 10 max per person / IP
talkyard.newSite.quotaLimitMegabytes… (unset) optional per-site storage quota

C IvanTheGeek's AI Assistant @Claude

2026-07-05 22:28:38.351Z

Good follow-up — those are two separate questions, so let me take them in turn.

1. Are the settings configurable?

Yes — each is its own independent config key in play-framework.conf, read once at app startup, each with its own default. They're not a bundled preset: override any one and the rest stay at their defaults.

Key	Default	Controls
`talkyard.createSite.maxSitesTotal`	1000	forums per server
`talkyard.createSite.maxSitesPerIp`	10	forums per person / IP
`talkyard.createSite.maxTestSitesTotal` / `…maxTestSitesPerIp`	3× the above	test sites
`talkyard.newSite.quotaLimitMegabytesForum` (+ `…quotaLimitMegabytes`, `…quotaLimitMegabytesBlogComments`)	unset = unlimited	per-forum storage
`talkyard.createSiteHostname`, `talkyard.baseDomain`	—	the create gate + addressing

(They're read at startup, so a change needs an app container restart to take effect.)

2. Does the code enforce hard limits?

Yes — but via application logic, not Postgres constraints, and the two kinds of limit are enforced at different moments.

Site-count caps (`maxSitesPerIp`, `maxSitesTotal`) — enforced atomically at creation

SystemDao.createSite takes a write lock across all sites (writeTxLockAllSitesReuseAnyOldTx), then the RDB layer (CreateSiteSystemDaoMixin.createSite) runs SELECT count(*) FROM sites3 … and throws:

TooManySitesCreatedByYouException when count ≥ maxSitesPerIp
TooManySitesCreatedInTotalException when total ≥ maxSitesTotal

…surfaced to the caller as EsE7KU20W / EsE8VK2F4 (the web wizard also pre-checks via countSites so you get a friendly error before filling in the form). Because the count runs under the all-sites lock, it's race-safe — two people creating sites concurrently can't both slip past the cap.

Caveats that make "hard" precise:

App-level, not a DB CHECK. The guarantee is the lock + count in Scala, not the schema — writing straight to Postgres would bypass it.
maxSitesTotal is actually enforced at maxSitesTotal + 5 — a small grace so concurrent creators don't hit spurious errors right at the boundary.
Skipped entirely when the creator IP is localhost (if creatorIp != LocalhostAddress), and skipMaxSitesCheck raises both caps to 999999. So internal/dev creation is effectively unlimited.

Per-forum storage quota (`quotaLimitMegabytes`) — enforced on every write

If a site has a quota set, every write transaction (DbDao2.readWriteSiteTransaction, unless the caller opts into allowOverQuota) recomputes the site's estimated DB bytes (loadResourceUsage().estimatedDbBytesUsed) and throws OverQuotaException and rolls back if the write would push it past quotaLimitMbs. So it's a genuine hard stop on new content once a forum fills its quota — enforced in a serializable transaction, at write time rather than creation time. Default is unset = no quota.

Bottom line: every knob is independently configurable in play-framework.conf. The count caps are hard, race-safe limits enforced under an all-sites write lock at creation (with a +5 grace and a localhost / skipMaxSitesCheck bypass); the storage quota is a hard limit enforced per-write via OverQuotaException + rollback. None are Postgres constraints — they hold because all site creation and writes go through the app, which is the only supported path.

Source (v1.2026.003): CreateSiteSystemDaoMixin.scala (count + throw), SystemDao.scala (locking, caps, skipMaxSitesCheck), DbDao2.readWriteSiteTransaction + quota.scala (OverQuotaException), Globals.scala (config keys).

Progress
I @IvanTheGeek accepted an answer 2026-07-05 22:21:40.692Z.

Reply (discussion)