Home Onidel Cloud

Onidel Cloud

Onidel Cloud features and how to utilise them
Onidel
By Onidel and 1 other
• 29 articles

BYO Windows Server Installation Guide

Onidel Cloud allows you to bring your own licensed copy of Windows Server and install it manually via a custom ISO. This guide walks you through preparing and installing Windows Server on a VPS using our VNC and ISO mounting features. Upload your Windows Server ISO 1. Prepare a direct HTTP URL that points to your Windows Server ISO file. Links from cloud storage services like Google Drive or Dropbox are typically not supported unless they provide a direct download link. 2. Login to Onidel Cloud, then go to Orchestration > Custom ISOs 3. Paste the direct ISO URL into the input field and click Upload 4. If the URL is valid, Onidel Cloud will begin transferring the ISO to your account. The download status will be updated every 5 minutes. Once the upload is complete, you will see a green Active status. 5. The ISO is now ready to be attached to your VPS for installation. Create your custom VPS 1. Head over to Virtual Machine Deploy page, the first step is to select the Server Type, then select the Location. 2. When selecting the image, you will see the uploaded ISO available in the ISO dropdown. Choose your uploaded Windows ISO. 3. You can skip SSH Keys and Firewall Group section unless you have specific requirements. 4. In the Server Configuration section, you can select the resources you require either with the prebuilt plans or customise the specifications. Windows Server will fit comfortably onto our $9.9/month plan, but you may customise your resources for your intended workload. 5. Choose your preferred payment cycle. Onidel Cloud supports both hourly billing and subscription-based plans, with discounts available for longer-term commitments. 6. Select any additional features you need, such as automatic backups. 7. Click Deploy Now. If you are selecting a subscription-based plan, an invoice will be generated for payment. Once the payment is completed, your VPS will be online and ready for installation in under 30 seconds. Changing VPS Settings Once your VPS is ready, you will receive an email with the access details. Before proceeding with the Windows installation, a few additional configuration steps are required: 1. Go to the VM Management page and open the Settings tab. 2. Enable TPM, switch the Boot Mode to UEFI, and click Change Boot Mode to apply the changes. 3. Next, navigate to Storage > ISO Images and attach the Virtio Drivers ISO. 4. Open the VPS Console, and follow the on-screen instructions to begin the Windows installation process. Installing Drivers 1. During installation, Windows Server may not detect any available drives for installation. To resolve this, click Load driver, then browse to the virtio-win-0.1.262 drive. Navigate to the amd64 directory, select the folder corresponding to your operating system version, and install the necessary storage drivers. 2. The installer should now detect the storage driver. Select it from the list and click Next to continue. 3. We will also need to install the network drivers. Click Load driver again, navigate to the driver disk, open the NetKVM directory, select the folder that matches your operating system version, and click Next to install 4. Once the storage and network drivers are installed, return to the drive selection screen and click Next to proceed with the installation. 5. Windows will begin copying files from the ISO and will automatically reboot once this step is complete. There is no need to detach the installation ISO at this point - as long as no keys are pressed during boot, Windows will continue the setup process automatically. 6. After the server reboots, you will be prompted to configure initial settings and set a password for the Administrator account. At this point, the Windows Server installation is complete. To enable Remote Desktop access, you will need to log in via the console. 7. Click the Console Commands button, then select Ctrl + Alt + Del to bring up the login screen. 8. To enable Remote Desktop access, navigate to the system settings and find Remote Desktop option. 9. Once Remote Desktop is enabled, you can log into the server using any remote desktop client. A successful login with the Administrator account will automatically log you out of the rescue console session.

Last updated on Aug 27, 2025

Self-Healing Failover Virtual Machines

Overview To ensure maximum uptime and reliability for your workloads, Onidel offers Self-Healing Failover Virtual Machines powered by high-availability (HA) clustering. This feature automatically detects host failures and seamlessly restarts your virtual machines (VMs) on healthy nodes, minimising downtime and reducing manual intervention. HA is available in all locations - in Amsterdam, Ho Chi Minh, New York, Singapore and Sydney. It is enabled on a VM when a green High Availability label is displayed next to the service name: How it works Distributed Storage with Triple Replication Your virtual machine disks are stored on NVMe-backed block storage, built on a CEPH-powered distributed storage system. Every block of data is replicated three times across independent nodes. This ensures: - Fault tolerance: Even if a storage device or node fails, your data remains accessible. - High performance: NVMe technology delivers fast read/write speeds. - Consistency: Automatic synchronisation maintains data integrity across all replicas. Continuous Node Monitoring The infrastructure continuously monitors the health of all compute nodes in the cluster. If a node becomes unresponsive (due to hardware, network, or power issues), the system immediately detects the failure. Automated VM Failover Once a failure is detected: - A failover event is triggered. - Affected VMs are automatically restarted on a healthy node within the same cluster. - The storage layer ensures that the VM has access to its replicated data with no risk of corruption. The system is self-healing, meaning no manual action is required from you: - Failed nodes are automatically isolated. - Services are restored as quickly as possible with minimal downtime. - Once the failed node is repaired and re-joins the cluster, it automatically reintegrates into the pool of available resources.

Last updated on Mar 16, 2026

Data Transfer (Bandwidth) Pooling

At Onidel Cloud, customers with multiple cloud servers benefit from automatic data-transfer pooling. This feature consolidates each server's data transfer allowance into a shared pool, giving you a combined, service-wide data limit. How it Works - Each server's data usage is tracked individually. - The data transfer allowance from each server in the same region is accumulated into a shared pool, allowing flexible usage across all these servers. - If one server reaches its individual limit, additional data usage is automatically drawn from the remaining allowance in the shared pool. Once the shared pool is fully used, any additional data used by hourly-billed cloud servers will be billed as excess at USD $0.01 per GB. Subscription-based cloud servers will be capped at 5Mbps. You can also purchase additional bandwidth at $3.5/TB. Data Transfer Pooling is only applicable to Virtual Machines and does not include the egress allocation of Onidel Object Storage instances within the same region. Regions There are currently 3 bandwidth pooling regions: - Asia Pacific (APAC) - Australia, Singapore, Vietnam - Europe - The Netherlands - North America - USA Usage Stats You can view and monitor the bandwidth usage/allocation of each region from Onidel Cloud panel by navigating to Bandwidth Usage, then selecting the region. Below you can see the total Pool (total traffic available in this region) and current Usage bars. Below it you can see the total contribution to allocation of each Virtual Machine you have in the given region. In this example, there are two VMs, each one contributing 1TB traffic to the pool. And at the bottom, the per VM usage stats within the region. Here despite the location of the VMs being different, they are still accounted in the same region (APAC).

Last updated on Mar 02, 2026

Hourly Billing

Introduction Onidel Cloud provides hourly billing in select locations, where cloud server charges accrue in hourly increments. Currently, hourly charges are deducted directly from the customer's account balance, so customers must recharge their account before provisioning hourly VMs. Eligibility To be eligible for provisioning VMs on an hourly billing cycle, customers must: - Verify their mobile phone number: Please visit this page to verify your phone number. - Recharge account balance: Hourly charges are deducted directly from your account balance, so customers must ensure sufficient credit to cover hourly charges. Onidel Cloud requires a minimum account balance equivalent to at least one day of hourly charges. For example, if a VM costs A$0.0082 per hour, you will need a minimum balance of A$0.0082 x 24 = A$0.1968 to avoid an insufficient balance error. How am I billed for my VMs? The hourly rate is calculated by dividing the monthly rate by 672 hours (28 days). If your VM remains online for more than 672 hours within a calendar month, you will only be billed the monthly rate. An invoice with accumulated charges will be generated on the 1st of each month for your reference. If you upgrade or downgrade your VM, it will incur one full hour's charge at the current rate before the update is applied, which may result in charges exceeding 672 hours in months when resizing occurs. VMs in a stopped state continue to reserve dedicated system resources and will incur charges until they are destroyed. To stop accruing charges for a VM, please terminate the service. How is bandwidth usage calculated? We calculate your bandwidth usage based on both inbound and outbound traffic. How are bandwidth caps calculated? Each month consists of 672 hours, and bandwidth allocations are distributed hourly throughout the month. If you exceed your allocated bandwidth at any point, an overage charge will apply. Bandwidth for each VM is allocated on an hourly basis while the instance is active. The monthly bandwidth cap varies depending on the VM’s specifications, so for each hour the instance operates, you accrue one hour's worth of its monthly cap. Onidel customers with multiple cloud servers benefit from pooled bandwidth across their instances as described in Data Transfer (Bandwidth) Pooling What is the bandwidth overage rate? We charge $0.01 per GB for bandwidth usage that exceeds your allocated quota. You can also purchase additional bandwidth at a lower rate of $3.50 per TB. How can I increase my account resource limits? Your account may become eligible for higher limit increases as you establish a credible history. To review your current limits, visit: https://cloud.onidel.com/account/resource-limit. If you would like to request a limit increase, please open a support ticket and provide details of your use case for review.

