0.2.23: Fix stale PyPI latest-version summary

The Python CLI upgrade command now selects the highest stable release that PyPI actually lists with a published, non-yanked artifact. PyPI can report an older info.version during package propagation even after a new release appears in its releases index. This prevents stale latest-version reads. The npm client retains the verified official registry metadata endpoint. One-time bootstrap from older CLIs: npm install -g cesiumcloud@0.2.23 --registry=https://registry.npmjs.org/ --prefer-online python -m pip install --no-cache-dir --index-url https://pypi.org/simple cesiumcloud==0.2.23

All upload and download behavior remains unchanged.

0.2.21: Corrected official npm upgrade registry endpoint

Fixed the npm CLI's direct-version lookup to use the verified npm registry dist-tags endpoint. The previously published 0.2.20 upgrade command could encounter HTTP 404 on npm despite the package being available. Both npm and Python use the official registries; the latest published version is pinned before installing. Previously installed older CLIs can bootstrap once with: npm install -g cesiumcloud@0.2.21 --registry=https://registry.npmjs.org/ --prefer-online python -m pip install --no-cache-dir --index-url https://pypi.org/simple cesiumcloud==0.2.21

No other CLI functions or production server configuration changed.

0.2.20: Official-registry upgrade fix

The CLI update and upgrade commands now obtain the exact latest version from the official npm or PyPI APIs, not a stale custom mirror or registry cache. They pin that verified version and install it from the official package registry. Users with older CLI versions can bootstrap once: npm install -g cesiumcloud@0.2.20 --registry=https://registry.npmjs.org/ --prefer-online python -m pip install --no-cache-dir --index-url https://pypi.org/simple cesiumcloud==0.2.20

No transfer behavior changes.

0.2.19: Optional 512 MiB upload experiment

The default single-file upload chunk remains 64 MiB. To test larger chunks, set CESIUMCLOUD_UPLOAD_CHUNK_MIB=512 before running cesiumcloud upload LOCAL_FILE. This opts in to a 512 MiB chunk (536,870,912 bytes) for that process only, on Windows and Linux. Unset the environment variable or set it to 64 to return to the normal chunk size. Batched and folder uploads remain at 4 MiB. Large chunks use more memory and may wait or retry when server memory is occupied. Server-side capacity is bounded to prevent a global memory spike. Upload failure and cancellation still permanently delete partials.

0.2.18: Recursive folder downloads

Use cesiumcloud download FOLDER --location DESTINATION to restore a cloud directory beneath DESTINATION, preserving all nested subfolders, files and explicitly empty folders. The folder keeps its name; when a matching local directory already exists, a numbered new folder is chosen to avoid overwriting existing data. This works on Windows and Linux, and preserves existing single-file downloads, parallel workers, and the full-account --all command.

CesiumCloud v0.2.0

CesiumCloud lets you upload, download, rename, and delete cloud files and folders.

Service: https://cloud.cesiummc.space/app/ API: https://api.cesiummc.space

CLI

Authenticate with cesiumcloud authenticate. Your credentials are local and can be revoked.

• cesiumcloud upload "path/to/file-or-folder"
• cesiumcloud list -a
• cesiumcloud search notes.txt
• cesiumcloud dir images
• cesiumcloud download "restore-directory"
• cesiumcloud download images/photo.png --location "restore-directory"
• cesiumcloud rename old.txt new.txt
• cesiumcloud move old.txt to root/archive
• cesiumcloud delete root/archive/old.txt

Uploads transfer in resumable 64 MiB chunks using a short-lived authorization grant. Individual files can be downloaded, replaced and permanently removed from active storage without rebuilding other files.

JavaScript SDK

const { IsolatedTransferClient } = require("cesiumcloud");
const storage = new IsolatedTransferClient(process.env.CESIUMCLOUD_API_KEY);
await storage.uploadFile("notes.txt", "docs/notes.txt");
const files = await storage.allFiles();
await storage.download(files[0].id, "./restored.txt");
await storage.delete(files[0].id);

Python SDK

import os
from cesiumcloud import IsolatedTransferClient
storage = IsolatedTransferClient(os.environ["CESIUMCLOUD_API_KEY"])
storage.upload_file("notes.txt", "docs/notes.txt")
files = storage.all_files()
storage.download_file(files[0]["id"], "restored.txt")
storage.delete_file(files[0]["id"])

Existing CesiumCloudClient high-level upload and download methods also use isolated file storage.

Optional local encryption

Use cesiumcloud e2ee keygen to generate a local recovery key, and cesiumcloud e2ee upload FILE to encrypt locally before upload. The server cannot recover your key. Keep an offline backup. Encryption protects contents, not filenames or sizes. The .ccenc format is authenticated and cross-platform.

Notes

Deleting a cloud file is permanent. Stopping an upload permanently removes its unfinished data and releases its reservation. Keep offline backups of important files.

Replacement and upload cancellation (0.2.1)

Use cesiumcloud upload --replace "file.txt" (or a folder) to replace a matching virtual path, or create it normally when absent. The SDK accepts replace=True in upload_file and upload_path and has cancel_upload(upload_id). Use cesiumcloud cancel-upload UPLOAD_ID or Ctrl+C on an active CLI upload. Already completed files are preserved. The website's ReplacedFiles history is separate from the CLI flag.

Version 0.2.10

The dir command validates its destination against the authenticated server catalog, including explicitly created empty folders. Deleted and trashed directories are rejected even when another terminal or browser tab still has an old folder view. The server rejects new uploads to invalid directories at both upload admission and file commit.

0.2.11: parallel uploads

Directory navigation remains authenticated against the server, including empty folders, with trashed or deleted destinations rejected. Uploading folders and multi-source selections now defaults to up to 40 simultaneous uploads while preserving account upload limits and ordinary file operations. The first set of 40 uploads is registered and transfers start immediately; subsequent registrations overlap with active transfers rather than blocking on admission for every selected file. Explicit -simultaneous N retains concurrency control, capped at 40 for uploads. Single-file uploads retain their live progress behavior. Incremental aggregate byte counters and throttled terminal refreshes avoid rescanning thousands of entries per update. Unused reservations are cancelled on interruption or partial failure.