Site files

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.

The site root

The breadcrumb always starts at site root and can't go above it. The root is the site's docroot:

The <slug> is the site's own directory name, so several sites can share one instance without ever sharing a tree.

The manager opens at the site directory, which holds releases/, shared/ and the current link. Application code is one level down, under current — that link points at the release serving right now, so editing through it edits the live site. Anything that must survive the next deploy belongs in shared/ instead of in a release.

These are the real served files, not a copy.

Available actions

• 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 files and Upload a folder put files into the current folder, up to 2 GB each by default.
• Download — saves a file to the local machine; a folder downloads as a tar.
• New folder — creates a folder in the current one.
• Rename and Duplicate — both stay inside the site root.
• Extract archive here — unpacks an uploaded archive in place, so a plugin or theme zip never has to go through an uploader that may be the thing that is broken. The archive is inspected before a byte is written and a hostile one is refused whole.
• Delete — removes a file or folder (asks first).

The guarantees, in plain terms

• A 2 GB per-file upload cap by default, enforced on the server the moment the byte count crosses rather than as a silent stall. It is a policy number and an operator can move it.
• 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.

The two cards below the file list

The file list shows each entry's owner and mode — the owner:group and the octal an ls -la would report. Two cards sit below it and answer the questions the list itself cannot.

• File ownership — the list shows what an entry's ownership is; this says whether that is what the site's type contracts for, names every entry that differs, and repairs them. It is the card to reach for when a plugin install ends in Could not create directory or WordPress starts asking for FTP credentials.
• Upload limits — the manager can move bytes; this says which of the four stacked ceilings — edge proxy, web server, PHP, destination writability — is the one actually saying no.

Neither runs on its own. Both execute inside the live instance, and opening the file manager is not consent to run I/O across a production docroot. The same pair appears on a WordPress site's WordPress tab, beside the limits and the plugin installs they explain.

What is intentionally NOT here

• No access to the panel server. The panel server's filesystem, another site's files, and anything outside this site's root are all unreachable.
• 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 — browsing and downloading still work, but the Add card and per-row Delete are hidden.