Last updated on Aug 25, 2025

Automatic Backup

Onidel Automatic Backup provides a reliable and efficient solution to safeguard your data with minimal effort. Designed for speed and flexibility, this feature ensures your critical information is securely stored and easily recoverable when needed. Key Features High-Performance SSD Storage Backups are stored on SSD storage, enabling lightning-fast backup creation and restoration. This ensures minimal downtime and quick access to your data when you need it most. Retention of Recent Backups The system retains the two most recent backup versions, giving you peace of mind with access to both your latest data and a previous backup. This dual-version approach enhances your recovery options. Customisable Backup Schedules Tailor the backup frequency to suit your needs: - Daily: Ideal for environments with frequent changes. - Weekly: Perfect for less dynamic workloads. - Monthly: Suitable for long-term archival needs. Choose the schedule that aligns with your operational requirements. Cost Structure Backups are priced at $0.10 per GB, calculated based on the size of the backed up disk. Flexible Recovery Options Onidel Automatic Backup offers versatile ways to access and utilise your backups: - Restore: Revert your instance to a selected backup version, ensuring quick recovery to a previous state. - Download Locally: Retrieve backups for local storage or disaster recovery planning. - Attach to Running Instance: Mount backups directly to an active instance for seamless individual file or system recovery. These options empower you to recover data on your terms. How to Enable Automatic Backup Enabling Automatic Backup is straightforward and can be done at different stages depending on your preference. During Order Activate automatic backups directly when placing your initial order. This ensures your instance is protected from day one with no additional setup required. VM Add-on If you didn't enable backups initially, you can turn them on later through the Add-ons tab on the VM management page. 1. Go to Compute > Virtual Machines > (Select Your VM) > Add-ons tab, and click on Add New button. 2. There, you will see the option to buy various add-ons for your VPS. For this tutorial, you will need to use the Automatic Backup one. To purchase it, click Submit and pay the generated invoice. Configuring Automatic Backup 1. After the Automatic Backup feature has been purchased, go to Storage > Backups tab of your VM and Schedule an automatic backup. 2. From there, you can choose the desired backup frequency. The schedule uses AEDT (UTC+11) as a timezone. In the Weekly and Monthly schedules, you will be asked to choose a day of the week/month. Click Save Schedule once you're finished setting it up. 3. Now, the automatic backups are enabled and you should see a notice about when the next one will be taken at. Note that here, the next backup schedule is shown in your local timezone. 4. When there comes the time for backup, your VM will change its status to Snapshot In Progress. Your VM will remain online during this time, however you can not change its configuration while backup is in progress. Restoring from a Backup 1. After the backup was successfully created, you should see it in the list under Storage > Backups. To restore from one, just click the Restore button. 2. You will get a warning about the restoration being a destructive operation. Restoring from a backup will overwrite all data on your drive. If you are sure you want to restore this backup, just confirm by clicking Restore. 3. Then you should see the status of your VM changed to Restoring. The VM will become offline and locked until it's fully restored. Downloading a Backup Backups of your VMs can be downloaded. This could be useful to easily recreate/migrate the VM into other environment or just to keep local backup of the data. 1. To download a backup, go to Storage > Backups and click the Download button. 2. The download should now start. Backups are not compressed so the download process could take a while. Converting Backup to Snapshot It is possible to convert a Backup to a Snapshot. This allows for a new Virtual Machine instance to be created using the backed up state of your Virtual Machine. 1. Go to Orchestration > Backups. There you will see the list of current backups from all VMs. 2. There, besides the previously showcased actions to Restore or Download the backup image, there is also an option to convert the Backup image to a Snapshot. 3. After you click on it, you will be asked to name the snapshot. 4. You should now see the Snapshot in the Orchestration > Snapshots view. 5. You can read more on Snapshots in this guide. Disabling and Re-enabling You can disable automatic backups at any time if they're no longer needed. However, to re-enable the feature after disabling it, you'll need to contact customer support for assistance. Retention Currently, we store 2 most recent versions of your VM backup regardless of backup frequency. For example, if your backup frequency is daily - backups older than 2 days will be deleted, if weekly - older than 2 weeks and so on.

Last updated on Mar 05, 2026

Enable 2-FA

What is 2-Factor Authentication? 2-Factor Authentication (2FA) is an important security method that enhances the protection of your account by requiring two forms of identity verification during login. Onidel Cloud supports 2FA via email and TOTP (Time-based One-Time Password). Below are the steps to enable this feature. Enable 2-Factor Authentication 1. Log in to your Onidel Cloud account at https://cloud.onidel.com. 2. Click on Settings under the Account section in the left-hand menu to access the Account Settings page. 3. On the Account Settings page, select the 2-Factor Authentication tab. 4. Click on Activate 2FA and choose your preferred authentication method: via Email or through an Authentication App Using Email 1. After selecting Activate 2FA and Authenticate via Email click the Save Changes button. A notification will appear asking you to enter a verification code. Click on the link in the notification to send the verification code to your email. 2. Check your email inbox for the verification code to activate 2FA. The email will be sent from Onidel Cloud ([email protected]) with the subject: Onidel Cloud - Verification Code 3. Enter the verification code and click Confirm. If the code is correct, 2FA will be successfully enabled on your account. Using TOTP App 1. Select Activate 2FA and Authentication via app, then click Save Changes. A notification will appear asking you to scan the QR code using an authentication app (such as Google Authenticator or Duo Security) 2. Use a TOTP authentication app (such as Google Authenticator) to scan the QR code or manually enter the secret key into the app to add your account. 3. If successful, the app will display an account with the label Onidel Cloud: . 4. Enter the OTP code and click Confirm. 5. If the OTP is correct, 2FA will be successfully enabled on your account.

Last updated on Aug 25, 2025

Affiliate Program

At Onidel Cloud, we value your support in helping us grow. Our Affiliate Program is designed to reward you for bringing new users to experience our fast, reliable, and affordable cloud infrastructure. Whether you are a current customer or simply a fan of Onidel's services, the program allows you to earn extra income effortlessly. How to Get Started 1. Sign Up: Log in to your Onidel account and navigate to the Affiliate section. 2. Share Your Referral Link: Share your unique referral link with friends, colleagues, or your audience through social media, blogs, or emails. 3. Earn Rewards and Help Others Save: Watch your commissions grow as your referrals join and enjoy their exclusive bonus. Affiliate Rewards Structure One-Time Bonus - Earn a one-time A$5 reward for every referral who spends more than A$10 on Onidel Cloud services. - The one-time bonus will become available 30 days after the last eligible transaction, i.e., the transaction that pushes the total spend of your referral over the A$10 threshold. Recurring Commission for Referrers - Earn a 15% commission on every purchase your referral makes, whether it’s for a new service or for renewals. - The commission rate is 5% for purchases made under promotional programs. - This means that as your referral continues to use Onidel, your earnings keep growing! Exclusive Bonus for Referees - Your referral will receive a 25% bonus on their first invoice as a welcome gift for joining Onidel Cloud using your referral link. - This bonus helps them save immediately while experiencing Onidel's services. Accessing Your Commission Availability Period Commissions become available 30 days after the referral’s purchase. This delay ensures that transactions are valid and accounts for any refunds or disputes. Payout Options Once your available commission exceeds A$50, you can:: - Convert to Account Credit: Convert your commission into Onidel credits and use them to pay for your own services. - Withdraw Your Earnings: Transfer your earnings to your PayPal account. Benefits of Joining the Onidel Affiliate Program No Limits on Earnings There's no cap on how much you can earn. The more people you refer, the more rewards you get! Passive Income As long as your referrals remain active customers, you'll keep earning commissions on their purchases. Help Your Referrals Save With the 25% bonus on their first invoice, your referrals get a fantastic start with Onidel. Easy Payouts Whether you want to reinvest in Onidel services or withdraw your earnings, we've made the process seamless. Quick Payouts Payouts are completed within 5 business days. To request payout, just open a open a ticket with our Billing Department. Transparent Tracking Monitor your referrals and earnings in real-time through the Onidel dashboard. Example Scenario Let's say you refer three users who each spend A$50 in their first month. Here's how your earnings would look: - One-Time Bonus: A$5 x 3 = A$15 - 15% Commission: (15% of A$50) x 3 = A$22.50 - Total Earnings: A$37.50 from just three referrals in their first month. As these users continue to make purchases, you'll keep earning 15% commissions from them.

Last updated on Apr 10, 2026

Peer Server

