S3-compatible storage is object storage that exposes an API compatible with common Amazon S3 operations. Instead of mounting storage as a normal disk, applications store files as objects inside buckets and access them through API calls, SDKs, CLI tools, backup software, or signed URLs.
For developers, the main reason to use it is not simply “more storage.” It is to separate durable file data from replaceable compute. User uploads, backups, media, exports, artifacts, and archives can survive a VM rebuild or application deployment without being tied to one server's local disk.
Raff Technologies provides S3-compatible Object Storage for this model. It is useful when an application needs S3-style workflows without making every durable file part of the VM lifecycle.
The practical rule is:
Use object storage for durable, API-addressed files that should live independently from one server. Use block storage or VM disk when the workload needs a mounted filesystem or low-latency block I/O.
For retention, expiration, version cleanup, and safe deletion design, continue with S3 Lifecycle Policy: Retention, Versioning, and Cleanup.
What is S3-compatible storage?
S3-compatible storage is an object-storage service that implements enough of the Amazon S3 API for common S3 clients, SDKs, and applications to communicate with it.
The basic model is:
Application / backup tool / CLI ↓ S3 API ↓ Bucket ↓ Objects: uploads / backups / assets / archives
Amazon S3 itself stores data as objects inside buckets. An object contains the file data plus metadata, and applications address it by bucket and object key rather than by mounting a normal filesystem path.
S3-compatible providers follow that API model so existing software can often connect by changing the endpoint, credentials, and sometimes region or signing configuration.
That portability is valuable, but it has an important limit:
S3-compatible does not mean identical to Amazon S3.
A provider may support common operations such as PutObject, GetObject, multipart upload, presigned URLs, and bucket policies while not implementing every AWS feature, policy condition, storage class, replication option, versioning feature, lifecycle rule, or Object Lock workflow.
Before migrating a production workload, test the exact S3 operations your application depends on rather than assuming feature parity from the word “compatible.”
S3-compatible object storage vs a normal disk
Object storage and disk storage expose different interfaces.
| Requirement | Object storage | VM disk / block volume |
|---|---|---|
| Access model | API, bucket, object key | Mounted filesystem / block device |
| Best for | Files, blobs, uploads, backups, archives | OS, databases, local app data |
| Shared by several app nodes | Strong fit | Requires another sharing model |
| Survives app-server replacement | Designed for this separation | Depends on disk/volume lifecycle |
| POSIX filesystem semantics | No | Yes |
| Random block updates | Poor fit | Strong fit |
| Direct browser upload workflow | Possible with presigned URLs | Usually app-mediated |
| Typical scaling model | Storage grows independently | Capacity attached to a server/volume |
Do not choose object storage merely because the data is “a file.”
Choose it when the application can work with an object API and when separating the file lifecycle from the compute lifecycle solves a real problem.
For the full storage decision, see Object Storage vs Block Storage vs VM Disk.
The best S3-compatible storage use cases for developers
1. User uploads and application media
Images, PDFs, videos, attachments, profile photos, documents, and generated media are strong object-storage workloads.
The weak architecture is:
User ↓ App VM ↓ /local/uploads
Once that VM is replaced, horizontally scaled, or restored separately, the application must solve synchronization and file recovery.
A cleaner model is:
User ↓ Application ↓ Object storage Database ↓ Stores owner, permissions, object key, status
The database stores structured metadata while the object store holds the file body.
This becomes especially useful when two or more application instances need access to the same durable files.
For the migration and ownership model, use App Uploads: VM Disk vs Object Storage.
2. Direct uploads with presigned URLs
Presigned URLs let an application grant time-limited permission for a client to upload or download a specific object without giving that client permanent S3 credentials.
A common upload path is:
Browser / mobile app ↓ asks for upload permission Application API ↓ returns presigned URL Client ↓ uploads directly Object storage
This can keep large file bodies out of the application server's request path while the application still controls who is allowed to upload and which object key is used.
Amazon S3 documents presigned URLs as a way to grant temporary object access, including uploads, without giving the uploader AWS credentials. Raff's current Object Storage product page also lists presigned GET and PUT URLs among supported S3 workflows.
Presigned URLs are authorization tools, not permanent public links. Keep expiration, object naming, content validation, malware scanning where required, and application-level ownership controls in the design.
3. Backups and database dumps
A backup stored only on the server it protects shares too much of the same failure boundary.
Object storage is a useful destination for:
- database dumps;
- backup repositories;
- configuration archives;
- exported recovery artifacts;
- application-generated backup bundles.
A stronger model is:
Production VM / database ↓ backup job S3-compatible object storage ↓ Separate recovery copy
But object storage alone does not create a backup strategy.
You still need to decide:
- backup frequency;
- retention;
- RPO and RTO;
- encryption;
- delete permissions;
- immutability requirements;
- restore testing.
If a backup policy requires provider-enforced immutable retention, verify that the target supports the required Object Lock or equivalent control before using it. Do not assume every S3-compatible service provides this feature.
4. Static assets and build artifacts
Object storage works well for durable application artifacts that do not need filesystem semantics, such as:
- release packages;
- frontend bundles;
- downloadable files;
- CI/CD artifacts;
- documentation assets;
- generated build outputs.
This separates artifact retention from build runners and application VMs.
However, storing static assets is not the same as providing static website hosting. Some S3-compatible providers support website-hosting features and others do not. Check the product's current compatibility matrix before designing around that feature.
5. Reports, exports, and generated files
CSV exports, invoices, generated PDFs, analytics reports, data extracts, and user-requested downloads often need to outlive the worker or request that produced them.
A useful pattern is:
Background worker ↓ generates report Object storage ↓ Application stores object key/status ↓ User receives controlled download
The worker can be replaced after the job finishes without becoming the long-term storage location for the output.
6. Logs, audit exports, and archives
Long-lived logs and historical archives can consume local VM capacity even though they are rarely read with filesystem-style random access.
Object storage can be a good destination for:
- exported logs;
- audit archives;
- long-term diagnostic bundles;
- historical application files;
- compliance exports where the provider's retention controls satisfy the requirement.
Do not confuse “archive destination” with automatic archival policy. Lifecycle rules and storage classes differ across S3-compatible providers, so retention automation must match the actual service capabilities.
7. Service-to-service file handoffs
Object storage can act as a durable handoff point between application components.
For example:
Upload service ↓ writes object Object storage ↓ object key Processing worker ↓ transforms file Object storage ↓ result object Application
This avoids requiring two services to share the same mounted disk and works well for media processing, batch jobs, imports, exports, and asynchronous document workflows.
Object storage should not replace a queue when the application needs queue semantics such as ordering, retries, visibility timeouts, or consumer coordination. The object is the durable payload; a queue or job system may still coordinate the work.
When S3-compatible object storage is the wrong choice
Object storage is not a universal replacement for VM or block storage.
Do not use it as the default location for:
- an operating system or boot disk;
- a database data directory that expects block I/O;
- software requiring POSIX filesystem behavior;
- swap;
- very low-latency scratch data that is constantly rewritten;
- workloads built around filesystem locking or atomic rename semantics;
- software that cannot use an object API without a fragile translation layer.
If an application needs a normal mounted disk with capacity independent from the VM's root disk, Block Storage Volumes is the more appropriate path.
S3-compatible does not mean full AWS S3 parity
This is one of the most important buying checks.
Two services can both call themselves S3-compatible while supporting different subsets of the API and different surrounding platform features.
Before choosing a provider, identify whether your workload depends on:
- multipart upload;
- presigned URLs;
- bucket policies;
- ACL behavior;
- object versioning;
- lifecycle rules;
- storage classes;
- Object Lock / WORM retention;
- replication;
- event notifications;
- static website hosting;
- exact IAM or policy-condition behavior;
- a specific SDK operation.
Then test those operations against the target endpoint.
For a basic application upload workflow, common object operations plus presigned URLs may be enough. For backup immutability, compliance retention, or complex AWS-native applications, the compatibility requirements are much stricter.
Security starts with private buckets and scoped credentials
Object storage often contains production data, so access design matters as much as storage capacity.
A sensible baseline is:
- keep buckets private unless public access is intentionally required;
- use separate credentials per application or workload;
- grant only the buckets and actions that workload needs;
- do not embed long-lived access keys in public client code;
- use presigned URLs for controlled temporary access where appropriate;
- rotate or revoke credentials when ownership changes;
- separate production and non-production access;
- protect delete permissions more carefully than read permissions when recovery depends on the bucket.
For the deeper security model, use S3 Bucket Security.
Object storage cost depends on more than GB stored
Do not choose an object-storage provider from the storage price alone.
Depending on the provider, total cost can include:
- stored GB-month;
- internet egress;
- API request classes;
- retrieval fees;
- minimum storage durations;
- replication;
- additional feature charges.
The cheapest provider therefore depends on the workload.
A storage-heavy workload with very few requests can favor a provider with a low raw per-GB price. A request-heavy application can favor a different billing model. A high-egress media workload can change the answer again.
Raff's own Object Storage comparison material explicitly notes that AWS S3 and Cloudflare R2 can beat Raff on raw per-GB storage price at larger volumes. Raff's current product model instead emphasizes a bundled allowance, included egress, and no separate per-request fees.
That makes the decision workload-specific rather than “Raff is always cheaper.” Use the live Object Storage and pricing pages for current rates and allowances before making a budget decision.
How Raff Object Storage fits
Raff Object Storage is designed for S3-style file workflows alongside Raff compute products.
The current public compatibility page lists support for common operations including object PUT/GET/HEAD/DELETE, multipart uploads, presigned URLs, ListObjectsV2, bucket policies/ACLs, SigV4 authentication, and tools such as AWS CLI, SDKs, rclone, s3cmd, and MinIO Client.
The same page currently lists several features as not supported yet, including versioning, lifecycle rules/storage-class transitions, Object Lock, cross-region replication, and static website hosting.
Those details can change. Treat the live product page as the source of truth before migrating a workflow that depends on a specific S3 feature.
A common Raff application architecture is:
Raff VM / Raff Apps / Functions ↓ Application logic ↓ Database = metadata, ownership, status ↓ Raff Object Storage = durable file bodies
Use this model when the goal is to keep uploads, backups, assets, exports, or artifacts independent from the server or app process that created them.
If the workload instead needs a filesystem, use Volumes. If it needs a self-managed server boundary, use Raff VM.
