S3-Compatible Object Storage Use Cases for Developers

Introduction

S3-compatible object storage is cloud storage that lets you store files as objects in buckets and access them through the familiar S3 API instead of mounting them like a local disk. For developers, that matters because it creates a clean place for backups, media, logs, static assets, exports, and other file-heavy data that should not live forever on the same VM disk as the application.

This topic matters more than it first appears. A lot of application architectures stay messy longer than they should because teams keep putting every file on the server that runs the app. That works at the beginning, but it becomes harder to scale, protect, back up, and reason about over time. One of the reasons Raff made its object storage S3-compatible is simple: developers already know the tools, SDKs, and workflows, so storage separation should not require learning a new API first.

In this guide, you will learn what S3-compatible object storage actually is, where it fits in a modern developer workflow, which use cases are strongest, and when it is the wrong tool. You will also see how this maps to Raff’s object storage, block storage volumes, and broader infrastructure stack.

What S3-Compatible Object Storage Actually Is

S3-compatible object storage is a storage system where data is stored as objects inside buckets and accessed over an HTTP API. Each object has data, a key, and metadata. Unlike a mounted disk, you do not attach object storage to a server and browse it like a normal filesystem path by default. Your application, script, CLI, or SDK talks to it through API operations such as upload, download, list, and delete.

The “S3-compatible” part is what makes this so practical. Amazon S3 became the de facto object storage interface for a huge amount of cloud software. If a storage service is S3-compatible, you can often use your existing tools with only an endpoint change. Raff’s object storage page explicitly states that it speaks the same S3 API style as AWS and works with AWS CLI, Boto3, AWS SDKs, rclone, Cyberduck, and s3cmd. That sharply lowers adoption friction.

How object storage differs from VM disk and block storage

This is where most developer confusion starts.

A VM disk is the storage that comes with the server and holds the OS, installed packages, app code, and local data. It is close to the compute, simple to start with, and often the first place teams put everything.

Block storage is different. It behaves like an attached disk volume. You mount it to the operating system, format it with a filesystem, and applications interact with it like local storage. It is the right fit when software expects a real mounted disk.

Object storage is different from both. It is not bootable storage, not a mounted operating system volume, and not the right place for a database that expects block-level access. It is best for durable file-like data that should be stored, served, moved, or archived via API.

If you want a deeper storage-model breakdown first, pair this guide with Object Storage vs Block Storage vs VM Disk.

Why developers end up needing object storage sooner than expected

Most teams do not start by saying, “We need object storage.”

They start with a simpler mindset: “We just need somewhere to put files.”

At first, the VM disk is enough. Then the app starts generating uploads, exports, thumbnails, reports, logs, build artifacts, backups, or customer media. Suddenly the application server is carrying too many responsibilities at once. The disk fills in the same place the app runs. Backup strategy gets less clear. Restores become awkward. Scaling the app and scaling the files stop being the same problem.

That is usually the moment when object storage starts making architectural sense.

The developer value is not that object storage is “advanced.” The value is that it helps separate concerns:

• compute runs the application
• the VM disk holds the OS and local runtime needs
• block storage handles attached-disk use cases
• object storage holds API-friendly file data that should outlive a single server instance

That separation is a big step toward a healthier cloud design.

Core S3-Compatible Object Storage Use Cases for Developers

Media libraries and user uploads

This is one of the clearest and most common use cases.

If your application accepts images, PDFs, videos, or user-submitted files, object storage is usually the right long-term home for them. Keeping uploads on the VM disk seems easy until you need more storage, move to multiple application instances, or rebuild the server. Once files are stored in object storage, the application layer and the file layer become easier to manage independently.

This is especially useful for:

• profile images
• product photos
• document uploads
• video libraries
• generated image or PDF assets
• downloadable customer files

Raff’s object storage page explicitly calls out media files and static assets as first-class use cases, which is the right framing because these are exactly the kinds of file workloads that benefit from API-based storage.

Static assets for web applications

Object storage is also a strong fit for front-end build outputs, documentation assets, downloadable resources, and static site files that do not need block storage semantics.

If your application generates or serves large amounts of static content, storing those assets outside the app VM creates a cleaner deployment boundary. It also gives you a more durable home for files that should remain stable even if the application server is replaced or resized.

For developers, the operational benefit is simple: your deployment process becomes less coupled to the server’s local disk.

Application backups and database dumps

Backups are one of the most important developer use cases for object storage.

A lot of teams already understand that backups should exist. Fewer teams think clearly enough about where those backups should live. If a server creates a backup but stores it only on the same VM or same attached disk path, you have not really created much separation.

Object storage is ideal for:

• nightly database dumps
• compressed application backups
• exported configuration snapshots
• backup archives from CI or cron jobs
• retention-based backup history

Raff’s product page explicitly mentions backups as a core use case, and that matches what object storage is best at: large, durable file retention accessed by scripts and automated jobs.

Logs, audit archives, and historical records

Object storage becomes very valuable when you want to keep large amounts of log-like or archive-like data without forcing it onto expensive application storage.

This includes:

• exported application logs
• audit records
• historical reports
• compliance-related archives
• long-term event data
• batched JSON or CSV exports

These files often matter for troubleshooting, governance, or post-event analysis, but they usually do not need to sit on the same high-priority storage path as your app runtime. Moving them into object storage makes the system easier to operate.

Build artifacts and CI/CD outputs