The Peer Server functionality strengthens system reliability and fault resilience for mission-critical applications by preventing two servers from being hosted on the same hypervisor. A peer server is usually a secondary server that shares the same responsibilities as the primary server. For example, two web servers running behind a load balancer are considered peer servers since they both equally manage web traffic. However, servers do not need to serve the same purpose to utilise this feature. It can be used to ensure that two servers are placed on separate hypervisors, improving service availability and minimising downtime in the event of a hypervisor failure. How it Works When a peer server is assigned, the platform checks whether both servers are currently located on the same hypervisor. If they are, a live migration will be scheduled to separate them. During the migration, your server will remain fully operational, but management actions through the control panel will be temporarily unavailable. Each server can have only one designated peer server. It is not possible to configure three or more servers to ensure they are all placed on different hypervisors. How to set Peer Servers The Peer Server feature is available for plans that utilise distributed storage. To enable it, follow these steps: - Navigate to the VM management page. - In the Overview > System Information section, click Set Peer Server: - Choose the server you want to designate as a peer, then click Update Once configured, the platform ensures that peer servers are not placed on the same hypervisor and will initiate a live migration if necessary to meet this requirement.

Last updated on Sep 03, 2025

Resource Alerts

Overview Resource alerts are automated notifications that monitor your server's performance metrics and notify you when usage patterns may impact server performance. This proactive monitoring helps you identify and resolve issues before they affect your users, including detecting potential security threats such as malware infections, suspicious activity, or unauthorised access attempts. How Resource Alerts Work Resource alerts monitor five key metrics: - CPU Usage: Average utilisation across all processors (0-100%) - Disk Read: Data read from disk storage (kB/s) - Disk Write: Data written to disk storage (kB/s) - Incoming Network Traffic: Data received by the server (kB/s) - Outgoing Network Traffic: Data sent from the server (kB/s) Monitoring Process: - Metrics are collected every 5 minutes - Every hour, the system calculates the average of all collected data points - If the one hour average exceeds your configured threshold, an alert is sent to your registered email address. - To prevent email flooding, subsequent notifications for the same alert are sent at least 4 hours apart. Understanding Alert Triggers Sudden increases in resource usage may indicate: Normal Activities - Traffic spikes from marketing campaigns - Scheduled backups or maintenance - Legitimate user activity increases - Software updates or deployments Potential Issues - DDoS attacks or brute force attempts - Malware or crypto-mining activity - Data exfiltration or unauthorised access - Misconfigured applications causing resource loops Configuring Alert Thresholds 1. Navigate to your server's management page 2. Click on the Resource Monitor tab 3. Select Resource Alerts 4. Adjust thresholds for each metric based on your usage patterns 5. Enable/disable specific alerts as needed Setting Appropriate Thresholds - New servers: 1. Let your server run normally for 24 hours 2. Review the usage graphs for each metric 3. Set thresholds based on the average values observed 4. Add 20-30% buffer for normal variations - Production servers: Set thresholds 20-30% above typical peak usage - Development servers: Consider higher thresholds or disable alerts Responding to Alerts When you receive an alert: 1. Do not panic - Alerts are informational and don't require immediate action 2. Check current usage - Log into your server to view real-time metrics 3. Identify the cause: - Review recent changes or deployments - Check access logs for unusual activity - Monitor running processes 4. Take action if needed: - Scale resources if legitimate growth - Block suspicious IPs if under attack - Optimise applications if inefficient - Adjust alert thresholds if false positive Common Scenarios High CPU Alert - Check for runaway processes: top or htop - Review application logs for errors - Consider CPU upgrade if consistently high High Network Traffic Alert - Analyse traffic sources: netstat or iftop - Check for DDoS patterns in logs - Verify CDN configuration if applicable High Disk I/O Alert - Check for large file operations: iotop - Review database query performance - Ensure adequate free disk space Disabling Alerts To disable alerts: 1. Access the Resource Alerts page 2. Toggle the active switch to off. Note: We recommend keeping critical alerts active even if you adjust thresholds rather than disabling completely.

Last updated on Feb 10, 2026

1-Click Apps

Overview 1-Click Apps provide pre-configured application environments that can be deployed instantly with minimal setup. These ready-to-use solutions eliminate the need for manual installation, configuration, and dependency management, allowing you to focus on using the application rather than setting it up. Key Features - Pre-configured environments: Applications are installed with recommended default settings. - Faster deployment: Skip manual installation steps and get started immediately. - Wide selection: Choose from commonly used apps such as CyberPanel, FASTPANEL, n8n, aaPanel and more. - Customisable: After deployment, you have full control to adjust settings, install additional packages, and configure the server as needed. How To Use 1-Click Apps To deploy with a 1-Click App, simply select the Application tab in the Software section when ordering a new service. You can also reinstall an existing VM using 1-Click Apps. Deployment time varies by application. Most apps are ready within 3–5 minutes, while some may take longer. For example, please allow 13–15 minutes for CyberPanel to be fully installed and ready to use. Notes & Limitations - 1-Click Apps are designed with default settings; additional hardening and optimisation may be required for production workloads. - Some applications may require post-installation steps (e.g., setting up an admin account). - Bandwidth, storage, and other resources depend on the VM plan you select.

Last updated on Sep 15, 2025

Reserved IP Addresses

Overview Reserved IP addresses (also known as floating IPs) are flexible, re-routable IP addresses that can be dynamically assigned to different virtual machines within your Onidel Cloud infrastructure. Unlike standard IPs that are permanently bound to a specific VM, Reserved IPs can be instantly moved between instances, providing high availability and seamless failover capabilities. When you provision a Reserved IP, it exists independently of any VM instance. You can attach it to a VM and later reassign it to another VM without changing DNS records or updating client configurations. Key Benefits - You can move the reserved IP address from one VM to another (e.g. during maintenance or in response to failure) through our control panel or API. - You can assign one or more Reserved IP addresses to your VM, allowing it to communicate with external systems using multiple public IPs. - When you decommission an old VM and provision a new one, you can attach the same Reserved IP. This avoids updating DNS records or client configurations, making migrations frictionless. - You can hold on to your favourite IP and use it again later - for any reason you like! How Reserved IPs Work A Reserved IP address has a dynamic, one-to-one relationship with an "Anchor" IP address. The Anchor IP is the primary IP address of the VM that the Reserved IP is being routed to. This sounds complicated, but it simply means that the Reserved IP piggybacks on another IP address, which you can choose and change at your leisure. Via the Onidel Cloud Control Panel and API, the Reserved IP ↔ Anchor IP relationship can be updated in real-time, allowing you to direct traffic to the VM of your choice. Example Scenario: 1. A user enters the Reserved IP address 198.51.100.50 in their browser 2. This Reserved IP's current Anchor IP is 203.0.113.10, which belongs to VM-A 3. The user will be served the website running on VM-A When you change the Anchor IP to 203.0.113.20 (which belongs to VM-B), the same user accessing the same Reserved IP will now be served the website running on VM-B. This change is instant, without any perceptible downtime from the end user's perspective. Behind the scenes, our infrastructure simply updates the routing table to forward all traffic destined for the Reserved IP to the new Anchor IP. Use Cases Unplanned Downtime Recovery If your primary VM becomes unavailable, instantly redirect traffic to a standby VM by reassigning the Reserved IP. This provides near-zero downtime recovery without DNS propagation delays. Zero-Downtime Maintenance Before performing maintenance on your production VM: 1. Ensure your standby VM is synchronised 2. Reassign the Reserved IP to the standby VM 3. Perform maintenance on the primary VM 4. Optionally reassign the Reserved IP back after maintenance Provisioning Reserved IPs Via Control Panel Navigate to Network > Reserved IPs in your Onidel Cloud dashboard. Then select the your desired location, IP type, the subnet and enter reserved IP name. Finally, click the Add Reserved IP button. 1. Reserved IPs are billed on hourly basis. See the pricing section below. 2. There are limits on how many reserved IPs you may create within a day. There is also a default limit of 5 Reserved IPs per account. If your use-case needs more, please contact us by opening a ticket to get the limit increased. Via API curl -X POST https://api.cloud.onidel.com/network/reserved_ips \ -H "Authorization: Bearer YOUR_API_TOKEN" \ -H "Content-Type: application/json" \ -d '{ "ip_type": "ipv4", "location": "sydney" }' Reference: Reserved IPs - Developer Docs Pricing 1. Billing: Hourly billing with a maximum of $3.00/month ($0.0045/hour) per /32 IPv4 or $1.00/month ($0.0015/hour) per /64 IPv6 subnet 2. Minimum Charge: 24 hours 3. No bandwidth charges: Uses your VM's allocated bandwidth Attaching Reserved IP to the VM Once purchased, you should see the Reserved IP in the Network > Reserved IPs tab. You may manage it by clicking the Gear icon. In the Instance Attachment dropdown, pick the VM you want to attach Reserved IP to. The list will only include instances in the same location as the reserved IP itself. After you click Attach, the Reserved IP will be connected to the selected VM. This does not involve any downtime, Reserved IP will be available to the VM as soon as it's attached. Configuring Reserved IPs Step 1: Configure on Target VMs Reserved IPs must be configured as secondary IPs on all potential target VMs: Ubuntu 22.04+ (Netplan): # Create a new file: /etc/netplan/60-reserved-ip.yaml network: version: 2 ethernets: eth0: addresses: - YOUR_RESERVED_IP/32 Apply the configuration: sudo netplan apply Ubuntu 20.04 and earlier / Debian: # Add to /etc/network/interfaces auto eth0:1 iface eth0:1 inet static address YOUR_RESERVED_IP netmask 255.255.255.255 Apply the configuration: sudo ifup eth0:1 # Or restart networking service sudo systemctl restart networking CentOS/RHEL: # Create /etc/sysconfig/network-scripts/ifcfg-eth0:1 DEVICE=eth0:1 IPADDR=YOUR_RESERVED_IP NETMASK=255.255.255.255 ONBOOT=yes Apply the configuration: sudo ifup eth0:1 # Or restart network service sudo systemctl restart network Step 2: Assign to Anchor IP Via Control Panel: 1. Go to Network > Reserved IPs 2. Click on your Reserved IP 3. Choose the target VM and click Attach Reserved IP Via API: curl -X PUT https://api.cloud.onidel.com/network/reserved-ips/YOUR_RESERVED_UUID \ -H "Authorization: Token YOUR_API_TOKEN" \ -H "Content-Type: application/json" \ -d '{ "anchor_ip": "TARGET_VM_PRIMARY_IP" }' Reference: Reserved IPs - Developer Docs Step 3: Verifying Configuration Test connectivity to ensure the Reserved IP is properly routed: # From external host ping YOUR_RESERVED_IP # From the VM ip addr show | grep YOUR_RESERVED_IP Limitations While Reserved IPs provide great degree of flexibility, there are also a few limitations to be aware of: - Reserved IPs may be billed only on hourly basis. - Reserved IPs can not be moved across locations or subnets. - Once VM's Primary IP address is converted into a Reserved IP, it can not be converted back.

