Skip to main content
CloudFS is a POSIX filesystem you mount on any host or container. Once mounted, it behaves like a local directory — read, write, mkdir, rename, git init — but every byte is stored durably in Telnyx Cloud Storage, and the same filesystem can be mounted by many clients at once — a fleet of agents reading and writing it concurrently. You mount it with the open-source JuiceFS Community Edition client (Apache-2.0), which you run yourself — Telnyx does not host or bundle it. JuiceFS has no server process: the client does all the filesystem work and talks directly to a metadata database and to object storage, so no JuiceFS component runs on the Telnyx side. Telnyx provides and authenticates the two managed backends — the metadata database and object storage — and hands you a ready-to-mount filesystem. The target use case is a shared, persistent filesystem for AI agents: provision one CloudFS, mount it once, and every file, repo, and checkpoint an agent produces is there — and still there on the next mount, from anywhere.
Do not touch the cloudfs-fs-* bucket directly. A CloudFS filesystem’s data lives in a bucket named cloudfs-fs-<hex> inside your own Telnyx Cloud Storage account — it appears alongside your other buckets and is reachable with your API key. Its objects are opaque JuiceFS blocks (chunks/… plus internal bookkeeping), not your files. Deleting, renaming, or editing objects in that bucket out of band corrupts the filesystem — a missing block is unrecoverable and there is no repair path. Manage a CloudFS filesystem only through the CloudFS API and a JuiceFS mount; treat its bucket as internal, hands-off storage.
CloudFS is in beta. The API surface and behavior may still change as it moves toward general availability.

​
Next Steps