Use Cases & Best Practices
StorageRaya is designed to store and serve data at scale using an S3-compatible object storage model.
This page explains when to use Object Storage, how to use it correctly, and how to avoid common pitfalls. It focuses on usage patterns and operational best practices, not step-by-step configuration.
Common Object Storage Use Cases
🗂️ Static Asset Storage
Typical workloads
- Images, videos, audio files
- CSS, JavaScript, and static website assets
- Public media for applications or CMS platforms
Recommended configuration
- Enable CDN for performance and global delivery
- Restrict file listing unless explicitly required
- Use public read access only for non-sensitive assets
Best practices
- Treat Object Storage as a content origin, not a file server
- Use versioned object naming to avoid cache issues
Avoid
- Storing private or sensitive data in publicly accessible buckets
📦 Application Data Storage
Typical workloads
- User uploads (documents, attachments)
- Application-generated files
- Exported reports or processed artifacts
Recommended configuration
- Keep buckets private
- Access via Access Key & Secret Key
- Enforce access control at the application layer
Best practices
- Separate buckets by environment (dev, staging, production)
- Rotate access keys periodically
Avoid
- Embedding access credentials in frontend or client-side code
🧠 Backup & Archive Storage
Typical workloads
- VM backups
- Database dumps
- Log archives and historical data
Recommended configuration
- No public access
- Clear retention policy
- Dedicated credentials for backup systems
Best practices
- Use Object Storage as a backup target, not a live filesystem
- Periodically test restores to validate backup integrity
Avoid
- Treating Object Storage as a replacement for block storage
🔄 Cross-System Data Exchange
Use Object Storage as a shared handoff point when data needs to move between different systems, teams, or external partners that do not connect to each other directly.
Typical workloads
- Sending files from one application to another system
- Sharing data with external partners or vendors
- Passing build artifacts or exports between pipelines and services
Recommended configuration
- Create a separate bucket for each system or integration
- Use the bucket’s own access key and secret key for that system only
- Clearly document:
- Who owns the bucket
- What data is stored
- Which system is allowed to access it
Best practices
- Do not reuse credentials across different systems
- Treat each bucket as a single-purpose data exchange point
- Remove access or delete the bucket when the integration is no longer needed
Access Pattern Best Practices
Public vs Private Access
- Private by default, expose only when required
- Public access is suitable only for static, non-sensitive content
- Hidden or random-looking URLs are not a security feature. Use access controls and credentials to protect private data.
Credential Management
- Treat Access Keys like passwords
- Rotate credentials regularly
- Use different credentials per application or team
- Reset keys immediately if exposure is suspected
Application Integration
- Use Object Storage via S3-compatible APIs
- Store Access Keys only in backend services or secure servers. Never expose credentials in frontend or client applications.
- Use your application to enforce user permissions and validate requests before allowing access to Object Storage.
Cost & Data Management Best Practices
- Set bucket quotas intentionally
- Monitor storage growth over time
- Clean up unused or obsolete objects
- Use Object Storage for persistent or shareable data, not for short-lived temporary files or intermediate processing output.
- Store temporary or processing files on local disk, ephemeral storage, or in-memory systems instead.
Cost awareness
- Storage grows silently if not monitored
- Unused objects still incur storage cost
Common Anti-Patterns to Avoid
- Using Object Storage as a traditional filesystem
- Making buckets public by default
- Sharing one access key across multiple teams or services
- Do not store sensitive credentials (API keys, passwords, access tokens, or private keys) as objects in storage buckets.
- Deleting buckets without verifying dependencies
Designing a Sustainable StorageRaya Strategy
For long-term stability:
- Create buckets based on application or workload purpose, not just for organizational convenience. This improves security, cost tracking, and operational control.
- Separate environments and access scopes
- Document ownership and access intent
- Treat deletion as a controlled, irreversible action
Object Storage works best when used intentionally, not incidentally.