Recipes
Self-contained, runnable scenarios for the patterns developers actually ship. Every recipe is grounded in K3’s real surface — no aspirational APIs — and authenticates with a Dodil API key (issue one with dodil auth apikey issue; see CLI Basics → API keys).
What’s here
| Recipe | When you need it |
|---|---|
| Direct-from-browser upload | Let logged-in users upload files straight to K3 from your frontend, without proxying bytes through your backend |
| Multipart for large files | Files over ~100 MB — resumable, parallelizable, and required past the 5 GB single-body cap |
| Share a public bucket | Hand out permanent, unsigned URLs to a whole bucket instead of minting one presign per download |
| Static site / asset hosting | Serve public assets (downloads, logos, build outputs) from K3 without minting presigned URLs |
| Mirror from AWS S3 | One-shot or ongoing copy from an existing AWS S3 bucket into K3 |
Conventions used in these recipes
- Two endpoints, and they are not interchangeable. Your own authenticated traffic goes to the S3 wire
https://object.uk-lon-1.dodil.io, which demands a credential on every request. Anonymous reads of a public bucket, and per-bucket CORS, are served only by the control-plane routehttps://api.data.dodil.io/orgs/<org>/<bucket>/<key>. - Bucket names use the placeholder
kb-prod— replace with your real bucket. - Credentials use the
<access_key_id>/<secret_access_key>pair from your Dodil API key. See S3 Compatibility for what goes in each field. - Path-style addressing is required everywhere —
forcePathStyle: truein the JS SDK,addressing_style: "path"in boto3.
See also
- Object Storage — the storage engine overview
- Quickstart — first object in 5 minutes via
dodil data - S3 Compatibility — client setup tabs + full compat matrix
- CLI Guide — every
dodil data objectcommand - API Reference — gRPC + HTTP admin contracts