Tesria

HTTPS and domains

HTTPS is what puts the padlock in the browser’s address bar. Everything between the browser and Tesria is encrypted, so nobody else on the network can read pages or passwords as they pass. Tesria always uses HTTPS; you never have to turn it on.

What differs is who vouches for Tesria’s certificate, the ID card a server shows to prove who it is. That depends on how people reach your Tesria, and this page helps you choose.

Which one are you?

  • Only on your own network. Tesria runs on a computer at home or in the office, and people open it by that computer’s name, such as studio.local. Tesria makes its own certificate. It works straight away, and each device warns once until you tell it to trust Tesria. This is how Tesria starts out. See On your own network below.

  • On a domain name you own. People open it at an address such as wiki.example.com, from anywhere. The certificate comes free from Let’s Encrypt, is trusted by every browser, and renews itself. See A real domain and On the public internet below.

With the standard configuration the two go together: a Tesria with a domain name also answers by its own name on the local network. The stricter configuration for the internet, below, serves only the domain.

On your own network

Nothing to set: this is what DOMAIN=localhost in .env does, and it is the default.

Tesria answers to whatever name a device uses to reach it. The first time a name is used, it makes a certificate for that name, signed by its own certificate authority. So phones and other computers can open it with no setup, and it keeps working if the computer’s network address changes.

Browsers do not know Tesria’s certificate authority, so each device warns until you tell it to trust it. That takes a few minutes, once per device, and then covers every name: Trusting the local certificate.

Open Tesria by a name rather than a number such as 192.168.1.50: a certificate is issued for a name, so a number keeps warning even on a device that trusts Tesria. Opening Tesria by name shows how to find the name and make it reliable.

A real domain

You need a domain name you control, and a server the internet can reach.

Step 1: Point the domain at the server

Where you manage the domain, add a DNS record (an A record) for the name, such as wiki in example.com, with the server’s public address.

Step 2: Open ports 80 and 443

The server must be reachable from the internet on both. On a home or office network, that usually means forwarding them to the server in the router’s settings. Let’s Encrypt checks port 80 when it issues the certificate.

Step 3: Set the address in .env

Bash / Shell
DOMAIN=wiki.example.com ACME_EMAIL=you@example.com CADDYFILE=deploy/Caddyfile.public

The third line is the stricter configuration for the internet, explained below. Use your own domain and email address.

Step 4: Restart and open it

Bash / Shell
docker compose up -d

Tesria asks Let’s Encrypt for a certificate, and renews it by itself from then on. Open https://wiki.example.com: a padlock, and no warning on any device.

On the public internet

The standard configuration is made for a private network, where it helps that Tesria makes a certificate for any name. On the internet that becomes a weakness: anyone who connects with a made-up name gets a certificate made for it. So a server the internet can reach uses the stricter configuration, with this line in .env:

Bash / Shell
CADDYFILE=deploy/Caddyfile.public

Then run docker compose up -d caddy. It differs from the standard one in three ways:

  • It serves only your domain.

  • It no longer offers the local certificate, which nobody outside your network would trust anyway.

  • It tells browsers to always use HTTPS for your domain from then on. This is called HSTS.

HSTS cannot be taken back quickly. Once a browser has seen it, for two years it refuses plain HTTP to your domain and will not let anyone click past a certificate warning, even if you switch the configuration back. Use it only with a real domain and a real certificate, never with localhost.

Before you let the internet in, work through Security hardening.

Your own proxy in front

If Tesria sits behind a reverse proxy of your own rather than directly on the internet, set PROXY_TRUSTED_NETWORKS in .env to that proxy’s address. Tesria then believes the visitor addresses the proxy passes on, which its sign-in limits depend on. Never publish Tesria’s own port, 8080, to the network: anyone who could reach it could claim to be any address.


Applies to

Tesria 0.5 and later

Updated

September 24, 2026

Changes

Revised.