openstead
Databases & storage

Object storage

Store application files in workspace buckets with scoped S3 keys, private downloads and signed links.

Suggest a change

Object storage keeps application files in workspace buckets that your application can access through an S3-compatible endpoint. It is useful for uploads, documents and files shared across services or replicas. It does not mount a filesystem inside your application.

Each workspace includes 1 GiB of object storage. A single object can be at most 64 MiB. Writes that exceed the allowance are rejected; storage overage is not automatically purchased or charged. The console shows the configured quota, current usage and maximum upload size.

Create a bucket and key

  1. Open Object storage in the workspace console.
  2. Create a bucket with a globally unique name: 3–63 lowercase letters, digits and single hyphens.
  3. Keep its visibility private unless every object is intended to be publicly downloadable.
  4. Create a read-only or read-and-write access key for that bucket.
  5. Copy the secret immediately into your server's secret store. It is shown once.
  6. Copy the endpoint displayed in the console and use signing region us-east-1 with path-style addressing.

Creating buckets, keys and uploads requires developer or greater workspace access. A key belongs to one bucket and inherits the current permissions of its issuing user. Read-only keys cannot upload or delete. Expiry, revocation, membership, verified email and workspace two-factor policy are checked when requests arrive.

S3 access keys are separate from Openstead REST API keys. Keep bucket secrets on your server; do not embed them in browser code. Give a browser a short-lived signed URL for the specific operation instead.

Use boto3

Install boto3, then configure these server-side variables from the console:

OPENSTEAD_S3_ENDPOINT=<the exact S3 endpoint shown in Object storage>
OPENSTEAD_S3_ACCESS_KEY_ID=<bucket access key ID>
OPENSTEAD_S3_SECRET_ACCESS_KEY=<bucket secret shown once>
OPENSTEAD_S3_BUCKET=<your bucket name>
import os

import boto3
from botocore.config import Config

s3 = boto3.client(
    "s3",
    endpoint_url=os.environ["OPENSTEAD_S3_ENDPOINT"],
    region_name="us-east-1",
    aws_access_key_id=os.environ["OPENSTEAD_S3_ACCESS_KEY_ID"],
    aws_secret_access_key=os.environ["OPENSTEAD_S3_SECRET_ACCESS_KEY"],
    config=Config(
        signature_version="s3v4",
        s3={"addressing_style": "path", "payload_signing_enabled": True},
        request_checksum_calculation="when_required",
        response_checksum_validation="when_required",
    ),
)
bucket = os.environ["OPENSTEAD_S3_BUCKET"]

with open("report.pdf", "rb") as source:
    s3.put_object(Bucket=bucket, Key="reports/report.pdf", Body=source)

page = s3.list_objects_v2(Bucket=bucket, Prefix="reports/")
for item in page.get("Contents", []):
    print(item["Key"], item["Size"])

link = s3.generate_presigned_url(
    "get_object",
    Params={"Bucket": bucket, "Key": "reports/report.pdf"},
    ExpiresIn=900,
)

Use put_object for a bounded file instead of upload_file or another transfer helper that may start multipart uploads. The checksum settings above avoid optional streaming trailers that this endpoint does not support. For AWS JavaScript SDK v3, use forcePathStyle: true, region us-east-1 and requestChecksumCalculation: "WHEN_REQUIRED"; send PutObjectCommand with a known byte length.

Keep the exact endpoint host displayed in the console. The host is part of its AWS SigV4 signature; changing it after signing invalidates the request.

Supported S3 operations

OperationSupport
PutObject, GetObject, HeadObject, DeleteObjectComplete single objects
HeadBucketVerify access to the named bucket
ListObjectsV2Prefixes, / delimiter, continuation tokens, URL encoding and up to 1,000 keys per page
Signed GET or PUT URLAWS SigV4 query signature, up to one hour

Header-based AWS SigV4 signatures are supported. Payload SHA-256, Content-MD5, CRC32 and SHA-256 checksums are validated. An ETag represents the MD5 of a complete single object.

Multipart uploads, range downloads, object copy, AWS chunk/trailer signatures, object ACLs, temporary AWS session tokens, versioning, object tags and custom encryption selection are unsupported. Use the console to manage bucket creation, visibility and access keys rather than AWS bucket administration APIs.

Object keys may include folders, spaces and percent characters, up to 1,024 UTF-8 bytes. They must be relative paths without control characters, backslashes, duplicate slashes or ./.. segments.

Private, public and signed access

Buckets and objects begin private. You can download private files through the authorized console, an S3 key or a signed link. Console-issued links normally expire after 15 minutes; application-generated links can expire within one hour. Anyone possessing a signed link can use its signed method until it expires, so treat the link as a credential.

A public bucket exposes every object in the bucket, including objects with an individual private setting. Alternatively, make one object public inside a private bucket. Changing current visibility removes future public access, but a download already in progress may finish. Public downloads are served as file attachments; this is not a static website host.

Revoke unused keys and rotate them when an application or collaborator loses access. If a secret is lost, create a replacement and revoke the old key. Removing the issuer or losing required workspace authorization blocks subsequent key and signed-link access.

Quota, replacement and deletion

Usage includes published objects, uploads in progress and files awaiting physical deletion. Replacing a file needs enough free space for the complete replacement while the old file is retained. The new object is published only after its upload succeeds; a failed replacement preserves the previous object.

Delete an object after preserving anything you need. Delete a bucket only after it is empty. Openstead removes access immediately and retries physical deletion asynchronously, so quota can take time to return after removal. There is no customer-facing object undelete or version history. Keep a separate backup for irreplaceable files.

If the console says storage is being configured, new uploads, buckets and keys remain unavailable until its backing connection is ready. An upload error may also indicate a revoked key, incorrect endpoint, unsupported SDK option, file-size limit or exhausted workspace quota.

Choose a persistent disk when the application needs a local mounted directory. Use object storage when multiple services need API access to the same application files.

Need a hand? Contact Openstead support.

On this page