Hosting and backups

Doorcom is one static binary and one SQLite file. It runs on any x86-64 or arm64 Linux with no runtime dependencies; Caddy in front gives it HTTPS. This chapter is the operations side: the service, the proxy, the database file, backups and upgrades.

The pieces

/usr/local/bin/doorcom: the binary.
/var/lib/doorcom/doorcom.db: the database, with its -wal and -shm companions while running. Photos, documents, snapshots and voice messages are inside it.
/etc/doorcom.env: the environment (mode 600).
/etc/systemd/system/doorcom.service: the unit, running as the doorcom user with the filesystem protections in the deploy folder.
/etc/caddy/Caddyfile: the reverse proxy.

Environment

Variable	Meaning	Default
`DC_DB`	Path of the SQLite file	`data/doorcom.db`
`DC_ADDR`	Listen address; keep it on localhost behind Caddy	`:8090`
`DC_PUBLIC_URL`	Public origin for QR codes and links; overrides the Public URL setting	unset
`DC_TZ`	Default timezone for times in the panel	`Europe/London`
`DC_DATA`	Data folder	`data`
`DC_PBX`	`off` or `stub` (the in-process fake for testing)	`off`

systemd

sudo systemctl status doorcom
sudo journalctl -u doorcom -f          # the log: rings, Telegram, email, purges
sudo systemctl restart doorcom          # after changing Telegram or SMS settings

The unit restarts the service three seconds after any crash and starts it at boot.

Caddy

The Caddyfile in deploy/ proxies the domain to 127.0.0.1:8090, sets X-Forwarded-For (used for rate limits) and X-Forwarded-Proto (used for secure cookies), keeps the ring status stream unbuffered, and adds a couple of security headers. Point the domain's A record at the server first; Caddy fetches the certificate on the first request. A second short domain can redirect to the main one for shorter poster addresses.

sudo apt install caddy
sudo cp deploy/Caddyfile /etc/caddy/Caddyfile
sudo systemctl reload caddy

Backups

Everything is in the one database file. Take a copy every night. A plain copy while the service is running is safe in WAL mode, but the SQLite backup command is better because it produces a single consistent file:

sqlite3 /var/lib/doorcom/doorcom.db ".backup /backups/doorcom-$(date +%F).db"

Keep a few weeks of copies somewhere off the server. To restore, stop the service, put the copy in place as doorcom.db (removing any -wal and -shm files), fix the ownership, and start the service. The environment file and the Caddyfile are worth keeping with the backups too.

Upgrades

make linux
sudo cp dist/doorcom-linux-amd64 /usr/local/bin/doorcom && sudo systemctl restart doorcom

Database migrations are additive and run at start-up; an older binary can still open a newer database, so a rollback is the same copy in reverse. Take a backup before an upgrade anyway.

Optional pieces

ffmpeg on the PATH turns visitor voice messages into Telegram voice notes that play inline; without it they are sent as audio files.
The PBX (Asterisk on MiRTA) needs the door dialplan and a WebSocket transport for the browser leg. Until it is there, rings go out by Telegram and email and the phone fields in Settings stay blank.
coturn for TURN when the browser audio leg is in use.

Sizing

One small VPS is plenty for many buildings: the database grows mainly with issue photos and documents, a few tens of megabytes per building. Snapshots and voice messages are purged after seven days by default and issue photos after a year (Settings).

Running it somewhere else

On Windows or a Mac for a look around: go build ./cmd/doorcom, doorcom create-owner ash secret, then DC_PBX=stub DC_PUBLIC_URL=http://localhost:8090 doorcom and open http://localhost:8090/login. The SMS and email dev fallbacks mean nothing is sent; codes appear on screen.