Tesria

Security hardening

Tesria arrives set up for a private network. Before people can reach it from the internet, a few things need doing that the software cannot do for you: strong passwords, the stricter web server configuration, two-factor sign-in for the people who run it. This page is that list, with why each item matters.

On a private network, the accounts and operations items still apply.

Configuration

  • DOMAIN is a real name you control, and ACME_EMAIL is an address someone reads. See HTTPS and domains.

  • CADDYFILE=deploy/Caddyfile.public is set. The standard configuration makes a certificate for any name a stranger connects with.

  • POSTGRES_PASSWORD, APP_DB_PASSWORD, BACKUP_ENCRYPTION_KEY and COLLAB_SHARED_SECRET are long, random and all different. APP_DB_PASSWORD is set; Tesria will not start without it.

  • Only ports 80 and 443 are open to the outside. Nothing publishes Tesria’s own port (8080), the database (5432) or the live editing service (8090).

  • If a proxy of your own sits in front, PROXY_TRUSTED_NETWORKS names exactly that proxy.

  • You have decided whether pages may show pictures from any website. If what your readers read is private, limit pictures in Admin, Settings (Admin is in the top bar; in a narrower window it is under More, and on a phone in the ☰ menu), under Images.

  • If single sign-on is on, OIDC_REQUIRE_HTTPS_METADATA is left out or true.

Accounts

  • The owner has two-factor sign-in on and has saved their recovery codes. Nobody else can reset the owner, so losing both locks the owner out. See Two-factor and recovery codes.

  • Every administrator has two-factor on, and Require two-factor for administrators is on (Admin, Security, Kill switches).

  • Each role has only what it needs: review Admin, Roles.

  • Allow public registration is off, so new accounts need an invite, unless you mean to run an open community.

  • Allow public spaces stays off until you mean to publish a space to people who are not signed in.

Operations

  • Backups run, a restore has been rehearsed, and there is at least one offsite copy.

  • The passphrases in .env are kept somewhere other than the server.

  • Email works, so alerts reach administrators: Send test email to me succeeds. See Email (SMTP).

  • Tesria’s log, which carries a copy of the audit log, is sent somewhere durable.

  • scripts/verify-audit-chain.sh runs on a schedule and someone watches its result. See Health checks and monitoring.

  • Someone watches for new releases and upgrades promptly. See Upgrading.

What Tesria does for you

Once those are done, Tesria covers a good deal by itself: limits on sign-in attempts from one address and lockouts for one account; alerts for patterns such as password spraying or mass deletion; a blocklist for addresses; strict browser security headers; attachments that cannot run scripts as the site; webhooks that cannot reach the server’s own network; and an audit log the running application cannot alter. The Security section explains each, and what it does not cover.


Applies to

Tesria 0.5 and later

Updated

September 24, 2026

Changes

Revised.