thyme upload
Bundle a task and publish an immutable function release in a workspace project. Uploading does not create an executable or activate a schedule.
thyme upload [task] --workspace WORKSPACE_ID --project PROJECT_ID --tag v1| Option | Purpose |
|---|---|
[task] | Task name, or an interactive picker when omitted. |
-w, --workspace <id> | Destination workspace. |
-p, --project <id> | Destination project. |
-t, --tag <tag> | Immutable version label. |
--ci, -y, --yes | Prompt controls; CI accepts confirmations but requires unresolved choices. |
A local Thyme project and valid authentication are required. The command validates the local task name, file, and optional permissions before remote discovery. It uses a matching workspace management credential when available, otherwise the standard configured token or THYME_AUTH_TOKEN.
Archive and metadata
The CLI bundles index.ts with esbuild, extracts argument-form metadata from source, and creates a deterministic ZIP. The archive contains:
| Entry | Contents |
|---|---|
source.ts | Original task entry source. |
bundle.js | Compiled bundle, including bundled imports. |
permissions.json | Optional validated release permission declaration. |
args.json, storage.json, and .env are not included as standalone archive files. Code and resources explicitly imported into a bundle may become part of it; keep secrets out of imports and source.
The SHA-256 checksum covers the ZIP, including any manifest. CLI ZIP timestamps are fixed so unchanged source, bundle, and manifest produce repeatable checksums. Source-schema extraction is best effort and produces a warning when a declared schema cannot be extracted; runtime validation still uses the actual Zod schema.
permissions.json errors stop upload even with --ci or --yes. See permissions.
Immutable tags
New function names default to v1. For an existing name, choose another tag; interactive mode offers a suggestion, while automation should always pass --tag.
- Tags are normalized to lowercase, contain 1–32 letters, digits,
.,_, or-, and must start with a letter or digit.latestis reserved. - The same active name, tag, and archive checksum returns the existing release.
- Changed code or manifest requires a different tag.
- Deleting a release does not free its tag for reuse.
- Existing executables remain pinned to their current function until explicitly switched.
thyme upload monitor --ci \
--workspace WORKSPACE_ID --project PROJECT_ID --tag v2Pause the executable before switching its function version. Review permissions and args, wait for the switch to complete, then resume. See management commands.
Upload API
The CLI uses multipart POST /api/task/upload with Bearer authentication:
data: JSON{ workspaceId, projectId, taskName, versionTag, checkSum, schema? }.blob: ZIP file namedtask.zip.
The backend validates the release and derives supported callback metadata. A successful response is { taskId, versionTag, created }.
| Status | Code | Meaning |
|---|---|---|
| 400 | invalid_version_tag | Invalid or reserved tag. |
| 409 | version_tag_required | Existing name requires an explicit tag; response includes reserved tags and a suggestion. |
| 409 | version_tag_conflict | Tag belongs to different content or is reserved by a deleted release. |
The upload endpoint is separate from the versioned management API. Use thyme functions to list, inspect, copy, or delete releases after upload.