STORAGE / OBJECT STORAGE
Consider object storage for media, user uploads and archived data. A useful plan explains how each file is named, which API accesses it, who may read it and how long it should be retained, alongside the application that creates it.
01 / Overview
Object storage treats data as content with a key and metadata. Applications access it through a supported API rather than a local file path. Do not assume that an application expecting a traditional file system can move to this model without integration changes.
Include uploads, private access and sharing in the application design. Verify the service’s API compatibility, file-size conditions and access methods. Features such as versioning, retention locks or a CDN should not be inferred from the general term object storage.
Separate application deployment from file lifecycle decisions. Define how a new application server will access the same data before moving the workload.
Public media and private documents need different policies. Consider reading, uploading and deleting as distinct permissions.
Define naming, metadata and retention from the start. Make it possible to identify abandoned uploads and files that the application no longer uses.
02 / Architecture
Illustrative flow: the application manages files through an API. Object organisation and access rules are designed together; no specific API capability is promised by the diagram.
Selection guide03 / Selection guide
| Consider | How to decide | Why it matters |
|---|---|---|
| Application compatibility | Verify the API operations required by your client software. | An API name does not establish complete feature-by-feature compatibility. |
| Access model | Separate read, write and delete access for each class of file. | Private-data exposure needs to be addressed in the access design. |
| Object organisation | Define keys, metadata, update and deletion rules. | A clear data model supports discovery, maintenance and migration. |
| Traffic and retention | Review access, request and transfer conditions alongside stored volume. | The full cost may involve more than the size of stored files. |
04 / Use cases
Classify images, videos and downloads by size and access frequency. Plan delivery around the application and expected traffic.
Design authentication, file-type validation and post-upload processing. Define permissions that prevent private content from becoming publicly readable by mistake.
Record integrity, access requirements and deletion dates. Treat a stored copy as part of a backup only when a workable restore process also exists.
Plans & pricing
Scroll horizontally to view all columns.
| Storage | $/Mo | Outbound Transfer | Objects / Cluster |
|---|---|---|---|
| 250 GB | $5 | 1 TB | Up to 50 Million |
| 500 GB | $10 | 1 TB | Up to 50 Million |
| 1 TB | $20 | 1 TB | Up to 50 Million |
| 10 TB | $200 | 1 TB | Up to 50 Million |
Review the current configuration, price and order terms before selecting a service.
05 / From planning to operation
Separate public, private and archived content. Document access and retention requirements for each category.
Upload, read and delete representative files. Check timeouts, failed operations and retry behaviour.
Give application credentials only the access they need. Keep keys out of client-side code and public source repositories.
Monitor incomplete uploads, unused objects and unexpected access. Revisit retention and recovery plans as the application evolves.
It is a different access model based on APIs. File-system adapters may exist, but application consistency and performance expectations still need to be tested.
Access depends on the service’s supported controls and your configuration. Define and test read, sharing and deletion rules for private files.
No. Backup requires the right capture, independent retention and a tested restore process. A single stored object does not complete that plan by itself.
Verify the API operations, client version and access methods you need. Capabilities such as versioning or retention locks are available only when supported by the selected service.
Connect product decisions with installation, configuration and operating knowledge.
These references explain the technical concepts discussed on this page. Available configurations and service scope are defined by FibaCloud product and order information.
FIBACLOUD / Object Storage
Tell us about your application, expected usage and operating requirements. Let’s bring the resource choices together.
