Namespace Storage
Every Ocalt account has its own private namespace — a self-contained storage space that belongs to that account alone. Nothing inside it is visible to any other account, and nothing outside it is ever visible from within it.
Locations: root, mounted and external
Every namespace has two permanent top-level locations, and one that a script can bind for itself.
/root— always present, on every plan. 1GB by default. Everything your namespace owns lives here, including the reserved areas below./mounted— additional storage alongside root, for keeping bulk data separate from your working files./external— not Ocalt storage at all. A remote file server bound into the namespace for the life of a script withEXTERNAL BIND, after which every path-taking verb reads and writes it exactly as it does the other two. See FTP & External Storage.
/root holds 1GB on every plan. /mounted is sized by plan, and Free has none; the sizes are listed on Quotas & Pricing. A write that would take a location past its size is refused with Storage limit reached. STORAGE USAGE reports what each location holds and its size. Storage and queries are the only resources a plan measures; nothing else is counted.Reserved areas inside /root
Three paths inside /root have special meaning and are managed by the platform rather than treated as ordinary folders.
/root/sites— this is where yourocalt.sitesubdomains live. Each registered subdomain gets its own folder here, named after the subdomain itself. Thesitesfolder and each individual subdomain folder cannot be deleted directly — they are removed automatically when the subdomain itself is deleted from your dashboard. The files inside a subdomain folder, however, are fully yours to read, write, and delete freely./root/db— a reserved internal area used by the platform. It is not visible or accessible through the file manager or any OcaltQL file verb./root/.ql— the namespace’s own working area. Sessions,CACHEentries,REMEMBERkeys,PERSISTENTvalues and job registries are held here, and so are the files the platform makes for a script: aQRimage, a frame taken from a video, and similar results arrive as paths inside it. It is managed by the platform, but it is your namespace’s data, in your namespace, rather than a separate platform allowance. File verbs can read it, which is how a script uses those results. Its files cannot be shared publicly:FILE SHARErefuses them, so copy a file into your own folders first. Changing or deleting what is in it can lose sessions, cached entries and remembered values, so leave its contents to the platform.
The isolation guarantee
Every part of OcaltQL that touches the filesystem — file operations, scripts running in WEBASSEMBLY sandboxes, and pages served from a subdomain — sees the exact same boundary. From inside any of these contexts, /root and /mounted are the entire visible world. There is no path that leads outside them: no access to the real server, no access to other accounts' namespaces, no access to Ocalt's own infrastructure. This is enforced the same way everywhere, with no exceptions per feature.
Working with your namespace
OcaltQL provides a full set of verbs for reading, writing, organising, compressing, and sharing files inside your namespace — covered in detail on the File Manager page.