Site files
A site-scoped file manager — browse, upload, download, and edit small files inside the site's docroot, confined to the site root with server-side traversal guards, a 50 MB upload cap, and an audit row on every write.
The Files tab on the site workspace is a small file manager for one site's docroot. It's for everyday edits — fix a config line, drop in an asset, download a file to inspect it — not a fleet-wide file browser. Open the site workspace and the Files tab.
Scoped to one site
This doesn't touch the panel server's filesystem at all. Every action runs inside the instance, on paths under the site root, and you can never browse above that root. One site's file manager can't see another site's files — they're separate containers.
The site root
The breadcrumb always starts at site root and can't go above it. The root is the site's docroot:
| Site type | Site root |
|---|---|
| static / PHP / WordPress | /var/www/html |
| Node | /srv/app |
These are the real served files, not a copy.
What you can do
- Browse — click a folder to go in; the breadcrumb or Up goes back (never past the root). Each entry shows its Kind (file/dir/link) and Size.
- Open / edit a small file — clicking a file up to 1 MB opens it in an inline editor; Save writes it back. Larger files are download-only.
- Upload — Upload a file puts a file (up to 50 MB) into the current folder.
- Download — saves a file to your machine.
- New folder — creates a folder in the current one.
- Delete — removes a file or folder (asks first).
The guarantees, in plain terms
You can't escape the site root
Path safety is enforced on the server, before the request reaches the instance — not in the
browser. Anything that tries to climb out of the site root (a ../, an encoded one, an absolute
path like /etc/passwd) is rejected. A symlink pointing out of the root is caught again inside
the instance. The breadcrumb can't go above the root either, so the guard holds no matter what.
- 50 MB upload cap, enforced on the server (and shown early in the browser). You just pick the file.
- 1 MB inline-edit cap. Larger files are download-only.
- Every write is audited. Upload, edit, new folder, delete, and rename each write an audit row. Browsing and downloading are not audited; writes always are.
What is intentionally NOT here
- No access to the panel server. You can't reach the panel server's filesystem, another site's files, or anything outside this site's root.
- No shell. This is file operations only — not a terminal. For a shell, use the instance console; for SFTP, hand a developer a scoped access key.
- No moving files across sites. Rename and move stay within the one site root.
Permissions
Browsing and downloading need SITES_FILES_VIEW; writes (upload, edit, new folder, delete,
rename) need SITES_FILES_MANAGE. Without MANAGE the tab is read-only — you can browse and
download, but the Add card and per-row Delete are hidden.
Site logs
Tail a site's access, error, and app logs live from the panel — filter/grep client-side, export the window you watched, and resume a killed tail from its exact byte offset with no gap and no duplicate.
Developer access keys
Hand a developer site-scoped SFTP access in two minutes — a per-site SFTP system user inside the instance, confined to the site root, reached via ProxyJump through the node, with a one-line revoke. Never a panel login.