cloud

The cloud collection holds first-party, deliberately-trusted blocks — blocks the platform grants capabilities that would be unsafe to hand an arbitrary third-party plugin. Its first members are the upload blocks, which materialize a file you uploaded (through the web UI or spade data upload) as a normal pipeline input.

Trust is granted by provenance: these blocks live in the Spade repository and are authored by the Spade team. That is what earns them their one elevated capability — receiving a short-lived, single-object pre-signed URL for your uploaded asset, minted by the worker at dispatch. The capability is gated by a worker-held allow-list of block names, never by anything a manifest declares, so a third-party block cannot obtain it by imitation.

• Language: Go
• Network: yes (the block fetches the asset over HTTPS)
• Runs: in the cloud only — see Cloud-only below.

Upload blocks🔗

There is one variant per Spade type. All four share a single implementation and differ only in their declared output type; the web UI presents them as a single Upload node with a type dropdown, so you never choose a variant by hand.

The declared type is an assertion about the file you provided — the block passes the bytes through unchanged and never converts formats. The type is chosen at upload time and defaults from the file extension (overridable).

How it works🔗

An upload block has no block inputs. The pipeline stores a stable reference to the asset — its object_key (and asset_id for provenance) — never a URL:

- id: 019cf4bc-1111-7000-0000-000000000000
  name: cloud.upload_raster
  inputs: []
  args:
    asset_id: 019cf4bc-aaaa-7000-0000-000000000000
    object_key: data/019cf4bc-owner-.../.../boundary.tif

- id: 019cf4bc-2222-7000-0000-000000000000
  name: raster.reproject
  inputs:
    - 019cf4bc-1111-7000-0000-000000000000   # consumes the upload's output
  args:
    target_crs: "EPSG:4326"

At dispatch the worker recognizes the allow-listed block, confirms the object_key belongs to the pipeline owner, mints a short-TTL pre-signed GET URL, and writes it into the block's url parameter. The block GETs the URL and writes the file to its output. The URL is a bearer capability that expires quickly and is never logged; a redelivered job simply mints a fresh one.

Downstream blocks consume the upload's output exactly like any other block output, and type matching resolves through the variant's static output declaration.

Cloud-only🔗

Upload blocks run only in the cloud. They depend on the worker minting a pre-signed URL for an object in Spade's user-data storage, which does not exist for a local spade run.

To run an equivalent pipeline locally, replace the upload block with data.read (or data.read_collection) pointed at your local file — it fetches from any URI scheme, including file://:

- id: 019cf4bc-1111-7000-0000-000000000000
  name: data.read
  args:
    uri: "file:///abs/path/boundary.tif"
    format: "GeoTIFF"

data.read's output has the same shape (a single file), so the rest of the pipeline is unchanged. Swap it back to cloud.upload_raster for cloud runs.

Creating an asset🔗

Upload a file and get an asset you can reference:

• Web UI — drag an Upload node onto the canvas, upload a new file or pick an existing one, and connect it downstream. See User uploads.
• CLI — spade data upload boundary.tif. See spade data.