Object storage basics and how to use it
Buckets, keys, S3 compatibility and when to use object storage instead of a disk.
Object storage keeps files as discrete "objects" in "buckets", addressed by key, over an HTTP API. It is how the modern web stores files.
Why not just use the server's disk?
Durability. Objects are typically replicated; a failed disk does not lose your uploads.
Scale. Buckets grow to any size without resizing a server.
Decoupling. The web server becomes disposable — rebuild it and the files are still there.
Delivery. Serve objects directly (or via a CDN) without proxying through your app.
What you get
In /panel/files you can create buckets and access keys. Our storage is S3-compatible, so any S3 SDK or tool works: the AWS CLI, the AWS SDKs, rclone, s3cmd, and libraries in any language.
Use it from the CLI
# Example with the AWS CLI pointed at our endpoint
aws --endpoint-url https://s3.hostingswift.example s3 mb s3://my-bucket
aws --endpoint-url https://s3.hostingswift.example s3 cp ./photo.jpg s3://my-bucket/
aws --endpoint-url https://s3.hostingswift.example s3 ls s3://my-bucket/Access control
Private buckets — objects reachable only with valid credentials. Default for user data.
Public buckets — objects readable by anyone with the URL. Fine for public assets; never for private data.
Time-limited signed URLs — grant temporary access to a private object without making it public. The right tool for downloads and paid content.
Never embed long-lived credentials in client-side code. Use signed URLs instead.
Good uses
Website and app uploads (avatars, documents, media).
Backups — an off-site copy is the whole point.
Static assets — CSS, JS, images, served via a CDN.
Video/audio for on-demand playback.
Not the right tool for
Live databases. Use a real database — see Databases on HostingSwift.
Frequent in-place edits. Objects are immutable-ish; editing means replacing.
A local scratch disk your app reads constantly — latency is higher than local disk.
Related reading