S3-Compatible Storage Explained: Drop-In Cloud for Your Tools
Most developers have already written the code to talk to S3-compatible storage. They have rclone configs, backup scripts, and CI pipelines that assume an S3-compatible endpoint is on the other end. S3-compatible storage is the standard that lets those tools work with any provider, not just AWS. You swap the endpoint, keep everything else, and move on.
Key Takeaways
- S3-compatible APIs speak AWS Signature V4, so any S3 tool works without code changes.
- You can point rclone, AWS CLI, Cyberduck, and s3cmd at a compatible endpoint with a config change only.
- Compatibility means no vendor lock-in: migrate providers by updating one URL.
- FileGig's VIP tier exposes a full S3-compatible API with virtual buckets and key management.
- Your files stay entirely within FileGig's own infrastructure, with access enforced in real time.
what is object storage
What Does "S3-Compatible" Actually Mean?
S3-compatible means a storage service implements the widely adopted S3 HTTP API: the same URL structure, the same request headers, and the same authentication scheme (AWS Signature V4). Any tool that was built to speak S3 will work against a compatible endpoint because the protocol is identical. The underlying hardware can be anything.
AWS Signature V4 is the authentication layer. Every request is signed with an HMAC-SHA256 hash of the request contents, a timestamp, and your access credentials. The server validates the signature before serving the request. Compatible providers implement the same signing verification, so existing AWS SDKs and tools authenticate without modification.
Photo via Pexels
The Core API Operations You Already Know
Compatible providers support the S3 operations that matter most in practice. That means PutObject and GetObject for uploads and downloads, ListObjects to browse contents, and DeleteObject for cleanup. Multipart uploads for large files are also part of the spec, which is what the AWS SDK uses automatically for objects above a certain size.
If your code uses the AWS SDK for Go, Python (boto3), Node.js, or Java, it already speaks this protocol. You pass a custom endpoint parameter, point it at the compatible provider, and the SDK handles the rest.
rclone setup guide
Why S3 Compatibility Matters More Than Price
Price is easy to compare. API compatibility is what determines whether you can actually switch. If a provider has its own proprietary API, every script, every SDK call, and every third-party integration needs to be rewritten when you want to leave. That is vendor lock-in in its most concrete form.
S3 compatibility breaks that dependency. Your rclone backup jobs, your Terraform state backends, your database snapshot pipelines — none of them need to know or care which compatible provider is on the other end. You update one endpoint URL in your config, rotate credentials, and the tools keep working.
Teams that adopt S3-compatible storage often report that the migration itself is the boring part. The interesting work is already done: the tooling exists, the patterns are established, and the only variable is which provider you trust with your data.
How to Connect Your Existing Tools
Connecting to an S3-compatible endpoint follows the same pattern across every tool. You need four things: an endpoint URL, an access key, a secret key, and a bucket (or virtual bucket) name. Here is how the most common tools handle it.
rclone
rclone is a command-line tool for syncing files to and from cloud storage. It has native S3 support and accepts a custom endpoint. Add a new remote to ~/.config/rclone/rclone.conf:
[filegig]
type = s3
provider = Other
access_key_id = YOUR_ACCESS_KEY
secret_access_key = YOUR_SECRET_KEY
endpoint = s3.filegig.com
After that, rclone ls filegig:your-bucket works the same as it does against AWS. Sync, copy, move, and mount commands all carry over.
AWS CLI
The AWS CLI accepts an --endpoint-url flag on every command. You do not need to change your credentials file format or your bucket operations:
S3 ls s3://your-bucket \
--endpoint-url https://s3.filegig.com
For convenience, set the endpoint in a named profile inside ~/.aws/config so you do not have to pass it on every command.
Cyberduck and s3cmd
Cyberduck is a GUI file browser that supports S3-compatible endpoints through its "Custom Connection" option. s3cmd uses a host_base and host_bucket setting in .s3cfg. Both tools follow the same pattern: provide the endpoint, access key, and secret, and the tool handles the AWS Signature V4 signing automatically.
Cyberduck setup with custom S3 endpoint
How FileGig's S3 API Works
FileGig's VIP tier provides a full S3-compatible API at s3.filegig.com. It implements AWS Signature V4, the standard signing scheme that tools like rclone and s3cmd already use, so your existing clients work without changes. Your files stay entirely within FileGig's own infrastructure, and access is always enforced by FileGig at delivery time.
This design is intentional. Because every request is served by FileGig itself, FileGig can enforce access control, quota checks, and download policies on every request — even when the request comes from an external S3 tool rather than the web dashboard. Your files stay inside FileGig's own infrastructure end to end, so access can be revoked instantly and never depends on a link that keeps working after you've cut it off.
Two Key Types: System Keys and Manual Keys
FileGig separates S3 credentials into two categories based on how they are used.
System keys use the fgi_ prefix. These are generated automatically when a VIP user logs in and are designed for the FileGig Dashboard's own S3 operations. They live in Redis with a time-to-live and are refreshed during active sessions. You will not need to manage these manually.
Manual keys use the fgk_live_ prefix. These are credentials you create in your account settings for use with external tools — rclone, Cyberduck, the AWS CLI, or any other S3-compatible client. They are stored encrypted in the database and remain valid until you revoke them. These are the keys you put into your config files.
how to create S3 API keys on FileGig
Virtual Buckets and the Flat Storage Model
S3 uses buckets as the top-level namespace. FileGig maps this concept to your root folders. Each root folder in your FileGig account behaves as a virtual bucket. Inside a bucket, the folder hierarchy you see in the dashboard corresponds to key prefixes — the same way S3 uses / as a delimiter to simulate folders in a flat key-value store.
This means you can organize files in the dashboard and access the same structure through the S3 API, or create structure through the API and see it reflected in the dashboard. Both views are consistent.
What S3 Compatibility Does Not Guarantee
Compatibility covers the core data operations. It does not mean every AWS-specific feature is available on every provider. Bucket policies written in IAM JSON, AWS Lambda triggers, S3 Object Lambda, and region-specific features like S3 Intelligent-Tiering are AWS-specific. A compatible provider implements the S3 wire protocol, not the full AWS ecosystem.
For the common use cases — backup, sync, static asset hosting, dataset storage, application file uploads — compatibility covers everything you need. Check your specific use case before assuming a niche AWS feature is available.
In our experience reviewing developer workflows, the operations that actually appear in production scripts are a short list: PutObject, GetObject, DeleteObject, ListObjectsV2, and CreateMultipartUpload with its completion and abort calls. A provider that implements these correctly handles the vast majority of real-world workloads.
FAQ
Can I use my existing AWS SDK code with a compatible endpoint?
Yes. Every major AWS SDK accepts a custom endpoint URL as a configuration parameter. You pass the compatible provider's URL, provide the access key and secret, and the SDK handles signing and request formatting identically. No other code changes are needed.
Do I need to change my bucket names when switching providers?
Your bucket names are local to the provider. If you have a bucket called my-backups on AWS, you create a bucket (or virtual bucket) with the same name on the compatible provider and update your endpoint URL. The tool sees the same bucket name at a different address.
Is AWS Signature V4 the same across all compatible providers?
The signing algorithm is standardized. Every compatible provider validates the same HMAC-SHA256 signature format that AWS defined. The credentials themselves (access key ID and secret) are issued by the provider, but the way they are used in signing is identical.
What happens if I exceed my quota with the S3 API?
FileGig's storage service calls the backend quota API on every upload request, even when the request comes from an external S3 tool. If your quota is exceeded, the upload is rejected with an appropriate error code. Your external tool will see this as a standard S3 error response.
Does FileGig support multipart uploads through the S3 API?
Yes. The S3-compatible API on FileGig's VIP tier supports multipart uploads. Tools and SDKs that use multipart for large files — which is most of them above a configurable threshold — work without any special configuration.
The Practical Case for S3-Compatible Storage
S3 set the standard because it worked and developers adopted it everywhere. Today, S3 compatibility is what separates a storage service you can actually use from one that demands you relearn your tools. Your backup scripts should not care who holds the bytes. Your CI pipeline should not break because you changed providers.
FileGig's VIP tier gives you a full S3-compatible API with the access control and quota enforcement that a platform service needs, with every file kept inside FileGig's own infrastructure. If your workflows already run against S3, pointing them at FileGig is a config change, not a migration project.