Last updated on Jun 11, 2026

Firewall and IP Lists

Onidel dashboard has built in support for firewall. It can be useful to filter incoming traffic on a layer above your VM guest Operating System. Any incoming traffic filtered out on that layer is not counted towards your server's data usage. Firewall is managed with Firewall Groups which allow you to create reusable groups of rules that can be applied to multiple Virtual Machines simultaneously. IP Lists are used to group IP addresses and subnets. Later, the firewall rules can be applied to them. That is especially useful when using external CDNs like Cloudflare or AWS Cloudfront, monitoring tools or services you want to only expose to trusted networks. Creating a Firewall Group Firewall Groups are sets of firewall rules which can be reused across multiple VMs in different locations. 1. Go to Networks > Firewall and click Add Firewall Group button. 2. Create a name for the Firewall Group. Ideally, it should describe what the rules defined there will achieve together. 3. Now, you can add rules in the firewall group by clicking the pen icon in Actions column. 4. Select a protocol or application, destination ports and source IP range to allow access from. After that click Save button on the right and the rule will be added to the list. The two rules at the bottom are permanent, they drop all incoming traffic. We use deny-by-default approach, user-created allow rules will take higher precedence according to how high they are on the list. There is no distinction between IPv4 and IPv6 in firewall rules. If you want a rule to work with specific address family, just define the Source as either IPv4 or IPv6 subnet. 5. After all the rules are added, click on Linked Instances to apply Firewall Group to your VMs. 6. From there, select your VM name and click the button on the right to apply the defined rules. 7. You will be asked for a confirmation of linking the set of rules to the VM instance. The VM won't reboot but it can take up to 2 minutes for the new rules to be applied. 8. Now, the rule has been applied to selected VM. The instance should also be visible in the Linked Instances tab. Additionally, going to Compute > Virtual Machine > (select your VM) > Network > Security should also show and let you change the rule group being used for your VM. Your firewall group can now also be selected when creating a New VM in the panel. 9. The firewall group can be modified even after VMs were linked to it and the new rules will take effect on all the VMs where given rule is set. Testing Firewall Rules To verify the rules were applied correctly, I initially started an nginx service running on port 80 (that was not covered by inbound rules added in the group). 1. Without firewall the web service was accessible with no restrictions: 2. After adding the VM to Firewall Group, the service is firewalled off and not accessible anymore: The default firewall deny policy is to DROP packets which causes timeout on filtered connections instead of rejecting them immediately. Using IP Lists Onidel provides a predefined set of IP Lists used for common reverse proxies, monitoring services or other known subnets which one may want to have allowed to access services on their VM. Currently the panel has predefined IP Lists for: - Cloudflare (reverse proxy) - AWS CloudFront (reverse proxy) - HetrixTools (monitoring) - UptimeRobot (monitoring) - Onidel (our IP ranges) Built-in To give certain service access to your VM, go to Networks > Firewall > (Select Firewall Group) and add a new Rule selecting IP List as a Source. Here, we allow 3rd party UptimeRobot service to send ICMP packets to all VMs using this Firewall Group. The VMs do not respond to pings from the outside: PING 104.250.118.70 (104.250.118.70) 56(84) bytes of data. --- 104.250.118.70 ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 3084ms However UptimeRobot can monitor them just fine with the PING checks: Custom If you want to define your own list of source addresses and subnets use in Firewall rules, you can use IP Lists. 1. In the Onidel Dashboard, go to Network > IP Lists and create a new one by clicking on Add IP List button. 2. Create a name and description for the IP List. 3. Then, you can add multiple IPv4/IPv6 addresses or subnets to the set. Just put it in the input field and click the Add button. *Note: you can not add an entry for subnet with /0 zero prefix size. We use hash:net set to match addresses within subnet and such notation is not supported there. If you really need to add entire address space to IP List, you would need to split the subnet into two /1s, like explained *here. 4. In this example, I added IP addresses of my other servers as well as some IPv4 and IPv6 ranges I consider trusted. 5. When you're done, just go back to Firewall Groups and the Firewall Group we were working with before. Then just add a new rule, selecting newly created IP List as a Source. 6. After this, only the IP addresses defined in IP List should be able to access to the restricted internal service.

Last updated on Feb 23, 2026

Private Networking (VPC)

Onidel Cloud supports VPC (Virtual Private Cloud) in every location. Private Networking allows Virtual Machines within one location to connect directly without reaching to the internet. This reduces the security risks by eliminating the need to expose internal services to the public. Private Networks usually offer higher throughput when sending data between VMs and they are not accounted for the used traffic. Creating and using Private Networks (VPCs) is completely free of charge. Prerequisites It is required to have at least two VMs in the same location to make meaningful use of the VPC network. Creating a Private Network 1. In Onidel Dashboard, go to Networks > VPC and click the New VPC Network button. 2. Then select the location you want the network to be created in. The location needs to be the same as the VMs from the Prerequisites section. 3. In the Private IP Range configuration, select Generate An IP Range For Me. There is also an option to Configure Your Own IP Range. Usually not needed unless you need to use a specific private address space for the internal network. In VPC Config enter the name and description of the private network and click Create VPC Network. 4. After that, the VPC Network will be created. You may need to wait up to 5 minutes for it to become Available. Adding Virtual Machines to VPC WARNING SSH host keys of your Virtual Machine may be regenerated after joining a new Private Network. This is because adding a new network interface changes the instance-id value which cloudinit uses to track instance metadata changes. You may get warning about the change of keys on the host when trying to SSH into VM after adding it to VPC: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. To prevent this behavior you need to create a file inside /etc/cloud/cloud.cfg.d/ directory inside the VM before proceeding with later steps: $ echo 'ssh_deletekeys: false' > /etc/cloud/cloud.cfg.d/99-keep-ssh-keys.cfg 1. Going to Compute > Virtual Machine > (select your VM) > Network > Private Network, you can add a VM to newly created private network by clicking the Join Network button. 2. You will be asked to select the VPC from the list and then to confirm joining the network. The VM will be rebooted to apply changes. 3. Once the VM joins network successfully, you will see your VPC listed in Private Networks tab. Assigning a VPC during VM creation When creating a new Virtual Machine instance, there is an option to enable VPC Network and select one for VM to be in. Using the VPC In this example setup, we have added 2 VMs in Amsterdam to the Private Network. You can see both of the VMs being listed in the VPC tab by going to Networks > VPC > (your VPC). 1. After logging into the VM you should see an additional interface with a private IPv4 address associated with it. $ ip a ... 3: ens19: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc fq_codel state UP group default qlen 1000 link/ether 0c:1d:e1:42:0c:5a brd ff:ff:ff:ff:ff:ff altname enp6s19 altname enx0c1de1420c5a inet 10.20.160.3/20 brd 10.20.175.255 scope global ens19 valid_lft forever preferred_lft forever inet6 fe80::e1d:e1ff:fe42:c5a/64 scope link proto kernel_ll valid_lft forever preferred_lft forever Since we use VXLANs as the transport protocol for VPC Networks, the MTU of this interface must be set to 1450 bytes. 2. You should also be able to ping the other VM via its private address. $ ping -c4 10.20.160.2 PING 10.20.160.2 (10.20.160.2) 56(84) bytes of data. 64 bytes from 10.20.160.2: icmp_seq=1 ttl=64 time=0.399 ms 64 bytes from 10.20.160.2: icmp_seq=2 ttl=64 time=0.352 ms 64 bytes from 10.20.160.2: icmp_seq=3 ttl=64 time=0.406 ms 64 bytes from 10.20.160.2: icmp_seq=4 ttl=64 time=0.404 ms --- 10.20.160.2 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3069ms rtt min/avg/max/mdev = 0.352/0.390/0.406/0.022 ms 3. From there, you can communicate between VMs using the VPC interface. Additional notes Bandwidth and Traffic Accounting I have used iperf3 utility to test the throughput between two VMs on via the private network. It was roughly 3Gbps (which is 3x the faster than the public interface). $ iperf3 -c 10.20.160.2 -t 120 Connecting to host 10.20.160.2, port 5201 [ 5] local 10.20.160.3 port 60338 connected to 10.20.160.2 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 363 MBytes 3.04 Gbits/sec 0 1.63 MBytes [ 5] 1.00-2.00 sec 359 MBytes 3.01 Gbits/sec 0 1.63 MBytes ... [ 5] 118.00-119.00 sec 364 MBytes 3.06 Gbits/sec 0 2.90 MBytes [ 5] 119.00-120.00 sec 370 MBytes 3.10 Gbits/sec 529 1.52 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-120.00 sec 41.9 GBytes 3.00 Gbits/sec 3438 sender [ 5] 0.00-120.00 sec 41.9 GBytes 3.00 Gbits/sec receiver iperf Done. The speed generally depends on the location and other factors of shared environment so it is not guaranteed you will get the same result. During this test, over 40 GB of transfer was used but since all packets were transmitted over the private network, the traffic usage was not accounted to the VM.

