Storage FAQs
This page covers common and critical questions related to CloudRaya Storage Services, including StorageRaya (Object Storage) and CloudRaya Container Registry (CCR), with a focus on real-world usage, production risks, access pitfalls, billing behavior, and long-term data management.
It is designed for developers, operators, and platform owners who want to avoid unexpected outages, access lockouts, and cost surprises when running storage and container workloads on CloudRaya.
Architecture & Design Decisions
Q: When should I use StorageRaya instead of storing files directly inside a VM or container?
A:
Use StorageRaya when you need data that must survive VM restarts, container redeployments, or cluster changes. Data stored inside a VM disk or container filesystem is tied to that resource. Object storage is designed for shared access, backups, static content, and application data that must outlive compute resources.
Q: Can I use StorageRaya as a database storage backend?
A:
No. StorageRaya is object storage, not block storage. It is designed for files and objects, not for low-latency, transactional workloads. Databases should run on VM disks or managed database services, and use StorageRaya for backups and exports, not as primary storage.
Q: Should I use one bucket or multiple buckets for my application?
A:
Use multiple buckets when you need different access levels, environments, or data lifecycles (for example, prod-assets, staging-uploads, backups). Because access control is applied at the bucket and object level, separating buckets makes security policies and cleanup safer and simpler.
Access & Credential Risks
Q: What happens if I lose my StorageRaya access keys?
A:
StorageRaya access keys are shown only once when generated. If you lose them, you must regenerate new keys and update all applications, scripts, and integrations that use them. The old keys will stop working after rotation.
Q: Can I see which applications are using my StorageRaya keys or CCR credentials?
A:
No. The platform does not track where credentials are used. It is your responsibility to document and manage credential usage across applications, CI/CD pipelines, and Kubernetes secrets.
Q: What breaks if I reset my Container Registry password?
A:
Everything that pulls or pushes images using the old password will fail. This includes:
- CI/CD pipelines
- Docker logins on developer machines
- Kubernetes
imagePullSecrets
You must update all consumers immediately after a reset to avoid deployment outages.
Production Safety & Failure Scenarios
Q: What is the fastest way to accidentally take my production system down using Storage Services?
A:
Deleting a bucket or registry. Both actions are permanent and irreversible. Any application that depends on the data or images inside will fail immediately. Always double-check the project and resource name before confirming deletion.
Q: What happens if my registry runs out of allocated storage during a CI/CD push?
A:
Image pushes will fail. This can block deployments and pipeline runs. You should monitor registry storage usage and resize the allocated storage before reaching capacity.
Q: Can my Kubernetes workloads fail even if the registry is still online?
A:
Yes. If your registry credentials change or imagePullSecrets become invalid, Kubernetes will fail to pull images, even though the registry itself is healthy.
Billing & Cost Control
Q: Why am I still being billed after deleting most of my images?
A:
CCR billing is based on the allocated storage size, not actual usage. Deleting images does not automatically reduce your bill. You must manually resize the registry storage allocation to a lower tier.
Q: Why does my storage bill not drop immediately after I delete data from a bucket?
A:
Storage billing reflects usage over time, not just the current state. Depending on the billing cycle, you may see changes in charges after the next usage calculation period.
Q: What is the most common cause of unexpected storage costs?
A:
Leaving unused buckets, registries, or large backup objects running after test or migration projects. Or forgetting to downsize registry storage after cleaning up images.
Kubernetes & CI/CD
Q: Is StorageRaya a “Kubernetes volume”?
A:
No. StorageRaya is accessed at the application level using S3-compatible APIs. It cannot be mounted as a Kubernetes Persistent Volume.
Q: Should I use the same registry for development and production?
A:
It’s strongly recommended to separate registries or repositories for development and production. This prevents accidental deployment of untested or overwritten image tags into production.
Q: What is tag immutability and why does it matter?
A:
Tag immutability prevents existing image tags (like latest or v1.0) from being overwritten. This ensures that what you deployed yesterday is the same image you pull tomorrow, which is critical for rollback and auditability.
Platform Limits & Quotas
Q: What is the default bucket storage limit?
A:
Each bucket is provisioned with a default storage limit of 20 GB.
This limit is applied to ensure fair resource allocation and platform stability across projects.
If your workload requires more than 20 GB per bucket, you may contact support for limit adjustment or upgrade options.
Q: How many buckets can I create per project?
A:
The current platform limit allows:
- Maximum Buckets per project: 4
This limit is based on the number of resources created, not the size of stored objects.
Governance & Compliance
Q: How do I prove who deleted a bucket or changed registry settings?
A:
All storage and registry actions are recorded in the User Action Log at the platform level.
Q: Can I restrict who is allowed to delete buckets or registries?
A:
No. At this time, all project members have the same level of access to resources within a project. This means any project member can create, modify, or delete storage resources such as buckets and container registries.
The main differences between a project member and the account owner are limited to account-level actions, such as topping up balance, managing account profile information, and accessing user-level services (for example, Manage Services, Marketplace, and DNS Buckets).
Best Practice: To reduce the risk of accidental deletion, use separate projects for production and non-production environments and limit project membership to only trusted operators.
Design Patterns & Best Practices
Q: What is a safe production pattern for storage and registries?
A:
A common pattern is:
- Separate projects for production and non-production
- Separate buckets and registries per environment
- Immutable image tags for production
- Scheduled credential rotation
- Periodic review of the User Action Log
Still Have Questions?
If you can’t find what you’re looking for, you can consult our CloudRaya AI Assistant through the live chat for quick guidance.
For more complex requirements, our support team can help you design a storage and image management architecture tailored to your workload.
📩 Contact Support: support@wowrack.co.id