Ports and roles

Ports

These are the ports of the Restow stack and who can reach them. Every other connection (the destinations the Restow host connects to, the Docker network, how endpoints and the instance reach their repositories, and firewall rules for a dedicated VM, a host behind a reverse proxy or a LAN-only installation) is on Network and ports.

Port	Service	Reachability	What it does
80, 443 (RESTOW_HTTP_PORT, RESTOW_HTTPS_PORT in the release stack)	Caddy	Public in public mode	Serves the web interface, proxies /api/*, /agent/* and /install/* to the api (see Agent endpoints) and terminates TLS (automatic Let’s Encrypt for RESTOW_APP_DOMAIN). Behind another reverse proxy, name it in RESTOW_EDGE_TRUSTED_PROXIES.
25 (JOURNAL_SMTP_PORT)	Archive journal receiver, inside the api	Closed until JOURNAL_SMTP_PORT is set; then TCP 25 inbound from the internet	Receives Exchange Online journal reports and, since 0.4.4, copies that a mail provider forwards, over SMTP with mandatory STARTTLS and a TLS certificate of your own; part of the archive, Business and Service Provider. It must be reached directly, not through Caddy or an HTTP proxy; if it listens on another port, forward port 25 to it. In the release stack JOURNAL_SMTP_BIND sets the address it is published on (default loopback). See Exchange journaling.
3000 (RESTOW_API_PORT)	api	Loopback only, by default	Health checks and the REST API on the host. Caddy reaches it over the Docker network.
5432 (POSTGRES_PORT)	postgres	Loopback only in the source stack; not published in the release stack	PostgreSQL.
8090	updater	Internal Docker network only, no published port	The opt-in updater (docker compose --profile updater up -d), which mounts the Docker socket, and that is root on the host; see Updates. The api reaches it at RESTOW_UPDATER_URL (default http://updater:8090). Caddy forwards only one read-only status document (/_maintenance/status) to it, for the maintenance page; it names no version.
8091	mounter	Internal Docker network only, no published port	The mounter (profile mounts; new installations start it by default since 0.4.0), which also mounts the Docker socket. It starts the runners of file share backups and adds NFS shares as repository storage from the web interface; see Mounter and NFS storage. The api and the worker reach it at RESTOW_MOUNTER_URL (default http://mounter:8091). Every service, port and volume of the Compose file: Release stack reference.
445 (SMB), 2049 (NFS)	Your file servers	Outbound from the Docker host to the file server; nothing inbound	File share backup (since 0.4.0): the Docker host mounts the share for one run. NFSv3 also needs 111 and the mount daemon. See Network and ports.
5173 (RESTOW_WEB_PORT), 1025 / 8025 (MAILPIT_SMTP_PORT / MAILPIT_UI_PORT)	Vite dev server, Mailpit	Development only	docker compose --profile dev up -d and --profile mail up -d; not part of a normal deployment.

worker and scheduler expose no ports of their own.

File share runners (since 0.4.0) talk to the api over the internal Docker network runners, on /internal/file-shares/v1 and /internal/file-shares/restic/<share id>/, with a credential that is valid for one run and can only add data. These paths are never forwarded by the web edge (Caddy answers 404 for everything under /internal/), and the api refuses proxied requests to them. See the release stack reference.

Graph notification hooks (since 0.4.4) are two public paths of the same address, /api/v1/hooks/graph/notifications and /api/v1/hooks/graph/lifecycle. Microsoft Graph posts to them without a session, once per archived Microsoft 365 mailbox that Graph captures; each post is checked against the subscription’s secret, and they answer 404 without an edition that includes capture from the mailbox. They need TCP 443 reachable from the internet and a public https:// URL, see Microsoft calls the instance.

Request size limits

Every request body is limited, so that no request can make the api buffer more than it needs. A body over a limit is refused with 413 and urn:restow:problem:payload-too-large (the limit is in limitBytes).

Where	Limit
api, every route unless listed below	1 MiB
api: restore and export selections, import requests, directory rules, IMAP account lists and their CSV import, an agent’s run report	16 MiB
api: endpoint download selections	4 MiB
api: import upload segments	the segment size, at most 32 MiB
api: the restic data path (/agent/restic/)	128 MiB per object
Caddy edge: sign-in, setup, set-password links and agent enrollment	1 MiB
Caddy edge: the rest of /api	33 MiB
Caddy edge: /agent/v1	16 MiB
Caddy edge: /agent/restic	no limit at the edge (the api applies its own)
Caddy edge: /agent/pve/v1 (Proxmox VE nodes)	80 MiB (frames of up to 16 blocks of 4 MiB)
Caddy edge: /agent/pve/restic (Proxmox VE containers)	no limit at the edge

A malformed or oversized enrollment request counts as a failed enrollment attempt.

Import folder

Both Compose stacks mount a host folder read-only into the api and worker containers: the folder RESTOW_IMPORT_DIR (default ./import next to the Compose file) appears at /var/lib/restow/import. Each tenant uses its own subfolder. Restow never writes to it. See Mail file import and export.

Agent endpoints

Machines backed up with the Restow agent, and Proxmox VE nodes, reach your instance over HTTPS on its public address, through Caddy, and need no other port. Caddy proxies these paths to api:

Path	Purpose
/agent/v1/...	The agent API: enrollment, configuration, heartbeat, runs, agent update.
/agent/restic/<endpoint id>/...	The restic repository of one endpoint, append-only for the agent.
/agent/pve/v1/...	The API of the Proxmox VE node helper restow-pve: enrollment, reports, tasks, the guest list, VM block uploads and reads, restore points.
/agent/pve/restic/<guest id>/...	The restic repository of one Proxmox VE container, append-only for the node.
/install/...	The install scripts (linux.sh, macos.sh, pve.sh for Proxmox VE nodes) and the agent, restow-pve and restic binaries with their SHA256SUMS.

The agent only connects out; nothing on the machine listens. See Endpoint backup. How the backup data gets from the agent into the storage target is described in Network and ports. Proxmox VE nodes (a preview) reach your instance the same way through the two /agent/pve/ paths, see Proxmox VE backup and Network and ports.

Application roles

Role	Scope	Can do
Provider admin	Whole installation	Manages tenants, invites tenant admins, has access to every tenant. Since 0.3.1 every edition, Community included, can have several provider administrators with roles (owner, administrator, technician, read only) in the provider team; limiting a member to chosen tenants is Service Provider.
Tenant admin	One tenant	Can be invited in every edition. Manages that tenant’s setup (protection, sources, schedules), repositories, members and restores, including restoring on behalf of another user (impersonation, always audited).
Restore operator (from 0.3.5)	One tenant	Sees and restores every backup of the tenant, without administering it (jobs, storage, users). Since 0.4.0 this includes the files of servers and clients, of Proxmox VE guests and SharePoint sites. See Team and roles.
Tenant user	Own data only	Signs in, restores and downloads only their own mailbox/OneDrive/IMAP account.

See Multi-tenancy for how tenants and roles relate to editions.

Database roles

Role	.env variable	Privileges
Owner	DATABASE_MIGRATION_URL	Owns every table; runs migrations only.
Application	DATABASE_URL	NOSUPERUSER, NOBYPASSRLS, owns no table. All tenant-scoped work at runtime. Since 0.3.5 it reaches tenant data only: of the sign-in tables nothing but a user’s name and email address, no installation table, and in the job queue it may only add a job.
Installation	DATABASE_PROVIDER_URL	BYPASSRLS. Cross-tenant lookups, installation-wide settings, the scheduler, webhook delivery, pg-boss’s schema.
Auth (since 0.3.5)	DATABASE_AUTH_URL, optional	Sign-in: sessions, passwords, passkeys and two-factor secrets, and the sign-in, account and membership code, under Row Level Security. The migration creates it, with a login derived from the other two (<application role>_auth, for example restow_app_auth); you set nothing for it.

Full explanation: Get started → The three database roles.