Last updated on Mar 06, 2026

BGP and BYOIP (Bring Your Own IP)

Onidel supports BGP sessions and BYOIP across all of our locations, except Vietnam. This article outlines the pricing, requirements, and process for getting started. Pricing - $10 one-time setup fee per location. There is no recurring fee. - Any subsequent changes to advertised prefixes or IP filter updates incur an additional $10 per request. What We Provide - A default route only is provided over the BGP session. - If you do not have your own ASN, we will assign you a private ASN for the session. Requirements - A valid Letter of Authorization (LOA) authorising Onidel (AS152900) to advertise your prefixes. - Valid ROAs (Route Origin Authorizations) must be in place to speed up the provisioning process. Exact-match ROAs are required - ensure your ROA covers the exact prefix length you intend to announce. Setup Timeline Setup time varies by location. Generally, provisioning is completed within 5 business days, but may take up to 2 weeks depending on the location and any outstanding requirements. Process 1. Open a support ticket detailing the following: - Your ASN (if applicable) - The prefix(es) you wish to announce - The location(s) where you need the BGP session 2. Attach a signed LOA authorising Onidel (AS152900) to announce your prefixes, originating from your ASN (if you have one) or from our ASN (AS152900). 3. We issue an invoice for the setup fee. 4. Once payment is received, we proceed with provisioning and will update you on the outcome via the support ticket.

Last updated on Apr 28, 2026

AMD SEV-SNP Attestation and Memory Encryption

