Skip to main content
Live. This area is documented as current, user-reliable behavior.

​
Goal

Build object workflows against the operations S2 implements and grant short-lived access without sharing long-lived keys.

​
Prerequisites

  • An S2 bucket
  • A bucket access key or StackShift API token

​
Workflow

1
Use the S3 endpoint for normal object reads, writes, listings, copies, tags, and multipart uploads.
2
Attach content headers and custom metadata when the application needs them returned with the object.
3
Use write preconditions and checksums when replacing important keys.
4
Generate a presigned URL for temporary browser, customer, or service access.
5
Use a temporary prefix-scoped key when a client needs several S3 operations instead of one URL.

​
Supported S3-compatible operations

  • ListBuckets, CreateBucket, HeadBucket, DeleteBucket, and GetBucketLocation.
  • ListObjectsV2 with prefix, delimiter, continuation token, and maximum-key controls.
  • PutObject, GetObject, HeadObject, DeleteObject, CopyObject, and DeleteObjects.
  • GET, PUT, and DELETE object tagging.
  • InitiateMultipartUpload, UploadPart, CompleteMultipartUpload, and AbortMultipartUpload.
  • GET, PUT, and DELETE bucket CORS configuration plus browser preflight handling.

​
Object headers and safe updates

  • S2 records content type, cache control, content disposition, content encoding, expiry, custom metadata, ETag, and SHA-256 checksum metadata.
  • Byte-range GET requests return partial object content for resumable downloads and media readers.
  • Conditional writes can reject an overwrite when the current ETag does not match the application expectation.
  • A supplied payload SHA-256 is validated before a write is accepted.

​
Presigned URLs

The control-plane presign operation supports GET, PUT, HEAD, and DELETE. It returns the URL, required signed headers, method, and expiry. The default lifetime is 15 minutes when no value is supplied. Presigned URLs are best for one object operation. Do not expose a bucket secret to a browser or download recipient when a URL can express the same access.
Create a presigned upload

​
Temporary credentials

Temporary S2 keys can expire from one second up to seven days, restrict access to one object-key prefix, and allow only selected operations. Supported operation names are get, head, put, delete, list, and multipart. The secret is returned once. Store it only for the lifetime of the delegated task and revoke the key early when the task completes.

​
Expected result

Applications use standard S3 request signing while temporary consumers receive only the method, prefix, and lifetime they need.

​
Common failures

  • Using a presigned PUT URL without the signed Content-Type header returned by the API.
  • Reusing a URL after its expiry or changing its method, path, query string, or signed headers.
  • Completing a multipart upload with missing, duplicated, or reordered part numbers and ETags.
  • Granting a temporary key a wider prefix or operation set than the client requires.

Create a bucket and connect an S3 client

Create an S2 bucket, capture its one-time credentials, and verify object operations with the AWS CLI.

Access keys, encryption, isolation, and quotas

Operate S2 credentials, encryption, visibility, tenant isolation, request limits, and customer-plan quotas safely.

Versioning, lifecycle, and retention

Protect object history, restore earlier versions, automate aging policies, and prevent protected objects from being deleted too early.