Firewall & SSH
What DeployOS changes in ufw, how SSH credentials are stored, and the per-server deploy key for private repos.
Firewall (ufw)
Bootstrapping a server configures ufw to allow exactly three ports: 22 (SSH), 80 (HTTP), and 443 (HTTPS) — then enables it. Nothing else is opened by default.
If a server's firewall isn't enabled yet, its Security page has an explicit Allow SSH & enable action that opens 22/80/443 and turns ufw on in one step — deliberately atomic, so you can't end up with ufw enabled while SSH itself is still blocked and lock yourself out.
How SSH credentials are stored
Whatever you provide when adding a server — a password or a private key — is stored in your operating system's native keychain (macOS Keychain, Windows Credential Manager), not in a plaintext file anywhere in DeployOS's app data. The same applies to database passwords, backup target keys, and secret-provider tokens.
Deploy keys for private repos
When you point an app at a private repo using a git@github.com:... SSH URL, DeployOS generates (or reuses) an SSH key pair on that server and shows you the public half to add under the repository's Settings → Deploy keys on GitHub. This scopes clone access to that one repo, on that one server — not your whole GitHub account.
Next: banning attackers and locking down SSH itself
The firewall controls what can reach the server. For blocking IPs that repeatedly fail to log in, and for hardening SSH itself (disabling root login or password auth), see Fail2Ban & SSH Hardening.
What DeployOS does not do
- It does not install a persistent agent or daemon on your server — see Adding a Server.
- It does not phone home to validate your license — see Activating Your License.
- It does not require root access beyond what a normal Docker + firewall setup needs.