Developers often think about object storage in production terms first, but CI/CD is just as relevant.

Build pipelines generate files all the time:

• release bundles
• container-adjacent exports
• test artifacts
• generated reports
• static build outputs
• deployment packages

Object storage gives those files a durable place to live outside the runner or build VM that created them. That matters if you want artifact retention, later download access, or cleaner automation between build and deploy stages.

Data exchange between services

Object storage is also useful as a neutral file handoff layer between workloads.

Sometimes one service generates a file and another service processes it later. You do not always need a queue, attached disk, or database for that workflow. In many cases, object storage is the simplest coordination layer:

• a job uploads a CSV export
• another service reads and transforms it
• a report generator writes finished files to a bucket
• a customer-facing service exposes those files for download

This is not the right answer for every pipeline, but it is often the easiest durable file handoff mechanism in cloud-native application design.

Generated exports, reports, and customer downloads

Many applications eventually need to generate files for humans, not just systems.

Examples include:

• invoices
• account exports
• analytics reports
• PDF summaries
• ZIP bundles
• generated spreadsheets

These files should usually persist outside the application server that created them. Object storage gives you a clean way to store them, set access rules around them, and deliver them later without bloating the VM disk.

Pre-signed upload and download workflows

One of the most useful developer patterns in S3-compatible storage is the pre-signed URL flow.

Instead of forcing every file upload through the application server, your app can generate a temporary signed URL and let the client upload directly to object storage. The same idea works for secure downloads.

This improves application design because:

• the app handles less file traffic directly
• uploads do not need to stream through your VM
• access can be time-limited and scoped
• the file ends up in the right storage layer immediately

Raff’s FAQ also highlights pre-signed URLs as part of the access-control model for object storage, which makes this a particularly relevant use case on the platform.

Comparison Framework: when to use object storage, block storage, or VM disk

The best storage decision is based on access pattern, not on what feels easiest today.

The simplest rule is this:

• use VM disk for the server itself
• use block storage when software needs a mounted volume
• use object storage when the data is file-like, durable, API-friendly, and should be separated from the server lifecycle

If you are currently deciding between mounted storage and API-based storage, also read Block Storage vs Local Disk.

Best practices for developers using S3-compatible object storage

Treat buckets as application boundaries, not junk drawers

Do not throw every file into one bucket and hope naming conventions will save you later. Buckets should reflect clear workload boundaries where possible: uploads, backups, exports, logs, or environment-specific data.

A simple bucket structure makes automation, permissions, and cleanup much easier.

Keep object storage out of the database when the file belongs in storage

A common anti-pattern is storing large files as database blobs even when they are really just application assets. Usually the better pattern is:

• database stores metadata and object key
• object storage stores the file itself

That gives you a cleaner data model and reduces unnecessary database weight.

Separate production and non-production data

Do not let test uploads and production assets mix casually. Even if the API makes that easy, it is not a good operating practice. Separate buckets or prefixes by environment so access policies, cleanup, and lifecycle management remain predictable.

Use object storage for durability, not as a random cache

Object storage is great for durable files and retrieval workflows. It is not the same thing as an in-memory cache or a low-latency application scratch disk. If the application needs mounted, filesystem-like temporary data, object storage is usually the wrong abstraction.

Build backup flows that leave the VM

If your backup job runs on a VM, make sure the backup artifact leaves that VM. This is one of the clearest wins object storage provides. It is a stronger retention location than the same server disk that created the backup.

For the full protection strategy side of this, also read Cloud Server Backup Strategies.

How this maps to Raff

Raff’s current object storage product is a strong fit for developers because it solves the right problem with a familiar interface.

The current public product page states:

• S3 API compatibility
• endpoint-based access using standard S3 clients
• support for AWS CLI, Boto3, AWS SDKs, rclone, Cyberduck, and s3cmd
• a starting price of $7/month
• 100 GB of included storage
• 1 TB of included egress transfer
• unlimited API requests
• excess storage at $0.07/GB/month
• excess egress at $0.01/GB

That is useful because it keeps the adoption curve low. You do not have to learn a proprietary storage model first. You can pair object storage with a Linux VM on Raff, move uploads or backups out of the server, and improve the storage shape of the application without redesigning the whole stack.

This is also one of the reasons Raff shipped S3-compatible object storage early in its platform direction: it improves a lot of real workloads immediately. Media libraries, backups, exports, and file-heavy apps all benefit from that separation sooner than many teams expect.

Conclusion

S3-compatible object storage is one of the most useful storage layers developers can add once an application starts producing or retaining meaningful file data. It is not a replacement for a VM disk or a mounted block device. It is the right tool when files should be durable, API-accessed, easy to move, and separated from the lifecycle of a single server.

The strongest developer use cases are practical, not theoretical: media uploads, static assets, backups, logs, build artifacts, generated reports, and service-to-service file handoffs. If your current architecture still keeps all of those on the same VM disk as the app, object storage is usually one of the cleanest improvements you can make.

For next steps, pair this guide with Object Storage vs Block Storage vs VM Disk, Block Storage vs Local Disk, and Cloud Server Backup Strategies. If you want to apply these patterns directly, start with Raff’s object storage and review current costs on the pricing page.

Our cloud solutions team sees the same pattern repeatedly: the moment a project starts generating meaningful files, the architecture gets easier to scale and protect once those files stop living only on the VM.