Storage Setup

remoteEaze requires S3-compatible object storage. It does not treat storage as an optional later integration.

The API validates the configured bucket during startup, and browser uploads use presigned URLs directly against the storage provider.

What the app expects

Your storage backend must support:

1. S3-compatible authentication
2. bucket existence and bucket metadata checks
3. presigned upload and download URLs
4. browser uploads from the web app

The current storage plugin uses path-style S3 access, which works well with many self-hosted or compatible providers.

Required variables

See the full descriptions in Environment Reference.

STORAGE_ENDPOINT=
STORAGE_REGION=us-east-1
STORAGE_BUCKET=
STORAGE_ACCESS_KEY=
STORAGE_SECRET_KEY=
STORAGE_PRESIGN_UPLOAD_EXPIRY_SECONDS=300
STORAGE_PRESIGN_DOWNLOAD_EXPIRY_SECONDS=900
STORAGE_MAX_FILE_SIZE_BYTES=52428800

Supported provider model

The app is designed for S3-compatible storage and can work with many providers if they support the required behavior.

Known tested paths:

• SeaweedFS
• Backblaze B2 S3-compatible API

Other S3-compatible providers may also work, but you should validate:

• presigned PUT uploads
• presigned downloads
• bucket lookup
• browser CORS behavior

SeaweedFS

SeaweedFS is a practical self-hosted option when you want local control over object storage.

Recommended references:

• SeaweedFS documentation

Operational guidance:

1. Use the S3 gateway endpoint as STORAGE_ENDPOINT.
2. Create the bucket before starting the API.
3. Use credentials with bucket access to the selected bucket.
4. Keep SeaweedFS on a different machine from the main app host in production if possible.

Backblaze B2 (S3-compatible)

Backblaze works well as a managed S3-compatible backend, but direct browser uploads require correct bucket CORS configuration.

Useful references:

• Backblaze: Getting Started with the S3 Compatible API
• Backblaze: Put Bucket CORS

Backblaze setup checklist

1. Create the bucket.
2. Use the exact S3-compatible endpoint shown by Backblaze for your bucket/region.
3. Create an application key with access to the bucket.
4. Configure bucket CORS for the web app origin.

Backblaze CORS requirements

Because uploads are browser-to-storage via presigned URLs, the bucket must allow the web app origin.

At minimum, allow:

• your web app origin, for example https://remote-eaze.example.com
• methods:
  • PUT
  • GET
  • HEAD
• request headers:
  • content-type
  • or * during initial setup if you want the least-friction configuration

Useful exposed headers often include:

• ETag

Startup failure behavior

If storage is wrong, expect startup or runtime symptoms such as:

• API fails during bucket health check
• upload start succeeds but browser upload fails
• download links are generated but rejected by the provider

Common causes:

• wrong endpoint
• wrong bucket name
• wrong credentials
• bucket not created
• missing bucket CORS rules for browser uploads

Example guidance for common topologies

Managed storage

If you do not want to run storage yourself:

• Backblaze is a reasonable choice
• use the provider endpoint directly
• configure bucket CORS before testing browser uploads

Self-hosted storage

If you want to self-host:

• SeaweedFS is a practical tested path
• provision it separately from the main app host when possible
• confirm the S3 gateway endpoint and bucket are ready before deploying the API

Next step

Once storage is configured, continue with Email and Notifications.