File browser
Browse the files on a SphereFiles volume from the console. Browse the directory tree, upload files in, download files out, create folders, rename and delete, pack a folder into a .tar.gz archive and unpack one — without rebuilding your service or opening a terminal on it.
/uploads
/var/db
/backup.tar.gzThe file browser isn't a separate storage product. It's the operations surface on top of SphereFiles: the same volume your services mount at the path you chose, browsed through the console (or the API) when you need to put something on it, get something off, or reorganize what's there.
When to reach for it
| Situation | Why the file browser fits |
|---|---|
| Load seed data | Upload fixtures or a SQL dump your app imports at start. |
| Get logs / artifacts out | Download log files, generated reports, or model checkpoints without setting up SCP. |
| Restore from a backup | Upload a .tar.gz from your local machine; the file browser can extract it into place. |
| Snapshot before a risky change | Tar a directory inside the volume, download it, keep it around. |
| Clear stale uploads | Delete a folder full of caches or old user uploads without redeploying. |
| See what's on the volume | Browse the tree instead of guessing what your service wrote where. |
If you need to add or remove a managed datastore (SphereDB, SphereCache, SphereQueue), see those pages — the file browser only deals with raw files on a SphereFiles volume.
What you can do
The file browser exposes one operation per file-system action you'd normally run with a shell:
| Action | What it does |
|---|---|
| List | Directory listing for a path on the volume. |
| Storage usage | Used / total / available bytes for the volume. |
| New folder | Create a directory at a path. |
| Upload | Push a file from your machine to a path on the volume. |
| Download | Pull a file from a path on the volume to your machine. |
| Rename | Rename a file or folder. |
| Delete | Delete a file or folder. |
| Details | Read file metadata (size, permissions, timestamps). |
| Tar | Archive a directory into a .tar.gz on the volume. |
| Untar | Extract a .tar.gz (already on the volume) into a directory. |
The console wraps these in a file-browser UI; the API exposes each as a POST endpoint.
Use it from the console
- From the environment's options menu, choose Storage management.
- Open the volume you want to browse.
- Under Files, choose Browse files.
- The first time, the file browser takes a few seconds to start (Starting the file browser…).
- Each file and folder has an actions menu: a file's has Download, Rename, Extract (for a
.tar.gz), Details and Delete; a folder's has Compress, Rename, Details and Delete. Changes are written straight to the volume, and every service that mounts it sees them.
The file browser stops when it's idle, at no cost.
Use it from the API
File browser operations live under /v2/spherefiles/*, scoped by spherestor_id and environment_id. spherestor_id is the volume's ID (the field keeps its original name). Most are a POST with those in the body; a download, and a transfer's status, are a GET with them in the query string. Large files go through transfers (below).
Get an API token from Settings → User tokens in the console — see API keys. If your user belongs to more than one account, send x-account-id: <ACCOUNT_ID> to disambiguate.
How it works
File browser operations don't run inside your service. The file browser runs on its own in your environment while you use it, with the volume mounted read and write.
- Your service can keep running while you upload, download, tar, or restore. Your services see the volume at their mount paths; the file browser sees all of it.
- It stops when it's idle, at no cost.
- Files up to 32 MiB stream through the ComputeSphere API. Large files go through a short-lived signed transfer: the file is staged in the region's transfer storage and copied to or from the volume, and the staged copy is kept at most a day.
Limits
- One volume at a time. Each file browser session works on one volume. To move files between volumes, download then upload, or tar then untar across two sessions.
- Two writers on one file still race. The file browser writes to the same volume your services mount. If a service might write the same file at the same moment, pause it or use another folder, and stop the services that write there before a large restore. See Several services writing at once.
- No file-level versioning. Renaming or deleting is immediate. To keep history, tar before you change things.
- Tar runs synchronously. Large archives take real time and the call doesn't return until they finish. For multi-GB archives, prefer a background job that calls the tar endpoint and checks completion.
- No symlinks out of a volume. A symlink that points outside the volume's root is rejected on creation/restore.
What's next
- SphereFiles — the volumes the file browser browses.
- Spherelets — the compute units that mount SphereFiles volumes at runtime.
- Environments — where SphereFiles volumes live.