Docs
Firewall and network setup
Two connections matter for Ottoch: inbound traffic to the app itself, and outbound traffic from Ottoch to your database. Here's what to open, and — more importantly — what to lock down.
Inbound — reaching Ottoch itself
Ottoch ships with Caddy, which listens on ports 80 and 443. Open both on whatever server or VM you deploy on — Caddy uses 80 for the initial Let's Encrypt HTTP challenge and 443 for HTTPS traffic afterward.
Outbound — Ottoch reaching your database
This is the direction that actually matters for database security. Ottoch connects out to your database server, from whatever machine runs the Docker container — your database is never exposed to Ottoch's infrastructure, because there isn't any: everything runs on your own server.
The practical firewall rule you want on your database server: allow
inbound connections on the database port only from the IP address of the machine
running Ottoch — not 0.0.0.0/0.
If your database is already only reachable from inside a private network or VPC that
the Ottoch server is also on, you likely don't need to change anything.
Reference
Default database ports
Whatever port your database actually listens on — these are just the defaults Ottoch pre-fills when you add a connection.
| Database | Default port |
|---|---|
| PostgreSQL | 5432 |
| MySQL / MariaDB | 3306 |
| SQL Server | 1433 |
| Redshift | 5439 |
| ClickHouse | 8123 (HTTP) / 8443 (HTTPS) |
| Databricks | 443 (HTTPS SQL warehouse endpoint) |
Finding the IP to allow-list
If your database is on a cloud provider (RDS, Cloud SQL, managed Postgres, etc.) and you want to restrict its firewall to just your Ottoch server, you need that server's outbound public IP. From the machine running Ottoch:
curl ifconfig.me
Add that IP to your database provider's firewall/security-group allow-list. If your server is behind a NAT gateway or load balancer, use that gateway's outbound IP instead — check your cloud provider's networking docs for how to find it.