Security
How each published site stays on its own address
People will try to upload a file manager, a shell, and a script that reads the directory next door. The current answer is simple: those files are not stored, and there is no interpreter to run them.
Static files are the security boundary
HTML, CSS, and JavaScript run in the visitor’s browser, on the subdomain that served them. They can change that page. They cannot open another site’s folder, because the server never maps their URL onto anyone else’s directory. The account session is a host-only cookie on the apex domain, so the published page does not receive it.
This is weaker than a virtual machine and stronger than a shared public_html. It matches what the product actually runs today.
Uploads are filtered before they land
The server rejects PHP and the lookalike extensions people use when a filter only checks the final suffix. It rejects dotfiles, web.config, and paths that climb upward. It limits size and count. SVG with a script is rejected so a drawing cannot carry executable markup onto a host we control.
Filtering is not a substitute for isolation. Both are in place for the static host. Filtering alone would not be enough if we executed PHP.
Why PHP is not switched on
A PHP file on a shared disk can include files outside the website, open a database, and call out to the network. Sandbox options such as open_basedir fail often enough that they are not the plan. When PHP is offered, each site will run in its own container, with its own filesystem, resource limits, and no network path to the platform or to other sites.
Until that container exists, uploading PHP returns an error. There is no hidden folder where it still runs.
Abuse
A static page can still be used for phishing or harassment. We do not try to pretend the file filter solves that. Reports are reviewed and a site can be suspended, which removes it from public serving.