Compute FAQ

This page covers common questions related to CloudRaya Compute Services, including Virtual Machines and KubeRaya (Managed Kubernetes), across scaling behavior, availability, quotas, pricing, and operational limits.

General Compute

Q: What services are included under CloudRaya Compute?

CloudRaya Compute includes Virtual Machines (VMs) and KubeRaya (Managed Kubernetes). Both services share common platform capabilities such as project-based resource organization, aaregional availability, and API-driven automation.

Q: Are compute limits based on resource size or the number of services I create?

Limits are currently based on the number of resources created, not the size or specification of each resource.

This means you can choose any supported VM size or cluster configuration, as long as you stay within the maximum count for each service.

Q: What are the current platform resource limits per project?

Current general limits per project:

Maximum Virtual Machines: 4
Maximum Kubernetes Clusters: 4
Maximum Public IPs: 4
Maximum Disks: 4
Maximum Buckets: 4

For object storage, each bucket has a default storage limit of 20 GB.

These limits are designed to maintain system stability and fair usage across all users.

Q: How can I increase my VM or KubeRaya resource limits?

Resource limits are managed at the account level. To request higher limits, ensure your account profile is complete and verified, including identity information where required. Then contact CloudRaya Support to submit a limit increase request.

Q: How is compute usage billed across different services?

Virtual Machines are billed hourly based on the selected compute specification, additional VM storage, public IP usage (included in some VM packages and charged separately for custom configurations), and additional licenses such as Windows. Charges are deducted from your available balance while the VM is running.

KubeRaya is billed as a cluster-level hourly fee, which includes the number of master and worker nodes.

Q: Can I deploy compute resources across multiple regions or availability zones?

Yes. You can deploy Virtual Machines and KubeRaya clusters in any available CloudRaya cloud zone such as Jakarta, Surabaya, Denpasar, Medan, and Seattle.

At this time, cloud zones are not connected through a private internal network. If you need communication between resources in different cloud zones, you must use public networking, such as public IP addresses.

This approach can be used to design disaster recovery environments, but cross-zone networking and failover must be managed at the application or network layer.

Q: How do I automate compute provisioning?

You can use the CloudRaya API to provision and manage both VMs and KubeRaya clusters programmatically.

Virtual Machines

Q: Do I need a separate project to create my first VM?

No. You can create a Virtual Machine inside any existing project, including the default project created for your account. Projects are used to group resources, manage team access, and track usage and billing.

Q: Can I resize a virtual machine without downtime?

Resizing a Virtual Machine in CloudRaya requires a restart to apply changes. This means the VM will experience a short downtime while the new configuration is being applied. We recommend performing resize operations during a maintenance window.

Q: What happens if the physical host running my VM fails?

CloudRaya Compute is designed with high availability (HA). If a physical host experiences a failure, the platform will automatically recover the affected Virtual Machine by restarting it on another host. You may experience a brief downtime during this process, but the VM and its data remain intact.

For higher availability at the application level, we recommend running multiple VMs behind a load balancer.

Q: Are stopped virtual machines billed?

When a Virtual Machine is stopped, you are not billed for the VM compute package. However, charges for storage (both the storage included in the VM package and any additional disks) and additional licenses (such as Windows) will continue to apply.

For public IP addresses, the IP included in the VM package is not billed separately. Charges only apply if you assign additional public IPs beyond what is included in the package.

Q: Can I move a VM to another Project?

No. Virtual Machines are bound to the Project where they were created and cannot be moved directly to another Project.

If you need to reorganize resources across Projects:

Create a new VM in the target Project
Migrate your data using third-party or self-managed methods, such as OS-level backups, application-level exports, or templates managed by you

Note: CloudRaya-managed snapshots and backups are Project-scoped and are not accessible across different Projects.

Q: Why can’t I view my root password after VM creation?

When a new VM is created and reaches Running state, the password section will initially display “View Password.”

After clicking View Password, a popup dialog will appear allowing you to copy the generated root password.

Once the popup is closed:

The password will no longer be visible.
The password section will automatically change to “Reset Password.”
The original password cannot be viewed again.

This behavior is intentional and part of our secure by design approach. We make infrastructure security intentional by limiting credential exposure and preventing repeated password retrieval.

If you forget the password, you must use Reset Password, and the new password will again only be shown once.

Q: Should I use password or SSH key for VM access?

We recommend using SSH key authentication as your primary access method.

Use SSH key if:

You want stronger security.
You regularly manage infrastructure from a trusted workstation.
You want to avoid repeated password resets.

Password login may still be useful if:

You frequently switch devices.
You need access from a temporary machine.
You access VM from mobile SSH clients.

For long-term and production workloads, SSH key is the recommended best practice.

KubeRaya (Managed Kubernetes)

Q: Can I access the Kubernetes API directly?

Yes. You receive cluster access credentials and can use:

kubectl
Kubernetes dashboards
CI/CD tools

KubeRaya is fully compatible with standard Kubernetes tooling.

Q: Is the Kubernetes control plane highly available?

High availability for the KubeRaya control plane is optional and configurable. When creating or updating a cluster, you can enable the High Availability option and choose the number of master nodes.

Enabling HA improves resilience and availability of the control plane, but it will increase the cluster’s hourly cost based on the number of master nodes selected.

Q: How does node scaling work in KubeRaya?

You can manually scale worker nodes or use autoscaling features to adjust node capacity based on workload demand and resource utilization.

Q: Does KubeRaya provide built-in persistent storage?

KubeRaya provides node-level storage as part of the cluster configuration. This storage is suitable for temporary or non-critical data and is tied to the worker nodes.

For persistent application data, you can integrate your workloads with StorageRaya Object Storage using S3-compatible APIs or application-level integrations.

At this time, CloudRaya block storage is not available as a Kubernetes Persistent Volume (CSI driver), so attaching VM-style disks directly to Kubernetes workloads is not supported.