Self-hosting

temetro is designed to be self-hosted: your clinic's data stays on infrastructure you control. The supported setup is Docker Compose, which runs all three parts:

Installing

Clone the repository and run from the backend/ folder. Pulling the prebuilt images from Docker Hub is the fastest path; --build instead compiles from source. No .env is required — the backend generates and persists the secrets it needs on first start.

git clone https://github.com/temetro/temetro.git
cd temetro/backend
docker compose pull        # fetch prebuilt images (or use: docker compose up --build -d)
docker compose up -d

The generated secrets are stored in the temetro_secrets Docker volume and stay stable across restarts. You don't need to configure any addresses for other computers on your network to reach temetro — that works automatically (see Network access).

Create a .env (cp .env.example .env) only when you want to customize something: serve over HTTPS (BETTER_AUTH_URL), send real email (SMTP_*), or manage your own secrets (BETTER_AUTH_SECRET / AI_CREDENTIALS_KEY). The full list is in the configuration reference.

Updating

temetro publishes prebuilt images to Docker Hub and cuts a GitHub release for each version. To update, pull the new images and restart on the server:

docker compose pull && docker compose up -d

Migrations apply automatically on backend start. Pin a specific version with TEMETRO_VERSION=0.1.0 docker compose up -d.

The app tells you when an update is available: it checks the latest GitHub release (via GET /api/version) and shows an optional, dismissible banner plus a status in Settings → About & updates, where the exact update command is one click to copy. Updating is always optional.

Network access (LAN)

You don't install temetro on every computer. It runs on one computer, and everyone else just opens it in a web browser over your clinic's network.

Step 1 — Find the server's address

On the server computer (the one running temetro), find its network IP address:

An address that begins with 192.168., 10., or 172. is a private network address — that's the one you want. (Ignore 127.0.0.1; that only means "this same computer".)

Step 2 — Open temetro from another computer

On any other computer on the same network, open a web browser and go to your server's address followed by :3000:

http://192.168.1.20:3000

Replace 192.168.1.20 with the address you found in Step 1. temetro works exactly as it does on the server — no extra setup. Bookmark it on each computer for easy access.

If other computers can't connect

• They must be on the same network as the server (same Wi-Fi or router).
• The server's firewall must allow incoming connections on ports 3000 and 4000. The first time someone connects, Windows or macOS may show a prompt — choose Allow.
• The server must be on and running temetro (docker compose up).
• This uses plain http:// and is meant for a trusted internal network only. Don't open these ports to the public internet; to reach temetro from outside the clinic, put it behind HTTPS (see the HTTPS note above).

Operating temetro

Database & backups

• Patient data lives in the db service's PostgreSQL database, stored in the temetro_pgdata Docker volume — it survives restarts and rebuilds.
• Database migrations run automatically when the backend starts; see Updating for the upgrade flow.
• Back up the volume (or run pg_dump against the database) on a schedule appropriate for a clinical system.
• To inspect the database in a browser, start the optional Adminer service:

docker compose --profile tools up adminer
# then open http://localhost:8080 (server: db, user/password/database: temetro)

Email

temetro sends emails for password resets, verification, and invitations. Configure an SMTP server via the SMTP_* settings in .env. Without SMTP configured, emails are printed to the backend's logs instead — fine for evaluation, not for production.

Email verification is currently not enforced at sign-in (it's wired and planned to be enabled — see the roadmap).

Port conflicts

If port 5432 is already taken on the host (an existing Postgres installation), set POSTGRES_PORT=5433 in .env. The containers keep talking to Postgres internally on 5432; only the host-side port changes.

Running without Docker (development)

For development you can run the pieces directly:

# Terminal 1 — backend (needs a local Postgres; point DATABASE_URL at it)
cd backend
npm install
cp .env.example .env
npm run db:migrate
npm run dev          # API on http://localhost:4000

# Terminal 2 — frontend
cd frontend
npm install
npm run dev          # app on http://localhost:3000

The frontend finds the API automatically from the address you open it on (so http://localhost:3000 talks to http://localhost:4000, and a LAN address works the same way). Set NEXT_PUBLIC_API_URL only if you need to point it at a fixed or reverse-proxied API URL.