This page is a tour of the primitives that make up BlobHub. Read it top to bottom and you will have a complete mental model of how the platform is organized.Documentation Index
Fetch the complete documentation index at: https://docs.blobhub.io/llms.txt
Use this file to discover all available pages before exploring further.
Organizations and Blobs
A Blob is the central primitive in BlobHub. It represents a typed, versioned unit of data that users store, evolve, and interact with. Blobs are grouped into Organizations. An Organization is both a container and an access boundary — it owns a collection of Blobs and defines who can see or modify them. Every Blob has a stable identifier, an owning Organization, a Blob Type, and a sequence of Revisions that record how the Blob has evolved over time.Blob Types
The Blob Type chosen at creation time determines a Blob’s internal data structure, its storage semantics, and the set of operations available on it. BlobHub currently offers three primary Blob Types:- Workflow Blobs describe and execute component-based backend workflows, with sessions, executions, and real-time execution events.
- Scheduler Blobs hold collections of time-based schedules that trigger workflow executions — either once or on a recurring cron cadence.
- ONNX Blobs host Open Neural Network Exchange machine learning models, with secure multipart upload and presigned downloads.
Revisions and the Revision Lifecycle
A Revision is a point-in-time checkpoint of a Blob. Every meaningful change to a Blob produces a new Revision, and every Revision moves through the same three-stage lifecycle.- Draft — the Revision is open for edits. Most write operations target Drafts.
- Commit — the Revision’s content is frozen and becomes immutable, but it is not yet a published version.
- Snapshot — the Revision is published and becomes a stable, addressable version of the Blob that other systems can safely depend on.
Metadata
Both Blobs and Revisions can carry Metadata — arbitrary key/value records attached to the object. Metadata is a first-class concept with its own operations (create, resolve, get, update, delete) and is useful for tagging, categorization, and storing integration-specific state alongside a Blob or Revision.Access Control
BlobHub offers flexible privacy controls layered on top of Organizations and Blobs.- Private Blobs are visible only to designated members and API key holders.
- Public Blobs are visible to all BlobHub users.
- Members grant individual users access to an Organization or a specific Blob.
- API Keys grant programmatic read/write access — scoped to an Organization or an individual Blob.
- Credentials are stored secrets that Blobs (for example, Workflow components) can reference when calling external systems.
Workflow Primitives
Workflow Blobs introduce a small set of additional primitives that describe how workflows are defined and executed.- Definition — the JSON blueprint describing the components of a workflow and the connections between them. Stored as the content of a Workflow Blob’s Revision.
- Session — a stateful context in which a Definition runs. Sessions hold shared state, uploaded objects, and a history of executions.
- Execution — a single invocation of a Definition inside a Session.
- Execution Events — the real-time stream of events emitted while an Execution runs. Events can also be observed at the Session level via Session Events.
Scheduler Primitives
Scheduler Blobs hold collections of Schedules that trigger workflow Executions on a time-based cadence.- Schedules are either one-time (fire once at a specific instant) or recurring cron (fire repeatedly based on a cron expression).
- Every Schedule carries an IANA timezone and optional start/end date windows.
- Each Schedule retains a history of past firings and their outcomes.