wtclaude
4426d3e339
All checks were successful
PR checks / checks (pull_request) Successful in 2m10s
PLAN.md §16, D63/D64, plus D67-D69 taken 2026-10-22. - Core docs use core's words: a Team, a game server, the sidecar, the bridge plugin, the game module. Detail that belonged to Ultima Online moved into its pages rather than being dropped. - New "Ultima Online" sidebar group (nine pages): an overview, Connect a ServUO shard, Verify the bridge, The shard connection, Client files, Troubleshooting, Bridge.cfg, sidecar.toml, Shard event catalog. Five moved URLs answer a real 301 (src/config/redirects.mjs, asserted by the served test). - Getting started is game-neutral. "Connect your game server" keeps the old URL and hands off to each game; Rust links docs main:rust-link/INSTALL.md until phase 15. "Verify the whole stack" stays, neutral (D69). - D68: GameExample.astro labels a game's real example on a core page with the game's name; checkTerms allows that game's words inside it. - scripts/checkTerms.mjs, the twelfth check: 16 game words, docs pages and both sidebar trees, one allowlisted phrase (Discord's "Guild (server) ID"). Wired into verify and pr-checks.yml. - canonicalDocs grouped by game; the Rust group carries four documents. - D67: the screenshot rule from #32 is adopted. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
101 lines
5.1 KiB
Plaintext
101 lines
5.1 KiB
Plaintext
---
|
|
title: Configuration
|
|
description: What is set in the environment file, what is set in the admin panel, and why the split is where it is.
|
|
---
|
|
|
|
import { Aside } from '@astrojs/starlight/components';
|
|
|
|
Two places hold configuration, and the line between them is not arbitrary.
|
|
|
|
| | Environment (`.env`) | Admin panel |
|
|
|---|---|---|
|
|
| **What** | How the process runs: ports, database, secrets, proxy trust, log level | How the site behaves: titles, registration, forums, integrations |
|
|
| **Changing it** | Edit the file, `docker compose up -d` | Save the form; effective immediately |
|
|
| **Who** | Whoever has the host | Whoever has an admin account |
|
|
| **Where it lives** | A file on the host | The database |
|
|
|
|
The rule behind the split: **anything that needs a restart or a shell is environment;
|
|
anything an administrator should be able to change without either is in the panel.** That
|
|
is why the Discord bot token, the OAuth client secrets and the game module's sidecar token are *not*
|
|
environment variables — they are entered in the panel and stored encrypted.
|
|
|
|
## Settings
|
|
|
|
**Admin → Settings**, the screen most of a new deployment's decisions live on.
|
|
|
|
| Field | What it does |
|
|
|---|---|
|
|
| **Site title** | Overrides `BRAND_NAME` in the page title, the header and link previews. |
|
|
| **Homepage teaser** | Rich text under the hero heading, when no custom hero layout is published. |
|
|
| **Maintenance message** | What visitors see while the site is in maintenance mode. |
|
|
| **Status message** | A short line for announcements — a maintenance window, an outage. |
|
|
| **Contact email** | Where the contact form delivers, and the address it falls back to as a `mailto:` link while email is unconfigured. |
|
|
| **Player registration** | Disabled, password, SSO, or both. **Off by default.** |
|
|
|
|
### Player registration is off until you turn it on
|
|
|
|
A new site accepts no self-registration at all. The three ways to let people in:
|
|
|
|
- **Password** — a normal sign-up form.
|
|
- **SSO** — sign-up through a linked provider, which needs a provider configured first.
|
|
- **Invites** — leave registration off entirely and issue invitations from
|
|
**Admin → Invites**. See [Users and roles](/docs/administration/users-and-roles/).
|
|
|
|
## Team forums
|
|
|
|
The same screen carries the forum switches, because they are site-wide policy rather than
|
|
per-Team settings:
|
|
|
|
- **Enable team forums** — off by default. Switching them off hides them completely (every
|
|
forum route answers *not found*) but **deletes nothing**: threads, posts, access grants
|
|
and notification preferences all survive and come back exactly as they were.
|
|
- **Images in forum posts** — disabled, remote URLs only, or uploads to your server.
|
|
Enabling uploads means content stored on infrastructure you are responsible for, and the
|
|
screen says so at some length before you can agree to it.
|
|
- **Post edit window** — how long an author may edit their own post. Staff are not bound by
|
|
it. Zero makes posts permanent once written; some bound is what stops a post being
|
|
rewritten out from under someone quoting it.
|
|
|
|
## Email
|
|
|
|
Configured on the same screen and covered in
|
|
[Notifications and email](/docs/administration/notifications-and-email/): pick a mail
|
|
transport, enter its host, port and credentials, and send a test. It depends on nothing
|
|
else on the site — a relay is the recommended posture, a mailbox provider over SMTP the
|
|
simplest, and your own MTA needs no credentials at all.
|
|
|
|
<Aside type="note" title="Until email is connected, the contact form is a mailto: link">
|
|
That is a deliberate fallback rather than a failure — but it does mean the *Contact email*
|
|
setting is doing real work on a site that has never configured delivery, and an unset one
|
|
leaves a contact form that goes nowhere.
|
|
</Aside>
|
|
|
|
## The environment file, in three groups
|
|
|
|
You wrote these in [Install the site](/docs/getting-started/install-the-site/); this is
|
|
what they mean when you come back to them.
|
|
|
|
**Identity and process** — `NODE_ENV`, `PORT`, `INTERNAL_PORT`, `IMAGE_TAG`. `INTERNAL_PORT`
|
|
is the server-to-bot channel and must never be published or proxied.
|
|
|
|
**Data and secrets** — the `DB_*` group, `JWT_SECRET`, `SECRET_ENC_KEY`, `BOT_INTERNAL_KEY`.
|
|
The last two are required in production, and `SECRET_ENC_KEY` is the key everything else
|
|
encrypted at rest is keyed by: change it and the stored secrets become unreadable.
|
|
|
|
**Behaviour at the edge** — `TRUST_PROXY`, `COOKIE_SECURE`, `COOKIE_NAME`,
|
|
`JWT_EXPIRES_IN`. `COOKIE_NAME` is worth one warning: changing it on a live site logs
|
|
everybody out.
|
|
|
|
<Aside type="caution" title="`MODULE_SOURCE_HOSTS` is bootstrap only">
|
|
It seeds the module install allowlist the first time a site boots without one. After that
|
|
the **setting** is authoritative and is edited in Admin → Modules — changing the variable on
|
|
an existing deployment does nothing, deliberately, so a redeploy cannot silently undo an
|
|
administrator's choice.
|
|
</Aside>
|
|
|
|
## Branding is data, not configuration
|
|
|
|
The `BRAND_*` variables and the `/brand` mount are how one prebuilt image runs as any
|
|
community's site. They get their own page:
|
|
[Branding and theming](/docs/administration/branding-and-theming/).
|