Secure remote access
To use Savorum from your phone, another computer, or outside your home, it needs to be reachable over HTTPS. Savorum itself only speaks plain HTTP, so keep it listening on its own machine and put a reverse proxy, such as Caddy or nginx, in front to handle HTTPS:
browser → HTTPS reverse proxy → HTTP on the same machine → SavorumTurn on sign-in first. Create the first administrator and start Savorum with --auth-enabled before it’s reachable from anywhere but its own machine. Never put Savorum in local mode on the internet: local mode signs nobody in. If you must, the proxy has to provide its own sign-in or private-network rule, with CSRF protection and secure cookies if it uses cookies. HTTPS on its own keeps nobody out.
Set it up
Section titled “Set it up”-
Start Savorum on the local address only, with sign-in on, your public address, and your proxy’s address:
Terminal window savorum serve \--database /var/lib/savorum/savorum.db \--assets /var/lib/savorum/assets \--listen 127.0.0.1:8080 \--auth-enabled \--public-url https://recipes.example.com \--trusted-proxy 127.0.0.1/32Set
--public-urlto the exact address people type. Savorum accepts requests only for that address, and passkeys are tied to it.--trusted-proxylets the proxy pass on the visitor’s address and the original host and protocol. Use::1/128if the proxy connects over IPv6. -
Configure your proxy, using one of the examples below.
Caddy gets a certificate automatically and sends the headers Savorum needs:
recipes.example.com { log reverse_proxy 127.0.0.1:8080}If a CDN or another proxy sits in front of Caddy, set Caddy’s own trusted_proxies for it. Savorum should still trust only Caddy’s address.
server { listen 443 ssl; server_name recipes.example.com;
ssl_certificate /etc/letsencrypt/live/recipes.example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/recipes.example.com/privkey.pem;
client_max_body_size 256m;
location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; }}Savorum accepts uploads and imports up to 64 MiB, but nginx refuses anything over 1 MB by default, so the example raises client_max_body_size. Add a separate port 80 server that redirects to HTTPS.
Check the setup
Section titled “Check the setup”-
Test the public address:
Terminal window curl --fail --show-error --head https://recipes.example.com/The response should include a content security policy,
Referrer-Policy: no-referrer,X-Content-Type-Options: nosniff, andX-Frame-Options: DENY. -
From another device, check that port 8080 can’t be reached directly.
-
In a private browser window, sign in at the public address, then sign out and confirm the session ends.
-
Check that a request without signing in is refused.
Do all of this before you add real recipes.
Good to know
Section titled “Good to know”- Trust only the proxy that connects directly to Savorum. Don’t trust a whole container network or home network range unless every address in it is a proxy you control.
--trusted-proxynever signs anyone in; signing in through a gateway is set up in Single sign-on. - The proxy should redirect HTTP to HTTPS, add HSTS once HTTPS works, and keep Savorum’s security headers.
- Don’t let a CDN or the proxy cache Savorum’s photos and files. They’re private: the proxy must check sign-in for an image exactly as for the page around it, and must never replay one after someone signs out or loses access.
- Live updates at
/api/v1/eventskeep a connection open for up to five minutes. Set the proxy’s read timeout to at least five minutes and don’t buffer these responses. nginx follows Savorum’sX-Accel-Buffering: noheader on its own. - Calendar apps can’t sign in. If your proxy asks people to sign in, let
/calendar/through. The secret in each feed address protects it. - Savorum announces its name on your local network. Turn this off with
--dns-sd=falseif the name shouldn’t be visible there.
Next: Back up and restore.