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

​
Goal

Choose S2 for general-purpose application storage and understand the controls available beyond basic upload and download.

​
Prerequisites

  • A StackShift account and API token
  • An S3-compatible client for object operations

​
Workflow

1
Create a logical S2 bucket through the StackShift control plane.
2
Save the bucket-scoped access key and one-time secret securely.
3
Point an S3-compatible client at the endpoint and region returned by the API.
4
Use object keys and prefixes to organize content inside the bucket.
5
Monitor usage against the storage quota included in the customer plan.

​
What S2 provides today

  • Multiple tenant-isolated logical buckets with private visibility by default.
  • S3 Signature Version 4 authentication with bucket-scoped access keys.
  • PUT, GET, HEAD, DELETE, copy, bulk delete, prefix listing, delimiter-based folder views, object tags, and byte-range downloads.
  • Multipart upload initiation, part upload, completion, and abort for larger objects.
  • Presigned GET, PUT, HEAD, and DELETE URLs plus expiring prefix-scoped credentials.
  • Version restore, lifecycle rules, retention rules, CORS, and static website settings.
  • Managed object events, access logs, usage analytics, inventory exports, and object catalogs.
  • Bucket-level server-side encryption defaults: none, StackShift-managed sse-s2, or platform-managed sse-kms.
  • Per-plan storage and object quotas plus gateway request-rate limiting.

​
Buckets, prefixes, and objects

A bucket is the isolation and credential boundary. Inside it, every object has one string key such as customers/42/avatar.webp. The slash has no filesystem meaning; clients show folders by listing with a prefix and / delimiter. Bucket names use lowercase S3-style naming. Choose a stable globally unique name because the current management API does not rename a bucket in place.

​
Two compatible interfaces

Use the S3 endpoint for object traffic from applications and standard S3 clients. Use the StackShift control-plane API, dashboard, CLI, or Terraform provider to manage buckets, credentials, policies, events, analytics, and other S2 platform features. The endpoint and signing region returned with a bucket are the source of truth for client configuration. S2 keeps the customer contract stable while StackShift manages the storage service behind it.

​
Not the Assets product

Use S2 when software needs a general S3-compatible object store. Use Assets when you need the account-scoped media workflow: upload sessions, transformations, moderation, DAM metadata, collections, delivery policy, and asset-specific lifecycle controls.

​
Expected result

You can choose the right S2 features for application files, generated artifacts, static content, protected downloads, and data workflows.

​
Common failures

  • Using an Assets API bucket as an S2 bucket. Assets and S2 have separate APIs, credentials, and lifecycle models.
  • Treating prefixes as real directories. S3-compatible object stores keep flat keys and derive folder views from delimiters.
  • Calling AWS-specific extensions outside the documented S2 compatibility surface. Use StackShift management APIs for S2 platform features.

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.

S3 operations and presigned access

Use the supported S3 operations, conditional requests, object metadata, tags, multipart uploads, and presigned URLs.

Access keys, encryption, isolation, and quotas

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

StackShift Assets

A grounded guide to Assets storage, uploads, delivery, imports, BYOB and S2, transformations, OCR, media processing, AI jobs, and DAM controls.