S3-compatible object storage is a storage model that keeps files as objects in buckets and exposes them through an API compatible with common Amazon S3 workflows.
For developers, the architectural value is separation. Application compute can be rebuilt, resized, or multiplied without making one VM disk the permanent home for uploads, backups, exports, media, or archives. Raff Technologies supports more than 3,000 customers and 15,000 VMs, and a recurring infrastructure pattern is that durable files become easier to protect once their lifecycle is no longer tied to one server.
This guide is the connector for Raff’s Object Storage & S3 cluster. It explains when S3-compatible object storage fits, when a VM disk or block volume is the better choice, and which deeper decision to make next. Use App Uploads: VM Disk vs Object Storage for customer-file architecture, S3 Bucket Security for credentials and private access, and S3 Lifecycle Policy for retention and cleanup decisions.
S3-compatible object storage separates files from server lifecycle
Object storage organizes data as objects rather than as blocks on a mounted filesystem. Each object is addressed by a key inside a bucket and is read or written through API operations.
The S3-compatible part matters because the S3 API has become a common interface across developer tools, SDKs, backup software, and cloud applications. In practice, a compatible service can often be used by changing credentials and the endpoint rather than redesigning the application’s entire file workflow.
That does not mean every S3-compatible provider implements every Amazon S3 feature. Core object operations may be compatible while identity, policy conditions, versioning, lifecycle automation, object lock, replication, logging, or storage classes differ. Treat S3 compatibility as API portability, not automatic feature parity.
The storage boundary is also different from a normal disk:
Application ↓ S3 API ↓ Bucket ↓ Objects: uploads / backups / assets / archives
The application can keep structured metadata such as ownership, status, and object keys in a database while the binary file body lives in object storage.
The decision framework starts with access pattern and lifecycle
The strongest object-storage decisions come from asking how the data is accessed and how independently it should live from compute.
| Requirement | Better default | Why |
|---|---|---|
| Operating system, packages, app runtime | VM disk | Requires normal local filesystem behavior |
| Temporary processing or scratch files | VM disk | Short-lived local access is simplest |
| Database data directory | VM disk or block volume | Databases expect block/filesystem semantics |
| Mounted application data | Block volume | Software needs a filesystem path |
| Customer uploads and media | Object storage | Files should survive app-server replacement |
| Backups and database dumps | Object storage | Recovery copies should leave the source server |
| Static assets and build artifacts | Object storage | API-based durable distribution fits well |
| Logs and long-term archives | Object storage | Retention can scale separately from compute |
| Generated reports and exports | Object storage | Files can outlive the job that created them |
| Two or more app instances need the same durable files | Object storage | Avoids synchronizing local upload directories |
A useful rule is: choose object storage when file data should scale, survive, or be accessed independently from the server that created it.
Choose VM disk when the data is local, temporary, reproducible, or tightly coupled to the server runtime. Choose block storage when the application needs a mounted filesystem, low-latency block access, or software that cannot speak an object API.
For the full three-way decision, use Object Storage vs Block Storage vs VM Disk.
The strongest developer use cases are durable file workloads
Object storage is most useful when the workload is file-like but does not require ordinary filesystem semantics.
User uploads and media
Images, PDFs, attachments, videos, documents, and generated files quickly become production data once users depend on them. Storing them separately from application compute makes VM replacement and horizontal scaling easier.
The deeper question is not only where the file sits. It is how the application stores ownership metadata, authorizes access, handles deletion, and migrates existing local files. App Uploads: VM Disk vs Object Storage covers that architecture.
Backups and database dumps
A backup stored only on the same VM that created it shares too much of the same failure boundary. Object storage is a practical destination for database dumps, configuration archives, backup-tool repositories, and exported recovery artifacts.
Object storage is still only a storage target. Backup frequency, retention, recovery objectives, and restore testing remain separate decisions.
Static assets and build artifacts
Frontend bundles, documentation files, downloadable assets, release packages, and CI/CD artifacts can live outside the build runner or application VM. This keeps deployment infrastructure disposable without making release files disposable.
Reports, exports, logs, and archives
Generated CSV files, invoices, analytics exports, historical logs, and audit archives often need durable retention but not low-latency block I/O. Object storage gives those files their own capacity and retention boundary.
Service-to-service file handoffs
One worker can write an object and another can process it later without sharing a mounted disk. This pattern works well for batch files, media processing, report generation, and other workflows where the handoff itself is a durable object.
Object storage is the wrong fit for mounted-disk workloads
S3-compatible storage is not a universal replacement for disks.
Do not use it as the default location for:
- an operating system or boot volume;
- a database data directory that expects block I/O;
- software that requires POSIX filesystem behavior;
- active swap or memory-backed workloads;
- low-latency scratch space that is constantly rewritten;
- applications that assume atomic filesystem operations unavailable through an object API.
A common architecture mistake is choosing object storage only because the data is “a file.” The better question is whether the software needs a filesystem or an object API.
Another mistake is moving tiny, short-lived temporary files to object storage when local disk already provides the right lifecycle. Separation has value only when it solves a real durability, scaling, sharing, recovery, or operational problem.
If an application needs more mounted capacity without changing CPU or RAM, Block Storage Volumes is the more relevant path.
Security, retention, and uploads deserve separate decisions
Once object storage becomes production infrastructure, three decisions should not be buried inside a generic storage guide.
Access and bucket security. Production buckets should begin from a private-by-default model, with credentials scoped to the workload rather than reused across every environment and application. S3 Bucket Security covers credentials, policies, presigned URLs, exposure, and recovery boundaries.
Retention and cleanup. Deletion rules should follow the business value of the object, recovery requirements, and the provider’s actual feature set. S3 Lifecycle Policy separates lifecycle automation, retention, versioning, backup, and application-managed cleanup.
Application uploads. Durable customer files need an ownership model in the application, not just a bucket. App Uploads: VM Disk vs Object Storage covers metadata, private delivery, migration, and when local uploads stop being the right default.
A practical operating baseline is to separate at least 2 environment boundaries: production and non-production. Split credentials or buckets further when workloads have different owners, exposure, delete rights, retention rules, or recovery requirements.
The connector decision is therefore simple: first decide whether object storage is the right abstraction; then make security, retention, and application-data decisions independently.
Raff Object Storage uses standard S3 workflows
Raff Object Storage is S3-compatible and is designed for API-addressed files such as backups, media, static assets, uploads, and archives. Current public product information supports common S3 tooling including AWS CLI, Boto3, AWS SDKs, rclone, Cyberduck, and s3cmd, using the Raff S3 endpoint.
The canonical pricing reference is $7/month for the first 100 GB, with additional storage at $0.07/GB-month and egress at $0.01/GB. Review the live pricing page before making a budget decision because product pricing and included allowances can change.
For feature planning, verify the current product controls rather than assuming full AWS S3 parity. Raff’s current FAQ documents common S3 workflows such as multipart uploads, presigned URLs, bucket policies, and ACLs, while native versioning, lifecycle rules, and object lock are not currently supported. That means retention requirements should be checked against the current platform before an application depends on provider-managed lifecycle automation.
A common Raff architecture looks like this:
Raff VM or application runtime ↓ Database = metadata and ownership ↓ Raff Object Storage = durable file bodies
The practical infrastructure insight is to keep compute replaceable. If a VM cannot be rebuilt because it contains the only authoritative copy of customer files or backups, the file layer is controlling the compute lifecycle.
Product and pricing details verified: 2026-08-10.
Conclusion: keep durable files independent from replaceable compute
S3-compatible object storage is the right abstraction when data is file-like, durable, API-addressed, and should live independently from one server. It is a strong fit for customer uploads, backups, media, static assets, reports, build artifacts, logs, archives, and file handoffs between services.
Use a VM disk for local runtime and temporary data. Use a block volume when software requires a mounted filesystem. Use object storage when the file lifecycle should be separated from compute, especially once files must survive rebuilds, support multiple app instances, or grow for storage reasons rather than CPU or RAM reasons.
Continue with App Uploads: VM Disk vs Object Storage, S3 Bucket Security, or S3 Lifecycle Policy based on the next decision you need to make.