Security
Manage the server firewall, control SSH access, and secure services installed on your server.
Security
The Security tab gives you a single place to manage the server's firewall rules and review the access controls that protect your infrastructure. Devpilot talks to your server's own firewall tooling (typically ufw, firewalld, or iptables depending on the distribution) so you don't need to edit configuration files directly.
Firewall Management
Open the Security tab on a server and switch to the Firewall section. Devpilot reads the current firewall state from the server and presents it as a set of rules you can add, update, or remove.
Viewing firewall rules
Each rule shows:
| Field | Description |
|---|---|
| Name | A descriptive label for the rule. |
| Direction | Inbound (traffic arriving) or Outbound (traffic leaving). |
| Protocol | TCP, UDP, or ICMP. |
| Port(s) | A single port or a port range (for example 443 or 8000-8100). |
| Source / Destination | An IP, a CIDR range (for example 10.0.0.0/8), or "Any". |
| Action | Allow or Deny. |
| Status | Enabled or Disabled. |
Adding a firewall rule
- Click Add Rule in the Firewall section.
- Enter a name (for example
Allow HTTPS). - Pick the direction (Inbound or Outbound).
- Pick the protocol (TCP, UDP, or ICMP).
- Specify the port or port range.
- Set the source (inbound) or destination (outbound).
- Choose Allow or Deny.
- Click Save Rule.
Devpilot applies the rule to the server's firewall immediately.
Be especially careful with SSH. If you block the SSH port without keeping an alternate entry point, Devpilot itself loses access and you will need console/rescue-mode access to the server to recover.
Enabling and disabling rules
Toggle a rule between Enabled and Disabled without deleting it. Useful for temporarily proving whether a rule is causing a connectivity issue before committing to removing it.
Deleting a rule
Delete removes the rule permanently from the server firewall. There's no undo — disable first if you're not sure.
SSH Access Controls
Your SSH credentials for a server are managed at the Devpilot level (see SSH and Connectivity). From a security standpoint, the core recommendations are:
- Use key-based authentication (uploaded or Devpilot-generated) instead of passwords.
- Disable root login over SSH and connect as a sudo user.
- Limit SSH exposure with a firewall rule that restricts the SSH port to your office, VPN, or known egress IPs where possible.
- Rotate keys when team members leave and remove stale entries from
authorized_keys.
Securing Services You Install
Installing services from the App Store (see App Store) makes it easier to keep them up to date because Devpilot tracks install state and supports uninstalling cleanly. Combine that with:
- Certbot from the App Store for Let's Encrypt certificates if you're serving HTTP(S) directly.
- Fail2ban from the App Store for brute-force protection on SSH and other services.
- phpMyAdmin behind a firewall rule or reverse proxy — never expose it directly to the public internet on a well-known port.
- Database remote access restricted to specific IPs (see Database Management for how Devpilot scopes the
hostvalue on database users).
Security Best Practices
- Keep rules minimal. Only open the ports your applications need. Deny by default where your firewall supports it.
- Segment access. Restrict SSH to trusted IPs; restrict database ports to your application servers; keep everything internal actually internal.
- Patch regularly. Use Scripts or the terminal to run system updates on a cadence.
- Audit. Review firewall rules periodically — stale rules from past experiments are a common source of exposure.