# List all API keys for the current user or organization Source: https://hyperbolic.ai/docs/api-reference/api-keys/list-all-api-keys-for-the-current-user-or-organization /api-reference/openapi.json get /v2/api-keys/list List all API keys for the current user or organization # List all API keys for the current user or organization Source: https://hyperbolic.ai/docs/api-reference/api-keys/list-all-api-keys-for-the-current-user-or-organization-1 /api-reference/openapi.json get /v2/alpha/api-keys/list **Deprecated.** This path is the pre-`/v2/` URL for `/v2/api-keys/list` and is kept only so existing integrations keep working. It behaves identically, responds with a `Sunset` header, and stops being served on 2027-03-01. Move to `/v2/api-keys/list`. List all API keys for the current user or organization # Get the current user or organization account's balance Source: https://hyperbolic.ai/docs/api-reference/balances/get-the-current-user-or-organization-accounts-balance /api-reference/openapi.json get /v2/customer/balance Get the current account's balance # Get the current user or organization account's balance Source: https://hyperbolic.ai/docs/api-reference/balances/get-the-current-user-or-organization-accounts-balance-1 /api-reference/openapi.json get /v2/alpha/customer/balance **Deprecated.** This path is the pre-`/v2/` URL for `/v2/customer/balance` and is kept only so existing integrations keep working. It behaves identically, responds with a `Sunset` header, and stops being served on 2027-03-01. Move to `/v2/customer/balance`. Get the current account's balance # Create a bare metal rental Source: https://hyperbolic.ai/docs/api-reference/bare-metal-rentals/create-a-bare-metal-rental /api-reference/openapi.json post /v2/on-demand/bare-metal-rentals **Deprecated.** Use `POST /v2/on-demand/rentals` with `rentalType: "bare-metal"`, which takes the same fields. # Create a bare metal rental Source: https://hyperbolic.ai/docs/api-reference/bare-metal-rentals/create-a-bare-metal-rental-1 /api-reference/openapi.json post /v2/alpha/on-demand/bare-metal-rentals **Deprecated.** This path is the pre-`/v2/` URL for `/v2/on-demand/bare-metal-rentals` and is kept only so existing integrations keep working. It behaves identically, responds with a `Sunset` header, and stops being served on 2027-03-01. Move to `/v2/on-demand/bare-metal-rentals`. Create a bare metal rental # Get a list of active bare metal rentals Source: https://hyperbolic.ai/docs/api-reference/bare-metal-rentals/get-a-list-of-active-bare-metal-rentals /api-reference/openapi.json get /v2/on-demand/bare-metal-rentals **Deprecated.** Returns every active bare metal rental in one response. Use `GET /v2/on-demand/rentals/active?rentalType=bare-metal`, which returns them a page at a time. # Get a list of active bare metal rentals Source: https://hyperbolic.ai/docs/api-reference/bare-metal-rentals/get-a-list-of-active-bare-metal-rentals-1 /api-reference/openapi.json get /v2/alpha/on-demand/bare-metal-rentals **Deprecated.** This path is the pre-`/v2/` URL for `/v2/on-demand/bare-metal-rentals` and is kept only so existing integrations keep working. It behaves identically, responds with a `Sunset` header, and stops being served on 2027-03-01. Move to `/v2/on-demand/bare-metal-rentals`. **Deprecated.** Returns every active bare metal rental in one response. Use `GET /v2/on-demand/rentals/active?rentalType=bare-metal`, which returns them a page at a time. # Terminate a bare metal rental Source: https://hyperbolic.ai/docs/api-reference/bare-metal-rentals/terminate-a-bare-metal-rental /api-reference/openapi.json post /v2/on-demand/bare-metal-rentals/terminate **Deprecated.** Use `POST /v2/on-demand/rentals/terminate`, which terminates either machine type. # Terminate a bare metal rental Source: https://hyperbolic.ai/docs/api-reference/bare-metal-rentals/terminate-a-bare-metal-rental-1 /api-reference/openapi.json post /v2/alpha/on-demand/bare-metal-rentals/terminate **Deprecated.** This path is the pre-`/v2/` URL for `/v2/on-demand/bare-metal-rentals/terminate` and is kept only so existing integrations keep working. It behaves identically, responds with a `Sunset` header, and stops being served on 2027-03-01. Move to `/v2/on-demand/bare-metal-rentals/terminate`. Terminate a bare metal rental # Get the public API specification Source: https://hyperbolic.ai/docs/api-reference/openapi/get-the-public-api-specification /api-reference/openapi.json get /v2/openapi.json Returns the OpenAPI 3.1 document for the public API exactly as this environment serves it, including only the endpoints this environment has enabled. This endpoint is open: it takes no API key, and sending one changes nothing about the response. # Check whether any past rentals exist Source: https://hyperbolic.ai/docs/api-reference/rentals/check-whether-any-past-rentals-exist /api-reference/openapi.json get /v2/on-demand/has-rental-history Whether the caller has at least one rental that has ended. # Convert a rental to a reserved term Source: https://hyperbolic.ai/docs/api-reference/rentals/convert-a-rental-to-a-reserved-term /api-reference/openapi.json post /v2/on-demand/convert-to-reserved Convert a rental to a reserved term # Create a rental Source: https://hyperbolic.ai/docs/api-reference/rentals/create-a-rental /api-reference/openapi.json post /v2/on-demand/rentals Rent a virtual machine or a bare metal server. `rentalType` decides which machine-type-specific fields apply; sending a field for the other type is a BAD_REQUEST (INVALID_INPUT_FOR_RENTAL_TYPE). # Extend a reserved rental Source: https://hyperbolic.ai/docs/api-reference/rentals/extend-a-reserved-rental /api-reference/openapi.json post /v2/on-demand/extend-reserved Extend a reserved rental # Get a list of past rentals Source: https://hyperbolic.ai/docs/api-reference/rentals/get-a-list-of-past-rentals /api-reference/openapi.json get /v2/on-demand/rental-history **Deprecated.** Returns every past rental in one response. Use `GET /v2/on-demand/rentals/history`, which returns them a page at a time. # Get a list of past rentals Source: https://hyperbolic.ai/docs/api-reference/rentals/get-a-list-of-past-rentals-1 /api-reference/openapi.json get /v2/alpha/on-demand/rental-history **Deprecated.** This path is the pre-`/v2/` URL for `/v2/on-demand/rental-history` and is kept only so existing integrations keep working. It behaves identically, responds with a `Sunset` header, and stops being served on 2027-03-01. Move to `/v2/on-demand/rental-history`. **Deprecated.** Returns every past rental in one response. Use `GET /v2/on-demand/rentals/history`, which returns them a page at a time. # Get a list of rental options Source: https://hyperbolic.ai/docs/api-reference/rentals/get-a-list-of-rental-options /api-reference/openapi.json get /v2/on-demand/rental-options Get a list of rental options # Get a list of rental options Source: https://hyperbolic.ai/docs/api-reference/rentals/get-a-list-of-rental-options-1 /api-reference/openapi.json get /v2/alpha/on-demand/rental-options **Deprecated.** This path is the pre-`/v2/` URL for `/v2/on-demand/rental-options` and is kept only so existing integrations keep working. It behaves identically, responds with a `Sunset` header, and stops being served on 2027-03-01. Move to `/v2/on-demand/rental-options`. Get a list of rental options # Get a list of reserve options Source: https://hyperbolic.ai/docs/api-reference/rentals/get-a-list-of-reserve-options /api-reference/openapi.json get /v2/on-demand/reserve-options Get a list of reserve options # Get a list of reserve options Source: https://hyperbolic.ai/docs/api-reference/rentals/get-a-list-of-reserve-options-1 /api-reference/openapi.json get /v2/alpha/on-demand/reserve-options **Deprecated.** This path is the pre-`/v2/` URL for `/v2/on-demand/reserve-options` and is kept only so existing integrations keep working. It behaves identically, responds with a `Sunset` header, and stops being served on 2027-03-01. Move to `/v2/on-demand/reserve-options`. Get a list of reserve options # Get a rental Source: https://hyperbolic.ai/docs/api-reference/rentals/get-a-rental /api-reference/openapi.json get /v2/on-demand/rental Look up one rental by its ID, whether it is still running or has ended. Returns null when no rental with that ID belongs to the caller. # Get a reservation extension quote Source: https://hyperbolic.ai/docs/api-reference/rentals/get-a-reservation-extension-quote /api-reference/openapi.json get /v2/on-demand/get-reservation-extension-quote Get a reservation extension quote # Get a reserved conversion quote Source: https://hyperbolic.ai/docs/api-reference/rentals/get-a-reserved-conversion-quote /api-reference/openapi.json get /v2/on-demand/get-reserved-conversion-quote Get a reserved conversion quote # Get a summary of active rentals Source: https://hyperbolic.ai/docs/api-reference/rentals/get-a-summary-of-active-rentals /api-reference/openapi.json get /v2/on-demand/active-rental-summary Count the caller's active rentals and sum their hourly cost in cents, in total and per term type. # List active rentals Source: https://hyperbolic.ai/docs/api-reference/rentals/list-active-rentals /api-reference/openapi.json get /v2/on-demand/rentals/active Active rentals of one machine type with their live status, most recently started first, as numbered pages. # List past rentals Source: https://hyperbolic.ai/docs/api-reference/rentals/list-past-rentals /api-reference/openapi.json get /v2/on-demand/rentals/history Past rentals, most recently terminated first, one page at a time. Pass the response's `nextCursor` as `cursor` to read the next page. # Reboot a single instance within a rental Source: https://hyperbolic.ai/docs/api-reference/rentals/reboot-a-single-instance-within-a-rental /api-reference/openapi.json post /v2/on-demand/rentals/reboot-instance Reboots one instance in place; tenant data is preserved. Call it only for an instance whose `instances[].supportedFeatures` includes `guest-reboot`. Reports INVALID_INSTANCE_REF for an `instanceRef` outside this rental, REBOOT_NOT_SUPPORTED for a rental whose provider cannot reboot, and REBOOT_ALREADY_IN_PROGRESS while one is in flight. # Request a reservation Source: https://hyperbolic.ai/docs/api-reference/rentals/request-a-reservation /api-reference/openapi.json post /v2/on-demand/request-reservation Request a reservation for a large instance # Request a reservation Source: https://hyperbolic.ai/docs/api-reference/rentals/request-a-reservation-1 /api-reference/openapi.json post /v2/alpha/on-demand/request-reservation **Deprecated.** This path is the pre-`/v2/` URL for `/v2/on-demand/request-reservation` and is kept only so existing integrations keep working. It behaves identically, responds with a `Sunset` header, and stops being served on 2027-03-01. Move to `/v2/on-demand/request-reservation`. Request a reservation for a large instance # Terminate a rental Source: https://hyperbolic.ai/docs/api-reference/rentals/terminate-a-rental /api-reference/openapi.json post /v2/on-demand/rentals/terminate Terminate a virtual machine or bare metal rental. # Update a rental Source: https://hyperbolic.ai/docs/api-reference/rentals/update-a-rental /api-reference/openapi.json post /v2/on-demand/rentals/update Update a rental's label and/or its reserved-term end-of-term action. Pass an empty label to clear it. # Update a rental Source: https://hyperbolic.ai/docs/api-reference/rentals/update-a-rental-1 /api-reference/openapi.json post /v2/alpha/on-demand/rentals/update **Deprecated.** This path is the pre-`/v2/` URL for `/v2/on-demand/rentals/update` and is kept only so existing integrations keep working. It behaves identically, responds with a `Sunset` header, and stops being served on 2027-03-01. Move to `/v2/on-demand/rentals/update`. Update a rental's label and/or its reserved-term end-of-term action. Pass an empty label to clear it. # Create an SSH public key for the current user or organization Source: https://hyperbolic.ai/docs/api-reference/ssh-keys/create-an-ssh-public-key-for-the-current-user-or-organization /api-reference/openapi.json post /v2/ssh-keys Create an SSH public key for the current user or organization. Reports SSH_PUBLIC_KEY_ALREADY_EXISTS when a key with identical type and body already exists under the current user or organization. # Delete an SSH public key Source: https://hyperbolic.ai/docs/api-reference/ssh-keys/delete-an-ssh-public-key /api-reference/openapi.json post /v2/ssh-keys/delete Deletes an SSH public key. Reports SSH_PUBLIC_KEY_IN_USE while the key is attached to a live rental, SSH_PUBLIC_KEY_NOT_FOUND for a key that doesn't exist or the user doesn't control, and NOT_AUTHORIZED_TO_ACCESS_OWNED_RESOURCE for an organization key added by another member unless the caller is an organization admin. # List SSH public keys for the current user or organization Source: https://hyperbolic.ai/docs/api-reference/ssh-keys/list-ssh-public-keys-for-the-current-user-or-organization /api-reference/openapi.json get /v2/ssh-keys List SSH public keys for the current user or organization # List the SSH public keys attached to a rental Source: https://hyperbolic.ai/docs/api-reference/ssh-keys/list-the-ssh-public-keys-attached-to-a-rental /api-reference/openapi.json get /v2/ssh-keys/rental List the SSH public keys attached to a rental. Reports RENTAL_NOT_FOUND for rentals that don't exist or the user doesn't control. # Rename an SSH public key Source: https://hyperbolic.ai/docs/api-reference/ssh-keys/rename-an-ssh-public-key /api-reference/openapi.json post /v2/ssh-keys/update Renames an SSH public key. Reports SSH_PUBLIC_KEY_NOT_FOUND for keys that don't exist or the user doesn't control, and NOT_AUTHORIZED_TO_ACCESS_OWNED_RESOURCE for an organization key added by another member unless the caller is an organization admin. # Attach a storage volume to bare metal instance(s) Source: https://hyperbolic.ai/docs/api-reference/storage-volumes/attach-a-storage-volume-to-bare-metal-instances /api-reference/openapi.json post /v2/on-demand/storage-volumes/attach Attach a storage volume to bare metal instance(s) # Attach a storage volume to bare metal instance(s) Source: https://hyperbolic.ai/docs/api-reference/storage-volumes/attach-a-storage-volume-to-bare-metal-instances-1 /api-reference/openapi.json post /v2/alpha/on-demand/storage-volumes/attach **Deprecated.** This path is the pre-`/v2/` URL for `/v2/on-demand/storage-volumes/attach` and is kept only so existing integrations keep working. It behaves identically, responds with a `Sunset` header, and stops being served on 2027-03-01. Move to `/v2/on-demand/storage-volumes/attach`. Attach a storage volume to bare metal instance(s) # Create a storage volume Source: https://hyperbolic.ai/docs/api-reference/storage-volumes/create-a-storage-volume /api-reference/openapi.json post /v2/on-demand/storage-volumes Create a storage volume # Create a storage volume Source: https://hyperbolic.ai/docs/api-reference/storage-volumes/create-a-storage-volume-1 /api-reference/openapi.json post /v2/alpha/on-demand/storage-volumes **Deprecated.** This path is the pre-`/v2/` URL for `/v2/on-demand/storage-volumes` and is kept only so existing integrations keep working. It behaves identically, responds with a `Sunset` header, and stops being served on 2027-03-01. Move to `/v2/on-demand/storage-volumes`. Create a storage volume # Get a list of storage volume options Source: https://hyperbolic.ai/docs/api-reference/storage-volumes/get-a-list-of-storage-volume-options /api-reference/openapi.json get /v2/on-demand/storage-volume-options Get a list of storage volume options # Get a list of storage volume options Source: https://hyperbolic.ai/docs/api-reference/storage-volumes/get-a-list-of-storage-volume-options-1 /api-reference/openapi.json get /v2/alpha/on-demand/storage-volume-options **Deprecated.** This path is the pre-`/v2/` URL for `/v2/on-demand/storage-volume-options` and is kept only so existing integrations keep working. It behaves identically, responds with a `Sunset` header, and stops being served on 2027-03-01. Move to `/v2/on-demand/storage-volume-options`. Get a list of storage volume options # Get a list of storage volumes Source: https://hyperbolic.ai/docs/api-reference/storage-volumes/get-a-list-of-storage-volumes /api-reference/openapi.json get /v2/on-demand/storage-volumes Get a list of storage volumes # Get a list of storage volumes Source: https://hyperbolic.ai/docs/api-reference/storage-volumes/get-a-list-of-storage-volumes-1 /api-reference/openapi.json get /v2/alpha/on-demand/storage-volumes **Deprecated.** This path is the pre-`/v2/` URL for `/v2/on-demand/storage-volumes` and is kept only so existing integrations keep working. It behaves identically, responds with a `Sunset` header, and stops being served on 2027-03-01. Move to `/v2/on-demand/storage-volumes`. Get a list of storage volumes # Terminate a storage volume Source: https://hyperbolic.ai/docs/api-reference/storage-volumes/terminate-a-storage-volume /api-reference/openapi.json post /v2/on-demand/storage-volumes/terminate Terminate a storage volume # Terminate a storage volume Source: https://hyperbolic.ai/docs/api-reference/storage-volumes/terminate-a-storage-volume-1 /api-reference/openapi.json post /v2/alpha/on-demand/storage-volumes/terminate **Deprecated.** This path is the pre-`/v2/` URL for `/v2/on-demand/storage-volumes/terminate` and is kept only so existing integrations keep working. It behaves identically, responds with a `Sunset` header, and stops being served on 2027-03-01. Move to `/v2/on-demand/storage-volumes/terminate`. Terminate a storage volume # Update a storage volume Source: https://hyperbolic.ai/docs/api-reference/storage-volumes/update-a-storage-volume /api-reference/openapi.json post /v2/on-demand/storage-volumes/update Update a storage volume's attached instances and/or size # Update a storage volume Source: https://hyperbolic.ai/docs/api-reference/storage-volumes/update-a-storage-volume-1 /api-reference/openapi.json post /v2/alpha/on-demand/storage-volumes/update **Deprecated.** This path is the pre-`/v2/` URL for `/v2/on-demand/storage-volumes/update` and is kept only so existing integrations keep working. It behaves identically, responds with a `Sunset` header, and stops being served on 2027-03-01. Move to `/v2/on-demand/storage-volumes/update`. Update a storage volume's attached instances and/or size # Delete the current user Source: https://hyperbolic.ai/docs/api-reference/users/delete-the-current-user /api-reference/openapi.json delete /v2/users/me Delete the current user # Delete the current user Source: https://hyperbolic.ai/docs/api-reference/users/delete-the-current-user-1 /api-reference/openapi.json delete /users/me **Deprecated.** This path is the pre-`/v2/` URL for `/v2/users/me` and is kept only so existing integrations keep working. It behaves identically, responds with a `Sunset` header, and stops being served on 2027-03-01. Move to `/v2/users/me`. Delete the current user # Get the current user Source: https://hyperbolic.ai/docs/api-reference/users/get-the-current-user /api-reference/openapi.json get /v2/users/me Get the current user # Get the current user Source: https://hyperbolic.ai/docs/api-reference/users/get-the-current-user-1 /api-reference/openapi.json get /users/me **Deprecated.** This path is the pre-`/v2/` URL for `/v2/users/me` and is kept only so existing integrations keep working. It behaves identically, responds with a `Sunset` header, and stops being served on 2027-03-01. Move to `/v2/users/me`. Get the current user # Update the current user Source: https://hyperbolic.ai/docs/api-reference/users/update-the-current-user /api-reference/openapi.json put /v2/users/me Update the current user # Update the current user Source: https://hyperbolic.ai/docs/api-reference/users/update-the-current-user-1 /api-reference/openapi.json put /users/me **Deprecated.** This path is the pre-`/v2/` URL for `/v2/users/me` and is kept only so existing integrations keep working. It behaves identically, responds with a `Sunset` header, and stops being served on 2027-03-01. Move to `/v2/users/me`. Update the current user # Verify a phone number Source: https://hyperbolic.ai/docs/api-reference/users/verify-a-phone-number /api-reference/openapi.json put /v2/users/me/verify-phone-number Verify a phone number # Verify a phone number Source: https://hyperbolic.ai/docs/api-reference/users/verify-a-phone-number-1 /api-reference/openapi.json put /users/me/verify-phone-number **Deprecated.** This path is the pre-`/v2/` URL for `/v2/users/me/verify-phone-number` and is kept only so existing integrations keep working. It behaves identically, responds with a `Sunset` header, and stops being served on 2027-03-01. Move to `/v2/users/me/verify-phone-number`. Verify a phone number # Create a virtual machine rental Source: https://hyperbolic.ai/docs/api-reference/virtual-machine-rentals/create-a-virtual-machine-rental /api-reference/openapi.json post /v2/on-demand/virtual-machine-rentals **Deprecated.** Use `POST /v2/on-demand/rentals` with `rentalType: "virtual-machine"`, which takes the same fields. # Create a virtual machine rental Source: https://hyperbolic.ai/docs/api-reference/virtual-machine-rentals/create-a-virtual-machine-rental-1 /api-reference/openapi.json post /v2/alpha/on-demand/virtual-machine-rentals **Deprecated.** This path is the pre-`/v2/` URL for `/v2/on-demand/virtual-machine-rentals` and is kept only so existing integrations keep working. It behaves identically, responds with a `Sunset` header, and stops being served on 2027-03-01. Move to `/v2/on-demand/virtual-machine-rentals`. Create a virtual machine rental # Get a list of active virtual machine rentals Source: https://hyperbolic.ai/docs/api-reference/virtual-machine-rentals/get-a-list-of-active-virtual-machine-rentals /api-reference/openapi.json get /v2/on-demand/virtual-machine-rentals **Deprecated.** Returns every active virtual machine rental in one response. Use `GET /v2/on-demand/rentals/active?rentalType=virtual-machine`, which returns them a page at a time. # Get a list of active virtual machine rentals Source: https://hyperbolic.ai/docs/api-reference/virtual-machine-rentals/get-a-list-of-active-virtual-machine-rentals-1 /api-reference/openapi.json get /v2/alpha/on-demand/virtual-machine-rentals **Deprecated.** This path is the pre-`/v2/` URL for `/v2/on-demand/virtual-machine-rentals` and is kept only so existing integrations keep working. It behaves identically, responds with a `Sunset` header, and stops being served on 2027-03-01. Move to `/v2/on-demand/virtual-machine-rentals`. **Deprecated.** Returns every active virtual machine rental in one response. Use `GET /v2/on-demand/rentals/active?rentalType=virtual-machine`, which returns them a page at a time. # Reboot a single instance within a virtual machine rental Source: https://hyperbolic.ai/docs/api-reference/virtual-machine-rentals/reboot-a-single-instance-within-a-virtual-machine-rental /api-reference/openapi.json post /v2/on-demand/virtual-machine-rentals/reboot-instance **Deprecated.** Use `POST /v2/on-demand/rentals/reboot-instance`, which takes the same fields. # Terminate a virtual machine rental Source: https://hyperbolic.ai/docs/api-reference/virtual-machine-rentals/terminate-a-virtual-machine-rental /api-reference/openapi.json post /v2/on-demand/virtual-machine-rentals/terminate **Deprecated.** Use `POST /v2/on-demand/rentals/terminate`, which terminates either machine type. # Terminate a virtual machine rental Source: https://hyperbolic.ai/docs/api-reference/virtual-machine-rentals/terminate-a-virtual-machine-rental-1 /api-reference/openapi.json post /v2/alpha/on-demand/virtual-machine-rentals/terminate **Deprecated.** This path is the pre-`/v2/` URL for `/v2/on-demand/virtual-machine-rentals/terminate` and is kept only so existing integrations keep working. It behaves identically, responds with a `Sunset` header, and stops being served on 2027-03-01. Move to `/v2/on-demand/virtual-machine-rentals/terminate`. Terminate a virtual machine rental # Changelog Source: https://hyperbolic.ai/docs/changelog New features, updates, and fixes to the Hyperbolic platform ## New features * **Change SSH keys on a live instance.** You can now attach or detach a saved SSH key on a running or pending virtual machine rental without relaunching it. Use this to fix a launch with the wrong key, replace a lost key, or give a teammate access. Changes apply to every node without a reboot. This is available through the API today: `POST /v2/on-demand/rentals/ssh-keys/attach` and `POST /v2/on-demand/rentals/ssh-keys/detach`, each with a `rentalId` and `sshPublicKeyId`. See [SSH keys](/docs/general/account-management#ssh-keys). * Personal rentals use your personal keys. Organization rentals use the organization's keys. * Any organization member can attach a key. Detaching is limited to admins and the member who created the rental. * A rental must keep at least one key. Detaching the last key returns `CANNOT_DETACH_LAST_RENTAL_SSH_KEY`. * Rentals that can't change keys, including all bare metal rentals, return `RENTAL_SSH_KEY_UPDATE_NOT_SUPPORTED`. * If a change fails with `FAILED_TO_UPDATE_RENTAL_SSH_KEYS`, you can safely retry it. ## New features * **Availability alerts.** You can get an email when a GPU configuration you want becomes available. Manage alerts from the alerts page. Pause, resume, or delete them, and launch a rental straight from a matched alert. Alerts are grouped into active and done tabs, and you can have up to 10 active alerts. Learn more in [Availability alerts](/docs/on-demand/availability-alerts). * **Multiple SSH keys.** You can now save more than one SSH key and choose one or more keys when you launch an instance. Each instance's details page lists the keys attached to it. See [SSH keys](/docs/general/account-management#ssh-keys). * **Organization SSH keys.** Organizations can now share SSH keys. Members can add and view keys. Admins can manage any key in the organization. See [Organizations](/docs/general/organizations). * **Event codes.** You can now scan an event QR code to claim free credit. Sign in or sign up, then choose your personal account or an organization to receive the credit. Some codes apply only to organizations, and you can create one during the flow. Each code can be redeemed once per account or organization, and once per person. After you redeem, you see the credit applied and your updated balance. See [Organizations](/docs/general/organizations). * **Spot rentals.** For eligible GPU configurations, the Launch Instance page now offers **Spot** as a term next to pay as you go. Spot costs 10% less per hour. Spot instances can be interrupted with 30 minutes' notice, and Hyperbolic emails you first. The Launch Instance page and the instance details page show the spot rate and the exact notice period. See [Pricing](/docs/on-demand/pricing). * **Instance management panel.** SSH access and reboot controls now live together in one panel on the instance details page. Multi-node rentals show each node in a table, or as cards on mobile. See [Managing instances](/docs/on-demand/managing-instances#rebooting-an-instance). ## Updates * **Managed Kubernetes (beta).** * Download a per-cluster SSO kubeconfig from **Cluster info**. See [kubectl access](/docs/managed-kubernetes/kubectl-access). * New node group pages for compute, billing, and settings, plus a node detail view. * Cluster usage now appears in your billing history. * Hyperbolic now emails you about low balance, control-plane status, and cluster termination. * Refreshed layout with a Beta label in the navigation, an actions menu, and better mobile support. * The cluster API endpoint now appears in full in the **Cluster info** card, with a copy button. The **Copy API endpoint** item is no longer in the cluster actions menu. * The cluster creation wizard and order summary no longer show control-plane class or replica details. Hyperbolic manages the control plane for you. * Cluster bring-up progress now tracks worker provisioning, node joining, and add-on installation, with simpler status text. * Learn more in [Managed Kubernetes](/docs/on-demand/managed-kubernetes). * **Alert emails.** Alert emails now include the connection type and a link to your alerts page. When you open an alert email, the dashboard tells you whether the GPUs are still available. * **GPU count filter.** GPU counts on alerts and the GPUs page now mean "N or more" GPUs. See [GPU count filter](/docs/on-demand/availability-alerts#gpu-count-filter-on-the-gpus-page). * **Public API.** * New paginated endpoints for active rentals and rental history, with filters for GPU type, region, and term type. The older unpaginated list endpoints are deprecated. * SSH key endpoints are now available, so you can list, create, rename, and delete keys. * New unified endpoints create, terminate, and reboot rentals of either machine type: `POST /v2/on-demand/rentals`, `POST /v2/on-demand/rentals/terminate`, and `POST /v2/on-demand/rentals/reboot-instance`. Set `rentalType` to `virtual-machine` or `bare-metal` when you create a rental. The per-type `virtual-machine-rentals` and `bare-metal-rentals` create, terminate, and reboot endpoints are deprecated but still work. * Endpoints to get a single rental, an active rental summary, and whether you have past rentals are now available. * Timestamps are now returned in RFC 3339 format. * GPU and storage counts in rental options are now rounded down to fixed steps. * New unified endpoints to create, terminate, and reboot rentals: `POST /v2/on-demand/rentals`, `POST /v2/on-demand/rentals/terminate`, and `POST /v2/on-demand/rentals/reboot-instance`. Set `rentalType` to choose a virtual machine or bare metal rental. Requests with fields that don't apply to the chosen type now return a clear `INVALID_INPUT_FOR_RENTAL_TYPE` error. * The separate virtual machine and bare metal create, terminate, and reboot endpoints are deprecated. They still work, and each one points to its replacement. * The **Virtual machine rentals** and **Bare metal rentals** groups are now marked deprecated in the API reference and listed last. Their endpoints still work, but we recommend the unified rental endpoints for new integrations. * The current user response from `GET /v2/users/me` no longer includes the `roles` list. Use the `role` field instead. * **Auto Top-Up reliability.** If an automatic top-up is interrupted, Hyperbolic now retries it. New safeguards make sure a retry never charges you twice. See [Auto Top-Up](/docs/general/auto-top-up). ## Bug fixes * Credits that Hyperbolic adds to your personal balance now unlock renting right away, the same as a card purchase. You no longer need to pay by card first. See [Account management](/docs/general/account-management). * Instance status no longer flips away from **Running** while a node reboots. * Custom ports now show on the instance details page for all eligible instances. * Managed Kubernetes node details now show the node's public IP. Before, the field was always empty. Use this IP to reach workloads on the ports you open. See [Managed Kubernetes](/docs/on-demand/managed-kubernetes). * Retrying a Managed Kubernetes cluster launch after a network or server error no longer creates a second, separately billed cluster. The retry resumes the original launch. See [Managed Kubernetes](/docs/on-demand/managed-kubernetes). * Managed Kubernetes node details now show the size of each NVMe disk. Before, every disk showed the node's total disk capacity. See [Managed Kubernetes](/docs/on-demand/managed-kubernetes). * Managed Kubernetes cluster and node group names are now validated on every request. Opening a cluster page with a malformed name now shows a not found page. * A temporary error from the cluster provider no longer marks a running Managed Kubernetes cluster as ended. When the provider removes a cluster, billing now stops at the time the deletion started. * The instance details page now shows each node's internal IP for rentals where it was missing. * Availability alerts now match on offered configurations, not free GPU counts, and no longer count the same GPUs twice. * GPUs that just sold out no longer appear as available. * The login modal now closes automatically when you're already signed in. * Signing in from a link now returns you to the exact page you opened, including its query parameters. * Fixed a 404 on the Support link in Private Cloud navigation. * Fixed the layout of past instance cards so the time sits under the price. * API error responses no longer include internal debugging details. * Terminating a bare metal rental that doesn't exist or has already ended now returns `RENTAL_NOT_FOUND` instead of a generic lookup error. * If a new bare metal rental fails or ends while it's provisioning, the launch screen now tells you. Before, it kept loading. See [Managing instances](/docs/on-demand/managing-instances). * Spot interruption emails now use the correct template for both personal and organization rentals. Each notice shows the instance name and interruption time in a consistent format. * An instance's running time no longer shows a wrong value or flickers when the page first loads. It now shows a placeholder until the time is calculated, then counts up every second. See [Managing instances](/docs/on-demand/managing-instances). # Account Management Source: https://hyperbolic.ai/docs/general/account-management Create and configure your Hyperbolic account, API keys, and SSH keys ## Plan This is where you view and manage your plan. Your plan determines your level of access to the platform and your API rate limits. There is never a monthly commitment to maintaining a plan. For all plans, you purchase “compute credits” which sit as a balance on your account. You use your compute credit balance for services on the platform, e.g. launching GPU instances and storage volumes, and creating storage volumes. Account Settings Plan page showing the Current Plan section, a phone-verification credit banner, and the Free Tier card We offer three plan tiers: free, pro, and enterprise. **Free tier:** The default plan for new accounts. There is no minimum spend amount required. You may not launch GPU instances nor storage volumes with a free-tier account. API rate limits are restrictive. Free Tier plan card showing $0.00/month, 60 RPM rate limit, 100 IP limit, and a prompt to deposit $5 to reach Pro Tier **Pro:** You must deposit at least \$5 one-time to automatically become a pro-tier user. You may access all features of the platform including GPU instances and storage volumes. Your API rate limits are much higher. Pro Tier plan card showing $0.00/month, 600 RPM rate limit, 100 IP limit, on-demand compute, pay as you go, and an Upgrade Now button **Enterprise:** For any custom plan, please reach out to us. Enterprise Tier plan card showing Custom Pricing with enterprise-grade security, unlimited rate limit, unlimited IP limit, dedicated instances, dedicated support, fine-tuning services, and a Contact Us to Upgrade button ## Billing This is where you view and edit your billing details. Billing Overview showing My Balance, Next Auto Top-Up, and Hourly Cost cards with an Add Funds button We do not keep your payment method on file unless you have chosen to store a card by enabling [Auto Top-Up](/docs/general/auto-top-up). ## API Keys This is where you create and manage your API Keys. Personal API Keys settings page with a Create API Key button and an empty API key list After creation, API keys cannot be viewed or recovered - make sure you copy and save your key immediately after creating it! API keys may be revoked at any time. An account may have any number of API keys. ## SSH Keys Manage your SSH public keys under **Settings > SSH Keys** in the [dashboard](https://app.hyperbolic.ai/settings/ssh-keys). An SSH key is required to provision GPU instances. Only add your SSH public key (for example, `id_ed25519.pub`). Never upload a private key. You can save multiple SSH keys to your account. For each key, you can: * **Add** a key by pasting it or dragging and dropping your `.pub` file. Hyperbolic pre-fills the name from the key's comment, and you can change it to something you'll recognize. * **Rename** a key at any time. * **Copy** a key's public key text. * **Delete** a key that isn't attached to a live instance. Hyperbolic rejects a key that's already saved on your account. The comparison ignores the key's comment, so the same key with a different comment counts as a duplicate. ### Choose a key when you launch When you rent an instance, you select one of your saved keys in the **Who can SSH into this instance?** step. You can also paste a new key there, and Hyperbolic saves it to your account. If you have only one saved key, it's selected automatically. The instance is provisioned with the selected key, so keep the matching private key on your machine or you may lose access to the instance. ### Attach multiple keys to an instance Some regions let you attach more than one SSH key to an instance, so several people can connect with their own keys. After you select a key, an **Add another key** button appears below it when the region you chose supports multiple keys. Click it to pick another saved key or paste a new one. Click **Remove** to detach a key before you launch. If you don't see **Add another key**, that region accepts one key per instance. If you switch from a multi-key region to a single-key region, Hyperbolic keeps only the first key you selected. An API request that attaches more than one key in a single-key region returns the `MULTIPLE_SSH_PUBLIC_KEYS_NOT_SUPPORTED_FOR_REGION` error. If a rental request through the API doesn't specify a key, Hyperbolic attaches your newest saved key. Under an Organization, Hyperbolic uses the Organization's newest key. To choose keys yourself, pass their IDs (from `GET /v2/ssh-keys`) in the `sshPublicKeyIds` array when you create a rental. ### Keys in use The key list shows how many live instances use each key. You can't delete a key while it's attached to a live instance. Terminate the instance first, then delete the key. ### Manage keys with the API You can also manage SSH keys through the Hyperbolic API with these endpoints. See the API Reference for full request and response schemas. | Method | Endpoint | Description | | - | - | - | | `GET` | `/v2/ssh-keys` | List your SSH keys | | `POST` | `/v2/ssh-keys` | Add an SSH key | | `POST` | `/v2/ssh-keys/update` | Rename an SSH key | | `POST` | `/v2/ssh-keys/delete` | Delete an SSH key | | `GET` | `/v2/ssh-keys/rental` | List the SSH keys attached to a rental | For example, add a key with an optional name: ```bash theme={null} curl -X POST https://api.hyperbolic.ai/v2/ssh-keys \ -H "Authorization: Bearer $HYPERBOLIC_API_KEY" \ -H "Content-Type: application/json" \ -d "{\"publicKey\": \"$(cat ~/.ssh/id_ed25519.pub)\", \"name\": \"Work laptop\"}" ``` Adding a duplicate key returns the `SSH_PUBLIC_KEY_ALREADY_EXISTS` error. When your API key belongs to an [Organization](/docs/general/organizations#ssh-keys), these endpoints manage the Organization's SSH keys instead of your personal keys. # Auto Top-Up Source: https://hyperbolic.ai/docs/general/auto-top-up Automatically recharge your balance to keep resources running Auto Top-Up is a powerful feature to help keep your account balance positive. It helps safeguard your running resources from automatic termination. We collect and securely store a specified payment method, then automatically charge that payment method when your account balance falls below a threshold. You configure the amount and the threshold. ## Enabling Auto Top-Up Follow the instructions below to enable Auto Top-Up. Go to **Settings → Billing** in the Hyperbolic dashboard. Under Billing, select **Enable Auto Top-Up**. Billing Overview with the Enable Auto Top-Up button in the Next Auto Top-Up card Add at least one payment method to keep on file. In **When my balance goes below…**, enter the balance that should trigger an automatic charge. In **Automatically add**, enter the amount Hyperbolic should charge when your balance falls below the threshold. Review the payment method, threshold, and top-up amount, then select **Confirm**. You may add additional payment methods at any time, but there is only ever one default payment method that is charged. **Coming soon:** Customers will soon be able to specify a backup payment method to use in the event that charging the default payment method fails. **Auto Top-Ups are not foolproof.** This is a convenience to make balance management easier — make sure your payment method is valid and your settings are configured correctly. We recommend a threshold equal to **72h of usage** and a top-up amount equal to **24h of usage** to prevent surprises and give plenty of time to remedy any issues. It is your responsibility to maintain a positive balance in your account. ## How Auto Top-Up works Auto Top-Up evaluates your balance **every 10 minutes** and may trigger a charge at each evaluation if your balance meets the configured threshold. It may miss massive spikes of usage that rapidly deplete your balance within that timeframe. The logic is conservative and avoids double-charging. If a payment fails, it uses a backoff strategy to avoid creating problems with your payment method (such as overdrafted accounts, account locks, or triggered fraud rules). Auto Top-Up will attempt multiple charges before giving up. If it cannot successfully charge the payment method on file within the limits of its retry policy, **you will be alerted and Auto Top-Up will be automatically disabled**. You must correct the issue with your payment method before re-enabling Auto Top-Up. # Billing and Payments Source: https://hyperbolic.ai/docs/general/billing-payments Manage billing, payment methods, credits, and pricing tiers ## Compute credits You can purchase compute credits at any time (minimum \$5). Credits are always 1:1 with the dollar amount purchased, sit in your account as a positive balance until used, and **never expire**. ## How credits are used Your balance decreases as you use services: | Service | Billing basis | | - | - | | GPU instances | On-demand: hourly · Reserved: up-front | | Storage volumes | Hourly, per GB of capacity | | Private Cloud | Custom contract — billed separately, not from credits | ## Fund your account ### Balance requirements You must maintain a positive account balance to continue using eligible Hyperbolic services. If your balance reaches zero or becomes negative: * You may be unable to launch new GPU instances. * Running GPU instances may be terminated. * Storage Volumes may be terminated after the applicable grace period. * Workloads may be interrupted. * Data stored directly on terminated instances may be permanently lost. Configure [Auto Top-Up](/docs/general/auto-top-up) to help maintain a positive balance and reduce the risk of service interruption. ### Add funds to your account To purchase compute credits: 1. Sign in to the Hyperbolic dashboard. 2. Select Deposit in the upper-right corner. 3. Enter the amount you want to add. 4. Complete checkout. Your account balance updates after the payment is processed. ### Transaction history The Billing page lists every deposit, charge, and credit on your account, including **pending** charges for running instances that haven't settled yet. Use it to reconcile spend or confirm a credit was applied. ### Billing and balance troubleshooting Did you make sure to deposit at least \$5, one-time? You need to do this to become a “pro” plan user before you can create GPU instances. There is no minimum charge for on-demand instances, but you are required to have a balance high enough to cover at least one hour of instance runtime at instance creation. This one hour of instance runtime includes the hourly cost of all your pending and running instances plus the new instance you intend to create. Did your account balance run out? Make sure to always keep a comfortable balance in your account to avoid automatic resource termination. Did you enable [Auto Top-Up](/docs/general/auto-top-up)? This feature helps keep your account balance positive and avoids automatic resource termination. Make sure that your Auto Top-Up is actually enabled - it must both be configured and enabled in order to work. Make sure the default payment method configured in your Auto Top-Up settings is active, valid, and not overdrafted or locked. Are your settings appropriate for your account activity? If the top-up amount or the top-up threshold is too low, Auto Top-Up may not have been able to keep up with your account spend. Auto Top-Up re-evaluates your balance every 10 minutes at most. We recommend setting the top-up threshold equal to 72h of usage, and a top-up amount equal to 24h of usage to prevent surprises and to give plenty of time to remedy any issues. Did a payment fail? Auto Top-Up is conservative and will avoid double-charging, overdrafting, or triggering account locks and fraud rules on your payment methods. If a payment fails, Auto Top-Up is probably backing off and retrying later. Keep an eye on your notifications! We will notify you when any charge fails. # Organizations Source: https://hyperbolic.ai/docs/general/organizations Share a workspace, billing balance, and infrastructure with your team Organizations let a team share access to the same workspace, billing balance, and infrastructure. Instead of teammates renting GPUs from separate personal accounts, everyone works from one shared account with shared funds and shared visibility into running instances. ## When to use an Organization * Your team shares a compute budget and wants one balance to fund and monitor * Multiple people need to launch, monitor, or terminate the same instances * You want infrastructure to survive personnel changes rather than living in one person's personal account ## Create or join an Organization 1. Open the **top-left menu** in your [dashboard](https://app.hyperbolic.ai) — you'll see your Personal workspace and a **New Organization** option. 2. Create the Organization, then **invite your teammates** by email. 3. Switch between your Personal workspace and Organizations from the same menu at any time. Organization switcher menu in the top-left of the dashboard, showing the Personal organization and a New Organization option Create or join your Organization **before** launching workloads, so instances and billing live in the shared workspace from the start. ## Roles and permissions Organizations have two roles. | | Admin | Member | | - | - | - | | Launch, manage, and terminate instances | ✓ | ✓ | | Spend from the shared balance | ✓ | ✓ | | Deposit funds and manage payment methods | ✓ | — | | Configure Auto Top-Up | ✓ | — | | Invite and remove members, change roles | ✓ | — | | View billing and purchase history | ✓ | — | | Create API keys for the Organization | ✓ | ✓ | | Revoke Organization API keys you created | ✓ | ✓ | | Revoke Organization API keys created by other members | ✓ | — | | View and add Organization SSH keys | ✓ | ✓ | | Rename and delete Organization SSH keys you added | ✓ | ✓ | | Rename and delete Organization SSH keys added by other members | ✓ | — | The person who creates the Organization is its first admin. Every API key created while working in an Organization belongs to that Organization and is attributed to the member who created it. Members can revoke only the keys they created; admins can revoke any key in the Organization. ## SSH keys An Organization has its own SSH keys, separate from members' personal keys. Manage them under **Organization Settings > SSH Keys** while you're working in the Organization. When you rent an instance under an Organization, you can only attach Organization SSH keys. Personal keys aren't available in the Organization's launch flow. * **Add a key**: paste a public key or drag and drop your `.pub` file. Every member can see the key and attach it to their rentals. * **Copy a personal key**: the **Copy a personal key** section lists your personal keys that aren't in the Organization yet. Click **Copy to organization** to add one to the Organization's list. * **Rename or delete a key**: members can rename and delete the keys they added. Admins can rename and delete any Organization key. As with personal keys, Hyperbolic rejects a key that's already saved in the Organization, and you can't delete a key while it's attached to a live instance. See [SSH Keys](/docs/general/account-management#ssh-keys) for details. ## Billing An Organization has its own balance, separate from members' personal balances. Deposits made to the Organization fund all instances and storage launched within it. [Auto Top-Up](/docs/general/auto-top-up) can be configured per workspace. # Security and Compliance Source: https://hyperbolic.ai/docs/general/security-compliance Security measures, compliance standards, and best practices Hyperbolic is committed to protecting your data and maintaining the highest security standards across our platform. This page outlines our security measures, compliance status, and best practices for securing your account. ## Platform security ### Infrastructure security Hyperbolic's infrastructure is designed with security as a foundational principle. **Data center security** * Geographically distributed data centers with physical access controls * 24/7 monitoring and surveillance * Redundant power and networking systems * Environmental controls and fire suppression **Network security** * Network segmentation and isolation between tenants * DDoS protection and traffic monitoring * Encrypted communications between all internal services * Regular security assessments and penetration testing ### Data protection **Encryption** | Data State | Encryption | | - | - | | In transit | TLS 1.2+ for all API communications | | At rest | AES-256 encryption for stored data | **Instance isolation** * Each GPU instance runs in an isolated environment * No shared memory or storage between tenant instances * Network isolation between customer workloads * Secure instance termination with data wiping For Private Cloud — dedicated, single-tenant clusters — see [Private Cloud Security](/docs/private-cloud/security). ### Access controls Hyperbolic uses multiple layers of authentication and authorization: * **API key authentication** - All API requests require valid API keys * **SSH key authentication** - Public key authentication for GPU instance access * **No shared credentials** - Each user has unique credentials * **Session management** - Automatic session expiration and secure token handling ## Compliance Current compliance status, reports, and policies are published at [trust.hyperbolic.ai](https://trust.hyperbolic.ai). Reports are available under NDA. ### SOC 2 Hyperbolic has completed a SOC 2 Type I audit and a SOC 2 Type II engagement is underway. SOC 2 evaluates: * **Security** - Protection against unauthorized access * **Availability** - System availability for operation and use * **Processing integrity** - System processing is complete and accurate * **Confidentiality** - Information designated as confidential is protected * **Privacy** - Personal information is collected and used appropriately ### GDPR For customers processing data subject to GDPR, Hyperbolic provides: * Data processing agreements (DPAs) upon request * Data residency options for EU-based processing * Support for data subject access requests * Clear data retention and deletion policies ### HIPAA Hyperbolic is not currently HIPAA-certified. Do not process Protected Health Information (PHI) on the platform without consulting our team first. For healthcare organizations interested in using Hyperbolic: * Contact us to discuss your specific compliance requirements * We can work with you on Business Associate Agreements (BAAs) for qualified use cases * Enterprise customers may have access to dedicated, compliant infrastructure Contact [support@hyperbolic.ai](mailto:support@hyperbolic.ai) for healthcare and HIPAA-related discussions. ## Vulnerability reporting Hyperbolic takes security vulnerabilities seriously. If you discover a security issue, please report it responsibly. ### How to report Email [support@hyperbolic.ai](mailto:support@hyperbolic.ai) with: * Description of the vulnerability * Steps to reproduce the issue * Potential impact assessment * Any supporting evidence (screenshots, logs, etc.) ### What to expect 1. **Acknowledgment** - We'll acknowledge receipt within 48 hours 2. **Investigation** - Our security team will investigate the report 3. **Updates** - We'll keep you informed of our progress 4. **Resolution** - We'll work to resolve valid vulnerabilities promptly 5. **Recognition** - With your permission, we'll acknowledge your contribution ### Responsible disclosure We ask that you: * Give us reasonable time to address the issue before public disclosure * Avoid accessing or modifying other users' data * Act in good faith to avoid privacy violations and service disruptions ## Best practices Follow these recommendations to keep your Hyperbolic account secure. ### API key security Treat your API key like a password. Anyone with your key can make requests on your behalf and incur charges. | Practice | Description | | - | - | | Never commit to repos | Add `.env` files to `.gitignore` | | Rotate periodically | Generate new keys if you suspect compromise | | Separate environments | Use different keys for development and production | | Monitor usage | Review billing for unexpected charges | ### SSH key security | Practice | Description | | - | - | | Use strong key types | Prefer Ed25519 or RSA with 4096 bits | | Protect private keys | Set permissions to 600 (`chmod 600 ~/.ssh/id_ed25519`) | | Use passphrases | Add a passphrase to your private key for extra protection | | Don't share keys | Each team member should have their own key pair | | Audit regularly | Remove unused keys from your account | ### Account security * **Sign in with Google or GitHub** - We support single sign-on with Google and GitHub. This is recommended, since it means you don't need to manage your own password * **Use a strong, unique password** - If you use a password, don't reuse passwords from other services * **Enable 2FA when available** - Two-factor authentication adds an extra layer of security * **Review active sessions** - Log out of sessions you don't recognize * **Keep contact info current** - Ensure you can receive security notifications ### Instance security * **Keep software updated** - Apply security patches as soon as they are available * **Use firewalls** - Reach out to us about your options; configuration differs across regions * **Don't expose unnecessary ports** - Only open ports required for your application * **Clean up sensitive data** - Remove sensitive files before terminating instances ## Support For security-related questions or concerns: | Contact | Purpose | | - | - | | [support@hyperbolic.ai](mailto:support@hyperbolic.ai) | Vulnerability reports, security questions, account security issues, compliance inquiries, and all other support inquiries | # Getting Support Source: https://hyperbolic.ai/docs/general/support How to reach the Hyperbolic team, what to include in a request, and what to expect ## Support channels | Channel | Best for | | - | - | | **In-app chat (Pylon)** — widget in the bottom-right corner of the [console](https://app.hyperbolic.ai) | Fastest response for account, billing, and instance issues | | **Email** — [support@hyperbolic.ai](mailto:support@hyperbolic.ai) | Anything, including vulnerability reports, compliance questions, and issues you want a written record of | | **Sales** — [sales@hyperbolic.ai](mailto:sales@hyperbolic.ai) | Private Cloud, large or long-term capacity, and custom configurations | | **Status page** — [status.hyperbolic.ai](https://status.hyperbolic.ai) | Current incidents and scheduled maintenance | | **Trust center** — [trust.hyperbolic.ai](https://trust.hyperbolic.ai) | Security and compliance documentation, SOC 2 status | ## What to include in a support request The more of this you include up front, the faster we can help: * The **email address** on your Hyperbolic account * The **instance ID** (from your Active Instances page), plus GPU type and region * **What you expected** and **what happened instead**, with timestamps (include your timezone) * **Error messages and logs** — copy the full text rather than a screenshot when possible * For connection issues: the SSH command you ran and its full output (`ssh -v` output helps) * For performance issues: the output of `nvidia-smi` and any benchmark results (see [Verifying Instance Performance](/docs/on-demand/verifying-performance)) Never share your SSH private key or full payment details in a support request. Support will never ask for them. ## What to expect * **Support hours:** support engineers work Monday to Friday, 06:00 to 17:00 Pacific Time. The in-app chat assistant answers at any time and passes anything it cannot solve to an engineer, with the details you already gave. Requests that reach an engineer outside those hours are picked up the next business day. * **Reserved and enterprise customers** with a dedicated Slack channel: response times by severity are in your Customer Support Guide. Private Cloud contracts include dedicated, direct-to-engineer 24×7 support — see the [platform comparison](/docs/overview/platform-comparison). * **Expertise:** support is staffed by engineers familiar with the platform's GPU infrastructure. Hardware-level issues (failed GPUs, network problems) are escalated to the infrastructure team. * **Uptime SLA:** On-Demand and Reserved instances carry a 99.5% uptime SLA. Private Cloud SLAs are custom and negotiated per contract — see the [platform comparison](/docs/overview/platform-comparison). ## Common requests * **Instance stuck in a pending state** for more than 30 minutes — contact support with the instance ID. Instances that never become ready are auto-terminated at the provisioning timeout (\~3 hours) and are never charged. * **GPUs not visible** (`nvidia-smi` reports no GPUs) — drivers are preinstalled on all instances; contact support rather than installing drivers yourself. * **Storage in other regions** — persistent storage volumes are currently limited to select regions; contact support to request other regions or custom configurations (see [requesting custom storage](/docs/on-demand/storage-and-ports#requesting-custom-storage-configurations)). * **Billing questions** — start with [Billing & Payments](/docs/general/billing-payments); contact support for anything unresolved. # Connect to a Managed Kubernetes Cluster Source: https://hyperbolic.ai/docs/managed-kubernetes/kubectl-access Install the kubelogin plugin and access your cluster with kubectl via single sign-on Managed Kubernetes clusters use **single sign-on**: the kubeconfig you download signs you in through Hyperbolic in your browser and authenticates `kubectl` as **you** — no shared admin credential, and every action is attributed to your identity. To run that sign-in, `kubectl` needs the `oidc-login` credential plugin (**kubelogin**). ## Install the kubelogin plugin ```bash Homebrew (macOS / Linux) theme={null} brew install kubelogin ``` ```bash Krew (macOS / Linux / Windows / ARM) theme={null} kubectl krew install oidc-login ``` ```powershell Chocolatey (Windows) theme={null} choco install kubelogin ``` All three install the **`kubectl oidc-login`** plugin, which is what the downloaded kubeconfig uses — so any of them works. Homebrew and Chocolatey also install a standalone `kubelogin` binary; Krew installs only the plugin form (invoked as `kubectl oidc-login`). Krew is the most portable option — it works anywhere `kubectl` does, including Windows and ARM. For manual binaries or other package managers, see the project's install guide. Source, releases, and full installation options for the kubelogin (`oidc-login`) plugin. Verify the install with `kubectl oidc-login --version` (works for every install method; `kubelogin --version` also works for Homebrew and Chocolatey). ## Connect to your cluster In the [dashboard](https://app.hyperbolic.ai), open **Kubernetes** > **My Clusters** and select your cluster. Once it's Ready, select **Download kubeconfig** in the **Connect with kubectl** section of the **Cluster info** card, or from the cluster actions menu (**⋮**). The file downloads as `.yaml`. ```bash theme={null} export KUBECONFIG=~/Downloads/.yaml ``` ```bash theme={null} kubectl get nodes ``` The first command opens your browser to sign in with Hyperbolic. After you sign in, `kubectl` runs as you and the command completes. Access tokens are short-lived — when one expires, `kubectl` reopens the browser to sign in again. Confirm who you're acting as with `kubectl auth whoami`. # Availability Alerts Source: https://hyperbolic.ai/docs/on-demand/availability-alerts Get an email when the GPU configuration you need is available to rent GPU capacity changes hour to hour. If the configuration you need is sold out, create an availability alert. Hyperbolic emails you when matching GPUs are available to rent. Availability alerts are available on personal accounts only. They aren't available in an organization view yet. ## Prerequisites * A signed-in Hyperbolic account at [app.hyperbolic.ai](https://app.hyperbolic.ai) * Your personal account selected, not an organization ## Create an alert You can start a new alert from two places: * **Availability Alerts page**: Go to **Rent > Availability Alerts** in the console and click the new alert button. * **GPUs page banner**: On [app.hyperbolic.ai/gpus](https://app.hyperbolic.ai/gpus), click **Notify me when available** in the "Can't find the GPU configuration you need?" banner. Both open the **New Availability Alert** form. ### Configuration settings These filters decide which capacity matches your alert. | Setting | Options | Notes | | - | - | - | | **GPU type** | H100, H200, and other listed GPUs | Required. | | **GPU count** | 1 or more, 2 or more, 4 or more, 8 or more, then steps of 8 up to 88 or more | Matches the count you pick or higher. For example, an "8 or more" alert also matches 16-GPU options. | | **Regions** | Any supported region | Leave empty to watch every region. | | **Deployment** | Any, Bare metal, Virtual machine | Defaults to Any. | | **Connectivity** | Any, InfiniBand, Ethernet | Defaults to Any. | ### Alert settings | Setting | Options | | - | - | | **Notify me** | **As soon as a match appears**. Once-a-day notifications aren't available yet. | | **Stop watching** | **Never**, **After the first match**, **In 7 days**, **In 30 days**, or **In 90 days** | | **Note** | Optional text to help you recognize the alert | **Stop watching** controls whether the alert is one-time or recurring: * **After the first match** creates a one-time alert. It emails you once and then turns off. * **Never** creates a recurring alert. It keeps emailing you when matching capacity appears. * **In 7, 30, or 90 days** creates a recurring alert that stops watching after that period. ## Alert status Each alert card on the **Availability Alerts** page shows its notification status: | Status | Meaning | | - | - | | **Notifications: on** | The alert is active and watching for matches. | | **Notifications: off** | You paused the alert. You don't receive emails until you resume it. | | **Notifications: ended** | A one-time alert already matched, or a recurring alert reached its stop-watching date. | Ended alerts can't be resumed or extended. To keep watching, create a new alert with the same filters. ## Pause, resume, or delete an alert From an alert card: * Click the bell icon, or open the actions menu and choose **Pause alert** or **Resume alert**. * Open the actions menu and choose **Delete** to remove the alert permanently. ## Active alert limit You can have up to 10 active alerts at a time. The **Availability Alerts** page shows how many you're using, for example "3 of 10 active." Paused and ended alerts don't count toward the limit. When you reach the limit, you can't create or resume another alert. Pause or delete an active alert to make room. ## When you get an alert email GPU capacity can sell out between the time Hyperbolic sends the email and the time you open it. When you click through from an alert email, the console opens a modal that checks availability again: * **Your GPUs are still available**: The modal shows how many options match your alert right now. Click **View rentals** to open the GPUs page with your alert's filters already applied. * **No longer available**: The matching GPUs were rented in the meantime. The modal tells you whether the alert is still watching, paused, or ended. * **We couldn't find that alert**: The alert was deleted. Click **Manage alerts** in the modal to return to your alerts list. ## GPU count filter on the GPUs page The GPU count filter on the GPUs page uses the same "or more" rule as alerts. Options read as **1+ GPUs**, **8+ GPUs**, and so on. Selecting **8+ GPUs** lists options with 8 or more GPUs. # Maintenance and Data Safety Source: https://hyperbolic.ai/docs/on-demand/maintenance How we handle planned maintenance, what to expect, and how to keep your data safe ## Planned maintenance **Maintenance we schedule** — platform software on your instance's host, firmware, BIOS, or driver updates — is tested before rollout, and: * You'll get **at least one week's notice** by email, and two weeks where we can. * The notice tells you what's changing, the window, and whether your instance will be **rebooted** (your instance and its data come back; anything running at the time is interrupted) or **reprovisioned** (a fresh instance — onboard data does not carry over). * On instances that occupy a whole node, timing is your call. Reply with a window that works, including off-hours or weekends, and we confirm before we start. Single-GPU instances share a host with other tenants, so we set that window and give you as much notice as we can. * Afterwards we confirm the node comes back and stays reachable. If the fault the maintenance was meant to clear comes back, we come back to you about a follow-up window rather than acting on our own. * For clusters, maintenance is rolled in batches so the whole cluster is never down at once. **Maintenance the datacenter schedules** on the host underneath your instance is sometimes mandatory and comes with its own timeline. We forward the notice as soon as we receive it and tell you the window we were given. It can be hours rather than days. ## Unplanned outages Current incidents are posted on the [status page](https://status.hyperbolic.ai). If your instance is affected, we'll reach out with what happened and next steps. Downtime credits are reviewed case by case with support — see [Getting Support](/docs/general/support). ## Protecting your data * **Onboard NVMe** is local to the machine. It survives a platform reboot; it does **not** survive reprovisioning, host replacement, or termination. * **Persistent storage volumes** survive all of the above. * Before you approve a maintenance window, before you ask us to power-cycle a node with a hardware fault, and on a schedule during long training runs, copy checkpoints to a persistent volume or your own object storage. [Storage and Ports](/docs/on-demand/storage-and-ports#backup-strategies) has ready-to-use `rsync` and `aws s3 sync` cron lines. [Rebooting an instance](/docs/on-demand/managing-instances#rebooting-an-instance) covers what a reboot does to onboard storage. Treat onboard NVMe as scratch. If it's the only copy of your checkpoints, you're one host reboot away from losing them. # Managed Kubernetes Source: https://hyperbolic.ai/docs/on-demand/managed-kubernetes A Kubernetes cluster on your GPU instances, with the control plane run by Hyperbolic Managed Kubernetes is in **beta**. It works, teams are running on it, and the surface is still changing. Expect the feature list below to grow, and tell us what's missing. Managed Kubernetes gives you a ready-to-use GPU Kubernetes cluster without running a control plane yourself. You choose the GPU nodes; Hyperbolic provisions the cluster, installs the NVIDIA stack, and gives you a single sign-on kubeconfig that authenticates `kubectl` as **you**. ## What you get * **A hosted control plane**, run and kept available by Hyperbolic, located in a cloud region close to your GPU nodes. * **GPU worker nodes** that are your rented instances — same hardware, same networking, same billing as renting them directly. * **NVIDIA GPU Operator and Network Operator** preinstalled, so GPUs, drivers, and RDMA networking are exposed to pods on day one. * **Single sign-on access.** You download a per-cluster kubeconfig; the first `kubectl` command signs you in through Hyperbolic in your browser and authenticates as **you** — short-lived, with every action attributed to your identity instead of a shared admin credential. Org admins get `cluster-admin`; other members get `edit`. RBAC inside the cluster is yours to extend. See [Connect with kubectl](/docs/managed-kubernetes/kubectl-access). * **Multi-node performance without overhead.** NCCL all-reduce inside a pod matches the same test run on the bare host. ## Create a cluster 1. In the console, open **Kubernetes**. The launch wizard opens. You can also reach it from **Launch Cluster** in the sidebar. 2. Pick the GPU type, node count, and region, then select **Launch cluster**. Nodes in one cluster are in the same region and on the same interconnect. 3. Wait for the cluster to show **Ready**. Provisioning bootstraps the control plane, joins the nodes, and installs the add-ons. The cluster dashboard opens as soon as the cluster is Ready. GPU and health tiles show "telemetry warming up" until the nodes start reporting. 4. Install the `kubectl oidc-login` plugin (one-time) and select **Download kubeconfig** in the **Connect with kubectl** section of the **Cluster info** card. It's also in the cluster actions menu (**⋮**) — see [Connect with kubectl](/docs/managed-kubernetes/kubectl-access) for the install commands. Then point `kubectl` at the file: ```bash theme={null} export KUBECONFIG=~/Downloads/hyperbolic-cluster.yaml kubectl get nodes -o wide ``` The first command opens your browser to sign in with Hyperbolic; after that, `kubectl` runs as you. You should see one node per GPU instance, each advertising `nvidia.com/gpu` capacity. You can still rent interconnected multi-node clusters **without** Kubernetes — see [On-Demand](/docs/on-demand/overview). Managed Kubernetes is one way to run on those nodes, not the only way. ## Node pools Nodes are grouped into pools. From the cluster's **Pools** tab you can see each pool's GPU type, size, and status, and add or remove nodes. CPU-only worker pools for non-GPU workloads (proxies, monitoring, controllers) are on the roadmap. ## Running GPU workloads Request GPUs like any other resource: ```yaml theme={null} resources: limits: nvidia.com/gpu: 8 ``` For multi-node training, the Network Operator exposes the RDMA interfaces to pods; use your framework's usual NCCL launcher. The NCCL and interconnect checks in [Verifying Instance Performance](/docs/on-demand/verifying-performance) apply unchanged inside Kubernetes. ## Exposing services Nodes have public IPs. A `NodePort` or `hostNetwork` service is reachable from the internet only once the port is open on the node — see [Opening inbound ports](/docs/on-demand/storage-and-ports#opening-inbound-ports). Prefer an in-cluster ingress plus one open port over exposing many NodePorts. ## Storage Node-local NVMe is available to pods as `hostPath` or a local volume and does **not** survive node replacement. Shared network storage for clusters is in development; until it ships, use your own object storage for checkpoints. ## Monitoring The cluster page in the console shows the pods and events on each node and live GPU telemetry. You are free to install Prometheus, Grafana, or any observability agent in the cluster. A fuller **Monitoring** tab with history is in development. ## What Hyperbolic runs, and what you run | Hyperbolic | You | | - | - | | Control plane availability and upgrades | Everything scheduled on the cluster | | Node provisioning, GPU drivers, add-on installation at bootstrap | RBAC, namespaces, network policy | | Single sign-on — authenticating users as themselves, short-lived | RBAC bindings for your own teams and service accounts | | Node replacement on hardware failure | Add-on configuration after bootstrap — if you modify or remove an add-on, that's the new state | | Platform telemetry | Application monitoring, logging, alerting | Managed Slurm is on the roadmap; Kubernetes is the supported orchestration path today. ## Terminate a cluster Open the cluster from **My Clusters**, then go to the **Settings** tab and select **Terminate** in the **Danger zone**. You can also select **Terminate** from the cluster actions menu (**⋮**). Terminating tears down the control plane and releases every node. Billing stops, and nothing on the cluster is recoverable. In an organization, only the member who created the cluster or an org admin can terminate it. Other members see a message in place of the **Terminate** button. Terminated clusters appear under **Past clusters** on the **My Clusters** page. Each entry shows the cluster's final name and the actual amount charged. ## Email notifications Hyperbolic emails your account contacts at key points in a cluster's lifecycle: | Email | When it's sent | | - | - | | Launching | Hyperbolic accepted your cluster request and started building it. | | Ready | The cluster reported **Ready** for the first time and billing started. | | Taking longer than expected | The cluster is still building after about 40 minutes. Sent once. | | Provisioning failed | The cluster couldn't finish bring-up and was torn down without charge. | | Control plane unreachable | Hyperbolic can't reach the cluster's control plane. Sent once per outage. | | Balance warning | Your balance is running low and the cluster will be terminated when it runs out. | | Terminated | A member of your account terminated the cluster. | | Terminated for zero balance | Hyperbolic terminated the cluster because your account balance reached zero. | ## Billing GPU nodes are billed exactly like the same instances rented directly. The hosted control plane is billed separately and shown on the cluster's billing tab. Clusters draw from your account balance like on-demand instances. When your balance runs low, Hyperbolic sends a balance warning for each running cluster. If your balance reaches zero, Hyperbolic terminates the cluster. Configure [Auto Top-Up](/docs/general/auto-top-up) to avoid losing a cluster to an empty balance. # Managing Instances Source: https://hyperbolic.ai/docs/on-demand/managing-instances Create, monitor, and manage high-performance GPU instances through the Web UI Master the full lifecycle of GPU instance management on Hyperbolic - from creation to termination, including monitoring, scaling, and troubleshooting. ## Creating Instances ### Web UI Method Go to [app.hyperbolic.ai/gpus](https://app.hyperbolic.ai/gpus) and browse available GPUs. * Choose GPU type (H100 80GB, H200 141GB, B200 192GB, B300 288GB — availability varies by region) * Select quantity * Pick region for optimal latency * Choose InfiniBand if needed for multi-GPU * **Storage**: Configure as needed for your storage needs * **Label**: Name your instance for easy identification * **SSH Key** (required): select a saved SSH key, or paste a new one. The instance is provisioned with the key you select. Some regions let you attach more than one key. See [Attach multiple keys to an instance](/docs/general/account-management#attach-multiple-keys-to-an-instance). Manage saved keys under [Settings > SSH Keys](https://app.hyperbolic.ai/settings/ssh-keys). Under an [Organization](/docs/general/organizations#ssh-keys), only Organization keys can be selected. Review pricing and click "Start Building". Instance will be ready in under 5 minutes. ## Connecting to Instances ### SSH Connection Basic SSH connection: ```bash theme={null} # Standard connection ssh ubuntu@ # With specific key ssh -i ~/.ssh/hyperbolic_key ubuntu@ ``` ### File Transfer ```bash theme={null} # Upload file scp model.pth ubuntu@:/home/ubuntu/ # Download file scp ubuntu@:/home/ubuntu/results.csv ./ # Upload directory scp -r dataset/ ubuntu@:/home/ubuntu/ ``` ```bash theme={null} # Sync directory (upload) rsync -avz --progress dataset/ ubuntu@:/home/ubuntu/dataset/ # Sync with deletion of removed files rsync -avz --delete --progress local/ ubuntu@:/home/ubuntu/remote/ # Resume interrupted transfer rsync -avz --partial --progress large_file.tar ubuntu@:/data/ ``` ```bash theme={null} # Interactive SFTP session sftp ubuntu@ # SFTP commands sftp> put model.pth sftp> get results/ sftp> ls sftp> pwd sftp> exit ``` ## Instance Lifecycle Management ### Rebooting an instance Where supported, **Reboot** is available from the instance's actions menu in the dashboard. Use it instead of `sudo reboot` from inside the instance — a reboot triggered from the console goes through the platform, which keeps the instance's state and network configuration intact. While a node reboots its card shows **Rebooting**. On a multi-node instance the instance itself stays **Running** while one node reboots. If the Reboot action isn't shown for an instance, that machine type doesn't support platform reboots. Contact support rather than rebooting from inside the OS; on some machines an in-OS reboot can leave the instance unrecoverable. Onboard storage is preserved across a platform reboot. It is **not** preserved across reprovisioning or termination — see [Storage and Ports](/docs/on-demand/storage-and-ports). Rebooting because of a hardware error — an Xid in `dmesg`, a GPU that has dropped off the bus, a row-remap or SRMA message? Back up first. A reboot on a faulted host doesn't always come back cleanly, and the recovery path is sometimes a fresh instance, which onboard data doesn't survive. ### Terminating Instances Termination is permanent. All data on the instance will be lost. Always backup important data before terminating. To terminate an instance: 1. Go to "My Instances" in the Web UI 2. Click "Terminate" in the instance actions 3. Confirm the deletion ## Monitoring and Metrics ### Real-Time GPU Monitoring SSH into your instance and use these commands: ```bash theme={null} # Basic GPU status nvidia-smi # Continuous monitoring (updates every 1 second) watch -n 1 nvidia-smi # Detailed GPU metrics nvidia-smi -q # Show running processes nvidia-smi pmon # GPU utilization over time nvidia-smi dmon ``` ### System Monitoring ```bash theme={null} # System resources htop # Disk usage df -h # Memory usage free -h # Network statistics nethogs # Install with: sudo apt install nethogs # Process monitoring ps aux | grep python ``` ### Setting Up Custom Monitoring ```bash theme={null} # Install DCGM exporter for GPU metrics docker run -d --gpus all --rm -p 9400:9400 nvidia/dcgm-exporter:latest # Install Prometheus docker run -d -p 9090:9090 \ -v prometheus.yml:/etc/prometheus/prometheus.yml \ prom/prometheus # Install Grafana docker run -d -p 3000:3000 grafana/grafana ``` ```python theme={null} import wandb import torch # Initialize W&B wandb.init(project="hyperbolic-training") # Log GPU metrics automatically wandb.watch(model) # Custom GPU logging for epoch in range(num_epochs): gpu_utilization = torch.cuda.utilization() gpu_memory = torch.cuda.memory_allocated() / 1024**3 wandb.log({ "gpu_utilization": gpu_utilization, "gpu_memory_gb": gpu_memory, "epoch": epoch }) ``` ## Managing Multiple Instances ### Viewing All Instances Go to [app.hyperbolic.ai/instances](https://app.hyperbolic.ai/instances) to view all your instances with: * Instance status * GPU type and configuration * Region * Running time and costs * Quick action buttons ### Batch Operations **Parallel SSH Commands**: ```bash theme={null} # Run command on multiple instances for ip in 192.168.1.10 192.168.1.11 192.168.1.12; do ssh ubuntu@$ip "nvidia-smi" & done wait # Using GNU parallel parallel -j 4 ssh ubuntu@{} "python train.py" ::: \ instance1.hyperbolic.ai \ instance2.hyperbolic.ai \ instance3.hyperbolic.ai ``` **Using Ansible**: ```yaml theme={null} # inventory.yml all: hosts: h100-1: ansible_host: 192.168.1.10 h100-2: ansible_host: 192.168.1.11 h100-3: ansible_host: 192.168.1.12 vars: ansible_user: ubuntu ansible_ssh_private_key_file: ~/.ssh/hyperbolic_key # Run command on all instances ansible all -i inventory.yml -m shell -a "nvidia-smi" ``` ## Instance States and Troubleshooting ### Instance States | State | Description | Billing | | - | - | - | | **Pending** | Instance is being provisioned | No | | **Running** | Instance is ready and accessible — billing starts here | Yes | | **Starting** | Instance is booting up | No | | **Converting** | Reservation has ended; converting to on-demand billing (or terminating) within \~10 minutes | Yes | | **Terminating** | Instance is being deleted | No | | **Failed** | Instance failed to start | No | ### Common Issues and Solutions **Solution**: * Allow a few minutes for provisioning * Check region availability in the dashboard * Contact [support](mailto:support@hyperbolic.ai) if pending > 30 minutes Check the instance status in your dashboard for updates. **Solution**: * Verify instance is in "Running" state * Check SSH key is authorized * Confirm IP address is correct * Test network connectivity ```bash theme={null} # Debug SSH connection ssh -vvv ubuntu@ ``` **Solution**: * Verify GPU driver is loaded * Check Docker runtime configuration * Restart instance if needed ```bash theme={null} # Check GPU availability nvidia-smi # Check driver nvidia-smi -q | grep "Driver Version" # For Docker containers docker run --gpus all nvidia/cuda:12.2.0-base nvidia-smi ``` **Possible causes**: * Insufficient account balance * Violation of terms of service * Hardware failure (rare) **Solution**: * Check billing status in your dashboard * Review instance logs * Contact support for clarification Still having issues? Contact [**support@hyperbolic.ai**](mailto:support@hyperbolic.ai) or use the chat in the bottom-right corner of the [app](https://app.hyperbolic.ai) after you sign in. ## Best Practices Name your instances clearly to track different projects and experiments. Set up scripts to automatically terminate idle instances to avoid unnecessary charges. Schedule regular backups of important data to external storage (S3, GCS, etc.). Set up billing alerts and regularly review instance usage to optimize costs. ### Auto-shutdown Script Example ```python theme={null} #!/usr/bin/env python3 import subprocess import time import sys def get_gpu_utilization(): """Get current GPU utilization percentage""" result = subprocess.run( ['nvidia-smi', '--query-gpu=utilization.gpu', '--format=csv,noheader,nounits'], capture_output=True, text=True ) return int(result.stdout.strip()) def auto_shutdown(idle_minutes=30, threshold=5): """Shutdown instance if GPU idle for specified minutes""" idle_count = 0 check_interval = 60 # Check every minute while True: util = get_gpu_utilization() if util < threshold: idle_count += 1 print(f"GPU idle ({util}%). Idle count: {idle_count}/{idle_minutes}") if idle_count >= idle_minutes: print("Shutting down due to inactivity...") subprocess.run(['sudo', 'shutdown', '-h', 'now']) sys.exit(0) else: idle_count = 0 print(f"GPU active ({util}%). Reset idle counter.") time.sleep(check_interval) if __name__ == "__main__": auto_shutdown(idle_minutes=30, threshold=5) ``` ## Advanced Configuration ### Custom Startup Scripts Create a startup script that runs when instance boots: ```bash theme={null} #!/bin/bash # /home/ubuntu/startup.sh # Mount additional storage sudo mount /dev/nvme1n1 /data # Start Jupyter jupyter notebook --no-browser --port=8888 & # Start TensorBoard tensorboard --logdir=/home/ubuntu/logs --port=6006 & # Start monitoring python /home/ubuntu/monitor_gpu.py & ``` ### Data Persistence Strategies ```bash theme={null} # Install AWS CLI sudo apt-get update sudo apt-get install awscli -y # Configure AWS credentials aws configure # Sync data to S3 aws s3 sync /home/ubuntu/models/ s3://my-bucket/models/ # Download from S3 aws s3 sync s3://my-bucket/dataset/ /home/ubuntu/dataset/ ``` ```bash theme={null} # Install Git LFS curl -s https://packagecloud.io/install/repositories/github/git-lfs/script.deb.sh | sudo bash sudo apt-get install git-lfs # Initialize Git LFS git lfs install # Track large files git lfs track "*.pth" git lfs track "*.h5" # Push to repository git add . git commit -m "Save model checkpoint" git push ``` ## Next Steps Configure persistent storage and network settings # GPU Monitoring Source: https://hyperbolic.ai/docs/on-demand/monitoring Real-time GPU metrics on supported instances, no setup required Most On-Demand and Reserved instances ship with GPU monitoring enabled. There is nothing to install and no extra charge — metrics start appearing within a few minutes of the instance becoming ready. A few machine types do not support it yet; see [Instances without monitoring](#instances-without-monitoring) below. ## Open monitoring for an instance From your instance's details page, click **Monitoring**. The view is scoped to that instance and lists each GPU attached to it. ## What you can see | Metric | What it tells you | | - | - | | **GPU utilization** | Percentage of time each GPU was executing kernels. Sustained low utilization during training usually means a data-loading or CPU bottleneck, not a GPU problem. | | **GPU memory** | Used vs. total per GPU. Running near the ceiling risks out-of-memory errors; see the [CUDA out of memory](/docs/on-demand/quickstart#gpu-issues) fix. | | **Temperature** | Per-GPU. Sustained readings well above the pack are worth flagging to support — thermal throttling shows up as lower clocks and slower steps before it shows up as an error. | Metrics refresh automatically about every 30 seconds. ## Instances without monitoring Monitoring depends on the platform agent being present on the instance. If an instance's details page has no **Monitoring** button, that machine type doesn't support it yet; `nvidia-smi` on the instance gives you the same numbers on demand — see [Managing Instances](/docs/on-demand/managing-instances#real-time-gpu-monitoring). ## What monitoring is not Monitoring is a read-only view. It does not alert you, and it does not restart or replace a GPU automatically. If you see a GPU that has dropped out or is throttling, run the checks in [Verifying Instance Performance](/docs/on-demand/verifying-performance) and contact support with the instance ID and the `nvidia-smi -q` output. # On-Demand GPU Overview Source: https://hyperbolic.ai/docs/on-demand/overview Launch H100, H200, B200, and B300 GPUs in minutes Hyperbolic On-Demand GPUs provide high-performance GPU capacity for training, fine-tuning, inference, benchmarking, and custom deployments. Teams can launch GPU instances, configure their runtime environment, and scale compute as workload requirements change, without committing to reserved infrastructure before the workload is proven. Available GPU types, regions, cluster configurations, and networking options may vary based on current supply. For specific capacity or configuration requirements, contact [sales@hyperbolic.ai](mailto:sales@hyperbolic.ai). ## On-Demand GPU Infrastructure **H100, H200, B200 & B300 GPU Clusters** Access H100, H200, and Blackwell GPUs from single instances to interconnected clusters, plus RTX Pro 6000 for single-GPU inference and development. * **Hardware**: H100 80GB, H200 141GB, B200 192GB, B300 288GB, RTX Pro 6000 96GB * **Availability**: 99.5% uptime SLA * **Instant Deployment**: Clusters ready in minutes * **Scalable**: Single GPU to 128+ GPU clusters * **InfiniBand Networking**: Up to 3.2 Tb/s for maximum multi-GPU performance ## Key Features ### Instant Deployment * Deploy GPUs in under 5 minutes * No sales calls or procurement delays * Ubuntu with NVIDIA drivers and Docker preinstalled — bring your own frameworks or containers * Available in multiple regions worldwide ### Flexible Access * Full SSH root access to your instances * Docker support * Persistent storage options available (depending on region) * Built-in [GPU monitoring](/docs/on-demand/monitoring) on supported instances — utilization, memory, and temperature, no agent to install ### Simple Billing * Pay only for what you use (hourly billing) * No upfront commitments or contracts * Automatic failure detection (no charges for failed instances) * Pay by credit card ### Developer-Friendly * REST API for automation ## Regions & Data Centers GPUs are available across multiple regions for optimal latency and compliance requirements. ### Available Regions Regions currently offered on the platform. GPU availability changes hour to hour — the console shows what's rentable right now in each region. Regions listed with InfiniBand or RoCE support multi-node clusters; single-GPU (1×) options are noted where offered. | Region | Geography | GPUs | Per node | Type | Interconnect | | - | - | - | - | - | - | | `us-central-3` | US Central | H100 | 8× | VM | Ethernet, InfiniBand | | `us-east-1` | US East | H100, H200 | 1×, 8× | VM | Ethernet | | `us-east-2` | US East | H200 | 1× | VM | Ethernet | | `us-east-3` | US East | RTX Pro 6000 | 1×, 8× | VM | Ethernet | | `us-southeast-1` | US Southeast | H200 | 8× | VM | RoCE | | `us-southeast-2` | US Southeast | H200 | 8× | VM | RoCE | | `ca-east-1` | Canada East | H100 | 8× | VM | Ethernet | | `ca-east-2` | Canada East | H100 | 8× | VM | RoCE | | `ca-east-3` | Canada East | H100 | 8× | VM | Ethernet | | `eu-north-4` | Northern Europe | H100 | 8× | VM | Ethernet | | `eu-north-5` | Northern Europe | H200 | 8× | VM | Ethernet | | `eu-north-7` | Northern Europe | H100, H200 | 1× | VM | Ethernet | | `eu-north-8` | Northern Europe | H100 | 1× | VM | Ethernet | | `eu-west-1` | Western Europe | H100 | 8× | VM | Ethernet | | `eu-west-3` | Western Europe | H100 | 8× | Bare metal | InfiniBand | | `eu-west-4` | Western Europe | H100 | 8× | Bare metal | InfiniBand | | `uk-southeast-3` | United Kingdom | H100 | 8× | Bare metal | InfiniBand | | `jp-east-1` | Japan | H100 | 8× | VM | Ethernet | Persistent storage volumes are available in select regions — the console shows the storage option for regions that support it. B200 and B300 capacity is rolling out. To get an email when a configuration comes online, create an [availability alert](/docs/on-demand/availability-alerts). **VM** here means full bare-metal passthrough. The GPUs, RDMA NICs, and NVMe drives are handed to your VM directly rather than virtualized, and per-rail bandwidth inside the VM measures at line rate. The console's type and interconnect filters only list what is rentable at that moment, so if you don't see bare metal or InfiniBand there, it's stock, not the catalog. ## Use Cases * **Fine-tune LLMs** on custom datasets with multi-GPU support * **Train computer vision models** with high-throughput data pipelines * **Run distributed training** across multiple nodes with InfiniBand * **Experiment with architectures** using automatic checkpointing **Recommended GPUs**: H100 for most training tasks, H200 for ultra-large models * **Host inference endpoints** on your own instances * **Deploy production model servers** using TorchServe, Triton, or vLLM * **Run batch inference jobs** with optimized throughput * **A/B test different models** with traffic splitting **Recommended GPUs**: H100 for high-throughput inference, H200 for serving 70B+ parameter models * **Prototype AI applications** with Jupyter notebooks * **Test GPU-accelerated code** with full debugging capabilities * **Build ML pipelines** with MLflow or Kubeflow integration * **Reproduce paper results** with exact environment replication **Recommended GPUs**: H100 for most research, H200 for cutting-edge experiments * **Large language model training** with model parallelism * **Distributed deep learning** with data parallelism * **High-performance computing** workloads * **Massive batch processing** with coordinated jobs **Recommended Setup**: 8x or 16x H100 with InfiniBand for optimal performance ## Security Best Practices Always follow security best practices when deploying GPU instances with public access. ### Instance Security * **SSH Keys**: Use strong SSH keys, never share private keys * **Updates**: Keep your OS and packages updated * **Monitoring**: Set up logging and monitoring for suspicious activity ### Data Protection * **Encryption**: Use encrypted storage for sensitive data * **Backups**: Regular backups of important models and datasets * **Access Control**: Implement proper IAM policies * **Compliance**: Ensure compliance with data regulations (GDPR, HIPAA) ## Performance For hardware specifications per GPU type (memory, bandwidth, interconnect), see the [GPU comparison table](/docs/overview/platform-comparison#available-gpus). To confirm an instance is performing as expected, run the benchmark tests in [Verifying Instance Performance](/docs/on-demand/verifying-performance). ## Getting Started * [Create your account](https://app.hyperbolic.ai) * Add your SSH public key in account settings * Fund with \$5.00+ to get started (credit card) Browse available GPUs at [app.hyperbolic.ai](https://app.hyperbolic.ai) Choose H100 for most AI workloads, H200 for ultra-large models requiring maximum memory, or B200 for frontier-scale training and inference demanding the highest performance. * Select GPU type and quantity * Configure storage (if needed) * Add or configure your SSH key for access * Click "Rent" to deploy ```bash theme={null} # Connect via SSH {ssh command from your Active Instances page} # Verify GPU is available nvidia-smi # Start building! python train.py ``` ## Resources 5-minute tutorial to launch your first GPU instance Get an email when the GPUs you need are available **Need help?** Email [support@hyperbolic.ai](mailto:support@hyperbolic.ai) for support inquiries, or use the chat in the bottom-right corner of the [app](https://app.hyperbolic.ai) after you sign in. # Pricing Source: https://hyperbolic.ai/docs/on-demand/pricing Learn how Hyperbolic bills GPU instances and storage across On-Demand, Reserved, Private Cloud, and Storage Volumes. ## At a glance | | On-Demand | Reserved | Private Cloud | | - | - | - | - | | **Billing** | Hourly, for the life of the instance | Paid up-front, in full, at creation | Negotiated per contract | | **Rate** | On-demand rate, locked at creation | Discounted rate for a fixed period | Custom, per contract | | **Terminate anytime?** | Yes | No — auto-terminated when the reservation ends | Per contract terms | | **Balance required** | Enough to cover 1 hour of runtime across all instances | Full cost of the reservation period | N/A — billed per contract | ## On-Demand New instances you create will be billed at on-demand rates by default. You may terminate on-demand instances at any time. On-demand instances are billed continuously for the lifetime of the instance until they are terminated. You must have a balance high enough to support at least one hour of instance runtime prior to creating a new on-demand instance, across all of your instances, including the new instance you intend to create. There is no minimum charge for on-demand instances - while you are required to be able to cover at least one hour of instance runtime at instance creation you may terminate your instance at any time, including before it becomes ready. ### When billing starts An instance becomes ready when it is fully provisioned and SSH-accessible. Billing starts the moment an instance becomes ready — you are only charged for time spent in the ready state. While rare, full or partial provisioning errors may occur. Any instance that fails to become ready within the provisioning timeout period (\~3 hours) is automatically terminated. You are never charged for instances that never enter a ready state. ### Price lock The cost per hour per GPU displayed during instance creation is locked in for the duration of the instance, with one exception: in rare circumstances, we may reach out about a price increase if you have had on-demand instances running at significantly below-market rates for a long time. *Instances may be automatically terminated if your account balance is no longer positive. To prevent termination, configure [Auto Top-Up](/docs/general/auto-top-up) to automatically deposit funds when your balance falls below a set amount.* Instance termination is permanent. On-machine data cannot be recovered. Data on attached storage volumes is never lost as a result of instance termination — but after your balance reaches zero, you have a 30-day grace period to recover storage volume data before the volumes themselves are automatically terminated. ## Reserved When creating an instance, you may choose to reserve it for a fixed period of time at a discounted rate. * Paid up-front. Reserved instances are paid in full at creation. Your balance must cover the entire cost of the reservation period. * Reservation starts at ready. The reservation duration begins the moment the instance becomes ready. If a reserved instance fails to become ready within the provisioning timeout period, it is automatically terminated and the full amount is immediately credited back to your account. You are never charged for instances that never enter a ready state. * No early termination. You may not terminate a reserved instance yourself. You can extend it before the term ends. At the end of the term, Reservation Protection, which is on by default at launch unless you turn it off, keeps it running at the on-demand rate; with Reservation Protection off it is automatically terminated — save all data to storage that does not live on the instance first. Reservation Protection: on by default when you launch a reserved instance, unless you turn it off. Instead of terminating at the end of the term, the instance converts to on-demand and is billed at the current on-demand rate until you terminate it. Turn it off in the instance's settings if you want the instance terminated at the end of the term. See [Reserved Overview](/docs/reserved/overview#what-happens-at-the-end-of-the-term). ## Private Cloud Private Cloud is arranged under a custom contract and is not self-serve. Once your contract is active, a **Private Cloud** tab appears in your dashboard. Under **Compute**, your cluster page shows the capacity you've purchased, SSH access for the login node, the node inventory, and the hardware and software configuration. The tab is read-only: start, stop, reboot, and reimage go through the contacts under **Support & escalation** on the cluster page. Access, management, and payment terms are unique to each contract and are negotiated directly with a sales representative and a technical representative. [Contact your sales representative](mailto:sales@hyperbolic.ai) to learn more about accessing and managing your Private Cloud instances. ## Storage Volumes Storage volumes are performant, on-prem network storage volumes that live independently from your instances. * Billed by size. Volumes are always billed at on-demand rates based on the total volume size, regardless of the capacity actually used or the volume of data transferred. * Terminate anytime. You may terminate storage volumes at any time. *Storage volumes may be automatically terminated if your account balance reaches zero. To prevent this, configure [Auto Top-Up](/docs/general/auto-top-up) to automatically deposit funds when your balance falls below a set amount.* Storage volume termination is permanent. Data cannot be recovered. Data on instances to which a volume is attached is never lost as a result of volume termination. After your account balance reaches zero, you have a 30-day grace period to recover data on storage volumes before they are automatically terminated. # On-Demand GPU Quick Start Source: https://hyperbolic.ai/docs/on-demand/quickstart Launch your first H100, H200, B200, or B300 GPU instance Use this guide to launch your first On-Demand GPU instance on Hyperbolic. This guide walks you through account setup, funding, SSH configuration, and launching your first GPU instance. ## Prerequisites Before you begin, make sure you have: Required for secure instance access. We'll show you how to create one if needed. Basic command line familiarity for SSH connections and running commands. ## Step 1: Create Your Account Visit [app.hyperbolic.ai](https://app.hyperbolic.ai) and create your account using: * Email address * Google OAuth * GitHub OAuth Check your inbox for a verification email and click the link to activate your account. ## Step 2: Generate & Add SSH Key SSH keys are required for instance access. Password authentication is disabled for security. ### Generate a new SSH key ```bash theme={null} # Generate ED25519 key (recommended) ssh-keygen -t ed25519 -C "your-email@example.com" # Or generate RSA key (legacy) ssh-keygen -t rsa -b 4096 -C "your-email@example.com" ``` ### Copy your public key ```bash theme={null} # For ED25519 cat ~/.ssh/id_ed25519.pub # For RSA cat ~/.ssh/id_rsa.pub ``` ### Using PowerShell ```powershell theme={null} # Generate key ssh-keygen -t ed25519 -C "your-email@example.com" # Display public key type $env:USERPROFILE\.ssh\id_ed25519.pub ``` ### Using PuTTYgen 1. Download [PuTTYgen](https://www.putty.org/) 2. Click "Generate" and move mouse randomly 3. Save private key 4. Copy public key from text area ### Add SSH Key to Hyperbolic 1. Go to [Settings > SSH Keys](https://app.hyperbolic.ai/settings/ssh-keys) 2. Paste your public key or drag and drop your `.pub` file 3. Optionally edit the key's name, then save it You can save multiple keys and select one when you launch an instance. See [SSH Keys](/docs/general/account-management#ssh-keys) for details. ## Step 3: Fund Your Account Add credits to rent GPUs. 1. Go to [Billing](https://app.hyperbolic.ai/billing) 2. Click "Add Funds" 3. Enter amount of credits you want to add 4. Click "Pay Now" 5. Complete payment via Stripe Credit card payments are processed instantly and securely via Stripe. ## Step 4: Choose Your GPU Browse available GPUs and select based on your needs: ### GPU Selection Guide For current rates, check live pricing in the [Hyperbolic console](https://app.hyperbolic.ai/gpus). | Use Case | Recommended GPU | Why | | - | - | - | | **Model Development** | H100 80GB | Industry standard for AI development | | **Production Training** | H100 80GB | Fast training, reliable performance | | **Large Models (70B+)** | H200 141GB | Maximum memory for huge models | | **Distributed Training** | H100 + InfiniBand | Multi-node clusters with fast interconnect | | **Ultra-Large Models** | H200 + InfiniBand | Next-gen performance for cutting-edge AI | View real-time GPU availability and pricing ## Step 5: Launch Your First Instance ### Quick Launch (Web UI) 1. Go to [Hyperbolic](https://app.hyperbolic.ai) 2. Filter by GPU type, price, or region 3. Click on an available GPU listing * **Storage**: Add if needed (optional) * **Label**: Name your instance (optional) 1. Review configuration and pricing 2. Click "Start Building" 3. Instance launches in under 5 minutes 4. Copy the SSH connection string ### Launch via API Automate instance creation with our REST API: ```bash Virtual Machine theme={null} curl -X POST "https://api.hyperbolic.xyz/v1/marketplace/virtual-machine" \ -H "Authorization: Bearer $HYPERBOLIC_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "gpu_count": 1, "gpu_type": "H100" }' ``` ```bash Bare Metal theme={null} curl -X POST "https://api.hyperbolic.xyz/v1/marketplace/bare-metal" \ -H "Authorization: Bearer $HYPERBOLIC_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "gpu_count": 8, "gpu_type": "H100", "network_type": "infiniband" }' ``` ## Step 6: Connect to Your Instance Once your instance is running, connect via SSH: ```bash theme={null} # Basic connection ssh ubuntu@ # With specific key file ssh -i ~/.ssh/id_ed25519 ubuntu@ ``` ### First Commands to Run ```bash theme={null} # Check GPU status nvidia-smi # Check CUDA version nvcc --version # Check available disk space df -h # Check Python and pip python3 --version pip3 --version # Monitor GPU usage in real-time watch -n 1 nvidia-smi ``` ## Step 7: Start Building ### Quick Examples ```python theme={null} # train.py import torch import torch.nn as nn from torch.utils.data import DataLoader # Check GPU availability device = torch.device('cuda' if torch.cuda.is_available() else 'cpu') print(f"Using device: {device}") # Your model model = YourModel().to(device) # Training loop for epoch in range(num_epochs): for batch in dataloader: inputs, labels = batch inputs, labels = inputs.to(device), labels.to(device) # Training code here ``` Run with: ```bash theme={null} python3 train.py ``` ```bash theme={null} # Install Jupyter if not present pip install jupyter # Start Jupyter with no browser jupyter notebook --no-browser --port=8888 # From your local machine, forward the port: # ssh -L 8888:localhost:8888 ubuntu@ # Then open: http://localhost:8888 ``` ```bash theme={null} # Clone your repo or upload data git clone https://github.com/your-repo/llm-finetuning.git cd llm-finetuning # Install requirements pip install -r requirements.txt # Run fine-tuning python finetune.py \ --model_name "meta-llama/Llama-2-7b-hf" \ --dataset "your-dataset" \ --output_dir "./fine-tuned-model" ``` ## Managing Your Instance ### Monitor Usage Check your instance status and billing: ```bash theme={null} # On the instance - check GPU utilization nvidia-smi # Check running processes ps aux | grep python # Monitor system resources htop ``` ### Save Your Work Always save your work regularly to persistent storage or cloud backups! ```bash theme={null} # Save to persistent storage cp -r /workspace/results /mnt/storage/ # Upload to cloud storage aws s3 cp model.pth s3://your-bucket/models/ # Push to git git add . git commit -m "Save checkpoint" git push ``` ### Stop or Terminate 1. Go to [My Instances](https://app.hyperbolic.ai/instances) 2. Find your running instance 3. Click "Terminate" ```bash theme={null} curl -X DELETE "https://api.hyperbolic.xyz/v1/marketplace/instance/" \ -H "Authorization: Bearer $HYPERBOLIC_API_KEY" ``` ## Common Issues & Solutions If you're still experiencing issues after trying these solutions, please contact us at [**support@hyperbolic.ai**](mailto:support@hyperbolic.ai) or use the chat in the bottom-right corner of the [app](https://app.hyperbolic.ai) after you sign in. ### Connection Issues **Problem**: SSH key not recognized **Solution**: ```bash theme={null} # Check you're using the right key ssh -i ~/.ssh/correct_key ubuntu@ # Verify key is added to account # Go to app.hyperbolic.ai/settings ``` **Problem**: Cannot reach instance **Solution**: * Check instance is running in dashboard * Verify IP address is correct * Check firewall/security group settings * Try different region if persistent **Problem**: SSH host key changed **Solution**: ```bash theme={null} # Remove old host key ssh-keygen -R # Then reconnect ssh ubuntu@ ``` ### GPU Issues **Problem**: GPU memory exhausted **Solution**: ```python theme={null} # Reduce batch size batch_size = 16 # Lower this # Use gradient accumulation accumulation_steps = 4 # Clear cache torch.cuda.empty_cache() # Use mixed precision from torch.cuda.amp import autocast with autocast(): output = model(input) ``` **Problem**: nvidia-smi shows no GPUs **Solution**: ```bash theme={null} # Check drivers nvidia-smi ``` GPU drivers are preinstalled on all instances. If `nvidia-smi` does not report your GPUs, contact support rather than installing drivers yourself. Don't run `sudo reboot` from inside the instance. If the dashboard shows a **Reboot** action for your instance, use that; if it doesn't, contact support — an in-OS reboot on those machines can leave the instance unrecoverable. **Still need help?** Email [**support@hyperbolic.ai**](mailto:support@hyperbolic.ai) or use the chat in the bottom-right corner of the [app](https://app.hyperbolic.ai) after you sign in. See [Support](/docs/general/support) for support hours. ## Best Practices Monitor GPU utilization to ensure you're getting the most from your H100/H200/B200 instances. Regularly save model checkpoints and important data to persistent storage or cloud. Use `nvidia-smi` and billing dashboard to track GPU utilization and costs. Always terminate instances when finished to avoid unnecessary charges. ## Next Steps Learn advanced instance management, monitoring, and automation Configure persistent storage and custom networking ## Need Help? For additional support: * **Email**: [support@hyperbolic.ai](mailto:support@hyperbolic.ai) * **Chat**: Sign in to the [app](https://app.hyperbolic.ai) and use the chat in the bottom-right corner # Storage and Port Configuration Source: https://hyperbolic.ai/docs/on-demand/storage-and-ports Learn how to configure storage volumes and network ports for your H100, H200, B200, and B300 GPU instances to support machine learning workloads, model training, and inference deployments. ## Storage Options Every GPU instance comes with onboard storage included, plus the option to attach persistent storage volumes. ### Where to Find Storage in the App Storage options are available in the dashboard under **GPUs → On-Demand GPUs → Storage**. To create a storage volume, click **Create New Storage** in the upper-right corner of the page. Storage Overview page in the Hyperbolic dashboard, reached via GPUs → On-Demand GPUs → Storage, showing total volumes, attached volumes, and total capacity, with the Create New Storage button in the upper-right corner Storage rates vary by region. ### Storage Types Overview **Automatically Included with Every Instance** * **Cost:** Free (included with instance pricing) * **Provisioning:** Automatically available when instance starts * **Persistence:** ❌ **Erased when instance is terminated** * **Performance:** High-speed NVMe SSD (up to 7,000 MB/s) * **Use Cases:** Active training, temporary data, cache, scratch space Onboard storage is erased when the instance is terminated. Always save important data to persistent storage or external services before terminating an instance. **Optional Add-on Storage Volumes** * **Cost:** Additional hourly charges apply * **Provisioning:** Created separately, then attached to instances * **Persistence:** ✅ **Survives instance termination** * **Performance:** Network-attached (up to 1,000 MB/s) * **Use Cases:** Long-term data, model checkpoints, datasets, shared resources * **Size:** 100GB - 10TB per volume (customizable) * **Availability:** Region-specific — the console shows the storage option for regions that support it (if you need storage in a region that doesn't offer it, please [contact us](mailto:support@hyperbolic.ai)) Persistent storage volumes are created and managed separately from instances. They can be: * Attached to running instances after creation * Detached from one instance and reattached to another * Retained even after all instances are terminated * Shared between multiple instances (read-only mode) Persistent storage availability varies by region. If your region doesn't show a storage option in the console, contact us at [support@hyperbolic.ai](mailto:support@hyperbolic.ai). ### Requesting Custom Storage Configurations If the standard options don't fit your workload — a region without a storage option in the console, larger volumes, specific performance requirements, or shared storage across a cluster — email [support@hyperbolic.ai](mailto:support@hyperbolic.ai) with: * **Region(s)** where you need the storage * **Capacity** and expected growth * **Performance needs** (throughput/IOPS, sequential vs. random access) * **Duration** — how long you'll need it, and whether it's tied to a reservation * **Attachment plan** — single instance, or shared across multiple instances/a cluster For large or long-term custom configurations, [sales@hyperbolic.ai](mailto:sales@hyperbolic.ai) can scope options as part of a Reserved or Private Cloud arrangement. ### Working with Storage #### Using Onboard Storage Onboard storage is automatically mounted and ready to use when your instance starts: ```bash theme={null} # View all available storage df -h # Onboard storage is typically mounted at: # /home/ubuntu (root volume for OS and user files) # /mnt or /data (additional onboard storage space) # Check onboard storage usage du -sh /home/ubuntu/* du -sh /mnt/* ``` The exact mount points may vary by instance configuration. Use `df -h` or `lsblk` to see all available storage. #### Creating and Attaching Persistent Storage In the Hyperbolic web console: 1. Navigate to the Storage section 2. Click "Create Persistent Volume" 3. Specify size (100GB - 10TB) 4. Select a region that supports storage volumes 5. Name your volume for easy identification Persistent storage incurs additional hourly charges. Check current pricing in the console. After creating the volume: 1. Go to your running instance details 2. Click "Attach Storage" 3. Select your persistent volume from the list 4. The volume will be attached as a block device (e.g., `/dev/vdb`) SSH into your instance and mount the volume: ```bash theme={null} # Check if volume is attached lsblk # Format if new volume (only do this once!) sudo mkfs.ext4 /dev/vdb # Create mount point sudo mkdir -p /mnt/persistent # Mount the volume sudo mount /dev/vdb /mnt/persistent # Set permissions sudo chown -R $USER:$USER /mnt/persistent # Make mount persistent across reboots echo "/dev/vdb /mnt/persistent ext4 defaults 0 2" | sudo tee -a /etc/fstab ``` ### Storage Configuration #### Storage Planning by Workload When launching an instance, plan your storage strategy based on your workload and available options: **Training Workloads:** * Use onboard storage for active training data and scratch space * If available in your region, attach persistent storage for: * Model checkpoints * Final trained models * Datasets you want to reuse * For regions without persistent storage, implement regular backups to S3/GCS/Azure **Development/Experimentation:** * Use onboard storage for active development * Save important results to persistent storage or external services * Implement git hooks to backup code changes #### Managing Storage Volumes ```bash theme={null} # View all storage available on your instance df -h # Check disk usage by directory du -sh /* # Monitor I/O performance iostat -x 1 ``` Your onboard storage is automatically available and includes: * System root volume (OS and applications) * Additional data volume (varies by configuration, up to 24TB) If you've created persistent storage (available in select regions): ```bash theme={null} # List block devices to find your persistent volume lsblk # Persistent volumes appear as /dev/vd* devices # Mount your persistent volume sudo mkdir -p /mnt/persistent sudo mount /dev/vdb /mnt/persistent # Make mount persistent across reboots echo "/dev/vdb /mnt/persistent ext4 defaults 0 2" | sudo tee -a /etc/fstab ``` Remember: Onboard storage is erased when the instance is terminated! Before terminating an instance: ```bash theme={null} # Option 1: Copy to persistent storage (if available) rsync -avP /home/ubuntu/important-data/ /mnt/persistent/backup/ # Option 2: Upload to S3 aws s3 sync /home/ubuntu/models/ s3://my-bucket/models/ # Option 3: Upload to Google Cloud Storage gsutil -m cp -r /home/ubuntu/checkpoints/ gs://my-bucket/checkpoints/ # Option 4: Create tar archive and upload tar -czf models.tar.gz /home/ubuntu/models/ curl -T models.tar.gz https://transfer.sh/models.tar.gz ``` ### Data Management Best Practices #### Organizing Your Storage **Using Onboard Storage (All Instances):** ```bash theme={null} # Onboard storage structure (size varies by configuration, up to 24TB) /home/ubuntu/ # User home directory ├── code/ # Your application code ├── data/ # Active datasets ├── models/ # Working models └── outputs/ # Results and logs /mnt/data/ # Additional onboard space (if available) ├── cache/ # Temporary files ├── checkpoints/ # Training checkpoints └── scratch/ # Experimental work ``` **Using Persistent Storage (When Available):** ```bash theme={null} # Persistent volume (created separately, attached to instance) /mnt/persistent/ # Survives instance termination ├── datasets/ # Reusable datasets ├── model-library/ # Trained models collection ├── checkpoints/ # Important checkpoints └── shared-resources/ # Team shared data ``` #### Backup Strategies Since onboard storage is erased on termination, implement appropriate backup strategies: **For Instances with Persistent Storage:** ```bash theme={null} # Automated backup from onboard to persistent storage # Add to crontab: crontab -e 0 */2 * * * rsync -avP /home/ubuntu/models/ /mnt/persistent/models/ 0 */4 * * * rsync -avP /home/ubuntu/checkpoints/ /mnt/persistent/checkpoints/ ``` **For Instances without Persistent Storage:** ```bash theme={null} # Option 1: Backup to S3 aws s3 sync /home/ubuntu/models/ s3://my-bucket/models/ --delete # Option 2: Backup to Google Cloud Storage gsutil -m rsync -r /home/ubuntu/models/ gs://my-bucket/models/ # Option 3: Backup to Azure Blob Storage az storage blob sync -s /home/ubuntu/models/ -c mycontainer # Automate with cron (every 6 hours) 0 */6 * * * aws s3 sync /home/ubuntu/important/ s3://my-bucket/backup/ ``` #### Optimizing Storage Performance **Maximize Onboard Storage Performance:** * Onboard NVMe provides up to 7,000 MB/s throughput * Use for active datasets and model training * Keep frequently accessed files on onboard storage * Clean temporary files regularly to maintain performance **Persistent Storage Optimization (if available):** * Network-attached with up to 1,000 MB/s throughput * Best for long-term storage, not active training * Use for model archives and dataset libraries * Consider compression for infrequently accessed data **Managing Limited Storage:** ```bash theme={null} # Monitor disk usage closely watch -n 60 'df -h | grep -v tmpfs' # Clean package caches pip cache purge conda clean --all -y apt-get clean # Remove old Docker images if using containers docker system prune -a -f # Stream large datasets instead of downloading # Example with TensorFlow: dataset = tf.data.TFRecordDataset(["s3://bucket/data.tfrecord"]) ``` **Data Lifecycle Management:** ```bash theme={null} # Set up automated cleanup for temporary files find /home/ubuntu/cache -type f -mtime +1 -delete find /tmp -type f -mtime +1 -delete # Compress old checkpoints find /home/ubuntu/checkpoints -name "*.ckpt" -mtime +7 -exec gzip {} \; # Archive completed experiments tar -czf experiment-$(date +%Y%m%d).tar.gz /home/ubuntu/experiments/completed/ ``` ## Port Configuration Configure network ports to enable access to services running on your GPU instances. ### Opening inbound ports Inbound ports on your instance's public IP are closed by default except SSH. **When you launch an instance**, add the ports you need in the port configuration field of the launch form. They're open by the time the instance is ready. **After launch**, port changes are made by our team — editing ports on a running instance is on the roadmap. Message support (chat widget or [support@hyperbolic.ai](mailto:support@hyperbolic.ai)) with: * the instance name(s) and public IP(s) * the ports and protocol (for example `443/tcp`, `3000/tcp`) Include everything above and requests are usually completed within one business day. Port 22 is reserved for platform SSH and can't be reassigned to your own service. If something you run wants port 22, put it on another port (2222 is the usual choice) and open that instead. For anything you don't need reachable from the internet, SSH tunnels (below) work immediately with no configuration. ### Exposing Services #### SSH Port Forwarding The most secure method for accessing services: ```bash theme={null} # Local machine: Create SSH tunnel ssh -L 8888:localhost:8888 ubuntu@[instance-ip] -i ~/.ssh/hyperbolic_key.pem # On instance: Launch Jupyter jupyter notebook --no-browser --port=8888 # Access at: http://localhost:8888 ``` ```bash theme={null} # Local machine: Create SSH tunnel ssh -L 6006:localhost:6006 ubuntu@[instance-ip] -i ~/.ssh/hyperbolic_key.pem # On instance: Launch TensorBoard tensorboard --logdir=/mnt/ml-data/logs --port=6006 # Access at: http://localhost:6006 ``` ```bash theme={null} # Local machine: Forward custom port (e.g., 5000) ssh -L 5000:localhost:5000 ubuntu@[instance-ip] -i ~/.ssh/hyperbolic_key.pem # On instance: Run your service python app.py --port=5000 # Access at: http://localhost:5000 ``` #### Multiple Port Forwarding ```bash theme={null} # Forward multiple ports simultaneously ssh -L 8888:localhost:8888 \ -L 6006:localhost:6006 \ -L 5000:localhost:5000 \ ubuntu@[instance-ip] -i ~/.ssh/hyperbolic_key.pem ``` ### Advanced Networking #### SOCKS Proxy Configuration For full network access through your instance: ```bash theme={null} # Create SOCKS proxy ssh -D 8080 ubuntu@[instance-ip] -i ~/.ssh/hyperbolic_key.pem # Configure applications to use SOCKS proxy at localhost:8080 ``` #### Persistent Tunnels Use `autossh` for maintaining persistent connections: ```bash theme={null} # Install autossh sudo apt-get install autossh # Create persistent tunnel with auto-reconnect autossh -M 0 -f -N \ -o "ServerAliveInterval 30" \ -o "ServerAliveCountMax 3" \ -L 8888:localhost:8888 \ ubuntu@[instance-ip] -i ~/.ssh/hyperbolic_key.pem ``` ### Security Considerations Never expose services directly to the internet without proper authentication and encryption. Always use SSH tunnels for development and testing. #### Best Practices 1. **Use SSH tunnels** for all development services 2. **Implement authentication** before exposing any service 3. **Enable HTTPS** for production deployments 4. **Monitor access logs** regularly 5. **Rotate SSH keys** periodically ```bash theme={null} # Monitor active connections netstat -tulpn | grep LISTEN # Check SSH connection attempts sudo tail -f /var/log/auth.log | grep sshd # List established connections ss -tunap | grep ESTABLISHED ``` ## Storage and Port Automation ### Monitoring and Alerts Set up monitoring for both storage types: ```bash theme={null} #!/bin/bash # storage-monitor.sh echo "=== Storage Health Check ===" # Check onboard storage ONBOARD_USAGE=$(df -h /home/ubuntu | tail -1 | awk '{print $5}' | sed 's/%//') ONBOARD_SIZE=$(df -h /home/ubuntu | tail -1 | awk '{print $2}') echo "Onboard Storage: $ONBOARD_SIZE (${ONBOARD_USAGE}% used)" # Alert threshold THRESHOLD=85 # Alert if over threshold if [ $ONBOARD_USAGE -gt $THRESHOLD ]; then echo "⚠️ WARNING: Onboard storage ${ONBOARD_USAGE}% full (threshold: ${THRESHOLD}%)" echo " → Clean temporary files: find /tmp -type f -mtime +1 -delete" echo " → Clear package cache: pip cache purge && conda clean --all" fi # Check for persistent storage if mountpoint -q /mnt/persistent 2>/dev/null; then PERSISTENT_USAGE=$(df -h /mnt/persistent | tail -1 | awk '{print $5}' | sed 's/%//') PERSISTENT_SIZE=$(df -h /mnt/persistent | tail -1 | awk '{print $2}') echo "Persistent Storage: $PERSISTENT_SIZE (${PERSISTENT_USAGE}% used)" echo "✓ Data on persistent storage survives termination" else echo "⚠️ No persistent storage attached" echo "⚠️ ALL DATA WILL BE LOST ON INSTANCE TERMINATION!" fi # I/O performance tracking echo -e "\n=== Storage Performance ===" iostat -x 1 3 | tail -4 | head -3 # Backup status check echo -e "\n=== Backup Status ===" if crontab -l 2>/dev/null | grep -q rsync; then echo "✓ Automated backups are configured" crontab -l | grep rsync else echo "⚠️ No automated backups configured" echo " → Set up backups to persistent storage or external services" fi ``` ## Troubleshooting ### Common Storage Issues **Symptoms:** Persistent volume not visible or mount fails **Solutions:** ```bash theme={null} # 1. Check if persistent volume is attached lsblk # Look for /dev/vdb or similar # 2. Check if it has a filesystem sudo file -s /dev/vdb # 3. If "data" (no filesystem), format it (ONLY for new volumes!) sudo mkfs.ext4 /dev/vdb # 4. Create mount point and mount sudo mkdir -p /mnt/persistent sudo mount /dev/vdb /mnt/persistent # 5. Fix permissions sudo chown -R $USER:$USER /mnt/persistent # 6. Make persistent across reboots echo "/dev/vdb /mnt/persistent ext4 defaults 0 2" | sudo tee -a /etc/fstab ``` **Note:** Persistent storage must be created in the web console first, then attached to your instance. **Symptoms:** Training fails, services crash, unable to save checkpoints **Solutions:** ```bash theme={null} # 1. Check what's using space du -sh /* 2>/dev/null | sort -rh | head -20 df -h # 2. Clean temporary files and caches find /tmp -type f -mtime +1 -delete find ~/cache -type f -mtime +7 -delete pip cache purge conda clean --all -y apt-get clean # 3. Compress old checkpoints find ~/checkpoints -name "*.ckpt" -mtime +3 -exec gzip {} \; # 4. If you have persistent storage, move data there if mountpoint -q /mnt/persistent; then rsync -avP ~/models/ /mnt/persistent/models/ rm -rf ~/models/old_versions/ fi # 5. If storage is limited, use external storage # Upload to S3 and delete local copies aws s3 sync ~/outputs/ s3://my-bucket/outputs/ --delete-removed # 6. Remove Docker images if using containers docker image prune -a -f docker system prune -a -f --volumes ``` **Prevention Tips:** * Set up automated cleanup in cron * Use persistent storage for long-term data (if available) * Stream large datasets instead of downloading * Implement regular backups to external storage ### Common Port Issues **Symptoms:** Service fails to start on specified port **Solutions:** ```bash theme={null} # Find process using port sudo lsof -i :8888 # Kill process if needed sudo kill -9 [PID] # Or use different port jupyter notebook --port=8889 ``` **Symptoms:** Service running but not accessible **Solutions:** ```bash theme={null} # Verify service is listening netstat -tulpn | grep [PORT] # Check SSH tunnel is active ps aux | grep ssh # Restart SSH tunnel ssh -L [PORT]:localhost:[PORT] ubuntu@[instance-ip] -i ~/.ssh/key.pem ``` ## Getting Help If you encounter issues with storage or port configuration: 1. Check the instance logs in the web console 2. Review the troubleshooting section above 3. Use the Pylon widget in the console for immediate assistance 4. Contact [support@hyperbolic.ai](mailto:support@hyperbolic.ai) with: * Instance ID * Error messages * Steps to reproduce the issue # Troubleshooting Source: https://hyperbolic.ai/docs/on-demand/troubleshooting Fixes for the most common issues with GPU instances, connections, storage, and billing Start here when something isn't working. Each section covers the quick fixes first and links to the detailed guide. ## Connection issues 1. Confirm the instance is in the **Ready** state — SSH is only available once provisioning completes. 2. Copy the exact SSH command from your **Active Instances** page rather than constructing it by hand. 3. Verify you're using the **private key** matching the public key on your account, with correct permissions (`chmod 600 ~/.ssh/your_key`). 4. Run with `ssh -v` and include the output if you contact support. More detail: [On-Demand Quickstart — troubleshooting](/docs/on-demand/quickstart). * Use `tmux` or `screen` so sessions survive disconnects. * Long-running jobs should never depend on an open SSH session — run them under `nohup`, `tmux`, or a process manager. ## Instance issues Provisioning normally completes in minutes. If an instance is pending for more than 30 minutes, contact [support](/docs/general/support) with the instance ID. Instances that never become ready are automatically terminated at the provisioning timeout (\~3 hours) and are **never charged** — see [Pricing](/docs/on-demand/pricing). GPU drivers are preinstalled on all instances. **Do not install or upgrade drivers yourself** — contact [support](/docs/general/support) with the instance ID and the `nvidia-smi` output. The two common causes: * **Balance reached zero.** Instances are automatically terminated when your account balance is no longer positive. Configure [Auto Top-Up](/docs/general/auto-top-up) to prevent this. Note the 30-day grace period to recover data on storage volumes. * **Reservation ended with Reservation Protection off.** Reserved instances with Reservation Protection turned off are terminated at the end of the reservation period. With it on (the default at launch), the instance keeps running at the on-demand rate instead — see [Reserved Overview](/docs/reserved/overview#what-happens-at-the-end-of-the-term). On-machine data is not recoverable after termination; data on attached storage volumes survives. Run the checks in [Verifying Instance Performance](/docs/on-demand/verifying-performance) — they'll either identify the bottleneck or give you the outputs support needs to investigate. See [Managing Instances](/docs/on-demand/managing-instances) for the full lifecycle of instance states and what each one means. ## Storage and networking Check usage with `df -h`. Onboard NVMe is fixed per configuration; attach a persistent storage volume for more space, or clean caches (`~/.cache`, old checkpoints, unused Docker images: `docker system prune`). Details: [Storage and Ports](/docs/on-demand/storage-and-ports). Confirm the port has been opened on your instance (see [opening inbound ports](/docs/on-demand/storage-and-ports#opening-inbound-ports)) and that the service is bound to `0.0.0.0` rather than `localhost`. Read [Securing Open Ports](/docs/securing-open-ports) before exposing anything publicly. Attachment, mounting, and performance issues are covered in the [storage troubleshooting section](/docs/on-demand/storage-and-ports#troubleshooting). ## Billing Balance, deposits, and charge questions are covered in [Billing & Payments](/docs/general/billing-payments). The most common surprise: billing starts the moment an instance becomes ready and continues until termination — even when the GPU is idle. ## Still stuck? Contact [support](/docs/general/support) — include your instance ID, region, timestamps, and the exact error output. # Verifying Instance Performance Source: https://hyperbolic.ai/docs/on-demand/verifying-performance Benchmark tests to confirm your GPUs, interconnect, and storage are performing as expected Use these checks after launching an instance to confirm you're getting the performance you're paying for, and before opening a support ticket about slow workloads. For the hardware specs to compare against (memory, bandwidth, interconnect), see the [GPU comparison table](/docs/overview/platform-comparison#available-gpus). ## Quick health check ```bash theme={null} # GPUs visible, correct model and count, driver loaded nvidia-smi # Detailed per-GPU state: clocks, power limits, ECC errors nvidia-smi -q ``` Confirm that: * The **GPU model and count** match what you rented (H100 80GB, H200 141GB, B200 192GB, or B300 288GB) * **ECC error counts** are zero or not climbing * No GPU is stuck at low clocks or in a fallback power state while idle ## GPU diagnostics (DCGM) NVIDIA's Data Center GPU Manager runs structured hardware diagnostics: ```bash theme={null} # Install if not present (Ubuntu) sudo apt-get install -y datacenter-gpu-manager sudo systemctl start nvidia-dcgm # Level 2 diagnostic (~2 minutes): PCIe, memory, compute sanity dcgmi diag -r 2 # Level 3 (~30 minutes): adds stress and stability tests dcgmi diag -r 3 ``` Any test reported as **Fail** is grounds for a support ticket — include the full output. ## Compute throughput A large matrix multiplication measures real achievable throughput: ```python theme={null} import torch, time n = 8192 a = torch.randn(n, n, dtype=torch.bfloat16, device="cuda") b = torch.randn(n, n, dtype=torch.bfloat16, device="cuda") for _ in range(10): # warmup a @ b torch.cuda.synchronize() iters = 100 start = time.time() for _ in range(iters): a @ b torch.cuda.synchronize() elapsed = time.time() - start tflops = (2 * n**3 * iters) / elapsed / 1e12 print(f"{tflops:.0f} TFLOPS (BF16)") ``` Compare against the GPU's datasheet peak for dense BF16. Well-tuned large matmuls should reach a substantial fraction of peak; results dramatically below that across repeated runs (rule out thermal throttling and shared load first) are worth reporting to support. ## Memory bandwidth ```bash theme={null} git clone https://github.com/NVIDIA/nvbandwidth && cd nvbandwidth sudo apt-get install -y libboost-program-options-dev cmake . && make # Host-to-device, device-to-host, and device-to-device bandwidth ./nvbandwidth ``` Device-to-device results should approach the memory bandwidth listed for your GPU (3.35 TB/s H100, 4.8 TB/s H200, 8 TB/s B200). ## Multi-GPU and interconnect For multi-GPU instances and InfiniBand clusters, verify collective bandwidth with [nccl-tests](https://github.com/NVIDIA/nccl-tests): ```bash theme={null} git clone https://github.com/NVIDIA/nccl-tests && cd nccl-tests make # All-reduce across all 8 GPUs, 8 B to 8 GB message sizes ./build/all_reduce_perf -b 8 -e 8G -f 2 -g 8 ``` Check the **busbw** column at large message sizes: * On NVLink-connected nodes, bus bandwidth should scale toward the NVLink spec (900 GB/s on H100/H200, 1.8 TB/s on B200) — several hundred GB/s at large sizes is healthy on 8x H100. * On InfiniBand clusters, run the multi-node variant (via MPI) and confirm inter-node bandwidth is consistent with the cluster's InfiniBand configuration (up to 3.2 Tb/s). You can also confirm the interconnect topology directly: ```bash theme={null} nvidia-smi topo -m # NV-links between GPU pairs ibstat # InfiniBand link state and rate (clusters) ``` ## Storage I/O ```bash theme={null} sudo apt-get install -y fio # Sequential write/read throughput on the current volume fio --name=seqwrite --rw=write --bs=1M --size=4G --numjobs=1 --direct=1 fio --name=seqread --rw=read --bs=1M --size=4G --numjobs=1 --direct=1 ``` See [Storage and Ports](/docs/on-demand/storage-and-ports) for the difference between local NVMe and network volumes — expected throughput differs substantially between the two. ## If results are below expectations 1. Re-run the failing test at least twice to rule out transient load. 2. Capture the output of `nvidia-smi -q` alongside the benchmark output. 3. Contact [support](/docs/general/support) with the instance ID, region, and the collected outputs. # Welcome to Hyperbolic Source: https://hyperbolic.ai/docs/overview/overview Hyperbolic is an AI cloud platform for training, fine-tuning, and serving AI models at scale. Teams use Hyperbolic to access high-performance GPU infrastructure across On-Demand, Reserved, and Private Cloud, helping them move from experimentation to production without long procurement cycles or rigid upfront commitments. ## Choose Your Solution Start with the product that matches your workload. Use On-Demand GPUs for flexible compute, Reserved for predictable capacity at a lower rate, or Private Cloud for dedicated infrastructure. ### On-Demand GPUs **Best for:** Experimentation, model training, fine-tuning, custom deployments, and flexible GPU access. Launch high-performance GPU instances when you need capacity without committing before your workload is proven. On-Demand GPUs give teams flexible access to GPU infrastructure for testing, training, fine-tuning, benchmarking, and early production workloads. [Learn more about On-Demand GPUs →](/docs/on-demand/overview) ### Reserved **Best for:** Sustained GPU demand, production workloads, predictable usage, and teams that want a lower rate than on-demand. Reserved gives you the same GPU capacity you would use on-demand, reserved for a fixed term at a discounted rate. It runs on the same platform and the same hardware — you simply commit to the capacity up front for a lower price. Reserved is self-serve in the app, and larger commitments can also be arranged with our team. [Learn more about Reserved →](/docs/reserved/overview) ### Private Cloud **Best for:** Enterprise AI teams, sensitive workloads, dedicated environments, and teams that need stronger isolation and operational control. Private Cloud gives organizations dedicated GPU infrastructure for production-scale AI workloads. It is designed for teams that need predictable capacity, stronger isolation, custom infrastructure requirements, and a long-term partner for AI compute planning. [Learn more about Private Cloud →](/docs/private-cloud/overview) ## Quick Comparison | Solution | Best For | Access Model | Commitment | Infrastructure Control | | - | - | - | - | - | | **On-Demand GPUs** | Experiments, training, fine-tuning, flexible compute | Self-serve GPU instances | None | Full instance-level control | | **Reserved** | Sustained, predictable workloads | Reserve on-demand capacity, self-serve | Fixed term, paid up front | Same platform and control as on-demand | | **Private Cloud** | Enterprise workloads, sensitive use cases, dedicated environments | Private GPU infrastructure | Custom | Highest level of control and isolation | **GPU availability note** Hyperbolic provides access to high-performance GPU capacity, including H100, H200, B200, and B300 infrastructure. Availability may vary by product, supply, region, and configuration. Check the [Hyperbolic console](https://app.hyperbolic.ai/gpus) for current On-Demand and Reserved GPU options, or [contact our team](mailto:sales@hyperbolic.ai) for Private Cloud requirements. ## Who Uses Hyperbolic? ### AI-Natives For teams building AI products where compute access directly affects product velocity. Start on demand, test quickly, and move into reserved infrastructure as usage grows. ### Research Teams and AI Labs For teams running experiments, benchmarking models, fine-tuning workloads, and scaling research infrastructure without waiting through long procurement cycles. ### Infrastructure and Engineering Leaders For teams responsible for sourcing, validating, and scaling GPU infrastructure across training, fine-tuning, and production workloads. ### Enterprise AI Teams For organizations that need predictable capacity, dedicated environments, stronger isolation, and a path from pilot projects to production AI infrastructure. ## Get Started Set up your account and launch your first workload in minutes *** > **Need Help Choosing?** > > Not sure which service is right for you? Check our [detailed comparison guide](/docs/overview/platform-comparison) or [contact our team](mailto:support@hyperbolic.ai) for personalized recommendations. # Platform Comparison Source: https://hyperbolic.ai/docs/overview/platform-comparison Choose the right Hyperbolic service for your AI workload. ## Quick Comparison Table | Feature | On-Demand GPUs | Reserved | Private Cloud | | - | - | - | - | | **Best for** | Training, fine-tuning, experiments, burst compute | Sustained 24/7 workloads, predictable capacity | Production-scale, lowest pricing, long-term | | **Setup time** | \< 5 minutes | \< 5 minutes | Custom (days); capacity confirmed in 24h | | **Minimum commitment** | None (hourly) | From 1 week | Long-term (multi-month to multi-year) | | **Pricing model** | \$/GPU/hour | Discounted prepaid \$/GPU/hour | Custom contract | | **GPU access** | Full SSH / root (VM or bare metal) | Full SSH / root (VM or bare metal) | Full root, single-tenant; optional managed k8s / Slurm | | **Scaling** | Manual; self-serve multi-node | Self-serve; reserved up front | Pre-provisioned, custom topology | | **Networking** | Ethernet or InfiniBand (multi-node) | Ethernet or InfiniBand (multi-node) | InfiniBand, private subnets, network isolation | | **Support level** | Standard (sub-24h; P0 \< 1h) | Standard | Dedicated, direct-to-engineer (24×7) | | **SLA** | 99.5% uptime | 99.5% uptime | Custom, negotiated per contract | GPU rates vary by region and availability. Always check [app.hyperbolic.ai/gpus](https://app.hyperbolic.ai/gpus) for current rates and real-time availability. ## Detailed Comparison ### On-Demand GPUs Self-serve, pay-as-you-go GPU instances drawn from an aggregated supplier network. Spin up a single GPU or an interconnected multi-node cluster in minutes — no contracts, no upfront commitment, no sales calls. **When to use:** * Training and fine-tuning custom models * Running experiments, notebooks, and evaluations * Burst and batch processing jobs * Short training runs where you need full control of the environment **Key features:** * Full root access via SSH * Virtual Machine or Bare Metal configurations * Deploy interconnected H100, H200, B200, or B300 clusters (8, 16, 32, 64, 128+ GPUs) * Hourly billing with no hidden or egress fees — failed instances are never charged ### Reserved The same GPU capacity you would use on-demand, reserved for a fixed term at a discounted rate. Same platform, same hardware, same setup — you simply commit up front for a lower price. **When to use:** * 24/7 production inference and LLM tooling * Sustained or scheduled training runs * High-volume, predictable usage * Teams that want a discount on capacity they already run on-demand **Key features:** * Same on-demand GPUs, networking, and environment — reserved for your term * Self-serve in the app; larger commitments can also be arranged with our team * Discounted rate in exchange for committing to a term * Reserved instances run for the full term; extend before it ends, and Reservation Protection keeps them running at the on-demand rate afterwards **Pricing structure:** * Discounted prepaid \$/GPU/hour — longer terms unlock lower rates * Paid up front for the reservation period * See [Pricing](/docs/on-demand/pricing) for details ### Private Cloud Dedicated, single-tenant GPU infrastructure for production-scale AI workloads. Get an isolated environment with custom networking, storage, and SLAs — plus the best unit economics on long-term commitments. **When to use:** * Enterprise production workloads at sustained scale * Security-conscious teams that require single-tenant isolation * Large, long-term commitments (typically \$1M+ deployments) * Workloads that need custom SLAs, custom networking, or custom storage **Key features:** * Single-tenant, customer-isolated GPU clusters (H100, H200, B200, B300) * Network isolation with private subnets and firewall rules * High-bandwidth InfiniBand interconnect for distributed training * Choice of operating model: full platform visibility, [Managed Kubernetes](/docs/on-demand/managed-kubernetes) (beta), or a fully isolated environment where only your team holds credentials. Managed Slurm is on the roadmap. * Custom storage architecture (node-local NVMe and shared/parallel filesystems) * Dedicated, direct-to-engineer support with 24×7 coverage for critical issues **Pricing structure:** * Custom contract based on cluster size, GPU type, term length, and configuration * Long-term commitments with the best unit economics * [Talk to sales](mailto:sales@hyperbolic.ai) for a tailored quote ## Available GPUs Hyperbolic offers H100, H200, B200, and B300 capacity across On-Demand GPUs, Reserved, and Private Cloud. Availability may vary by product, region, supply, and configuration. If you need a specific GPU type, cluster configuration, or capacity profile, contact [sales@hyperbolic.ai](mailto:sales@hyperbolic.ai) and our team can help evaluate what is available or what can be sourced for your workload. | GPU | Architecture | Memory | Memory Bandwidth | NVLink | TDP | Best for | | - | - | - | - | - | - | - | | **B300** | Blackwell Ultra | 288 GB HBM3e | 8 TB/s | 1.8 TB/s | up to 1400 W | Long-context inference and frontier-scale training | | **B200** | Blackwell | 192 GB HBM3e | 8 TB/s | 1.8 TB/s | \~1000 W | Frontier-scale training and highest-throughput inference | | **H200** | Hopper | 141 GB HBM3e | 4.8 TB/s | 900 GB/s | 700 W | Large-model training and memory-bound inference | | **H100** | Hopper | 80 GB HBM3 | 3.35 TB/s | 900 GB/s | 700 W | Mainstream training, fine-tuning, and inference | **Node configuration (H100 / H200):** 8 GPUs per node with up to 160 vCPUs and up to 2 TB RAM per node, and up to 24 TB of local NVMe storage. Available as Virtual Machines (fast, flexible, ideal for development and small-to-medium training) or Bare Metal (full root access and system-level control, ideal for large-scale distributed training and custom CUDA configurations). **Node configuration (B200):** 8× NVIDIA B200 per node with dual Intel Xeon 6960P CPUs, \~3 TB of RAM, NVMe storage (960 GB OS drive plus 4× 3.84 TB in RAID5), and 2× 100 GbE bonded networking. **Interconnect:** Single-node instances use standard networking; multi-node clusters can use InfiniBand (up to 3.2 Tb/s, NDR / ConnectX-7) for low-latency GPU-to-GPU communication — essential for distributed training at 32+ GPUs. Choosing between H100, H200, B200, and B300? Use H100 for mainstream training, fine-tuning, and inference. Choose H200 for larger models, longer context, or memory-bound inference. Choose B200 for maximum per-GPU throughput on frontier-scale training and inference. Choose B300 when memory per GPU is the constraint — largest models and longest contexts. ## Need Help Deciding? Get personalized recommendations and custom quotes for Reserved and Private Cloud Get help from our support team Price a reserved cluster in-app in minutes Launch your first GPU instance in minutes # Getting Started Source: https://hyperbolic.ai/docs/overview/quickstart Set up your Hyperbolic account and launch your first AI workload in minutes ## Getting Started [Sign up for Hyperbolic](https://app.hyperbolic.ai), then verify your email address. Check your inbox for a verification email and click the link to activate your account. Once verification is complete, you will be able to access the Hyperbolic platform. Before launching GPU instances, add funds to your account. Go to Billing → Add Funds, or click the Deposit icon in the top-right of your dashboard. Add at least \$5.00 to your balance, then complete your payment through Stripe. Add credits dialog with preset amounts ($25, $50, $100, other) and a Pay Now button Pro tip: Enable Auto Top-Up to help avoid interruptions. Auto Top-Up automatically adds credits to your account when your balance gets low, helping prevent active instances from being stopped or terminated because of insufficient funds. Set up automatic reloading to ensure uninterrupted service: 1. Go to Billing → Auto Top-Up Settings 2. Set your minimum balance threshold (e.g., \$20) 3. Choose auto-reload amount (e.g., \$50) 4. Save your preferences You can manage your payment method, credits, and Auto Top-Up settings from the Billing page. If you are working with a team, create or join an Organization before launching workloads. Organizations let teammates share access to the same workspace, billing balance, and infrastructure usage. After creating or joining an Organization, invite your teammates so everyone can manage resources from one account instead of using separate individual accounts. You can manage Organizations from the top-left menu in your dashboard. Organization switcher menu in the top-left of the dashboard, showing the Personal organization and a New Organization option Select the product that matches your workload: * Need flexible GPU access? Start with [On-Demand GPUs](/docs/on-demand/overview). * Need predictable capacity at a lower rate? Reserve it self-serve with [Reserved](/docs/reserved/overview). * Need dedicated, custom-built infrastructure? [Contact the team](mailto:sales@hyperbolic.ai) about Private Cloud. Launch workloads, test infrastructure, serve models, and scale into reserved or dedicated capacity when your requirements become predictable. Follow the quickstart for your path: * [On-Demand GPU Quick Start](/docs/on-demand/quickstart) — launch your first GPU instance Launching a GPU instance requires a saved SSH key, which you select when you launch. Add keys in your account settings. See [SSH Keys](/docs/general/account-management#ssh-keys) for details. ## Platform Capabilities Start with on-demand GPU instances, then move into reserved or private infrastructure as workloads scale. Lock in GPU capacity for a fixed term at a discounted rate, self-serve from the dashboard. Support training, fine-tuning, inference, and production AI workloads with infrastructure that can grow with your team. ## Ready to Build? Choose the infrastructure path that matches your workload today, then scale as your requirements become clearer. **Useful links:** * [Dashboard](https://app.hyperbolic.ai) — manage instances, billing, and organizations ## Need Help? * 📧 Email: [support@hyperbolic.ai](mailto:support@hyperbolic.ai) ## Common Issues * Credit card payments appear instantly * Contact support if credits don't appear within 30 minutes 1. Ensure the instance was launched with the SSH key whose private key you're using 2. Check instance is in "running" state # Cluster Configuration Source: https://hyperbolic.ai/docs/private-cloud/configuration Design custom cluster topology, networking, and storage # Cluster Configuration Configure your dedicated cluster with the exact specifications your workloads require. Our team works with you to design the optimal setup for your use case. ## GPU Selection Choose from the latest NVIDIA hardware: | GPU Model | Memory | Best For | | - | - | - | | **Blackwell Ultra (B300)** | 288GB HBM3e | Largest models and long-context inference | | **Blackwell (B200)** | 192GB HBM3e | Cutting-edge training and inference | | **H200** | 141GB HBM3e | Next-gen LLM training and inference | | **H100** | 80GB HBM3 | Industry standard for large-scale training | ## Networking Options High-speed interconnects are critical for distributed training. Choose the right networking for your needs: ### InfiniBand (400Gb/s) Ultra-low latency networking for distributed training at scale. * Best for: Multi-node training with 32+ GPUs * Latency: Sub-microsecond * Topology: Fat-tree or custom ### RoCE (200Gb/s) High-speed Ethernet alternative with RDMA support. * Best for: Mixed training/inference workloads * Latency: Low microsecond * Easier integration with existing infrastructure ### NVLink Direct GPU-to-GPU communication within a node. * Best for: Intra-node communication * Bandwidth: Up to 900GB/s * Included with multi-GPU nodes ### Custom Topology Need something specific? We can design custom network architectures for your requirements. ## Compute Specifications Configure the CPU and memory for your nodes: | Component | Options | | - | - | | **CPU** | Up to 256 cores per node | | **RAM** | Up to 2TB per node | | **Internet Bandwidth** | 10-100 Gbps connectivity | ## Storage Storage for Private Cloud is designed per deployment. What's available depends on the datacenter your cluster is built in, so we scope it with you rather than from a fixed menu. * **Node-local NVMe** — every node ships with local NVMe for checkpoints and scratch. Capacity and layout vary by SKU and site; we confirm the exact configuration in your order form. * **Shared filesystem** — network-attached shared storage (NFS or a parallel filesystem, depending on the site) can be provisioned for datasets and checkpoints shared across nodes. Capacity, throughput, and pricing are quoted per deployment. * **Object storage and backups** — available where the site supports it; scoped on request. When you talk to sales, include: total capacity and expected growth, throughput or IOPS requirements, whether it needs to be shared across the whole cluster, and how long you'll need it. That's enough for us to come back with what the site can do and what it costs. ## Example Configurations ### LLM Training Cluster Optimized for training large language models: | Component | Specification | | - | - | | GPUs | 64x H100 80GB | | Networking | InfiniBand 400Gb/s | | CPU | 128 cores per node | | RAM | 1TB per node | | Storage | Node-local NVMe + shared filesystem, scoped per deployment | Contact sales for pricing based on your specific configuration and commitment terms. ### Inference Cluster Optimized for high-throughput inference: | Component | Specification | | - | - | | GPUs | 16x H100 80GB | | Networking | RoCE 200Gb/s | | CPU | 64 cores per node | | RAM | 512GB per node | | Storage | Node-local NVMe, scoped per deployment | ### Research Cluster Flexible configuration for R\&D teams: | Component | Specification | | - | - | | GPUs | 32x H200 141GB | | Networking | NVLink + RoCE | | CPU | 128 cores per node | | RAM | 1TB per node | | Storage | Node-local NVMe + shared filesystem, scoped per deployment | ## Security Options * **VPN Access**: Secure connectivity to your cluster * **Private Networking**: Isolated network environment * **Custom Firewall Rules**: Control inbound/outbound traffic * **Compliance Configurations**: Hyperbolic is currently pursuing a SOC 2 Type II certification ## Next Steps Learn how Private Cloud works and when to use it Discuss your requirements and get a tailored quote # Cluster Handover Source: https://hyperbolic.ai/docs/private-cloud/handover What we validate before delivering a Private Cloud cluster, and what your handover document contains Every Private Cloud cluster is delivered with a handover document specific to your deployment. This page describes what we check before handover and what the document contains, so you know what to expect and what to verify on first login. ## Before handover A cluster is not delivered until it has passed: 1. **Acceptance certification.** A benchmark run across the delivered nodes — GPU health, NCCL collectives (all-reduce, reduce-scatter, all-gather), per-rail and pairwise fabric bandwidth, and correctness — scored against pass thresholds. The certification run ID and score are recorded in your document. 2. **Hardening validation.** The effective SSH daemon configuration is audited (`sshd -T`) for public-key-only authentication; a password-only login attempt must fail with `Permission denied (publickey)`; default accounts are confirmed locked; the firewall or security-group policy is reviewed against the intended exposure. 3. **Account cleanup.** Provisioning, installer, and partner accounts are removed. Your user and public key are installed; the sudo decision (passwordless or not) is recorded. 4. **Data sanitization.** Drives that have been used before are block-erased at the hardware level and fresh filesystems created. Nothing from a previous tenant is copied forward. 5. **Runtime checks.** Docker and the NVIDIA Container Toolkit are verified on every node with a disposable GPU container that must see all GPUs; the test containers and images are removed afterwards. 6. **Cleanup.** Benchmark containers, temporary files, and benchmarking artifacts are removed. No benchmark jobs are left running at handover unless coordinated with you. 7. **Baseline capture.** OS, kernel, driver, container runtime, and RDMA port state are recorded per node. When nodes are **added** to an existing cluster, the additions get access, runtime, and sanitization checks and a fresh baseline. The original certification is not automatically extended to the combined cluster — ask for a re-certification if you want a benchmark that covers the new topology. ## What the handover document contains | Section | What's in it | | - | - | | **Access and node inventory** | Hostname, public IP, and internal IP for every node; the SSH command and user; the fingerprint of the key we installed (never the key itself); sudo state | | **System baseline** | Per node: OS release, kernel, NVIDIA driver, Docker version, active RDMA ports — recorded on the handover date | | **GPU topology** | GPU model, GPUs per node, total GPUs, enumeration check, and the command to view per-node topology (`nvidia-smi topo -m`) | | **Fabric** | Interconnect type — InfiniBand, or RoCE over Ethernet — active RDMA ports per node, observed link speed, and the verification commands (`ibstat`, `ibv_devinfo`). GPUDirect RDMA is verified with a GPU-aware NCCL run | | **Storage** | Local NVMe layout per node (for example a striped LVM/ext4 volume mounted at `/data`), root filesystem size and usage, sanitization status, and any shared or network mounts. Anything marked not mounted or not recorded is yours to verify before the first workload | | **Container runtime** | Docker, NVIDIA Container Toolkit, containerd, Buildx, and Compose versions; default runtime; GPU container smoke-test result | | **Recommended NCCL configuration** | The environment variables used during certification — HCA list, GID index, `NCCL_CROSS_NIC`, `NCCL_SOCKET_IFNAME`, and the rest. These were tuned for multi-node jobs on this fabric; don't apply the forced fabric settings to single-node jobs, and confirm library compatibility before you rely on them | | **Benchmark results** | Certification run, scorecard, and headline numbers — large-message all-reduce bandwidth, MFU, scaling efficiency — with the exact set of nodes they cover | | **Verification commands** | A spot-check set for first login | | **Handover status** | Each requirement above with its status and evidence | | **Notes, support, and escalation** | Deployment-specific caveats, how to reach us, and your reference IDs | ## First login Run these on each node and compare with your document: ```bash theme={null} whoami && sudo -n whoami # your user, passwordless sudo if recorded hostname && uptime nvidia-smi # all GPUs visible nvidia-smi topo -m # GPU <-> NIC topology ibstat && ibv_devinfo # RDMA ports active, link layer, rate docker ps # nothing of ours left running df -h / && lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS ``` Then confirm GPU access from a container: ```bash theme={null} docker run --rm --gpus all --ipc=host --ulimit memlock=-1 --net=host \ nvidia/cuda:12.8.1-base-ubuntu24.04 nvidia-smi ``` Anything that doesn't match the document — a missing mount, a port not active, a GPU not enumerated — goes to support with the node's short name and the command output. # Private Cloud Overview Source: https://hyperbolic.ai/docs/private-cloud/overview Custom GPU infrastructure for production-scale AI Private Cloud gives you dedicated GPU capacity configured around your networking, storage, security, and SLA requirements, with strong unit economics for long-term commitments. Private Cloud is arranged through our sales team under a custom contract. It is not self-serve. Once your contract is active, a **Private Cloud** tab in your dashboard shows your cluster's capacity, access details, and configuration. ## When to use Private Cloud * Enterprise production workloads at sustained scale * Security-conscious teams that require single-tenant isolation * Large, long-term commitments (typically \$1M+ deployments) * Workloads that need custom SLAs, custom networking, or custom storage ## Key features * Dedicated H100, H200, B200, and B300 GPU clusters * Network isolation with private subnets and firewall rules — see [Private Cloud Security](/docs/private-cloud/security) * High-bandwidth InfiniBand networking for distributed training * Flexible operating models, including [Managed Kubernetes](/docs/on-demand/managed-kubernetes) or a fully isolated environment where only your team holds credentials * Custom storage with node-local NVMe and shared or parallel filesystems * Delivered with acceptance benchmarks, hardening validation, and a per-node handover document — see [Cluster Handover](/docs/private-cloud/handover) * Direct access to engineers, with 24/7 coverage for critical issues ## Pricing and contract * Custom contract based on cluster size, GPU type, term length, and configuration * Long-term commitments with the best unit economics * Access, management, and payment terms are unique to each contract and are negotiated directly with a sales representative and a technical representative [Talk to sales](mailto:sales@hyperbolic.ai) for a tailored quote and to learn more about accessing and managing your Private Cloud instances. ## Your Private Cloud in the dashboard Once your contract is active, a **Private Cloud** tab appears in your dashboard. Select your cluster under **Compute**. The cluster page shows: * Cluster summary: GPU count and model, total GPU memory, node count, interconnect, and shared storage. * SSH access for the login node: user, authentication method, login node IP, private IP, connect command, and key fingerprint. * Node inventory: each node's role, hostname, public IP, internal IP, and GPU count. * System configuration and network: platform, NVIDIA driver, CUDA version, CPU, memory, InfiniBand ports, link class, aggregate bandwidth, and OFED version. * GPU software stack: the validated container image and NCCL version. * Storage: each filesystem with its mount point and size, plus local scratch. * Recommended NCCL configuration for your cluster. * Forwarded ports. * Additional information: benchmark results, support and escalation contacts, deployment notes, storage details, verification commands, and the handover date. The status shown is the state Hyperbolic last recorded for your cluster, not live telemetry. The handover document itself isn't available for download from the dashboard; request a copy from your support representative if you need one. You can't start, stop, reboot, or reimage nodes from the dashboard. For those actions, and for anything urgent, use the contacts under **Support & escalation** on the cluster page. # Security Source: https://hyperbolic.ai/docs/private-cloud/security **This page is about Private Cloud** — dedicated, single-tenant clusters built for one customer under contract and handed over for direct use. It does not describe On-Demand or Reserved instances; those run on the platform, are isolated by the orchestration layer, and are covered in [Security and Compliance](/docs/general/security-compliance). ## Shared responsibility For every infrastructure layer, Hyperbolic is your accountable party and single point of contact, whether we operate the layer directly or through the datacenter partner under our direction. | Layer | Hyperbolic | You | | - | - | - | | Facility, power, cooling | ✔ | | | Hardware lifecycle and replacement (GPU, fabric, storage) | ✔ | | | Out-of-band management (BMC/IPMI) | ✔ | By arrangement only | | Network edge: firewall and security-group policy, ingress | ✔ | Requested changes | | Fabric isolation (InfiniBand / RoCE partitioning) | ✔ | | | Baseline OS image and host configuration at handover | ✔ | | | In-OS configuration after handover (users, software, workloads) | | ✔ | | Your own images or reprovisioning pipelines on delivered nodes | Support | ✔ | | Data inside the environment | | ✔ | | Sanitization between tenants and at contract exit | ✔ | | If you reprovision nodes with your own images, in-OS controls become yours after handover; everything below the OS stays with us. ## Tenant isolation Private Cloud deployments are isolated at five layers: 1. **Allocation** — each physical host is assigned to exactly one customer at a time. No co-tenancy on a node. 2. **Access** — only your designated users and keys can authenticate to your nodes. 3. **Network** — nodes in your cluster can talk to each other; traffic between different customers' environments is denied by default. 4. **Storage and data** — your data stays local to your nodes and is wiped before any hardware is reused. 5. **Lifecycle** — a node must pass sanitization and validation before it can be assigned to anyone else. ## Network * **Perimeter.** Ingress is controlled by firewall or security-group policy scoped to your environment. Default posture is SSH only, with all other inbound ports closed; additional ports are opened on request for identified services. Where a site doesn't expose provider-side network controls, the same policy is enforced with host firewalls, instance-scoped access, and cross-customer deny rules. * **Source-IP allowlisting** of SSH and management access is available and recommended. A bastion — one hardened entry point on a non-standard port, allowlisted, with compute nodes not directly exposed — is the standard pattern. If you don't have stable egress IPs, a customer-managed VPN or overlay (Tailscale, for example) or restricted user allowlists work instead. * **Compute fabric.** InfiniBand and RoCE fabrics are partitioned per tenant. On InfiniBand your nodes sit in a dedicated partition (P\_Key) with full membership and the default partition is restricted, so nodes outside your partition cannot exchange RDMA traffic with yours. Partition membership is set at the subnet manager and tested end to end (cross-partition RDMA and IPoIB reachability checks) before handover. * **Out-of-band management.** BMC/IPMI is not exposed to customers by default; reimage, console, virtual media, and power operations are done by our operations team on a ticket. Where BMC access is extended to you by arrangement, it is reachable only from your allowlisted source IPs and scoped to your cluster. ## Host hardening at handover For clusters we provision and configure: * **Key-based SSH only.** Your public keys are installed and password authentication is disabled in the SSH daemon (`PasswordAuthentication no`, `KbdInteractiveAuthentication no`, `AuthenticationMethods publickey`, `PermitEmptyPasswords no`). Default OS account passwords are locked. Hardening lives in configuration drop-ins that take precedence over provisioning-time defaults, so it survives reprovisioning. * **Named accounts.** SSH is limited to your designated accounts and keys; `AllowUsers` allowlisting is applied on request. * **No third-party accounts.** Provisioning, installer, and partner accounts are removed or disabled before handover. No shared or template credentials remain on delivered nodes; anything needed for handover is delivered through a secure channel and rotated at handover. Where nodes are provisioned by the datacenter partner we require and validate the same posture. See [Cluster Handover](/docs/private-cloud/handover) for what is checked before delivery. ## Data lifecycle * **Between tenants:** storage is wiped, customer keys and accounts removed, the node re-imaged and re-validated before it can enter another customer's environment. * **At contract exit:** your data is deleted. The same exit and deletion requirements are imposed on datacenter partners through our due-diligence framework. ## Operations * **Monitoring and incident response.** Hardware and fabric health (GPU and ECC state, link health, performance baselines) are validated at onboarding and re-validated after any remediation. In-service issues are tracked through a shared ticketing pipeline with severity-based response targets — see [Getting Support](/docs/general/support). Security events follow a defined process: containment (isolating or removing affected nodes), credential rotation, log collection across host and partner layers, root-cause analysis, and customer notification with remediation status. Partner-side log retention varies by site and is assessed during datacenter partner due diligence. During a security investigation we collect the host and partner logs that are available for your environment; if a specific retention period matters for your compliance program, raise it with your account team so it can be written into your agreement. * **Change management.** Firmware, BIOS, and driver updates on your cluster are tested before rollout and scheduled with you in coordinated maintenance windows. We require change-control visibility from partners for the layers they operate. * **Physical security.** Clusters are hosted in enterprise datacenters with badged and escorted access, surveillance, and redundant power and cooling. Facility security is assessed as part of partner due diligence. ## Security program * **SOC 2.** Type I audit complete; the report is available under NDA. A Type II engagement is underway and the report will be available on completion. Current status and documents: [trust.hyperbolic.ai](https://trust.hyperbolic.ai). * **Continuous control monitoring** through a GRC platform with automated evidence collection and drift alerting. * **Vulnerability management** on defined SLAs: critical and high within 30 days, medium within 60, low within 90. * **Access governance.** Least privilege with periodic access reviews; MFA enforced on corporate identity, code repositories, and production tooling; employee background checks. * **Datacenter partner due diligence.** Every partner behind dedicated capacity is assessed on operating history and incident record, facility power and cooling, network and fabric architecture, tenant-isolation requirements, firmware/BIOS/driver change control, log retention, access management, spare-capacity and remediation commitments, and exit and data-deletion requirements. Capacity passes acceptance testing — performance and fabric-health benchmarks included — before it is offered to a customer, and is re-tested after material fixes or infrastructure changes. Specific deployments can differ from the standard controls above — for example where a customer declines IP allowlisting or runs its own images. Your deployment's configuration is recorded in your cluster handover document. # Reserved Getting Started Source: https://hyperbolic.ai/docs/reserved/getting-started Reserve GPU capacity in a few steps, self-serve through the app Reserving capacity works just like launching an On-Demand instance, using the same app and the same flow. Choose a fixed reservation term, pay up front, and lock in the capacity at a discounted rate. ## Reserve an instance Log in to Hyperbolic and select **GPUs** from the navigation. Browse the GPU capacity currently available in the platform. Don't see the capacity you need? [Contact Sales](mailto:sales@hyperbolic.ai) for additional capacity. Select the GPU type you want and select the GPU Count. Available reservation terms and discounted rates will appear below. Longer reservation terms have lower rates. Reservation step showing GPU count selection and term options — pay as you go, 1 week, 2 weeks, 1 month — with per-GPU/hr rates and savings Choose the reservation length that works for your workload. Review the rate and reservation details, then continue to the SSH key step. Reserved instances are paid up front, so your balance must cover the full reservation cost. Select a saved SSH key, or paste a new public key to save it and attach it to the instance. Then complete the instance configuration. See [SSH Keys](/docs/general/account-management#ssh-keys) to manage your saved keys. When you're ready, click **Start Building** to create your reserved instance. Your reservation begins when the instance is ready and runs for the full reservation term. Before it ends you can extend it from the instance's details page. When the term ends, **Reservation Protection**, which is on by default at launch unless you turn it off, keeps the instance running at the on-demand rate. If you turned it off, the instance is terminated when the reservation ends — save any data you need to persistent storage first. See [Reserved Overview](/docs/reserved/overview#what-happens-at-the-end-of-the-term). Have a large or long-term commitment? You can also work with our team directly. [Contact sales](mailto:sales@hyperbolic.ai) to discuss volume pricing and terms. Need dedicated, single-tenant infrastructure custom-built for your team instead? See [Private Cloud](/docs/private-cloud/overview). # Reserved Overview Source: https://hyperbolic.ai/docs/reserved/overview Reserve GPU capacity for a fixed term at a discounted rate Reserved gives you the same GPU capacity as On-Demand at a lower rate in exchange for a fixed-term commitment. It runs on the same platform and hardware. You can reserve capacity directly in the app or work with our sales team on larger commitments. ## On-Demand vs. Reserved Both use Hyperbolic's platform capacity through the same application. The only real difference is how you pay for it: | | On-Demand | Reserved | | - | - | - | | **Access** | Self-serve through the app | Self-serve in the app, or contact Sales for additional capacity | | **Billing** | Hourly, pay as you go | Paid up-front for the reservation term | | **Rate** | Standard on-demand rate | Discounted rate in exchange for committing | | **Terminate anytime?** | Yes | No — runs for the full reserved term; can be extended before it ends | | **At end of term** | — | Keeps running at the on-demand rate with Reservation Protection, which is on by default at launch unless you turn it off; otherwise terminates | | **Best for** | Flexible, short-term, or bursty workloads | Predictable, sustained workloads | Same GPUs, networking, and setup. Reserved locks in the capacity at a lower price. ## When to use Reserved * You have predictable, sustained GPU usage * You want a lower rate than on-demand in exchange for committing to a term * You want capacity secured for the duration of your reservation ## How it works Choose a fixed term when you create your instance and pay up front. Reserved instances run for the full reservation period and cannot be terminated early by you. ## Extending a reservation You can extend a running reservation before the term ends. Open the instance's details page and click **Extend Reservation** next to the current plan and end date. Choose a term, and the extension is added on top of your current end date. Extensions are prepaid at today's rate, with the same term discounts available at reservation time. Only one extension can be pending at a time; once the extended term begins, you can extend again. The instance keeps its IP, data, and configuration. ## What happens at the end of the term What happens is controlled by **Reservation Protection**, a setting on each reserved instance. It is on by default when you launch a reserved instance, unless you turn it off. * **Reservation Protection on:** the instance keeps running after the reservation ends and is billed hourly at the current on-demand rate until you terminate it. Conversion happens within about 10 minutes of the reservation ending; during that window the instance's end time reads **converting**. * **Reservation Protection off:** the instance is terminated at the end of the reservation. On-machine data is not recoverable, so save anything you need to persistent storage or an external service before the end date. You can set Reservation Protection when you create the reservation, or toggle it at any time before the term ends from **Instance Settings** on the instance's details page. Both on-demand and reserved capacity are self-serve through the app. For large commitments, you can also work with our team directly — [contact sales](mailto:sales@hyperbolic.ai) to discuss volume pricing and terms. Need dedicated, single-tenant infrastructure custom-built for your team? That's [Private Cloud](/docs/private-cloud/overview).