Files and blobs your workflows can keep
Storing a file usually means standing up a bucket and handing out a key that works from anywhere. Here objects live in per-workspace storage, scoped to who you are — reachable from a workflow step, browsable from a console, with downloads that come straight from the store.
Per-workspace object and file storage, scoped by a key derived from your workspace, reachable from a workflow and browsable from a console.
What the object store gives you
- Scoped to your workspace by construction — Every object lands under a key derived from the workspace that stored it, not from anything the request names. There is no field in which to ask for another workspace's location, so the boundary is a property of how the key is built rather than a check a caller has to pass.
- Store and read from a workflow — Put an object away and read it back as an ordinary step on the canvas, with the same run history and error handling as every other node. It is also available to an agent as a tool, so a workflow can keep a file between runs without provisioning anything.
- Browse, download and delete from a console — See the namespaces you have written to, list the objects inside each, download any of them and remove the ones you no longer need — all from a console, with viewing and deleting held apart so reading an object is not the same permission as removing it.
- Downloads come straight from the store — A download is a link minted for that click, so the bytes travel directly from the store rather than being streamed back through the platform. A large file does not have to pass through an API on its way to you.
Platform capabilities
- Per workspace: How every object is scoped
- None: Storage keys you have to hand out
- Step or tool: Ways to reach it from a workflow
Do I have to set up a bucket or an S3 key?
No. The storage runs as part of the platform, so there is nothing to provision, connect or hand a credential out for. You write objects under a workspace namespace and read them back the same way, and there is deliberately no separate key to leak — access always goes through the platform, which scopes it to your workspace.
Can another workspace read my objects?
No. Every object is addressed by a key derived from the workspace that stored it, and a request has no way to name a different workspace's location. The store answers only within your own prefix rather than quietly returning something else, so the boundary is enforced where the data lives.
Can a workflow store and read files on its own?
Yes. The store is available as an ordinary step you place on the canvas and as a tool an agent may call, so a workflow can keep a file between runs and read it back later. Both routes are scoped to the same workspace, so granting the capability does not widen what can be reached.