What CageFS actually isolates

CageFS is CloudLinux’s per-account filesystem jail on our shared hosting. It stops your account from reading another customer’s files, including things like wp-config.php, and it blocks system-wide package installs. That isolation is a core part of how shared hosting stays safe for everyone on the server. Older symlink tricks that once crossed account boundaries should fail under CageFS. If you need a full view of the machine and root access, a VPS is the right product instead.

What you see from inside the cage

Your home directory is real and fully usable for your sites and data. PHP, cron, and SSH sessions run against a reconstructed /etc, a limited /proc, and a trimmed /usr with the binaries you are allowed to use. Mail delivery, MySQL sockets, and PHP handlers are still provided in a controlled way. You are not locked in an empty environment; you are limited to a safe view of the system. A script that expects /etc/passwd to list every user on the server will only see a small fake list, which is intentional.

LVE works alongside CageFS. LVE limits CPU, RAM, I/O, and process counts, while CageFS limits what files you can see. Together they keep one busy or compromised account from reading or starving the next. They do not stop you from harming your own files. A webshell running as your user still runs as you, inside the cage, with access to your own content.

What CageFS does not protect

CageFS is not a reason to set directories to chmod 777. It is not a web application firewall, and it is not a backup system. It will not block a plugin that blindly evaluates POST input, and it will not hide a phpinfo.php file you leave in public_html. What it does stop is walking into /home/someoneelse and reading that account’s data.

Practical limits for scripts and migrations

If a vendor script must write under /usr/local, it is the wrong fit for shared hosting. Keep installs under your home directory instead. If a migration guide tells you to edit /etc/hosts for the whole server, use the account’s local view or move to a VPS. Backup habits still matter inside the cage: JetBackup sees your account, not your neighbor, which is the other half of isolation.

SSH inside CageFS sees the same limited /etc. That is why installers that grep /etc/passwd for every user look broken even though they are behaving correctly. WP-CLI, Composer in your home path, and cron PHP all run jailed. Jobs that need direct access to /var/lib/mysql files belong on a VPS; on shared hosting you use the socket you were given. Tools that demand root filesystem snapshots also belong on a VPS, not in a ticket about CageFS blocking backups.