Onidel supports AMD SEV-SNP technology on both EPYC™ Premium and EPYC™ High-Frequency Virtual Machines in all locations except Vietnam. Price Using AMD SEV-SNP is free of charge. It is a feature that can be turned on and off for a VM at any time. Requirements and Limitations AMD SEV-SNP requires certain conditions to be fully functional: - UEFI boot mode - AMD SEV-SNP requires the VM to be booted in UEFI boot mode. - Recent Linux Operating System - AMD SEV-SNP requires kernel 6.11 or newer inside guest to work reliably. Additionally, if you are using the GRUB bootloader, ensure EFI_UNACCEPTED_MEMORY is supported. Otherwise your guest OS may not be able to address all the allocated memory while SEV-SNP is enabled. It is recommended to use GRUB version 2.12 or newer. It also comes with a few drawbacks: - No vTPM or Secure Boot - Current implementation of AMD SEV-SNP inside the hypervisor we use does not support vTPM or Secure Boot. We will focus on exploring alternative solutions to enable vTPM support running inside SEV-SNP environment at VMPL0, like the Coconot SVSM. - No Live Migration - The VM will be powered off during hypervisor maintenance since AMD SEV-SNP can not run on a different CPU. As of June 2026, some Operating Systems (or their installers) still may not fully support SEV-SNP: - Ubuntu Server 26.04 offers full SEV-SNP support and can be installed with it enabled. - Debian (including version 13) needs to be installed with SEV-SNP disabled at first, the feature can be enabled after installation. - OpenBSD does not support SEV-SNP yet, although there are plans for future releases. Enabling SEV-SNP for your VM 1. In Onidel Cloud Platform, navigate to Compute > Virtual Machines > (Select your VM) > Settings. From there, you need to change the Boot Mode to UEFI and click on Change Boot Mode button. The VM will restart automatically after the changes to Boot Configuration. 2. After the VM is restarted, you can now enable the AMD SEV-SNP option in the Security Settings. Then, you will need to restart the Virtual Machine manually by clicking on Server Restart icon. 3. Once the VM boots back up, you should see the notices about AMD SEV features in the system dmesg log. This indicates the feature has been enabled successfully and the VM currently has its memory encrypted. $ dmesg | grep SEV [ 0.391403] Memory Encryption Features active: AMD SEV SEV-ES SEV-SNP [ 0.392603] SEV: Status: SEV SEV-ES SEV-SNP [ 0.515139] SEV: APIC: wakeup_secondary_cpu() replaced with wakeup_cpu_via_vmgexit() [ 0.569713] SEV: Using SNP CPUID table, 33 entries present. [ 0.570745] SEV: SNP running at VMPL0. [ 1.471827] SEV: SNP guest platform device initialized. [ 8.508905] sev-guest sev-guest: Initialized SEV guest driver (using VMPCK0 communication key) [ 9.297485] kvm_amd: KVM is unsupported when running as an SEV guest Attestation You can use the snpguest utility to perform guest attestation and make sure your VM runs on a genuine AMD CPU (the Versioned Chip Endorsement Key (VCEK) is signed by authentic key from AMD). Installing snpguest 1. Install required dependencies. snpguest is written in Rust and requires to be compiled manually since it has not been packaged for all major distributions yet. On Debian/Ubuntu: $ apt update $ apt install -y curl git gcc make pkg-config libssl-dev On CentOS/RHEL/Alma/Rocky: $ dnf update -y $ dnf install -y curl git gcc make pkgconfig openssl-devel Then install the newest version of Rust from the rustup distribution. $ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh 2. Next clone the snpguest repository, activate the rust environment and compile the utility with cargo. $ git clone https://github.com/virtee/snpguest.git $ cd snpguest $ source "$HOME/.cargo/env" $ cargo build --release ... Compiling snpguest v0.10.0 (/root/snpguest) Finished `release` profile [optimized] target(s) in 5m 51s 3. After the successful compilation, the resulting binary should be in target/release directory. $ ./target/release/snpguest Navigation utility for AMD SEV-SNP guest environment Usage: snpguest [OPTIONS] <COMMAND> Commands: report Report command to request an attestation report certificates Certificates command to request cached certificates from the AMD PSP fetch Fetch command to request certificates verify Verify command to verify certificates and attestation report display Display command to display files in human readable form key Key command to generate derived key ok Probe system for SEV-SNP support generate Generate Pre-Attestation components help Print this message or the help of the given subcommand(s) Options: -q, --quiet Don't print anything to the console -h, --help Print help -V, --version Print version Generating Attestation Report Now you can generate the attestation report. $ snpguest report report.bin request-data.txt --random This command will generate two files: - report.bin - an attestation report of your VM. - request-data.txt - securely generated random data that acts like a 512 bits nonce and prevents replay attacks. Reading Attestation Report You can display the report taken in the previous step using the display report command of snpguest. Here, you can see all the environment parameters of your Virtual Machine. There is also the SHA-384 Measurement Hash of current environment which will be used for expected launch measurement verification in the next section of this guide. $ snpguest display report report.bin Attestation Report: Version: 3 Guest SVN: 0 Guest Policy (0x30000): ABI Major: 0 ABI Minor: 0 SMT Allowed: true Migrate MA: false Debug Allowed: false Single Socket: false CXL Allowed: false AEX 256 XTS: false RAPL Allowed: false Ciphertext hiding: false Page Swap Disable: false ... Current TCB: TCB Version: Microcode: 222 SNP: 28 TEE: 0 Boot Loader: 4 FMC: None Platform Info (39): SMT Enabled: true TSME Enabled: true ECC Enabled: true RAPL Disabled: false Ciphertext Hiding Enabled: false Alias Check Complete: true SEV-TIO Enabled: false Key Information: author key enabled: false mask chip key: false signing key: vcek Report Data: F1 F1 78 33 45 E0 58 77 57 12 83 6C 57 C9 76 4B 1E 7F C9 97 F7 F4 21 A3 38 A4 09 E5 58 BF F4 16 6B EE D3 86 E2 69 9E 45 F7 D5 11 52 3E 2E D5 22 31 FA 70 2C EB 4F 99 53 2D B4 B5 B1 7C 01 5D 25 Measurement: E9 BF F4 69 E7 D3 D1 F5 84 B0 FA 32 27 92 C0 03 4A 50 C7 75 17 D3 A0 85 16 0E 30 07 0E F4 04 88 60 9D 47 0B EB A3 02 58 97 8B A1 6B 96 C2 0A 74 ... Fetching AMD Certificate Chain To verify the signature on your report, you need the public certificate chain. It consists of the AMD Root Key (ARK), AMD SEV Key (ASK), and the Versioned Chip Endorsement Key (VCEK). The certificate chain is fetched from the AMD Key Distribution System (KDS). Note: use the value milan on EPYC™ Premium and turin on EPYC™ High-Frequency Virtual Machines. $ mkdir certs $ snpguest fetch ca pem ./certs milan # turin if running epyc high-frequency vm $ snpguest fetch vcek pem ./certs report.bin $ ls -la certs/ total 20 drwxr-xr-x 2 root root 4096 Feb 28 19:09 . drwxr-xr-x 8 root root 4096 Feb 28 19:01 .. -rw-r--r-- 1 root root 2277 Feb 28 19:02 ark.pem -rw-r--r-- 1 root root 2325 Feb 28 19:02 ask.pem -rw-r--r-- 1 root root 1887 Feb 28 19:09 vcek.pem Verifying the Certificate Chain Now use the snpguest utility to verify fetched certificates. This ensures that the VCEK was legitimately signed by the ASK, and the ASK was signed by the ARK. The correct output is shown below. $ snpguest verify certs ./certs The AMD ARK was self-signed! The AMD ASK was signed by the AMD ARK! The VCEK was signed by the AMD ASK! Verifying the Attestation Report Finally, verify the attestation report of your VM. The expected output shown below. $ snpguest verify attestation ./certs report.bin Reported TCB Boot Loader from certificate matches the attestation report. Reported TCB TEE from certificate matches the attestation report. Reported TCB SNP from certificate matches the attestation report. Reported TCB Microcode from certificate matches the attestation report. VEK signed the Attestation Report! The successful verification means: - The report was cryptographically signed by genuine AMD hardware (your VM is not being emulated or spoofed by a malicious hypervisor). - The state and measurements of your VM match the expected policies of a SEV-SNP confidential environment. Expected Launch Measurement Verification After performing successful attestation, you may want to verify the authenticity of core system components and make sure the instance is in expected state. The AMD Secure Processor calculates the launch measurement based on several inputs: the UEFI firmware (OVMF), the number of vCPUs, the CPU model, the kernel, initrd, and kernel command line parameters. If any of these parameters differ, the resulting hash will change. You can calculate the expected launch measurement value in a trusted environment using the sev-snp-measure utility and compare it with the measurement hash returned by the AMD Secure Processor from the VM. Obtain kernel and initrd $ ls -la /boot | grep 'initrd\|vmlinuz' lrwxrwxrwx 1 root root 27 Jun 13 15:21 initrd.img -> initrd.img-7.0.0-22-generic -rw------- 1 root root 63164846 Jun 13 15:28 initrd.img-7.0.0-22-generic lrwxrwxrwx 1 root root 27 Jun 14 06:45 initrd.img.old -> initrd.img-7.0.0-22-generic lrwxrwxrwx 1 root root 24 Jun 13 15:21 vmlinuz -> vmlinuz-7.0.0-22-generic -rw------- 1 root root 17275272 May 25 12:42 vmlinuz-7.0.0-22-generic lrwxrwxrwx 1 root root 24 Jun 14 06:45 vmlinuz.old -> vmlinuz-7.0.0-22-generic Additional Notes OVMF Stub To enable measured boot, we publish the OVMF binary used on our hypervisors. You can download it from here (it's the OVMF extracted from the official Debian ovmf-amdsev package). Data Encryption While properly working AMD SEV-SNP encrypts the working memory (RAM) making it impossible to trivially dump it from the hypervisor, your data may still not be encrypted at rest. If you need to make sure your data remains inaccessible from the hypervisor, we strongly recommend performing a Custom OS installation using LUKS to encrypt data on the disk. In cloud environments, this can be automated using a preseed file, as showcased in our Debian Preseed Installation guide. Changing SWIOTLB Size The amount of RAM you get with SEV-SNP enabled may be slightly lower. This is because Linux Kernel allocated certain region of shared memory for unencrypted communication with external devices (SWIOTLB bounce buffers). By default, Linux kernel allocates 64 MB of RAM for bounce buffers when SEV-SNP is active. The size of this allocation can be controlled with a kernel parameter. For example swiotlb=4096 means there will be 4096 slots allocated. Since each slot is 2KB in size, this will make the kernel only take away 8MB of working memory for the bounce buffers. Performance Benchmarks To encrypt and decrypt memory contents, AMD SEV-SNP uses a dedicated hardware AES-128 encryption engine integrated within the DRAM controller of EPYC CPU. This eliminates the need for the CPU to perform any expensive cryptographic operations associated with encryption memory at GB/s speeds. As a result, the performance in synthetic benchmarks is almost on par with a VM that has memory unencrypted. The impact of SEV-SNP is most noticeable on the disk IO speeds. To communicate with external devices like nvme disks on the host, the guest needs to copy unencrypted version of the data to a shared memory region using SWIOTLB (Software I/O Translation Lookaside Buffer). This slows down IO operations especially at high speeds due to the data copying operations required. Both benchmarks were taken using yabs.sh on EPYC™ Premium (Milan) platform. Without AMD SEV-SNP Sat Feb 28 19:42:15 UTC 2026 Basic System Information: --------------------------------- Uptime : 0 days, 0 hours, 2 minutes Processor : AMD EPYC 7713 64-Core Processor CPU cores : 1 @ 1996.249 MHz AES-NI : ✔ Enabled VM-x/AMD-V : ✔ Enabled RAM : 1.9 GiB Swap : 0.0 KiB Disk : 19.6 GiB Distro : Debian GNU/Linux 13 (trixie) Kernel : 6.12.73+deb13-amd64 VM Type : KVM IPv4/IPv6 : ✔ Online / ✔ Online IPv6 Network Information: --------------------------------- ISP : Onidel Pty Ltd ASN : AS152900 Onidel Pty Ltd Host : Onidel Pty Ltd Location : Amsterdam, North Holland (NH) Country : Netherlands fio Disk Speed Tests (Mixed R/W 50/50) (Partition /dev/vda1): --------------------------------- Block Size | 4k (IOPS) | 64k (IOPS) ------ | --- ---- | ---- ---- Read | 120.81 MB/s (30.2k) | 1.79 GB/s (28.0k) Write | 121.13 MB/s (30.2k) | 1.80 GB/s (28.1k) Total | 241.95 MB/s (60.4k) | 3.59 GB/s (56.1k) | | Block Size | 512k (IOPS) | 1m (IOPS) ------ | --- ---- | ---- ---- Read | 10.06 GB/s (19.6k) | 6.74 GB/s (6.5k) Write | 10.59 GB/s (20.6k) | 7.19 GB/s (7.0k) Total | 20.66 GB/s (40.3k) | 13.93 GB/s (13.6k) Geekbench 6 Benchmark Test: --------------------------------- Test | Value | Single Core | 1232 Multi Core | 1338 Full Test | https://browser.geekbench.com/v6/cpu/16798001 YABS completed in 10 min 40 sec With AMD SEV-SNP Sat Feb 28 19:58:14 UTC 2026 Basic System Information: --------------------------------- Uptime : 0 days, 0 hours, 0 minutes Processor : AMD EPYC 7713 64-Core Processor CPU cores : 1 @ 1996.249 MHz AES-NI : ✔ Enabled VM-x/AMD-V : ✔ Enabled RAM : 1.8 GiB Swap : 0.0 KiB Disk : 19.6 GiB Distro : Debian GNU/Linux 13 (trixie) Kernel : 6.12.73+deb13-amd64 VM Type : KVM IPv4/IPv6 : ✔ Online / ✔ Online IPv6 Network Information: --------------------------------- ISP : Onidel Pty Ltd ASN : AS152900 Onidel Pty Ltd Host : Onidel Pty Ltd Location : Amsterdam, North Holland (NH) Country : Netherlands fio Disk Speed Tests (Mixed R/W 50/50) (Partition /dev/vda1): --------------------------------- Block Size | 4k (IOPS) | 64k (IOPS) ------ | --- ---- | ---- ---- Read | 96.56 MB/s (24.1k) | 768.70 MB/s (12.0k) Write | 96.81 MB/s (24.2k) | 772.75 MB/s (12.0k) Total | 193.37 MB/s (48.3k) | 1.54 GB/s (24.0k) | | Block Size | 512k (IOPS) | 1m (IOPS) ------ | --- ---- | ---- ---- Read | 1.74 GB/s (3.4k) | 2.05 GB/s (2.0k) Write | 1.84 GB/s (3.5k) | 2.19 GB/s (2.1k) Total | 3.59 GB/s (7.0k) | 4.24 GB/s (4.1k) Geekbench 6 Benchmark Test: --------------------------------- Test | Value | Single Core | 1380 Multi Core | 1376 Full Test | https://browser.geekbench.com/v6/cpu/16798234 YABS completed in 10 min 0 sec

