Skip to main content
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.

​
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.
See Blob Types for the full reference of each type.

​
Revisions and the Revision Lifecycle

A Revision is a point-in-time checkpoint of a Blob. A Blob has exactly one default Revision at any time — the word default names it wherever a Blob is named — and at most one draft, which is always the default. A draft is the only Revision that runs; a committed Revision is frozen, both its content and its runtime. Every Revision carries two independent axes: phase, where it sits in its life, and status, whether it is healthy right now. Operations move them separately.
  • draft — open for edits, and the only phase that runs. Most write operations target the draft.
  • commit — sealed: content and runtime alike are frozen. Reopen moves a blob’s own default commit back to draft; nothing else does.
  • managed — a Scheduler Blob’s single Revision, created once and never moved through commit or draft at all.
A failure is recoverable, not terminal. A failed create can be deleted; a failed commit is reset back to draft / ready and committed again — there is no direct retry for a failed commit; a failed delete or discard can be reset and re-issued. Nothing about this locks the Blob itself: the lock is the Revision’s own status, so one Revision’s failure never strands the others. Choosing a Revision other than the default is a client-side preference, not a permanent move — see Delete Revision and Create Revision for exactly what New, Commit, Reopen, Discard, Delete and Reset each require and change.

​
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, an individual Blob, or a User.
  • Service Accounts are users with no human behind them, so a key scoped to one authenticates as a first-class identity instead of borrowing a person’s. See Service Accounts.
  • Credentials are stored secrets that Blobs (for example, Workflow components) can reference when calling external systems.
Read access, write access, and administrative access are all distinguished, and grants can be attached at the Organization, Blob, or User level — the last of which is how Service Accounts authenticate.

​
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.
Playgrounds add an interactive layer on top of Definitions, allowing workflows to be tested and debugged visually from the BlobHub web application.

​
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.

​
Operations

Any long-running action in BlobHub — such as committing a large Revision or uploading a model — is exposed as an Operation. Operations can be polled for status and completion, and are how the platform models asynchronous work consistently across all Blob Types.

​
Putting It All Together

With these primitives — Organization → Blob → Revision, plus the Workflow, Scheduler, and ONNX engines on top — the rest of the BlobHub documentation should feel like a natural extension of what you already know.