spade data

The spade data command manages user data files — your own inputs (often large geospatial files) that pipelines reference through the platform upload blocks. Bytes are stored in Spade's object storage; a catalog row records the file's name, size, type, and owner. A pipeline references an asset by a stable id, so it can be shared and reused without re-uploading.

These commands talk to your Spade cloud account, so they require a spade login session.

Usage🔗

spade data upload <path> [--name <name>] [--visibility <v>]   # upload a file OR folder
spade data list [--scope mine|shared|public]                  # list files and folders
spade data download <id> [output]                             # download a file or folder
spade data pending                                            # folder uploads started but not finished
spade data abandon <folder-id> [--yes]                        # delete an unfinished folder upload

Uploading🔗

spade data upload streams the file directly to object storage through a pre-signed URL, then records the catalog row:

spade data upload boundary.tif
Uploading boundary.tif (142.3 MB)...
Uploaded. File ID: 019cf4bc-aaaa-7000-0000-000000000000

The printed File ID is the asset_id a pipeline references. Options:

Duplicate uploads are skipped🔗

Before transferring, the CLI computes the file's SHA-256 and asks whether you already own those exact bytes. If you do, nothing is transferred:

spade data upload boundary.tif
Already uploaded as "boundary.tif" (File ID: 019cf4bc-aaaa-7000-0000-000000000000) -- identical contents, nothing transferred.
Use --force to upload a second copy anyway.

The check is scoped to assets you own. Matching someone else's public asset would leave your pipeline depending on something you cannot stop from being deleted or unpublished.

Downloads are verified the same way: when the catalog knows an asset's hash, spade data download checks the bytes against it and discards the file on a mismatch rather than leaving a corrupt file wearing a trusted name. Assets uploaded before hashing existed carry no hash — those downloads are simply unverified, not failures.

The Spade type used to pick the upload block variant (raster/vector/table/file) is defaulted from the file extension when you wire the asset into a pipeline; in the web UI you can override it on the Upload node.

Uploading a folder🔗

Point spade data upload at a directory to store the whole folder as a single asset — one object per file, structure preserved:

spade data upload ./tiles --name "DEM tiles"
Uploading DEM tiles (128 files, 2.1 GB)...
Uploaded. Folder ID: 019cf4bc-ffff-7000-0000-000000000000

The walk includes hidden files (dotfiles) and skips symlinks (for containment) and zero-byte files. Whether the folder is later read as a flattened collection or a structure-preserving directory is chosen when you author the pipeline (see the platform folder blocks), not at upload time — so a folder has no --type.

Folder-specific options:

Large folders: parallel and resumable🔗

Files transfer several at a time, and each one gets its own short-lived upload URL just before it starts, so a big folder is never bounded by one URL's lifetime. If a file fails, the others keep going; at the end the CLI lists what failed and exits non-zero:

spade data upload ./tiles --name "DEM tiles"
Uploading: 61.2 GB / 72.9 GB (84%)  372/418 files  [4 workers]
3 files failed:
  tiles/2021/q3/0412.tif: storage returned 500 after 5 attempts
  ...
Run the same command again to resume. Folder ID: 019cf4bc-ffff-7000-0000-000000000000

Run the same command again and it resumes. The CLI remembers which upload a directory belongs to, asks the server which files already arrived, transfers only what is missing or changed, and removes any object for a file you have since deleted from the folder. The same applies after Ctrl-C.

spade data upload ./tiles --name "DEM tiles"
Resuming folder upload "DEM tiles" (019cf4bc-ffff-…): 415 of 418 files already uploaded (72.4 GB).
Uploading: 72.9 GB / 72.9 GB (100%)  418/418 files  [4 workers]
Uploaded. Folder ID: 019cf4bc-ffff-7000-0000-000000000000

spade data pending shows uploads you started but never finished, and spade data abandon <folder-id> deletes one along with everything it transferred. An unfinished upload is not in your catalog and cannot be referenced by a pipeline until it completes.

Listing🔗

spade data list
ID                                    Name          Kind    Size      Files  Visibility  Created
019cf4bc-aaaa-7000-0000-000000000000  boundary.tif  file    142.3 MB  -      private     2026-07-15 14:02
019cf4bc-ffff-7000-0000-000000000000  DEM tiles     folder  2.1 GB    128    shared      2026-07-16 09:20

--scope selects which assets are shown: mine (default), shared (shared with you), or public.

Downloading🔗

spade data download 019cf4bc-aaaa-7000-0000-000000000000 local.tif

The file streams directly from object storage. If you omit the output path, it is saved under its registered name in the current directory. Downloading a folder asset recreates its directory tree under the output path (or the folder's name):

spade data download 019cf4bc-ffff-7000-0000-000000000000 ./restored-tiles
Downloading DEM tiles (128 files, 2.1 GB)...
Saved 128 files to ./restored-tiles

Referencing an uploaded file in a pipeline🔗

Uploaded files are consumed by the platform upload blocks. In the web UI, use the Upload node (see User uploads) — it wires the asset in for you. For a hand-authored pipeline, reference the asset from an upload block:

- id: 019cf4bc-1111-7000-0000-000000000000
  name: platform.upload_raster
  args:
    asset_id: 019cf4bc-aaaa-7000-0000-000000000000
    object_key: data/<owner>/<file>/boundary.tif

That pipeline runs in both places: in the cloud the worker presigns the asset, and locally spade run resolves it from disk (see Running locally). Going the other way — a pipeline that reads local paths with data.read — is what spade submit is for.