Last updated on Jun 14, 2026

Object Storage

Locations Onidel offers S3-compatible Object Storage in the following locations: - Singapore 🇸🇬 (test file) - Sydney, Australia 🇦🇺 (test file) Technology The underlying technology powering Onidel Object Storage is CEPH - an open-source, robust distributed storage solution. Your data is triple replicated to make ensure its integrity and availability. Supported Features - CORS - Lifecycle Rules - Versioning support - Pre-signed URLs - Static Website Hosting Minimum Size Minimum Object Storage plan is 1TB. You can upgrade to higher capacity later. Pricing Ingress Ingress is free on Onidel Object Storage. You can upload as much data as you like. Egress Egress is free up to 3x the storage size so for example, if you have 1TB object storage plan, you can use up to 3TB of egress data transfer without any additional cost. Excess bandwidth is billed at $0.01 per GB. Creating Object Storage Service 1. Log into Onidel Cloud Panel and navigate to Storage > Object Storage. Then, click on Create Object Storage Service button. 2. Now, choose the: - Location - if unsure, you can test the speed and latency to both of our locations using the test files provided at the top of this page. - Billing Cycle - annual billing gives you 20% discount. The billing period can be adjusted after the service is created. - Service Name - it is not the same as the bucket name. Later, you can create up to 100 unique storage buckets within one service and give a different name for each of them. - Storage Size - desired maximum object storage size, starts at 1TB and can be upgraded later. It can not be downgraded later. After that, click on Deploy Now and the service should appear in the Object Storage list. Creating a Bucket 1. After going to your newly created service, you can see stats about usage of capacity, traffic and active bucket amount. You can also create a new bucket. 2. Now select the: 1. Name of your bucket - it will be referenced in apps that use your S3 bucket. 2. Versioning toggle - if you need to store separate versions of objects uploaded to this bucket. This can increase the storage used by the object if there are multiple versions of it, but it lets you access specific version of the object instead of overwriting it on update. If unsure, leave this disabled. It can be enabled later. 3. Object Lock toggle - if you want to enable WORM (Write Once Read Many) feature of object storage. This ensures no data can be deleted and that there are always past versions of objects stored. Enabling WORM also turns on Versioning option. Then confirm creation by clicking the Create button. 3. After the bucket is created, you will see it in the Bucket List. Managing Objects from the Panel Onidel Cloud Panel offers a Web UI where you can upload files, create paths and manage them in an easy and intuitive way. 1. After choosing the bucket from the list, you can drag and drop files into it in the Objects tab. 2. After choosing a file, the upload will start. 3. You can also create Folders (S3 paths) for a better object structure inside the bucket. 4. You can upload objects there by navigating to the folder and uploading files there. External Applications s3cmd s3cmd is a free, open-source client for s3 compatible object storage. It allows managing your objects using with a simple command line interface. We will use it as an example of external application connecting to Onidel Object Storage service. You can install s3cmd via pip or as a package on many Linux distributions. 1. To access your Object Storage from external applications, you will first need to get a bucket access key. To get it, go to the Access Keys tab and note your Access and Secret key. It is recommended that each application uses a dedicated Access/Secret Key pair. To generate a new one for another app, just click Add Access Key button. 2. Next, we will perform initial configuration of s3cmd to let it manage the bucket. $ s3cmd --configure When asked, provide: - Access Key (from Step 1.) - Secret Key (from Step 1.) - S3 Endpoint - you can view the bucket endpoint in the Settings tab It should be: - s3.ap-southeast-1.onidel.cloud in Singapore - s3.ap-southeast-2.onidel.cloud in Australia - DNS-style bucket+hostname:port template for accessing a bucket - Same as S3 endpoint above but with %(bucket)s. prepended to it: - %(bucket)s.s3.ap-southeast-1.onidel.cloud in Singapore - %(bucket)s.s3.ap-southeast-2.onidel.cloud in Australia 3. After that's done, you will be presented with the full configuration and asked if you want to test and save it to a local file. New settings: Access Key: S40SVDFEQL2YZ3A7LALN Secret Key: [redacted] Default Region: SG S3 Endpoint: s3.ap-southeast-1.onidel.cloud DNS-style bucket+hostname:port template for accessing a bucket: %(bucket)s.s3.ap-southeast-1.onidel.cloud Encryption password: Path to GPG program: /usr/bin/gpg Use HTTPS protocol: True HTTP Proxy server name: HTTP Proxy server port: 0 Test access with supplied credentials? [Y/n] Y Please wait, attempting to list all buckets... Success. Your access key and secret key worked fine :-) Now verifying that encryption works... Not configured. Never mind. Save settings? [y/N] y Configuration saved to '/home/user/.s3cfg' 4. From there, you should be able to access your bucket directly from the command line using the s3cmd utility. $ s3cmd ls s3://cat-pictures 2026-03-14 15:05 20425 s3://cat-pictures/cat1.jpg 2026-03-14 15:05 57982 s3://cat-pictures/cat2.jpg 2026-03-14 15:05 68630 s3://cat-pictures/cat3.webp 2026-03-14 15:05 32602 s3://cat-pictures/cat4.jpg 2026-03-14 15:05 67608 s3://cat-pictures/cat5.jpg 5. Refer to s3cmd documentation for more detailed usage instructions. Renaming Object Storage Service Object Storage services can be renamed after purchase in case you accidentally picked the wrong name on creation or the purpose of the object storage changes. If you ever need to rename the service, go to Object Storage services list and pick Rename from the details menu. Then you can pick new desired name for the service and update it. Now you should see the new name in the list of services. Keep in mind this is entirely separate from the buckets inside the Object Storage service. Buckets can be created, removed and renamed independently. Adding Your Own Domain If you want to use your own domain with Onidel Object Storage, take a look at a dedicated tutorial.

Last updated on Mar 29, 2026

Team Management

Team Management is a built-in organizational feature used to group users who collaborate on shared resources and projects. They let you share resources, billing and control with other Onidel users. Each Team has an owner and members with predefined roles. Creating a new Team Teams can be created by any Onidel user, right from the Cloud Panel. To create a new team, navigate to Teams > Team Management and click the New Team button. You will be asked to provide a Name and Description for the team. You may use either default team's billing information (1) - usually the billing information of you as a customer, or provide per-team billing details. After that, click the Create Team button and the team should get created. Team Billing Information When you uncheck the default team's billing information checkbox, you will be asked to provide team specific details. Here, you may also choose the currency used within team (2). Team Overview In a newly created team, you will see yourself as a Team Owner and the only member. Team details (name, description) can be changed at any time. Transferring Funds to a Team As a Team Admin or Owner, you may add Team Credits. Those funds can be spent by every member of the team without affecting their own account balance. To make a transfer, select the source Team which you want to get the funds taken from. In our case, this will just be the default user's team, which had account credits topped up before. To transfer those funds to newly created team, just type in the amount into the input and press the Transfer button. Instantly after that, the credits should appear in the destination team. Inviting People While a team with one person can exist and certainly has some uses (for example changing currency, or just better grouping resources), you may want to invite some collaborators to your team. To do that, as a Team Owner or Admin, click the Invite People at the bottom of the list. From there, you may invite one or more people by providing their email address and assigning them a role. Even if the person does not currently have an active Onidel account, they will get an email with your invitation to register. Here is how the invitation email looks like. The invited person, just needs to Accept Invitation and from now they will be a part of your team. Roles In the Team, each user has a role. These roles define what actions a user can perform, what resources they can access, and how they interact with the cloud environment. Below listed are all 4 currently available roles from least to most privileged. Team Biller Person responsible for billing within a team - the one who pays invoices and manages costs. Team Biller can: - View the active services - Pay Invoices - Access Activity Log Team Member Member of the team, they can create manage shared VM instances and other services within the team. Team Member can also: - Create and manage services (VMs, Storage, Reserved IPs, etc.) - Configure Firewall Rules - Create and use the VPC network Team Admin Person managing the team. Team Admin can also: - Manage users and permissions within team (levels lower than Admin) - Add funds to the team Team Owner The user who originally created the team. Team Owner can also: - Add or remove Team Admins Each team role has access to what the roles above them have + a new set of permissions listed. Activity Log The Activity Log is a centralized audit trail that records all actions performed by members of a team on the Onidel Cloud. It is designed to provide transparency, traceability, and accountability across all team operations. The Activity Log enables teams to: - Monitor user activity in real time or retrospectively - Investigate issues and anomalies - Support compliance and auditing requirements - Track operational and financial events You can access it by going to Team > Activity Log in Onidel Cloud Panel. There is a list of all actions and events in chronological order. Each Activity has its own associated details. It contains necessary data about the environment the action was performed from and the additional context which may be helpful to trace it. Some activities (like VM provisioning after the invoice is paid) are performed by System. You may use the Additional Context to find relevant invoice which triggered the operation. Changing Primary Team You may want your new team to become the default one. It is especially useful when the account is intended for mostly collaboration (for example within a company or organization) rather than for personal use. The steps required to change it are already described as part of a different tutorial. Moving Services Between Teams While moving services between different teams is not generally possible from the panel, you may ask for the resource to be moved by opening a ticket. You need to be an owner of both the source and destination teams for the transfer to be performed.

