SSH access and resource limits

Where these live

Both are settings on a hosting package: Admin → Packages, then create or edit a package. Every account on that package gets them, and a change applies straight away to every account already on it. Both work on every tier, Community included.

SSH access

The SSH access switch decides whether accounts on the package can log in over SSH. It is off by default. Leave it off unless you trust those customers with a shell: SSH gives them a real login on the server as their own account (not root), able to run anything their account can.

What the customer does

1. In the customer panel, open SSH Keys and add a public key. Both the OpenSSH format (ssh-ed25519 AAAA… name) and the PuTTY format (the block PuTTYgen shows, starting ---- BEGIN SSH2 PUBLIC KEY ----) are accepted. Private keys, DSA keys and RSA keys shorter than 2048 bits are refused.
2. The same page shows how to connect: the exact ssh command, and the Host Name, Port and Login-as values for PuTTY.

If the package does not include SSH, the page says so and the login is refused. Keys added in the meantime are kept and start working as soon as you switch SSH on for the package.

What turns it off

• The package. Switching SSH off, or moving the account to a package without it, removes access and ends any open SSH sessions.
• Suspension. A suspended account cannot log in over SSH; access comes back on unsuspend.
• No package. An account with no package has no SSH access.

SFTP runs over SSH, so it follows the same switch. Plain FTP accounts are separate and are not affected. The terminal inside the customer panel does not use SSH either, so it keeps working whatever this switch says. Your own root login over SSH is never touched: the panel only blocks hosting accounts it manages.

Private home folders

Every customer's home folder (/srv/sites/<user>) is private to that customer. Other accounts on the server cannot list or read it, which matters most once customers have a shell. The web servers and the panel keep exactly the access they need to serve the sites and manage the files.

Resource limits

The Resource limits section of a package sets three caps per customer. Each one is unlimited when left empty or set to 0, which is the default.

• CPU limit (%): 100% is one full CPU core, 200% two cores, and so on. A customer at the cap is slowed down, not stopped.
• Memory limit (MB): the customer's processes are slowed as they near the limit, and the process using the most memory is stopped if they go over it.
• Max processes: processes and threads together. At the cap, starting another one fails, which is what stops a runaway script or a fork bomb.

What the limits cover

• the customer's Node and Python apps and background workers
• the terminal in the customer panel
• deploy builds and custom deploy commands (builds also stop after 30 minutes)
• App Installer scripts
• SSH sessions
• cron jobs

Apps and workers share one set of limits; SSH sessions and cron jobs share a second set with the same values. When you first give a customer with running apps a limit, the panel restarts those apps once to move them under it, which takes a few seconds.

What they don't cover yet

PHP websites are not limited. WordPress and other PHP sites run in the server's shared PHP service, outside the customer's limits. Each PHP site is still capped by its own pool settings, which bound how many requests it handles at once, but not its CPU or memory. Covering PHP is planned.

Servers that can't enforce limits

Limits need cgroup v2, which every supported Ubuntu and Debian release uses. Some containers (LXC, OpenVZ) don't give the panel the controls it needs. In that case the Packages page shows a warning that says which part is missing, and the values are saved but not enforced.

Checking it works

As root on the server, systemctl status novapanel-u$(id -u <user>).slice shows a customer's apps and the panel-launched processes with their limits, and systemctl status user-$(id -u <user>).slice shows their SSH sessions and cron jobs.