HestiaCP: manage packages, users and firewall rules

This guide shows you how to manage packages and users in HestiaCP and how to control the panel's firewall from the same screen. You will create a hosting package, add a user who inherits its limits, then add and test firewall rules without cutting off your own SSH session.

HestiaCP keeps three things in one place: packages (the limits and templates an account gets), users (the accounts that own websites, mail and databases), and the firewall (the iptables rules the panel writes for you). Doing them in that order saves you from re-editing a user later.

Before you start

• A Linux VPS with HestiaCP already installed and reachable at https://203.0.113.10:8083.
• Root SSH access to the server, or the admin login for the panel.
• A note of which ports you actually need open. At minimum: SSH (22), the panel (8083), and HTTP/HTTPS (80 and 443) if you host websites.
• The HestiaCP CLI scripts live in /usr/local/hestia/bin. You can call them by full path or add the directory to your PATH.

Check what is installed and which scripts are available:

ssh root@203.0.113.10
ls /usr/local/hestia/bin | grep -E 'package|user|firewall'

Manage packages and users in HestiaCP

Create the package

Packages define how many domains, mail accounts, databases, cron jobs and disk space a user may consume. Build them in the panel, because the form shows every field and validates the values for you.

1. Log in to the panel as admin at https://203.0.113.10:8083.
2. Open Packages in the top menu and choose Add Package.
3. Give the package a short name such as starter. Names are case-sensitive and are used later on the command line.
4. Set the templates for web, proxy, DNS and mail. Leave them on the defaults unless you have a reason to change them.
5. Set the limits: web domains, DNS domains, mail domains, mail accounts, databases, cron jobs, backups, disk quota and bandwidth.
6. Choose the PHP version and whether the user gets SSH shell access. Leave shell access off unless the user genuinely needs it.
7. Save the package.

If you prefer the command line, v-add-package does the same job, but the argument order is long and easy to get wrong. Run it without arguments to see the current usage list for your HestiaCP version, and check the project documentation when a field name changes between releases.

Create the user

Once the package exists, create the user and assign it in one step:

v-add-user deploy 'ChangeThisPassword123!' deploy@example.com starter

The arguments are username, password, email address and package name. To move an existing user to a different package later:

v-change-user-package deploy starter

List the accounts on the server to confirm the user exists:

v-list-users

Manage HestiaCP firewall rules

HestiaCP's firewall is a front end for iptables. Rules are stored in /usr/local/hestia/data/firewall/rules.conf and applied to the running kernel when you save them. Fail2ban runs alongside it and adds temporary bans for repeated failed logins.

Add a rule in the panel

1. Go to Server and open the Firewall tab.
2. Choose Add Rule.
3. Fill in the action (ACCEPT or DROP), the protocol (TCP, UDP or ICMP), the port, and the IP address or CIDR range the rule applies to. Leave the IP blank to match everyone.
4. Add a comment so the rule is still understandable in six months.
5. Save, then confirm the rule appears in the list.

Add a rule from the CLI

The same rule from a shell:

v-add-firewall-rule ACCEPT TCP 22 203.0.113.10 'SSH from office'

The arguments are action, protocol, port, IP address and comment. Apply any pending changes and list what is active:

v-update-firewall
v-list-firewall

Remove a rule by its ID from the list:

v-delete-firewall-rule 5
v-update-firewall

To see what Fail2ban has banned, open the Fail2ban section next to the firewall rules in the panel. Unban an address there rather than editing iptables by hand, so the change survives the next reload.

Check it works

Confirm the kernel actually has your rules:

iptables -S | grep -E '22|8083|443'

You should see the ACCEPT lines you added. Then test from the outside, not from the server itself:

1. Open https://203.0.113.10:8083 in a browser and log in as deploy with the password you set. If the login works, the user and package are wired up correctly.
2. Open a second SSH session as deploy if you granted shell access. If you did not, the login should fail — that is expected.
3. From another machine, try to reach a port you deliberately blocked. A DROP rule makes the connection hang until it times out rather than refusing it, which is normal.

Troubleshooting

• The new user cannot log in. The password was mistyped or the account is still on a package without panel access. Reset the password from Users → Edit User in the panel and check the package assignment with v-list-users.
• A firewall rule is listed in the panel but the port is still closed. The rule was saved but not applied. Run v-update-firewall and check iptables -S for the matching line.
• SSH stopped responding after a firewall change. A DROP rule caught port 22. Use the browser console in your VPS provider's control panel to get back in, then delete the offending rule ID with v-delete-firewall-rule.
• Rules disappear after a reboot. Something else is flushing iptables at boot, usually UFW or a Docker daemon. Pick a single firewall owner and disable the other.
• Package limits look wrong for an existing site. The user may have been created before the package existed and picked up the default. Reassign with v-change-user-package and re-check the domain count in the panel.

Next steps

• First steps after your Linux VPS is ready — SSH, updates and an initial firewall pass.
• Test firewall changes safely with an automatic rollback — a safety net for remote rule changes.
• List users and groups on a Linux server — see how panel users map to system accounts.