Objects

The Objects engine is S3-compatible, with re-signing for SigV4 / SigV2 and K3 token-based access. It speaks the standard S3 protocol — PUT / GET / HEAD / DELETE / LIST, the full multipart lifecycle, and presigned URLs — so existing S3 tooling works out of the box. Access control and CORS are K3’s own, on the admin plane: the S3 ?policy and ?cors subresources pass through to the storage backend and are never read by K3.

Speak S3 to it. The byte plane is a SigV4 S3 endpoint at object.uk-lon-1.dodil.io — AWS CLI, boto3, and rclone work as-is. See Connect & Adapters and S3 compatibility.

It also doubles as the base storage layer for every other K3 engine: SQL tables persist their Delta Lake artifacts in the bucket, and Vector collections snapshot to S3 as well. Objects is “where bytes live”; the other engines layer meaning, structure, and retrieval on top.

What makes the Objects engine different from plain S3: every upload can flow into an ingest pipeline automatically — vector indexes, warehouses, or custom Scriptum workflows. See Pipelines for that side.

What you can do

Standard S3 PUT / GET / HEAD / DELETE / LIST (including multipart) against the K3 gateway
Bucket creation, S3-style policy (ACL), CORS configuration — on the admin plane
Pre-signed URLs (SigV4, SigV2, K3 token)
Anonymous, unsigned reads of a PUBLIC bucket over api.data.dodil.io/orgs/<org>/…
Drop in existing S3 SDKs and tooling — aws-cli, boto3, @aws-sdk/client-s3, MinIO client, etc.
Auto-discovery into ingest pipelines on upload

In this section

Quickstart — your first bucket, object, and presigned URL in 5 minutes
Core Concepts — buckets, objects, policy, CORS, presigned URLs
S3 Compatibility — credentials, the operation matrix, the honest unsupported list
API Reference — gRPC + HTTP contracts, grouped per resource
CLI Guide — dodil data CLI for buckets, policy, CORS, objects, and mounts
Recipes — browser upload, multipart, public buckets, static sites, S3 mirroring

Objects

What you can do

In this section

See also