Use the tools you know
Connect aws-cli, rclone, boto3 or another S3 client. Change the endpoint and keys, keep your upload code.
S3 STORAGE · BETA
A home for files.Outside your app.
S3-compatible storage for user uploads, media and backups. Your app can restart and update while files stay in their bucket.
Beta. Keep another copy of critical data. Storage space and traffic are metered.
HOW IT FITS TOGETHER
Files outlive the deployment
Keep uploads and backups outside the container. Rebuilding the app does not remove objects from the bucket.
Choose who can open a file
Use direct URLs for public assets and temporary signed links for private documents.
GET STARTED
From bucket to first upload.
- 01
Create a bucket
Choose a name, project and public or private access. Data is stored on servers in Russia.
- 02
Connect your S3 client
Get the endpoint and access keys in the console. Pass keys to your app as environment variables, not repository files.
- 03
Upload and share
Use an S3-compatible SDK or CLI to upload files. Share public URLs or signed links with limited lifetimes.
Know the limits
S3 buckets are available in Beta. There is no built-in CDN, object versioning or fine-grained IAM policy support yet.
Beta means Beta
Bucket creation and the S3 protocol already work; some capabilities are still being finished. Good enough for backups, static assets and user uploads, not yet for the only copy of critical data.
No built-in CDN yet
Files are served straight from storage. For a Russian audience that is usually enough, but global edge delivery has to be built separately for now.
No object versioning
Overwriting an object replaces it. If you need file history, keep it in dated keys or separate buckets — the platform cannot bring an overwritten object back.
Keys grant access to a whole bucket
Fine-grained Amazon-IAM-style policies are not supported yet. The simpler split is separate buckets per job: public assets, private documents, backups.
Traffic is metered
You pay for the space used and the traffic. Serving heavy video straight to users is a supported case, but it is worth costing out in advance rather than discovering it on the invoice.
Object storage FAQ
What state is object storage in?
It's in Beta. Creating S3-compatible buckets works; some capabilities are still being finished. Don't build critical workflows on it until it's out of beta — it is fine for backups and static assets, not yet for the only copy of important data.
What tools is it compatible with?
The API is S3-compatible, so familiar tools work: aws-cli, s3cmd, rclone, MinIO Client, and SDKs for Python, Node.js, Go and PHP. You point the client at the platform endpoint instead of the Amazon one.
How is it billed?
By volume: you pay for the space actually used and the traffic, not a fixed disk tier. An empty bucket costs nothing and the bill grows with the real data.
Where do I get access keys?
The access key and secret key are revealed in the panel on request — they live in a separate connection secret. They don't belong in the repository: the app receives them as environment variables.
More questions
Can I serve files directly to users?
Yes. Public objects are served over a direct link, private ones over a temporary signed link with a limited lifetime. The second option is what you use for documents and anything that should not be indexed by search engines.
Is it suitable for database backups?
Yes, that is the main scenario. Managed PostgreSQL dumps land in a bucket and are downloaded from the panel over a temporary link. Keeping backups away from the database itself is the rule that saves you when an instance is lost.
Where is the data physically stored?
On servers in Russia. If your app stores files belonging to Russian users, this is the same 152-FZ question as the database — everyone remembers the database, almost nobody remembers the uploads.
Is there a file size limit?
Large files go through multipart upload, which every compatible client supports, exactly as in any S3 storage. For serving large media that is the normal mode, not a workaround.
Can I mount a bucket as the app's disk?
No, and that is deliberate. Storage speaks the S3 HTTP protocol: the app talks to it through a client, not through the filesystem. If you specifically need a disk that shows up as a directory, attach a persistent volume to the app — that is a separate resource.
What happens to files when the app is rebuilt?
Nothing: objects in a bucket live independently of the container. That is exactly why user uploads belong in storage — a container's local disk is wiped on every build, and everything sitting next to the code goes with it.
How do I move files from another S3?
With rclone or aws-cli: point it at both endpoints and sync the buckets directly, without pulling everything down to a laptop. The protocol is the same, so the migration is one command plus the time the transfer takes.