Last updated on Apr 15, 2026

Feature Matrix

This page lists status of services and features currently available on Onidel Cloud. If the location or service is not listed in the table, it means most likely it is not supported. Premium VPS Main product page | Location | CPU | High-Availability | SEV-SNP | IPv6 | DDoS Protection | | --- | --- | --- | --- | --- | --- | | Amsterdam 🇳🇱 | EPYC Milan | ✅ | ✅ | ✅| ✅ | | Ho Chi Minh 🇻🇳 | EPYC Rome | ✅ | ❌ | ✅ | ❌ | | New York 🇺🇸 | EPYC Milan | ✅ | ✅ | ✅ | ❌ | | Singapore 🇸🇬 | EPYC Milan | ✅ | ✅ | ✅ | ❌ | | Sydney 🇦🇺 | EPYC Milan | ✅ | ✅ | ✅ | ❌ | High-Frequency VPS Main product page The CPU used on High-Frequency plans is AMD EPYC 9375F. | Location | CPU | High-Availability | SEV-SNP | IPv6 | DDoS Protection | | --- | --- | --- | --- | --- | --- | | Singapore 🇸🇬 | EPYC Turin | ❌ | ✅ | ✅ | ❌ | OniBox Storage VPS Main product page The CPU on OniBox Storage VPS is Intel Xeon Gold 6242 (2nd Gen Intel Xeon Scalable). | Location | CPU | Storage Type | High-Availability | SEV-SNP | IPv6 | | --- | --- | --- | --- | --- | --- | | Singapore 🇸🇬 | Xeon SG2 | HDD (+20GB SSD for OS) | ✅ | ❌ | ✅ | | Sydney 🇦🇺 | Xeon SG2 | HDD (+20GB SSD for OS) | ✅ | ❌ | ✅ | Block Storage Addon Main product page | Location | NVMe SSD | HDD | | --- | --- | --- | | Amsterdam 🇳🇱 | ✅ | ❌ | | Ho Chi Minh 🇻🇳 | ❌ | ❌ | | New York 🇺🇸 | ✅ | ❌ | | Singapore 🇸🇬 | ✅ | ✅ | | Sydney 🇦🇺 | ✅ | ✅ | Object Storage Main product page | Location | Replication | CORS | Lifecycle Rules | Versioning | Pre-signed URLs | Static Website | | --- | --- | --- | --- | --- | --- | --- | | Singapore 🇸🇬 | 3x | ✅ | ✅ | ✅ | ✅ | ✅ | | Sydney 🇦🇺 | 3x | ✅ | ✅ | ✅ | ✅ | ✅ | Reserved IPs | Location | IPv4 | IPv6 | | --- | --- | --- | | Amsterdam 🇳🇱 | ✅ | ✅ (/64) | | Ho Chi Minh 🇻🇳 | ✅ | ✅ (/64) | | New York 🇺🇸 | ✅ | ✅ (/64) | | Singapore 🇸🇬 | ✅ | ✅ (/64) | | Sydney 🇦🇺 | ✅ | ✅ (/64) | Virtual Private Cloud (VPC) Main article | Location | VPC | | --- | --- | | Amsterdam 🇳🇱 | ✅ | | Ho Chi Minh 🇻🇳 | ✅ | | New York 🇺🇸 | ✅ | | Singapore 🇸🇬 | ✅ | | Sydney 🇦🇺 | ✅ | BGP/BYOIP Main article | Location | BGP/BYOIP | | --- | --- | | Amsterdam 🇳🇱 | ✅ | | Ho Chi Minh 🇻🇳 | ❌ | | New York 🇺🇸 | ✅ | | Singapore 🇸🇬 | ✅ | | Sydney 🇦🇺 | ✅ | Hourly Billing Main article | Service | Hourly Billing | | --- | --- | | Premium VPS | ✅ | | High-Frequency VPS | ✅ | | OniBox Storage VPS | ❌ | | Block Storage Addon | ❌ | | Object Storage | ❌ | | Reserved IPs | ✅ |

Last updated on Mar 24, 2026

Startup Scripts

Startup Scripts on Onidel Cloud enable users to automate common initialization tasks, typically performed right after deploying a new Virtual Machine. Those are executed once during the instance creation as root in the context of guest OS, using cloud-init. They are highly reusable and location-independent, allowing you to easily standardize environments across all your deployments. Startup Scripts are primarily meant for: - Automated Software Installation - Basic Software Configuration - Security Hardening There is an example script included at the end of this wiki page showcasing how to implement those in practice. You are free to take it as a base and add any other actions you want to be performed automatically during provisioning. You can use any scripting language as long as the interpreter is included within the OS template of your choice. Creating a Script In Onidel Cloud Panel, go to Orchestration > Scripts then click on New Script. From there, you can name your script and paste its contents. Remember to use appropriate shebang in the first line of your script, so it can be interpreted correctly. To save it, click New Script at the bottom. After that, your script should be visible in the list of scripts. Deploying a VM with Startup Script You can select the Startup Script to be applied to a VM during the ordering process. After the instance is deployed, the script will automatically be executed. Keep in mind the build process may be slightly longer during the time your startup script is executed. Example Startup Script Here's an example startup script made for provisioning Debian VMs. You can treat it as a presentation of common actions performed automatically after deployment, or as a reference script to be tweaked to your liking. #!/bin/bash # name of non-root user NEW_USER="onichan" export DEBIAN_FRONTEND=noninteractive # install some common utilities apt-get update apt-get install -y fish htop btop doas vnstat iftop # create new non-root user with fish as login shell useradd -m -s /usr/bin/fish "$NEW_USER" # copy ssh authorized client key from root to new user ROOT_SSH="/root/.ssh" USER_SSH="/home/$NEW_USER/.ssh" if [ -d "$ROOT_SSH" ]; then mkdir -p "$USER_SSH" chmod 700 "$USER_SSH" if [ -f "$ROOT_SSH/authorized_keys" ]; then cp "$ROOT_SSH/authorized_keys" "$USER_SSH/" fi chown -R "$NEW_USER:$NEW_USER" "$USER_SSH" chmod 600 "$USER_SSH/authorized_keys" 2>/dev/null || true fi # configure doas echo "permit persist $NEW_USER" > /etc/doas.conf chmod 0400 /etc/doas.conf # disallow root and password login on ssh rm /etc/ssh/sshd_config.d/*cloud-init*.conf echo 'PasswordAuthentication no' >> /etc/ssh/sshd_config.d/99-custom.conf echo 'PermitRootLogin no' >> /etc/ssh/sshd_config.d/99-custom.conf systemctl restart sshd # lock root account passwd -l root # force password change on first login, password is the same as username initially echo "$NEW_USER:$NEW_USER" | chpasswd chage -d 0 "$NEW_USER" It installs some common monitoring utilities, disallows SSH password logins, blocks root user and creates a new regular user whose password needs to be changed on first login. The SSH public key is copied from root user to newly created one to allow logins using SSH key you've set when the VM deployment. It also changes user shell to fish and configures the doas utility to enable controlled execution of commands as root. Demonstration After the Virtual Machine with the example script was deployed, I logged into the VM using SSH key previously uploaded to Onidel Cloud. It first asks for the non-root user password to be set. $ ssh -i ~/.ssh/onidel_main_key [email protected] ... WARNING: Your password has expired. You must change your password now and log in again! Changing password for onichan. Current password: New password: Retype new password: passwd: password updated successfully Connection to 185.232.84.76 closed. Then I'm able to login into shell using SSH key. $ ssh -i ~/.ssh/onidel_main_key [email protected] ... Welcome to fish, the friendly interactive shell Type help for instructions on how to use fish onichan@work-vm ~> Without supplying the key, login attempts are instantly rejected. $ ssh [email protected] [email protected]: Permission denied (publickey). Inside the VM, I can also verify that monitoring utilities were installed properly. onichan@work-vm ~> vnstat -d eth0 / daily day rx | tx | total | avg. rate ------------------------+-------------+-------------+--------------- 2026-03-15 10.40 MiB | 279.38 KiB | 10.68 MiB | 16.10 kbit/s ------------------------+-------------+-------------+--------------- estimated 105.78 MiB | 2.75 MiB | 108.53 MiB |

Last updated on Mar 15, 2026