# Welcome to Compute with Hivenet
Source: https://docs.hivenet.com/about-hivenet
Understand how Compute uses organizations, prepaid credits, containers, virtual machines, and distributed GPU and CPU infrastructure.
Compute with Hivenet provides on-demand GPU and CPU resources for AI, software development, rendering, data processing, and other workloads that need more capacity than a local machine can provide.
You choose an available location, hardware configuration, software environment, and connection method. Compute prepares the resource and charges for eligible usage while it runs.
## How Compute is organized
Every Compute account operates within an **organization**. The organization is the shared boundary for:
* People and their roles
* Instances and other Compute resources
* Prepaid credits
* Billing and transaction history
An organization has one **Owner** and can also include **Admins** and **Members**.
* The Owner controls credits, payment methods, auto top-up, people, and ownership.
* Admins help manage people and organization settings and can view organization billing.
* Members can create and use organization resources but cannot manage people or billing.
See [How organizations work in Compute](/documentation/organizations/how-organizations-work) for the complete role comparison.
## What you can create
Compute supports two main instance types.
### Containers
Containers provide prepared software environments for application, development, AI, and inference workloads. You can use an available template or create a custom template for repeated configurations.
### Virtual machines
Virtual machines provide a full operating system for workloads that need broader system-level control.
Both types can use GPU or CPU-only configurations when those resources are available in the selected location.
## How instance creation works
The creation flow guides you through the main choices:
1. Confirm the organization you are using.
2. Choose a container or virtual machine.
3. Select an available location.
4. Choose GPU or vCPU-only resources and a suitable size.
5. Select a template or operating system.
6. Configure SSH, HTTPS, TCP, UDP, or Jupyter access as needed.
7. Name the instance and review the estimated cost.
8. Create it and wait for the status to reach **Running**.
Charging begins after the instance is running. See [Launch and connect to your first Compute instance](/documentation/essentials/create-instance) for detailed instructions.
## How billing works
Compute uses prepaid credits held in the organization balance. Running resources draw from that shared balance, and eligible Compute usage is charged per second.
Only the organization Owner can add credits, manage payment methods, or configure auto top-up. Admins can review organization spending, while Members cannot see organization-wide billing.
If an Admin or Member reaches the creation review with insufficient credits, the organization Owner must add more before the instance can be launched.
See [Billing information](/documentation/account-billing/billing-info) for payment, role, and transaction-history details.
## How you access a workload
Connection options depend on what you enable during creation:
* **SSH** for terminal access
* **HTTPS** for secure browser or API access
* **TCP or UDP** for applications that require those protocols
* **Jupyter Notebook** for browser-based notebook workflows when available
Some connection settings cannot be changed after creation, so review them before launching.
## Stop, start, and terminate
Use the instance lifecycle controls according to what you need next:
* **Stop** pauses compute charges and preserves the instance temporarily for a later start.
* **Start** returns a stopped instance to service when suitable capacity is available.
* **Terminate** permanently deletes the instance and its local data.
Save important data before terminating an instance. Terminated data cannot be recovered from the instance.
## Distributed infrastructure
Hivenet runs Compute across distributed infrastructure rather than relying on one central facility. Available locations and configurations depend on the capacity connected to the platform.
You choose from the resources currently offered in the console. The creation screen shows availability, technical specifications, and active pricing before you launch.
## Before you start
You’ll need:
* A Compute account
* Access to an organization
* Enough organization credits for the selected resource
* An SSH public key when you want terminal access
* A plan for saving any data you cannot afford to lose
Continue with the [Compute quickstart](/quickstart) when you’re ready to create your first instance.
# List hardware presets
Source: https://docs.hivenet.com/api-reference/catalogue/list-hardware-presets
/public-v1.yaml get /presets
Returns a cursor-paginated list of the hardware configurations
instances can run on, with their hourly price.
A preset fixes the GPU model and count, CPU, memory and storage. The
same preset may be offered in several regions at different prices, so
filter by `region` when comparing.
# List regions
Source: https://docs.hivenet.com/api-reference/catalogue/list-regions
/public-v1.yaml get /regions
Returns the region codes used across the API. Use a region's `name`
as the `region` filter on `GET /presets` and `GET /instances`.
The set is fixed — currently `UAE`, `FR` and `US` — and is returned in
full rather than paginated. It tells you which values the filters
accept, not which locations currently have capacity; use
`GET /presets` for what can actually be launched.
# Get an instance
Source: https://docs.hivenet.com/api-reference/instances/get-an-instance
/public-v1.yaml get /instances/{id}
Returns the full detail of one of your instances.
# List your instances
Source: https://docs.hivenet.com/api-reference/instances/list-your-instances
/public-v1.yaml get /instances
Returns a cursor-paginated list of your instances, newest first.
Only instances belonging to your account are returned. There is no way
to widen the result set to another account or organisation.
# Read an instance's logs
Source: https://docs.hivenet.com/api-reference/instances/read-an-instances-logs
/public-v1.yaml get /instances/{id}/logs
Returns recent console output from one of your instances, **newest
line first** (the same order as `kubectl logs --tail`). The window
reaches back at most 10 hours; older output is not retrievable through
this endpoint.
# Start an instance
Source: https://docs.hivenet.com/api-reference/instances/start-an-instance
/public-v1.yaml post /instances/{id}/start
Starts a stopped instance. The call returns as soon as the request is
accepted; the instance moves `STARTING → RUNNING` in the background, so
poll `GET /instances/{id}` to observe the transition.
Starting an already-running instance is accepted and changes nothing.
Returns `409` when the instance is `TERMINATING` or `TERMINATED`. A
terminated instance can never be started again.
# Stop an instance
Source: https://docs.hivenet.com/api-reference/instances/stop-an-instance
/public-v1.yaml post /instances/{id}/stop
Stops a running instance. The call returns as soon as the request is
accepted; the instance moves `STOPPING → STOPPED` in the background.
Storage is retained and the instance can be started again. Billing for
compute stops; storage may still be charged.
Stopping an already-stopped instance is accepted and changes nothing.
Returns `409` when the instance is `TERMINATING` or `TERMINATED`.
# Terminate an instance
Source: https://docs.hivenet.com/api-reference/instances/terminate-an-instance
/public-v1.yaml post /instances/{id}/terminate
Permanently destroys an instance and its storage.
**This cannot be undone.** The instance moves `TERMINATING → TERMINATED`
and can never be started again. Use `POST /instances/{id}/stop` if you
only want to pause billing.
Terminating one that is `STOPPING` is accepted; the stop does not have
to settle first.
Terminating one that is already `TERMINATING` is also accepted, and
re-issues the teardown. That is the way to recover a termination that
failed part-way. It is not a safe blind retry, though: once the
underlying resource is actually gone, a further call returns `500` until
the instance settles at `TERMINATED`. Poll `GET /instances/{id}` rather
than retrying on a timer.
Returns `409` only when the instance is already `TERMINATED`.
# Changelog
Source: https://docs.hivenet.com/changelog
Product updates and announcements for Compute with Hivenet, including new API endpoints, guides, and platform changes for developers.
> ## More reliable instance starts, SSH connections, and billing.
#### Instance reliability and storage
* Instances now reach **Running** only after they respond over SSH. Applications inside the instance may still need time to start.
* The console filters instance sizes against host capacity, refreshes availability as instances are created, and hides presets with no available location.
* Failed starts have a limited number of automatic retries. Start and stop operations recover more reliably from internal conflicts.
* Startup waits for disk preparation to finish. Cleanup fixes prevent healthy instances from being terminated and protect persistent volumes if an instance cleanup fault occurs.
See [Start and stop instances](/documentation/essentials/start-stop-instances) for recovery steps and the existing retention limits. Keep backups of important data before terminating an instance.
#### SSH and diagnostics
* Instances present signed SSH host certificates for server identity verification and can use a configured login username instead of an image's default username.
* SSH routing recovers automatically when it loses track of an instance.
* Support can use VM serial-console logs to investigate boot and crash problems.
Use the username and SSH command in the instance's connection details. See [SSH configuration and host verification](/tutorials/more-guides/SSH-config-file-explained).
#### Billing and credits
* Auto top-up is disabled when a user is moved to another organization without choosing to join it.
* Running Inference API deployments with an effective cost of €0 under a fully discounted contract are no longer stopped solely because the organization has zero credits.
* Organization discounts now apply to LLM model presets.
* Internal ledger entries no longer appear in transaction history.
See [Billing information](/documentation/account-billing/billing-info) and [Inference Service billing](/documentation/inference-api/billing).
#### VM performance
GPU hosts use NVIDIA driver 610 with open kernel modules. Updated GPU VM images avoid rebuilding the driver at startup, reducing boot preparation. CPU-only VMs use hugepages to improve memory performance.
> ## More predictable billing, more resilient Endpoints deployments, and clearer instance recovery.
#### Billing and credits
* Instance billing now stops as soon as an instance leaves the Running state. Time spent stopping or terminating is no longer charged.
* Organizations on contracts with a 100% discount now show an effective hourly price of €0.
* Endpoints deployments stop automatically when an organization's credit balance reaches zero.
#### Endpoints
* Replicas stuck in Starting can now recover automatically, with a manual retry available when needed.
* Scaling down pauses surplus replicas instead of deleting them, making it faster to scale back up.
* Dashboard metrics now report 7-day request counts and input/output token counts more accurately. p95 latency and error rate are measured over a 24-hour window.
* GPT-OSS 20B now supports OpenAI-compatible tool calls and reasoning output.
* Model variants are now served under their own names, avoiding collisions between variants.
#### Instance reliability
* Instances that fail to start retry a limited number of times before moving to a clear error state that you can retry manually.
* Instances stuck while stopping or terminating are cleaned up automatically.
* Reboots now have their own recovery window and no longer fall back to a stop.
* Invalid instance actions now return clearer errors instead of generic server errors.
#### SSH connectivity
Every instance now exposes a stable SSH endpoint on port 22. The endpoint is reported in the instance's events so it can be discovered consistently as the instance moves through its lifecycle.
> ## Public API access, organizations and teams, the production launch of Hivenet Inference API, and major reliability improvements across Compute.
#### Public Compute API v1
The first public Compute API is now available.
You can use eight documented endpoints to:
* List and inspect instances
* Read recent instance logs
* Start, stop, and terminate instances
* List available regions
* Browse available hardware presets
The API includes a published OpenAPI specification, consistent error responses, request IDs, and rate limiting. API tokens are tied to your user identity.
See the [getting-started guide](https://docs.hivenet.com/public-api/get-started-with-the-compute-api) to start using the API, or check the API changelog for endpoint-specific changes.
#### Organizations and teams
Organizations are now available to all Compute users, making it possible to manage instances, teammates, and credits together.
You can now:
* Create an organization
* Invite teammates by email
* Preview, resend, and manage pending invitations
* Assign roles to organization members
* Use a shared organization credit balance
Organization owners and admins can see all instances belonging to their organization.
Billing and transaction history now stay associated with the correct organization when members join, leave, or are removed. Credit transfers between accounts and organizations also appear in billing history.
Existing individual accounts have been migrated automatically to a personal organization.
Additional safeguards prevent accounts from being deleted while they still own an organization or have running instances.
#### Hivenet Inference API
The Hivenet Inference API is now available in production, with OpenAI-compatible endpoints running on NVIDIA RTX 5090 hardware.
Five models are available at launch:
* Qwen 3.6 27B
* Qwen 3.6 35B
* Gemma 4 31B
* Gemma 4 26B
* GPT-OSS 20B
Chat and asynchronous workloads support up to a 16K context window, while agentic workloads support up to 128K.
Inference usage is integrated with Compute billing and credits. Your inference workloads contribute to your live spend rate and stop automatically when your organization runs out of credit.
Inference reliability has also improved:
* Failed replicas restart faster.
* Model weights are loaded from a local cache at each location, reducing dependency on external downloads during startup.
* API keys associated with an organization are removed when that organization is deleted.
See the [Inference Service overview](/documentation/inference-api/overview) for how the managed service works, or follow [Get started with Hivenet Inference Service](/documentation/inference-api/get-started) to deploy an endpoint and make your first request.
#### Shared dedicated servers
Private Compute locations can now be shared across multiple organizations.
This allows several organizations, including separate teams belonging to the same customer, to use infrastructure reserved on the same dedicated server without requiring a separate location for each organization.
#### Instance reliability
A broad set of improvements makes core instance management and networking more reliable, including fixes across instance lifecycle, recovery, and networking behavior.
#### Faster support for instance issues
Hivenet Support can now perform additional recovery actions directly when troubleshooting an instance, including rebuilding an instance or changing its instance type.
This reduces the need to escalate some recovery cases to the Compute engineering team and can help get affected instances working again sooner.
#### Platform reliability
This release also includes infrastructure changes that improve monitoring, incident detection, deployment reliability, and how Compute manages regions as the platform expands.
> ## Manage existing Compute instances through the Hivenet API.
**Public Compute API documentation**
The new [Compute API documentation](/public-api/get-started-with-the-compute-api) is now available for developers building scripts, tools, and integrations with Hivenet.
The documentation covers:
* Listing, inspecting, starting, stopping, and terminating existing instances
* Reading recent instance logs
* Listing supported region codes and available hardware presets
* Authentication, pagination, error handling, and rate limits
* Request and response examples for every documented endpoint
See the [API changelog](/public-api/api-changelog) for endpoint additions and changes that may affect your integration.
> ## The RTX 4090 fleet has been retired from Compute with Hivenet.
On August 8, 2026, Hivenet completed the retirement of its RTX 4090 Compute fleet as part of the transition to newer GPU hardware.
RTX 4090 instances are no longer available for new workloads. Current GPU workloads should use the presets available in the Compute console, including NVIDIA RTX 5090 configurations.
Existing RTX 4090 instances and their local data were removed when the retired nodes were decommissioned.
Older tutorials, benchmark articles, and changelog entries may still mention RTX 4090 hardware when it is relevant to the configuration tested or available at the time. These references are historical and do not indicate current availability.
See [GPU types and sizes](/documentation/reference/gpu-types) for current fleet guidance.
> ## More accurate instance availability, Falcon-OCR inference, and more predictable networking.
**More accurate instance availability**
Instance presets now reflect real-time capacity more accurately. Configurations that can’t currently be provisioned appear disabled instead of disappearing from the list.
Sold-out and storage-constrained states are now more precise, reducing cases where an instance looked available but failed to launch.
**Inference improvements**
Falcon-OCR is now available in the managed model catalog.
Managed models now start faster and more reliably by loading weights from a local cache at launch instead of pulling them from an external endpoint.
vLLM runtime behavior is also more stable, with pinned dependencies and cleaner shutdown handling.
**Storage capacity checks improved**
Compute now checks available disk capacity more accurately before launch, including scheduling limits, disk reservations, and live replica state.
**Networking improvements**
Per-instance network controls now apply to both VM and container instances, helping make network behavior more predictable and reducing noisy-neighbor variability.
> ## More reliable GPU VM restarts, cleaner billing, and easier instance access.
**GPU VM reliability improved**
* Fixed several issues that could prevent GPU VMs from restarting, booting, or recovering cleanly, especially on Ubuntu GPU VMs and larger eight-GPU configurations.
* NVIDIA driver configuration now persists more reliably across package reinstalls and kernel upgrades, reducing the chance of GPU drivers breaking after a reboot.
**Instance lifecycle fixes**
* Stuck instances are now detected and recovered more reliably.
* Deleted instances now clean up related resources more consistently and are marked as terminated correctly.
* Deprecated Ubuntu and older image variants have been removed from the template catalog so unsupported builds can no longer be launched.
**Connectivity improvements**
* Instance connection panels now show full access URLs for each open port, making it easier to open Jupyter and custom services.
Fixed an issue where newly created instances could show an external TCP port as `0` in the Connectivity panel.
**Billing reliability improved**
* Fixed billing drift on stopped and errored instances.
* Compute now checks stopped instances regularly and closes any billing records that should no longer be active.
> Additional infrastructure and monitoring improvements were added to support more reliable regional routing and faster issue detection.
> ## This release improves GPU VM reliability, instance cleanup, SSH compatibility, and auto top-up stability.
**GPU VMs**
* Fixed GPU driver issues that could prevent GPU VMs from starting correctly on supported operating systems.
* Prevented automatic OS updates from breaking GPU drivers after a reboot on GPU VM images.
* Fixed a boot issue that could affect 8-GPU VMs.
* Improved image tagging for more predictable deployments across environments.
**Instance lifecycle**
* Fixed cleanup issues that could leave resources behind after an instance was terminated.
* Fixed an issue that could incorrectly show some instances as sold out in certain environments.
* Instances stuck in an error state are now automatically terminated and cleaned up.
* Fixed several edge cases affecting instance status updates and restart flows.
**SSH and security**
* Added ECDSA SSH key support.
* Enforced a minimum RSA key length of 2048 bits.
* Improved SSH connection performance for large file transfers.
**Infrastructure**
* Improved the reliability of auto top-up credit handling for accounts with automatic billing enabled.
> ## Improvements to instance management, billing, and reliability, plus a few UI polish updates.
**Instances**
* Instances can now be terminated while starting.
* Stopped instances are now retained for 10 days instead of 5.
* Improved the instance experience across several flows.
* Fixed OS image name display.
**Billing and transactions**
* Added a transaction history view.
* Lowered the minimum custom top-up amount from €20 to €10.
* Sold-out states are now handled more gracefully.
**Infrastructure and reliability**
* Improved SSH key validation.
**Copy and UI**
* Updated UI text and labels across the product.
> ## Lower GPU pricing, faster startup, and smoother custom networking.
**Pricing at the time of this release:**
* RTX 4090: **0.20 EUR/hour**
* RTX 5090: **0.40 EUR/hour**
These prices and GPU options are historical. See the current Compute console for available hardware and pricing.
**Enhanced networking:**
* Custom TCP, UDP, and HTTPS port configuration for improved flexibility.
* Upgraded SSH documentation and in-app help link for easier setup.
**Upgraded base container images:**
* Ubuntu 24.04 LTS, CUDA 12.8, and pre-configured Hugging Face cache.
* Faster time-to-first-training and consistent environments across GPUs.
**User experience improvements:**
* Updated sign-up profiling questions for clarity.
* Last seen tracking for active users on Compute.
> ## Expanded vLLM model catalog, faster launch times, and improved stability.
New pre-packaged vLLM models added (total of 10 now available):
* Meta Llama-3.1 8B Instruct
* Mistral Small-3.1 24B Instruct
* Llama 3.3 70B Instruct
* Mistral Small-24B Instruct
* Qwen-2.5 VL 32B Instruct
* GPT OSS 20B
Improved launch speed for LLM models with local caching (70B models can take up to 45 minutes).
Custom credit amounts now available for customers.
New user profiling on first sign-up or login (optional).
Stability improvements and bug fixes across workflows.
> ## HTTPS support, new inference options, and smoother instance setup.
HTTPS services are now available.
vLLM inference servers added.
Improved instance flow for smoother setup and management.
More connectivity options introduced.
> ## Instance controls, custom templates, and RTX 5090 support.
Stop and start your Compute instances.
Custom templates now supported.
Added RTX 5090 support.
# Billing information
Source: https://docs.hivenet.com/documentation/account-billing/billing-info
Learn how organization credits, billing roles, payment methods, auto top-up, invoices, and transaction history work for Compute organizations.
Compute uses prepaid credits held in an **organization balance**. Charges are deducted in real time while the organization runs Compute resources.
Your role determines which billing information you can see and whether you can change payment settings.
Only the organization **Owner** can add credits, manage payment methods, or configure auto top-up. **Admins** have read-only access to organization billing. **Members** cannot view or manage billing.
## Billing access by role
| Billing action | Owner | Admin | Member |
| :- | :-: | :-: | :-: |
| View the organization balance | Yes | Yes | No |
| View the current spend rate | Yes | Yes | No |
| View billing details | Yes | Yes | No |
| View transaction history | Yes | Yes | No |
| Add credits | Yes | No | No |
| Manage payment methods | Yes | No | No |
| Configure auto top-up | Yes | No | No |
Members can still create and use organization resources. Their usage is charged to the shared organization balance, even though they cannot see its billing details.
## Find billing in the console
Select **Billing** from the left sidebar.
What appears depends on your role:
* The **Owner** sees the balance, current spend rate, credit controls, auto top-up, billing details, and transaction history.
* **Admins** can review spending, billing details, auto top-up status, and transaction history, but cannot change them.
* **Members** see a notice that billing is managed by the organization Owner.
For an explanation of the role model, see [How organizations work in Compute](/documentation/organizations/how-organizations-work).
## How the organization balance works
The balance belongs to the organization rather than to an individual person. Usage from running instances and Hivenet Inference Service workloads draws from the same balance.
The console shows:
* **Balance:** Credits currently available to the organization, shown in EUR.
* **Current spend rate:** The combined hourly rate of resources running at that moment.
* **Time remaining:** An estimate based on the current balance and spend rate. It changes when resources start or stop.
The spend rate is shown per hour to make active costs easier to understand. Compute charges eligible usage per second, without an hourly minimum.
## Add credits
Only the Owner can add credits.
1. Open **Billing**.
2. Under **Add credits**, enter an amount or choose one of the available credit packs.
3. Select **Complete payment**.
4. Complete the payment through Stripe.
5. Return to Compute and confirm that the organization balance has updated.
Other Admins and Members cannot charge a payment method or add credits to the organization.
## Configure auto top-up
Auto top-up adds credits when the balance falls below a threshold. Only the Owner can configure it.
1. Open **Billing**.
2. Find **Auto top-up**.
3. Enable auto top-up.
4. Choose the balance threshold.
5. Choose how many credits to add when the threshold is reached.
6. Save the configuration.
Transferring organization ownership turns off the existing auto top-up configuration. The new Owner must review the payment details and configure auto top-up again.
Auto top-up is also disabled if your account is moved to another organization without you choosing to join it. Check the organization shown in the console and its payment details before the Owner enables auto top-up again.
## Review billing details and transaction history
Owners and Admins can review the organization’s billing details and transaction history.
Transaction history records changes to the organization balance, including:
* Credit purchases
* Credits transferred when someone joins the organization
* Other recorded credit transfers
Internal ledger entries are excluded from transaction history.
Billing details and payment methods are managed through Stripe. Only the Owner can make changes, but Admins can view the information shown in Compute.
## How charging works
* Charges begin when an instance reaches **Running** and stop as soon as it leaves the **Running** state. Time spent stopping or terminating is not charged.
* Running Hivenet Inference Service endpoints also contribute to the organization’s live spend rate. See [Understand Inference Service billing](/documentation/inference-api/billing) for how replica charges start, change, and stop.
* Stopping an instance pauses compute charges while preserving it for a later start.
* Terminating an instance permanently deletes it and its local data.
If your organization has a contracted discount, instance prices and LLM model preset prices reflect the effective hourly rate after that discount. A 100% discount therefore appears as €0 per hour.
If an instance runs for 12 minutes and 20 seconds, Compute charges for 740 seconds at that instance’s active price.
## What happens when credits run low
Compute prevents workloads from starting without enough credits. As the organization balance approaches zero, running workloads may stop or be terminated to prevent a negative balance. Running Hivenet Inference Service endpoints with a nonzero effective cost stop automatically when the organization reaches zero credit. Endpoints with an effective cost of €0 under a fully discounted contract are not stopped solely because the balance is zero.
The Owner can add credits or enable auto top-up to reduce the risk of an interruption.
Stopped and terminated workloads behave differently. Stopping preserves an instance temporarily; termination deletes its local data. Back up important files before the balance runs out.
## Payments, receipts, and taxes
* **Payment methods:** Available credit and debit cards are processed through Stripe.
* **Receipts:** Stripe sends a receipt after a successful credit purchase.
* **Currency:** Compute balances and prices are shown in EUR. Stripe may handle currency conversion for cards billed in another currency.
* **Taxes and VAT:** Applied where required using the billing information supplied through Stripe.
## Troubleshoot a payment
* **Card declined:** Check the available funds, complete any required 3-D Secure prompt, or use another card.
* **Payment completed but credits are missing:** Refresh Billing after a short wait. If the balance still has not changed, contact Support with the date, amount, and last four digits of the card.
* **Billing information is incorrect:** Ask the organization Owner to update the details through Stripe.
* **You cannot add credits:** Confirm that you are the organization Owner. Admins and Members cannot add credits.
Purchased Compute credits are non-refundable. If a payment error or confirmed technical fault caused an incorrect charge, contact Support so the case can be reviewed.
## See also
* [Understand Inference Service billing](/documentation/inference-api/billing)
* [Track organization spending in real time](/documentation/account-billing/track-costs-real-time)
* [How organizations work in Compute](/documentation/organizations/how-organizations-work)
* [Transfer ownership or delete an organization](/documentation/organizations/transfer-ownership-delete-organization)
# Delete your Compute account
Source: https://docs.hivenet.com/documentation/account-billing/delete-account
Prepare your organization membership, transfer ownership, terminate remaining instances, and permanently delete your personal Compute account from Hivenet.
Deleting your Compute account removes your personal access to Compute. It is different from deleting an organization, which removes shared resources, credits, and access for everyone in that organization.
Account deletion is permanent and cannot be undone. Save important data and resolve your organization membership before continuing.
## Before you delete your account
Complete these checks first:
* Download any data you want to keep from instances you created.
* Terminate every instance that has not already been terminated, including stopped instances.
* Save any data you still need before terminating those instances.
* Leave the organization you currently belong to.
* If you are the Owner, transfer ownership or delete the organization first.
Compute prevents account deletion while you still own an organization or have any non-terminated instances.
Terminating an instance permanently deletes its local data. Back up anything important before you stop using the account.
## Resolve your organization role
### If you are the Owner
An Owner cannot delete their personal account while they still control an organization.
Choose one of these paths:
* **Keep the organization:** Transfer ownership to an Admin, then leave the organization.
* **Remove the organization:** Delete the organization after confirming that its resources, data, remaining credits, and pending invitations are no longer needed.
If the person who should become Owner is currently a Member, change them to an Admin first.
See [Transfer ownership or delete an organization](/documentation/organizations/transfer-ownership-delete-organization).
### If you are an Admin or Member
Leave the organization before deleting your account:
1. Open **Organization** from the account menu.
2. Find your name and open its menu.
3. Select **Leave organization**.
4. Review the consequences and confirm the action.
If Compute reports that you still have instances, open **Instances**, save any necessary data, terminate the instances, and try again.
See [Join or leave a Compute organization](/documentation/organizations/join-leave-organization#leave-an-organization).
## Understand what happens to organization resources
The effect depends on what you do before deleting your account:
* If you transfer ownership and leave, the organization and its resources remain under the new Owner’s control.
* If you delete the organization, its instances and data are deleted, remaining credits are lost, and pending invitations are canceled.
* Leaving or losing access to an organization does not give you continued access to its billing history or shared resources.
Credits belong to the organization. Discuss the remaining balance with the Owner before leaving a shared organization.
## Delete your account
After resolving the organization and instance requirements:
1. Sign in to Compute.
2. Open the menu next to your account at the bottom of the sidebar.
3. Select **Settings**.
4. Find **Delete account**.
5. Select **Request to delete account**.
6. Review and complete the confirmations shown in the dialog.
7. Select **Delete account** to confirm.
You will lose access to the deleted Compute account when the deletion completes.
## What account deletion does not affect
Compute currently uses an account separate from Hivenet Store, Send, and other Hivenet services. Deleting your Compute account does not delete files or access associated with those services.
To delete your general Hivenet account as well, follow the instructions in the [Hivenet Help Center](https://help.hivenet.com/en/articles/164662-how-can-i-delete-my-hivenet-account).
## If you cannot delete the account
Check the most common blockers:
* **You still own an organization:** Transfer ownership or delete the organization.
* **You still have a non-terminated instance:** Terminate it and try again.
* **You still belong to an organization:** Leave it before returning to Settings.
* **You need help preserving access for other people:** Contact Support before changing ownership or deleting anything.
## Alternatives to account deletion
Depending on what you are trying to solve, you may be able to:
* Stop or terminate individual instances.
* Leave a shared organization.
* Transfer organization ownership.
* Turn off auto top-up.
* Ask the Owner to change your role or remove your access.
Contact Support through the Compute console if you are unsure which option preserves the resources you need.
# Track organization spending in real time
Source: https://docs.hivenet.com/documentation/account-billing/track-costs-real-time
Monitor your organization's credit balance, spend rate, and active resource costs in real time from the Compute console and Billing page.
Compute updates spending information as your organization starts and stops resources. Owners and Admins can use the console to see the organization’s current costs and review changes to its balance.
**Members** cannot see organization-wide billing. They can see the instances they created and the active price shown for those resources, but the organization Owner manages the balance and payment settings.
## Check the organization overview
Owners and Admins can use **Overview** for a quick picture of organization activity. Depending on the available data, the dashboard can show:
* Current balance
* Today’s spending
* Spending during the current month
* Current spend rate
* Active instances and models
* GPUs and vCPUs in use
* Total uptime
The dashboard changes as people in the organization create, start, stop, or terminate resources.
## Open Billing for the full account view
1. Select **Billing** from the left sidebar.
2. Check the **Balance** to see how many credits remain.
3. Check the **Current spend rate** to see the combined hourly rate of active resources.
4. Review **Transaction history** for credit purchases and transfers.
5. Review **Billing details** when you need payment or invoice information.
Only the Owner can add credits or change billing controls. Admins can use the same information for monitoring, but their access is read-only.
## Check which instances are contributing to spend
Open **Instances** and review the running-instance list.
Owners and Admins can see all instances in the organization. Members see the instances they created.
The instance table shows the configuration and active price for each resource. Use it to identify:
* Instances that are still running
* High-cost configurations
* Duplicate or forgotten workloads
* The person who created an organization instance, when that information is shown
If the current spend rate looks higher than expected, start with the **Running** tab. A workload left running by another person still draws from the shared organization balance.
## Understand the current spend rate
The current spend rate is the total effective hourly price of resources running at that moment, including applicable organization discounts on LLM model presets. A fully discounted endpoint contributes €0 per hour. It is a live estimate rather than the billing interval.
Compute charges eligible usage per second. For example, an instance priced at €0.75 per hour that runs for 30 minutes contributes approximately €0.375 before any other applicable usage.
The spend rate changes when:
* Someone starts an instance
* A new instance reaches **Running**
* A running instance leaves the **Running** state, including while stopping or terminating
* Hivenet Inference Service usage starts or stops
* The active configuration changes
## Understand the time-remaining estimate
The sidebar may show an estimated **Time remaining** based on the organization’s current balance and spend rate.
This estimate is not a fixed deadline. It can increase or decrease when:
* The Owner adds credits
* Auto top-up adds credits
* Resources start or stop
* Another person in the organization changes their workload
* Active inference usage changes
Use it as a warning signal rather than a guarantee of runtime.
## Reduce active spending
When you no longer need a running resource:
* **Compute instance:** Stop it if you expect to continue later, or terminate it when the work is finished and you no longer need its local data.
* **Inference Service deployment:** Stop it if you want to keep the deployment configuration for later, or terminate it when you no longer need the endpoint.
Terminating a Compute instance permanently deletes the instance and its local data. Terminating an Inference Service deployment permanently shuts down that deployment and makes its endpoint unusable.
For the full lifecycle explanations, see [How to stop or terminate a Compute instance](/documentation/essentials/stop-terminate-instance) and [Manage an Inference Service deployment](/documentation/inference-api/manage-deployments).
## Investigate an unexpected charge
If organization spending does not match what you expected:
1. Check every running instance, not only the ones you created.
2. Review the active price and configuration of each instance.
3. Check whether Hivenet Inference Service workloads are active.
4. Review transaction history for recent credit purchases or transfers. Internal ledger entries are not displayed.
5. Note the organization name, affected instance IDs, and approximate timeframe.
6. Contact Support through the console if the discrepancy remains.
Admins can investigate organization usage and billing details, but only the Owner can add credits, change payment methods, or configure auto top-up.
## See also
* [Billing information](/documentation/account-billing/billing-info)
* [How organizations work in Compute](/documentation/organizations/how-organizations-work)
* [How to start and stop your Compute instances](/documentation/essentials/start-stop-instances)
# How can I connect to a Compute instance from macOS?
Source: https://docs.hivenet.com/documentation/connectivity/connect-instance-macos
Connect to a Compute with Hivenet instance from macOS using the built-in Terminal and ssh command, including first-login steps and known_hosts prompts.
## What you’ll need
Make sure you have:
* A Compute instance in **Running**
* Its SSH connection details from the Compute console
* Your **private SSH key** (.pem or .ed25519 file you downloaded)
* A Mac with Terminal (you’ll find it in Spotlight)
## Step 1: Find your connection details
Open the instance in the Compute console and wait for **Running**. This means it has responded over SSH. Open its SSH connection details to find the current command, hostname, and username.
## Step 2: Open Terminal
Press **Cmd + Space**, type `Terminal`, and hit **Return** to open it.
## Step 3: Prepare your SSH key (recommended for security)
To keep things tidy and secure, move your downloaded key to your Mac’s SSH folder.
In Terminal, run these commands one by one:
```text theme={null}
mkdir -p ~/.ssh # Make the SSH folder if it doesn’t exist
chmod 700 ~/.ssh # Lock the folder so only you can open it
mv ~/Downloads/your-key.pem ~/.ssh/ # Move your downloaded key
chmod 600 ~/.ssh/your-key.pem # Lock the key file
```
Replace `/path/to/your-key.pem` with the actual path to the key you downloaded.
## Step 4: Connect to your instance
Open the instance's connectivity details in Compute and copy the SSH command shown there. Compute exposes a stable SSH endpoint for each instance on port 22, so use the current command from the console rather than reconstructing the address yourself.
A typical command looks like:
```text theme={null}
ssh -i /path/to/your-key.pem YOUR_SSH_USER@YOUR_SSH_HOST
```
1. Replace `/path/to/your-key.pem` with your key file location if needed.
2. Use the hostname and username shown for your instance in Compute.
3. The login can use a configured username. Do not assume the image’s default user.
## Step 5: Verify the server identity
Compute instances present signed SSH host certificates. Use the SSH configuration supplied by the console. If your client asks you to accept a host identity, verify it with trusted information from Hivenet first.
For certificate trust and changed-host warnings, see [SSH configuration and host verification](/tutorials/more-guides/SSH-config-file-explained).
## You're in
You’ll land in your instance’s terminal, ready to install packages, run apps, or start a Jupyter notebook.
If you already use 1Password, you can store and use SSH keys directly—no need to manage files or worry about permissions. [Here’s how SSH with 1Password works](https://developer.1password.com/docs/ssh/).
## Troubleshooting tips
* **Permission denied (publickey)?**
* Make sure the path to your `.pem` file is correct and that it’s set to `chmod 600`.
* **Connection times out?**
* Confirm the instance is Running, use its current connection details, and check whether your network allows outbound port 22. If it still fails, contact Support with the instance ID and error.
# How can I connect to a Compute instance from Windows?
Source: https://docs.hivenet.com/documentation/connectivity/connect-instance-windows
Connect to a Compute with Hivenet instance from Windows using PowerShell or the built-in OpenSSH client, from first login to a working shell prompt.
## What you’ll need
* A Compute instance in **Running**, which means it has responded over SSH
* Your SSH private key
* Windows Terminal or another SSH-capable terminal (like PowerShell)
* A configured `config` file (optional but helpful)
## Step 1 – Open the SSH connection details
Open your instance in Compute and go to **Connectivity options → SSH**. Compute exposes a stable SSH endpoint for the instance on port 22.
The console shows the current hostname, username, and connection command. The login can use a configured username instead of the image’s default user. Use those values rather than building the hostname yourself.
![Connect Instance Windows 1 Pn]()
## Step 2 – Connect
**Fastest option (recommended)**
1. In the dashboard go to **Instance → Connectivity options → SSH**.
2. Click **Copy to terminal to connect**.
3. Paste the command into your terminal and hit Enter.
* The command already includes your instance ID and user.
* If the command uses an SSH alias, add the console’s matching SSH config snippet first.
![Connect Instance Windows Gif Gi]()
**Build the command yourself**
If you prefer to type the command manually, use the hostname and username shown in the instance's SSH connection details:
```text theme={null}
ssh -i /path/to/private_key YOUR_SSH_USER@YOUR_SSH_HOST
```
SSH uses port 22 by default, so you do not need to specify the port unless the console tells you otherwise.
If you’ve created a Host entry named `hivenet` in `~/.ssh/config`:
```text theme={null}
ssh hivenet
```
## Step 3 – Verify the server identity
Compute instances present signed SSH host certificates. Use the SSH configuration supplied by the console, including any additional connection settings it requires. Only add a proxy or jump host when those instructions specify one.
If the client asks you to accept a host identity or reports that it has changed, verify it before continuing. See [SSH configuration and host verification](/tutorials/more-guides/SSH-config-file-explained).
## Step 4 – Confirm your connection
If everything works, you'll land in a Linux shell on your instance. You can now:
* Install packages
* Clone repos
* Run workloads
* Start your apps (like Fooocus, Jupyter, etc.)
## Troubleshooting
* **Terminal closes immediately** — Run your SSH command from an open terminal window instead of double-clicking a file.
* **Connection timed out** — Add `-v` to get detailed output and check for network issues.
* **Permission denied** — Check that your SSH key matches what you uploaded in the Compute dashboard.
* **Bad Gateway** — You may be trying to access a web app before it’s started. Use `curl localhost:` to confirm it's running.
# Agent network and firewall basics
Source: https://docs.hivenet.com/documentation/connectivity/firewall-basics
Learn what the Hivenet Agent does, which ports and hosts it needs, and how to configure your firewall to avoid Compute connection and login issues.
## **What the Hivenet Agent is**
The Hivenet Agent is a lightweight network tool that:
* Helps your instance discover and connect with others on the network
* Manages secure tunnels for HTTPS endpoints
* Enables peer-to-peer communication without needing a central gateway
If your instance’s public URL isn’t working—or if SSH fails unexpectedly—the Agent might be blocked or misconfigured.
## **Which ports the Agent needs**
To work correctly, the Agent uses:
* **Port 4001 (TCP/UDP)** – For peer discovery and swarm networking
* **Port 4443 (TCP)** – For secure tunneling and HTTPS exposure
These should be open on your machine or network if you're running the Agent directly or using advanced features.
## **When you need to open these ports**
Most users don’t need to manually open ports unless:
* You're behind a corporate firewall or router with strict rules
* You're contributing resources (via Contribute) or hosting long-running HTTPS endpoints
* You want to ensure the best-case network performance with external tools
Test your setup on a mobile hotspot to see if network restrictions are the cause.
## **How to check if the Agent is working**
| Where you are running | What to do |
| :- | :- |
| **Inside a Compute instance** | Open the logs:\`journalctl -u hivenet-agent --no-pager |
Root is disabled on all Compute containers. Commands that require sudo will fail.
## **Firewall troubleshooting tips**
* Allow outgoing connections on ports 4001 and 4443
* Temporarily disable firewall apps or try switching to a less restricted network
* Restart the instance and check if the error persists
# How to forward ports to reach your web app
Source: https://docs.hivenet.com/documentation/connectivity/forwards-ports
Forward ports over SSH to reach web UIs, Jupyter, or APIs running on your Compute instance from your local browser without exposing them publicly.
## When you need port forwarding
If your app says something like:
```text theme={null}
App started at http://127.0.0.1:7865
```
…it means the web interface is only accessible *inside* the Compute instance. You’ll need to forward the port to use it in your local browser.
This is common with:
* Fooocus
* Stable Diffusion UIs
* Jupyter Notebook
* Gradio / Streamlit apps
## Step 1 – Set up local port forwarding
In your Windows Terminal, run:
```text theme={null}
ssh -L 7865:localhost:7865 YOUR_SSH_USER@YOUR_SSH_HOST
```
Use the SSH username and hostname shown in the instance’s connection details. Keep any key or connection options from the console’s SSH command.
Replace:
* `7865` with the actual port your app uses
* `YOUR_SSH_USER` and `YOUR_SSH_HOST` with the console’s SSH username and hostname
Now open [http://localhost:7865](http://localhost:7865) in your browser.
**Tip:** Keep the terminal open! If the SSH session closes, the connection breaks.
## Step 2 – Get your port and IP details
If you’re not sure which port your app uses:
Run this from inside your instance:
```text theme={null}
whoami
hostname -I
```
Then test your app inside the VM:
```text theme={null}
curl http://localhost:7865
```
If that works, you can forward the port.
## Step 3 – Trying the public Hivenet URL
You can try visiting:
```text theme={null}
https://-8888..tenants.hivecompute.ai
```
Replace `` with the region shown for your instance.
This is a public-facing URL Hivenet creates automatically for instances.
However, it only works if:
* Your app listens on port 8888
* It's bound to `0.0.0.0` (not just `localhost`)
* It's currently running
If it doesn’t work or shows “Bad Gateway,” fall back to SSH port forwarding.
## Bonus: Forward multiple ports
You can add more `-L` flags to forward several ports at once:
```text theme={null}
ssh -L 7865:localhost:7865 -L 8888:localhost:8888 YOUR_SSH_USER@YOUR_SSH_HOST
```
Great for debugging or running multiple services.
# Serve an HTTPS site with SSH port forwarding
Source: https://docs.hivenet.com/documentation/connectivity/https-site-ssh-port-forwarding
Run python -m http.server or your own web app on a Compute instance and reach it locally over an encrypted SSH tunnel, without public exposure.
## What this solves
If your app prints something like:
```text theme={null}
Serving HTTP on 127.0.0.1 port 8888
```
and your public URL (e.g. `https://-8888.tenants.hivecompute.ai`) shows **Bad Gateway**, it likely means:
* The app is only available locally (localhost)
* HTTPS reverse proxy can’t reach it
### Step 1 – Start your server (pick **one**)
| If you already have an app | If you just want to browse files |
| :- | :- |
| SSH into the instance and launch your app on **port 8888** with **host 0.0.0.0**. Example (Flask): `app.run(host="0.0.0.0", port=8888)` | SSH in and run a one-off file server: `python3 -m http.server 8888 --bind 0.0.0.0` |
Only one process can occupy port 8888. Stop the file server before starting your real app—or give one of them a different port.
### Step 2 – Bind to 0.0.0.0, not 127.0.0.1
Visit `https://-8888.tenants.hivecompute.ai`.\
If you switched ports, replace `8888` in both the URL and your app command.
### Step 3 – Open the HTTPS URL
Once your app is running and listening on the correct interface and port, go to:
```text theme={null}
https://-8888..tenants.hivecompute.ai
```
Make sure your firewall or instance settings don’t block port 8888.
If you still see "Bad Gateway":
* Double-check your app is running
* Use `curl http://localhost:8888` from inside the instance to test
* Restart your app if needed
## Alternative: Use SSH port forwarding
If HTTPS still doesn’t work or you prefer to access it directly:
```text theme={null}
ssh -L 8888:localhost:8888 YOUR_SSH_USER@YOUR_SSH_HOST
```
Use the SSH username and hostname shown in the instance’s connection details. Keep any key or connection options from the console’s SSH command.
Then open [http://localhost:8888](http://localhost:8888) on your Windows or Mac browser
# How to generate and add an SSH key on Linux
Source: https://docs.hivenet.com/documentation/connectivity/ssh-key-linux
Generate an ed25519 SSH key on Linux with ssh-keygen and add the public key to Compute with Hivenet so you can connect to instances securely.
## What you’ll need
* A Hivenet account with Compute credits ready
* A Debian-, Ubuntu-, Fedora-, or Arch-based distro (others work too)
* **OpenSSH client** (`ssh`) installed
* A terminal emulator
## Step 1 – Create your SSH key pair
```text theme={null}
ssh-keygen -t ed25519
```
* Accept the default path (`/home//.ssh/id_ed25519`).
* Add a passphrase for extra security.
Password managers such as 1Password, Bitwarden, and KeePassXC can generate and store SSH keys automatically. If you already rely on one, it’s an easy alternative to the `ssh-keygen` command.
## Step 2 – Find your key files
Open the folder in your file manager:
```text theme={null}
xdg-open ~/.ssh
```
—or browse there manually (`Home → .ssh`). You should see:
* `id_ed25519` (private)
* `id_ed25519.pub` (public)
## Step 3 – Add your public key to Hivenet
1. Copy the public key to your clipboard:
```text theme={null}
cat ~/.ssh/id_ed25519.pub | xclip -selection clipboard
```
\_(If \_`xclip`*isn’t installed, just open the file in a text editor and copy.)*
2. In **Compute with Hivenet**, paste the key into **SSH key** when you spin up an instance.
Share only the `.pub` key. Keep the private key private.
## Step 4 – (Optional) add a quick SSH config
Create or edit **\~/.ssh/config**:
```text theme={null}
Host hivenet
HostName YOUR_SSH_HOST
User YOUR_SSH_USER
IdentityFile ~/.ssh/id_ed25519
Port 22
```
Replace `YOUR_SSH_HOST` and `YOUR_SSH_USER` with the values in the instance’s SSH connection details, and use your matching private key. Include any additional settings supplied by the console. See [SSH configuration and host verification](/tutorials/more-guides/SSH-config-file-explained).
Connect with:
```text theme={null}
ssh hivenet
```
## Troubleshooting
| Message | Likely cause & fix |
| :- | :- |
| **Permission denied (publickey)** | Wrong key or the public key isn’t on the instance. Re-check the key path or re-add the key. |
| **Connection timed out** | Check the console’s connection details and outbound port 22. Try `ssh -v hivenet` for details. |
| **ssh: command not found** | Install the OpenSSH client package (`install openssh-client`, `sudo dnf install openssh-clients`, etc.). |
# How to generate and add an SSH key on macOS
Source: https://docs.hivenet.com/documentation/connectivity/ssh-key-macos
Generate an ed25519 SSH key on macOS with ssh-keygen and add the public key to Compute with Hivenet so you can connect to instances securely.
## What you’ll need
* A Hivenet account with Compute credits ready
* macOS 11 (Big Sur) or newer
* **Terminal** (built in)
* **OpenSSH** (installed by default)
## Step 1 – Create your SSH key pair
1. Open **Terminal**.
2. Run:
```text theme={null}
ssh-keygen -t ed25519
```
3. Press **Enter** to accept the default location (`/Users//.ssh/id_ed25519`).
4. When prompted, enter a passphrase (optional but recommended).
Already use a password manager? Many, including 1Password and Bitwarden, can create and store SSH keys in one click. If that’s your jam, generate the key there and copy the public part straight from the manager.
The command (or your manager) creates two files:
| File | What it is |
| :- | :- |
| `id_ed25519` | Your private key — keep it secret |
| `id_ed25519.pub` | Your public key — you’ll upload this to Hivenet |
## Step 2 – Find your key files
Open the `.ssh` folder in Finder:
```text theme={null}
open ~/.ssh
```
You’ll see the two files listed above.
## Step 3 – Add your public key to Hivenet
1. Double-click **id\_ed25519.pub** to open it in TextEdit.
2. Copy the entire line (it starts with `ssh-ed25519`).
3. In **Compute with Hivenet**, paste that line into the **SSH key** field when you create an instance.
Paste only the `.pub` file contents. Never share the private key.
The SSH key field accepts **one public key only**.
If you want to authorize more keys later (for teammates or alternate devices), connect to the instance and add them manually in `~/.ssh/authorized_keys`.
## Step 4 – (Optional) add a quick SSH config
In **\~/.ssh**, create or edit a file named **config** (no extension) and paste:
```text theme={null}
Host hivenet
HostName YOUR_SSH_HOST
User YOUR_SSH_USER
IdentityFile ~/.ssh/id_ed25519
Port 22
```
Replace `YOUR_SSH_HOST` and `YOUR_SSH_USER` with the values in the instance’s SSH connection details, and use your matching private key. Include any additional settings supplied by the console. See [SSH configuration and host verification](/tutorials/more-guides/SSH-config-file-explained).
Now you can connect with:
```text theme={null}
ssh hivenet
```
—much quicker than pasting the full string each time.
## Troubleshooting
| Message | Likely cause & fix |
| :- | :- |
| **Permission denied (publickey)** | The public key isn’t on the instance, or you’re using the wrong private key. Re-add the key or point SSH at the right file. |
| **Host key verification failed** | Verify the server identity with Hivenet before changing `known_hosts`. See the host-verification guide above. |
| **ssh: command not found** | OpenSSH is missing (rare on macOS). Install **Xcode Command Line Tools** with `xcode-select --install`. |
# How can I generate and add an SSH key on Windows?
Source: https://docs.hivenet.com/documentation/connectivity/ssh-key-windows
Generate an SSH key on Windows using PowerShell or PuTTYgen and add the public key to Compute with Hivenet to connect to instances securely.
## What you’ll need
* A Hivenet account with Compute credits
* Windows 10 or later
* Windows Terminal (or PowerShell)
* OpenSSH installed (enabled by default on Windows 10+)
## Step 1 – Create your SSH key pair
Open Windows Terminal and run this command:
```
ssh-keygen
```
* Press Enter to accept the default location (`C:\Users\\.ssh\id_ed25519`)
* When prompted, you can set a passphrase (optional but recommended)
This creates two files:
* `id_ed25519` (your **private key**) — never share this
* `id_ed25519.pub` (your **public key**) — you’ll upload this to Hivenet
**Tip:** If you see a message that the file already exists, you can overwrite it or cancel and use a new name (e.g., `id_hivenet`, `id_rsa`).
Already use a password manager? Many, including 1Password and Bitwarden, can generate and store SSH keys for you in one click. If that’s your workflow, feel free to skip the `ssh-keygen` command and copy the public key straight from your manager.
## Step 2 – Find your key files
Your key files are located in:
```
C:\Users\\.ssh\
```
You can open this folder in File Explorer or use PowerShell:
```text theme={null}
explorer "$env:USERPROFILE\.ssh"
```
## Step 3 – Add your public key to Hivenet
1. Open the `.pub` file in a text editor (right-click > Open with Notepad)
2. Copy the entire contents of the file
3. Paste it into the **SSH Key** field when creating your instance on the Compute dashboard
Only paste the `.pub` file contents. Do **not** paste the private key.
The SSH key field accepts **one public key only**.
If you want to authorize more keys later (for teammates or alternate devices), connect to the instance and add them manually in `~/.ssh/authorized_keys`.
## Step 4 – Create a basic SSH config file (optional but useful)
In the same `.ssh` folder, create a new file named `config` (no file extension). Paste this in (make sure your SSH key name is similar to the name given):
```text theme={null}
Host hivenet
HostName YOUR_SSH_HOST
User YOUR_SSH_USER
IdentityFile ~/.ssh/id_ed25519
Port 22
```
Replace `YOUR_SSH_HOST` and `YOUR_SSH_USER` with the values in the instance’s SSH connection details, and use your matching private key. Include any additional settings supplied by the console. See [SSH configuration and host verification](/tutorials/more-guides/SSH-config-file-explained).
This lets you connect with:
```
ssh hivenet
```
instead of typing the full connection string every time.
## Troubleshooting
* **"Permission denied (publickey)"** — Your public key may not be added correctly or you're using the wrong private key.
* **"Connection timed out"** — Check your config file or try adding `-v` for more detailed output.
* **Terminal closes too fast?** Open a terminal first, then paste the command manually instead of double-clicking a script.
# SSH into a Compute instance from Windows
Source: https://docs.hivenet.com/documentation/connectivity/ssh-puttygen-openssh
Convert a PuTTYgen private key to OpenSSH format and connect to your Compute instance from Windows using the built-in ssh command.
## What you’ll need
* A Compute instance with your SSH public key uploaded
* **Windows 10 or later**
* Windows Terminal / PowerShell (OpenSSH)
## OpenSSH via Windows Terminal
### Step 1 – Check OpenSSH is installed
Open PowerShell and run:
```
ssh -V
```
You should see an OpenSSH version. If not, enable it:
1. Settings → Apps → Optional features
2. Add a feature → OpenSSH Client
### Step 2 – Create or convert your key
If you already have an OpenSSH private key, use it directly with Windows OpenSSH.
If your key is in PuTTY's `.ppk` format:
1. Open PuTTYgen and load the private key.
2. Select **Conversions → Export OpenSSH key**.
3. Save the exported private key and use its path with `ssh -i` or `IdentityFile` below.
For a new key pair, follow [Add an SSH key on Windows](/documentation/connectivity/ssh-key-windows). Add only the public key to Compute.
### Step 3 – Create a config entry (optional)
In `C:\Users\\.ssh\config`, add:
```text theme={null}
Host hivenet
HostName YOUR_SSH_HOST
User YOUR_SSH_USER
IdentityFile ~/.ssh/id_ed25519
Port 22
```
Replace `YOUR_SSH_HOST` and `YOUR_SSH_USER` with the values in the instance’s SSH connection details, and use your matching private key. Include any additional settings supplied by the console. See [SSH configuration and host verification](/tutorials/more-guides/SSH-config-file-explained).
Save, then simply:
```
ssh hivenet
```
### Step 4 – Connect manually
Without a config file, run:
```text theme={null}
ssh -i ~/.ssh/id_ed25519 YOUR_SSH_USER@YOUR_SSH_HOST
```
Use the username and hostname from the console and the private key matching your uploaded public key.
## Troubleshooting OpenSSH
* **Permission denied** → Wrong key or not uploaded
* **Connection timed out** → Check internet/firewall
* **Unknown host** → Typo in instance ID
## Common PuTTY pitfalls
* **Server unexpectedly closed connection** → Wrong port or host name
* **No supported authentication methods available** → Wrong key format
* **Support modern encryption and OpenSSH compatible formats**
# Choosing between a virtual machine and a container
Source: https://docs.hivenet.com/documentation/essentials/choosing-between-a-virtual-machine-and-a-container
Compare Compute virtual machines and containers, and pick the instance type that matches how much OS control, isolation, and packaging your workload needs.
***
When you create a Compute instance, you choose how it runs: as a **container** or as a **virtual machine** (VM). Both options can run real workloads. The difference is how much control you get over the operating system and how you manage software.
If you’re unsure, start with a container. It’s usually the quickest path to getting work done, and you can switch by creating a new instance later if you run into OS limits.
## Quick rule of thumb
Choose a **container** if you want a fast, managed runtime for scripts, apps, and models.
Choose a **virtual machine** if you need full OS control, sudo access, kernel-level settings, or a specific Linux distribution.
## Containers in Compute
Containers are designed for most common workloads. They’re a good fit when you want to run code and ship a working environment without managing the operating system.
A container-based instance is usually the right choice when you’re:
* Running scripts, apps, or APIs
* Doing standard ML workflows with typical dependencies
* Serving models and inference workloads with a supported template
* Prioritizing a simple setup and quick startup
A few things to know up front:
* Containers don’t support root access. Commands that require `sudo` won’t work.
* System-level changes are handled through templates rather than modifying the OS directly.
If your workflow depends on installing OS packages manually, running system services, or changing low-level settings, you’ll likely want a VM instead.
## Virtual machines in Compute
Virtual machines are for workloads that need a traditional server experience. You get full control of the operating system, including the ability to install and configure software at the OS level.
A VM is usually the right choice when you’re:
* Installing system packages with your OS package manager and managing services
* Running software that expects full OS behavior
* Working with tools that require deeper system access
* Needing a specific Linux distribution or custom OS image
* Depending on kernel-level configuration or system drivers
With a VM, you can expect to work more like you would on a typical Linux server. That flexibility can be worth it, but it also means you’re taking on more responsibility for OS setup and maintenance.
## Common scenarios
If you’re running a Python script, a small service, or a straightforward app, start with a **container**.
If you’re serving an LLM using a standard inference setup, a **container** is often enough. Choose a **VM** if your setup requires OS-level customization, system services, or a specific distro.
If you need to install system packages, configure services, or rely on `sudo`, choose a **VM**.
If you’re not sure and you just want the simplest path to “it works,” choose a **container**.
## What changes between containers and VMs
Here’s what users notice most in practice:
* OS control: containers have limited OS control, VMs give full OS access
* Installing software: containers rely on templates and app-level dependencies, VMs use standard OS package tools and configuration
* Setup speed: containers tend to be faster to get running, VMs are more flexible but require more setup
* Compatibility: containers cover most workflows, VMs are better when your workload depends on OS-specific behavior or a specific distribution
If you hit a wall with OS-level requirements, that’s a strong signal you should move the workload to a VM.
## Switching if you picked the wrong one
You can switch approaches by creating a new instance of the other type and redeploying your workload.
Before you switch, it helps to write down:
* The template or base image you used
* Your application dependencies and install steps
* Any environment variables or secrets your workload needs
* The commands you use to run your workload
If you’re moving from a container to a VM, plan for OS-level setup that you may not have needed before (packages, services, users, and startup scripts).
## Next steps
* [Launch and connect to your first instance](/documentation/essentials/create-instance)
* [Templates and images](/documentation/essentials/custom-templates)
* [Start and stop instances](/documentation/essentials/start-stop-instances)
* [Troubleshoot instance errors](/documentation/troubleshooting/bad-gateway-errors)
# Launch and connect to your first Compute instance
Source: https://docs.hivenet.com/documentation/essentials/create-instance
Pick an organization, configure a Compute container or virtual machine, choose SSH or web access, review cost, and connect once it reaches Running.
This guide explains each part of creating a Compute instance. It covers the organization context, resource and software choices, connection settings, price review, and the first connection after launch.
## What you’ll need
* A Compute account with access to an organization
* Enough credits in the organization balance
* An SSH public key if you want terminal access
* A general idea of the hardware, software, and network access your workload needs
## Before you create the instance
Check the organization shown in the upper-left corner of the console. The instance will use that organization’s balance and access rules.
* **Owners** can add credits and manage organization billing.
* **Admins** can create instances and view all organization instances, but cannot add credits.
* **Members** can create instances using the shared balance and see the instances they created.
If the organization does not have enough credits, ask its Owner to add more. Admins and Members cannot add credits themselves.
## Choose between a container and virtual machine
Select **Create** from the left sidebar, then choose the resource type you want to launch.
### Container
Choose a container when you want a prepared application environment and do not need control of the full operating system. Templates can provide an operating system, drivers, libraries, and development tools.
### Virtual machine
Choose a virtual machine when your workload needs a full operating system or broader system-level control.
See [Choosing between a virtual machine and a container](/documentation/essentials/choosing-between-a-virtual-machine-and-a-container) for help deciding.
## Configure the instance
Select an available location for the instance. Presets with no available location are hidden.
Consider where your users, services, and data are located. A nearby location can reduce network latency. Configurations marked as sold out cannot be selected until capacity becomes available.
Select **GPU** or **vCPU only**, then choose the available resource profile and size.
The console shows the main specifications for each option, including:
* GPU count and model, when applicable
* vCPU allocation
* GPU memory and system memory
* Disk space
* Network bandwidth
* Active price
The console offers sizes that a host can accommodate and updates availability as instances are created. Capacity can still change before your launch completes.
Use the smallest configuration that meets the workload’s memory and performance needs. You can create another instance later if you need a different setup.
For a container, choose one of the available templates or select the option to create a new custom template.
For a virtual machine, choose the operating-system image you want to install.
Review the image details before continuing. A template may already include drivers, libraries, notebook software, or workload-specific tools.
Choose how you’ll access the instance.
**SSH**
Compute uses a public SSH key to authorize terminal access. The key saved to your account may appear automatically. Select **Edit** if you need to replace it before creating the instance.
**HTTPS**
Enable HTTPS when the workload needs a secure browser-accessible or API endpoint.
**TCP and UDP**
Enable the protocol required by your service. Leave these options off when the workload does not need inbound access over them.
**Jupyter Notebook**
Enable Jupyter Notebook when the option is available and you want notebook access in a browser. The access link appears in the instance’s connectivity details after launch.
Some connection settings are permanent after creation. Confirm the protocols and access methods you need before continuing.
Enter a name that follows the rules shown in the console. Instance names generally use letters, numbers, and dashes without spaces or special characters.
A descriptive name makes the instance easier to identify later, especially when several people are creating resources in the same organization.
The review section summarizes:
* Location
* Resource type and size
* Template or operating system
* Memory, disk, and bandwidth
* Connection options
* Estimated hourly, daily, and weekly cost
Review the active price and make sure the selected organization has enough credits.
The hourly, daily, and weekly values help you estimate spending. Eligible Compute usage is charged per second after the instance reaches **Running**.
Select the button to create the container or virtual machine.
The instance appears on the **Instances** page while Compute prepares it. Wait until its status changes to **Running** before trying to connect. This means the instance has responded over SSH; an application or notebook inside it may still be starting.
Preparation usually takes a few minutes. Charging begins when the instance is running, rather than while the creation form is open.
## Connect over SSH
After the instance reaches **Running**:
1. Open **Instances**.
2. Select the running instance.
3. Open its connectivity details.
4. Copy the SSH command shown by the console.
5. Run the command in your terminal.
A typical command looks like this:
```bash theme={null}
ssh -i /path/to/private_key username@host
```
Use the username and address shown in the instance’s connection details. The login can use a configured username, so do not assume it is the image’s default user. Use the private key that matches the public key supplied during creation.
After a successful connection, you can add the host and identity file to `~/.ssh/config` to make later connections shorter.
For platform-specific instructions, see:
* [Connect from macOS](/documentation/connectivity/connect-instance-macos)
* [Connect from Windows](/documentation/connectivity/connect-instance-windows)
* [Add an SSH key on Linux](/documentation/connectivity/ssh-key-linux)
## Connect through Jupyter or a public endpoint
When you enabled Jupyter Notebook, HTTPS, TCP, or UDP during creation, open the instance’s connectivity details to find the available address or access link.
If a service is not reachable:
* Confirm that the required connection option was enabled.
* Check that the application is listening on the expected interface and port.
* Review any firewall rules inside the container or virtual machine.
* Make sure the instance is still running.
## Understand who can see the instance
The person who creates an instance can see it in their instance list.
* Owners and Admins can see all instances created within the organization.
* Members see the instances they created.
* Usage is charged to the organization balance, regardless of who created the instance.
See [How organizations work in Compute](/documentation/organizations/how-organizations-work) for the full role comparison.
## Stop or terminate the instance
When you finish working:
* **Stop** the instance to pause compute charges and preserve it temporarily for a later start.
* **Terminate** the instance when you no longer need it or its local data.
Termination permanently deletes the instance and its local data. Download important files before you terminate it.
See [How to stop or terminate a Compute instance](/documentation/essentials/stop-terminate-instance) for the lifecycle details.
## If creation is blocked by the balance
The review section tells you when the organization needs more credits.
* If you are the **Owner**, open **Billing** and add credits.
* If you are an **Admin** or **Member**, ask the organization Owner to add credits.
After the balance updates, return to the creation form and review the configuration again before launching.
## See also
* [Compute quickstart](/quickstart)
* [Billing information](/documentation/account-billing/billing-info)
* [Understand and choose your Compute instance](/documentation/essentials/understand-choose-instance)
* [How to use custom templates](/documentation/essentials/custom-templates)
# How to use custom templates
Source: https://docs.hivenet.com/documentation/essentials/custom-templates
Create, save, and reuse custom Compute with Hivenet templates so you can launch instances with your own container image, ports, and environment settings.
Custom templates let you save and reuse container configurations for your compute jobs. Instead of manually setting up the same environment each time, you can create a template once and launch new instances from it whenever you need.
## Why use custom templates
* **Save time**: No need to retype registry paths, variables, or commands every time.
* **Stay consistent**: Make sure all your instances use the same base image and environment.
* **Reuse securely**: Keep sensitive values as secrets so they’re injected only at runtime.
## Creating a new template
You can create a custom template directly in the Compute console when launching a new **container** instance. Select **New template** under the *Pick a template* step.
### General settings
* **Name** – Choose a clear, descriptive name for your template.
* **Instance type** – Select whether this template is for a **GPU** or **CPU** instance.
* **Visibility** – Templates are **Private** by default (only you can see and use them). Public templates will be available in the future.
![Custom Templates 1 Pn]()
### Container configuration
* **Registry** – Provide the full path to your container image (for example, `docker.io/library/nginx:latest`).
* **Registry credentials** – Enable this option if you’re using a private registry that requires authentication.
### Environment variables
Define environment variables as `KEY=value` pairs. You can add:
* **Variables** – Standard environment values.
* **Secrets** – Sensitive keys (e.g., API tokens). Secrets are injected securely at runtime.
### Instructions for base images
When building your template, you can use the provided Hivenet base image and setup script:
```dockerfile theme={null}
FROM 993cz8u0.c1.gra9.container-registry.ovh.net/hive-compute-public/base-ubuntu:latest
CMD ["/usr/local/bin/setup_instance.sh"]
```
# Compute account settings and preferences
Source: https://docs.hivenet.com/documentation/essentials/general-settings
Manage personal Compute preferences, SSH keys, appearance and language options, organization access, and account deletion from the account menu.
The account menu at the bottom of the Compute sidebar gives you access to personal settings, organization management, appearance, language, and sign-out controls.
## Open the account menu
Select the menu next to your account at the bottom of the left sidebar. Depending on your account and role, it contains:
* **Settings**
* **Organization**
* **Theme**
* **Language**
* **Sign out**
Personal settings apply to your own Compute account. Organization actions and billing permissions depend on whether you are an Owner, Admin, or Member.
## Organization
Select **Organization** to open the organization page. You can also select the organization name in the upper-left corner, then choose **Organization options**.
The organization page shows its Owner, Admins, Members, and pending invitations. The actions available to you depend on your role.
* **Owners** can manage people, billing, ownership, and organization deletion.
* **Admins** can manage people and organization settings and view billing details.
* **Members** can view the people in the organization and use its resources, but cannot manage the organization.
See [How organizations work in Compute](/documentation/organizations/how-organizations-work) for the full role comparison.
## Theme
Choose how the Compute console looks:
* **System:** Matches the theme used by your operating system or browser.
* **Light:** Uses a light background and dark text.
* **Dark:** Uses a dark background and light text.
This changes only the appearance of the Compute console for your account.
## Language
Use **Language** to change the language of the Compute interface.
The available languages currently include:
* English
* French
Changing the interface language does not affect your organization, resources, or technical configuration.
## SSH key
Your SSH public key is used to authorize access to new instances you create.
To replace it:
1. Open **Settings**.
2. Find the SSH key field.
3. Paste the new public key.
4. Select **Modify** to save it.
The new key applies to instances you create afterward.
Replacing the SSH key in Settings does not update instances that already exist. Add or remove keys manually on those instances when needed.
For operating-system-specific instructions, see:
* [Add an SSH key on Linux](/documentation/connectivity/ssh-key-linux)
* [Add an SSH key on macOS](/documentation/connectivity/ssh-key-macos)
* [Add an SSH key on Windows](/documentation/connectivity/ssh-key-windows)
## Delete account
Select **Request to delete account** only when you are ready to permanently remove your personal Compute account.
Before deletion, you must resolve anything that still ties the account to active Compute resources:
* Terminate running instances.
* Leave your current organization.
* Transfer ownership or delete the organization if you are its Owner.
Account deletion is irreversible. Download important data before terminating instances or deleting an organization.
Follow [Delete your Compute account](/documentation/account-billing/delete-account) for the complete preparation and deletion process.
# Using vCPUs
Source: https://docs.hivenet.com/documentation/essentials/how-to-vcpu
Learn how vCPUs work on Compute with Hivenet, when to pick a CPU-only instance over a GPU, and which vCPU, RAM, and disk sizes are available.
vCPUs (virtual CPUs) let you run general-purpose workloads without a GPU. They’re ideal for everyday computing tasks, development, or background services where GPU acceleration isn’t required.
## What is a vCPU?
A vCPU is a portion of a physical CPU made available to your instance. In Compute with Hivenet, vCPUs come in preconfigured sizes that include matching RAM, disk, and bandwidth so you can get started quickly.
## Available vCPU setups
From the console, you can choose between GPU-powered instances or CPU-only instances. The CPU-only option gives you these configurations:
| vCPU | RAM | Disk space | Bandwidth | Price (/h) |
| - | - | - | - | - |
| 2 | 4 GB | 50 GB | 250 Mb/s | €0.035 |
| 4 | 8 GB | 100 GB | 250 Mb/s | €0.07 |
| 8 | 16 GB | 200 GB | 500 Mb/s | €0.14 |
| 16 | 32 GB | 400 GB | 1000 Mb/s | €0.28 |
| 32 | 64 GB | 800 GB | 1000 Mb/s | €0.56 |
## When to use vCPUs
vCPUs are a good fit when your workload doesn’t need GPU acceleration. Common use cases include:
* Running lightweight web servers or APIs
* Hosting databases for development or testing
* Running CI/CD pipelines and automated builds
* Data processing scripts that don’t rely on GPU parallelism
* Background services or always-on workloads
If your workload depends heavily on parallelism (like machine learning training, video rendering, or simulations), a GPU instance is usually the better choice.
## Things to keep in mind
* **Scaling**: Start with 2 vCPUs and scale up as your project grows.
* **Billing**: Instances are billed per second via credits, with the hourly rate shown in the console.
* **Flexibility**: You can stop and start vCPU instances without losing data on attached disks.
## See also
* [Choosing between GPU and vCPU instances](/tutorials/more-guides/choosing-between-cpu-gpu)
* [Using GPUs in Compute with Hivenet](/documentation/essentials/create-instance)
# How to start and stop your Compute instances
Source: https://docs.hivenet.com/documentation/essentials/start-stop-instances
Start and stop Compute with Hivenet instances from the dashboard to pause usage without losing progress and only pay while an instance is running.
With the Start/Stop feature in Compute, you can control when your instances are active. If you need to take a break, save on costs, or just pause a project, you can stop an instance to temporarily pause it and stop compute charges.
When you start it again, the instance resumes from its previous state, as long as it hasn’t been automatically terminated.
## View your instances
* Go to your **Compute** dashboard.
* Select the **Instances** tab.
* Here you'll see all of your instances—running or stopped—with details like uptime, resource usage, and hourly cost.
To create a new instance, click **Create** on the sidebar or in the top-right corner.
![Chooseinstanceselector]()
## Stop an instance
To stop billing and pause usage:
* Click the `⋮` next to the instance you want to stop.
* Select **Stop** from the dropdown.
Billing stops as soon as the instance leaves **Running**. The status then updates to **Stopped**, while the instance configuration and data are kept temporarily.
Stopping an instance releases the underlying capacity. When you start again, availability depends on current demand, and you may not get the same host or GPU.
![Start Stop Instances 2 Pn]()
**Important: stopped instances are temporary**
When an instance is stopped, it isn’t kept indefinitely.
If an instance remains stopped for more than 10 days, it is automatically terminated.
Once terminated, the instance and its data can’t be recovered. To keep an instance, make sure to start it again within that time window.
If an instance was stopped for more than 10 days, it may have already been terminated and won’t be available to start.
## Start a stopped instance
To resume activity:
* Find your stopped instance in the **Instances** tab.
* Click the `⋮` next to it.
* Select **Start**.
![Start Stop Instances 3 Pn]()
Review the configuration details, then click **Start instance** to confirm.
![Start Stop Instances 4 Pn]()
The instance returns to **Running** after it responds over SSH, and billing resumes. Disk preparation finishes before startup proceeds. An application inside the instance may still need time to become ready.
![Start Stop Instances 5 Pn]()
## If resources aren't available
If the network can’t allocate the same configuration immediately, you’ll see a message asking you to try again later. This usually means there’s no matching capacity in that region right now. Your data and settings are kept within the stopped-instance retention window described above. Back up important files; waiting for capacity does not extend that window.
## If an instance fails to start
Compute retries failed starts a limited number of times instead of retrying indefinitely. If the instance still cannot start, it moves to a clear error state and you can retry the action manually from the instance controls.
Start and stop operations also retry after internal conflicts. Let the current action settle before trying again.
If repeated retries fail, note the instance ID, error, and approximate failure time before contacting Support. For virtual machines, Support can also review serial-console logs to investigate boot and crash problems.
## Data protection during cleanup
Persistent volumes are protected if an instance cleanup fault occurs. This safeguard does not replace backups or change the termination and stopped-instance retention guidance above.
## Manage instances through the API
To check an existing instance's status or start and stop it programmatically, see [Work with instances through the Compute API](/public-api/work-with-instances). The Compute API cannot create new instances.
# How to stop or terminate a Compute instance on Hivenet
Source: https://docs.hivenet.com/documentation/essentials/stop-terminate-instance
Compare Stop and Terminate for Compute with Hivenet instances, understand what each action keeps or deletes, and pick the safest option for your workload.
On your **Instances** page, the three-dot menu (`⋮`) next to each instance offers two choices: **Stop** or **Terminate**. Seeing them side-by-side can be confusing, especially when one of those buttons can wipe an instance for good.
They might seem similar, but the results couldn’t be more different. One pauses your instance and keeps it around. The other deletes it entirely, no undo.
This short guide breaks down what each option does, when to use it, and how to run the action step-by-step.
## Where to find these actions
1. Go to **Compute → Instances**
2. Find the instance you want to manage
3. Click the **three-dot menu** (`⋮`) on the right
4. Choose **Stop** or **Terminate**
5. Confirm your choice in the pop-up dialog
You’ll need to tick some boxes before confirming Terminate, just to be sure you know what you're doing.
## Stop vs. Terminate
| Action | What it does | Can you restart it later? | Keeps config? | Charges stop? | Auto-expires? |
| :- | :- | :- | :- | :- | :- |
| **Stop** | Pauses the instance | Yes, within 10 days | Yes | As soon as it leaves **Running** | Yes, after **10 days** |
| **Terminate** | Deletes the instance permanently | No | No | As soon as it leaves **Running** | Yes, immediately |
## ⚠️ Stopped instances are not forever
Stopping an instance pauses it, but only temporarily. If you don’t restart it within **10 days**, it will be **automatically terminated**, and that means:
* The instance is deleted
* All data is lost
* There’s no recovery option
This includes anything stored on the system disk. If it’s stopped and you forget about it, it will be gone.
## When to use **Stop**
Use Stop when you:
* Need to temporarily pause an instance
* Want to save on Compute charges for a bit
* Plan to restart it soon
Once stopped, the instance will show as **Stopped** in your list. To avoid losing it, make sure you start it again within 10 days.
## When to use **Terminate**
Terminate is for when you're done with the instance for good. Choose it when:
* You’ve completed a job and want to clean up
* You no longer need the instance or its data
* You want to completely stop all charges
Before the instance is deleted, you’ll be asked to confirm that:
* All tasks will stop
* All data will be wiped
* This cannot be undone
Once terminated, the instance disappears from your dashboard and cannot be recovered.
## Manage instances through the API
To check the status of an existing instance or stop or terminate it programmatically, see [Work with instances through the Compute API](/public-api/work-with-instances). The API does not create new instances.
# Understand and choose your Compute instance
Source: https://docs.hivenet.com/documentation/essentials/understand-choose-instance
A practical guide to choosing, launching, and connecting to the right Compute with Hivenet instance based on your GPU, CPU, RAM, and storage needs.
## What makes up a Compute instance?
A Compute instance is a unit of compute resources you run on Hivenet. Depending on your use case, an instance can run as a **container** or as a **virtual machine**.
When you create an instance, you choose a combination of hardware, runtime type, and configuration that determines how it behaves and what level of control you have.
### Container-based instances
Containers are designed for most common workloads, such as running scripts, applications, and models.
* Root access is disabled. Commands that require sudo won’t work.
* System-level packages are managed through templates rather than manual installation.
### Virtual machine instances
Virtual machines are intended for workloads that need full operating system control.
* Full OS-level access, including sudo and kernel-level configuration.
* Support for standard Linux distributions such as Ubuntu, Fedora, and Debian.
## What you choose when creating an instance
Regardless of the instance type, you’ll configure the following:
* **GPU(s)**
Choose from the GPU presets currently available in your selected location. Compute currently uses NVIDIA RTX 5090 GPUs, with 32 GB of VRAM per GPU and multi-GPU configurations available when capacity allows.
* **vCPUs and RAM**
Review the CPU and system-memory resources attached to each preset. These support the runtime, data loading, preprocessing, and CPU-side parts of your workload.
* **Storage**
Instances include fast local SSD storage. Storage behavior depends on the instance type and lifecycle. See the instance lifecycle documentation for details.
* **Region**
Select where your instance runs. Region choice affects latency, capacity, and data residency.
* **Billing type**
Instances use on-demand billing. Eligible usage is charged per second while the instance is running.
Instance sizes are filtered against host capacity, and presets with no available location are hidden. Availability updates as instances are created and can change before a launch completes. Use the creation screen as the source of truth for the hardware, memory, disk, bandwidth, and price you can launch now.
## How to choose the right instance
The right choice depends on what you’re building.
* Running scripts, apps, or model inference?
A container-based instance is usually the simplest option when a prepared image already includes what you need.
* Running a GPU workload?
Start with the model or application’s VRAM requirement. One RTX 5090 provides 32 GB of VRAM. Add GPUs only when the software supports multi-GPU execution or when you want to run work in parallel.
* Need full OS control, custom system packages, or kernel access?
Use a virtual machine instance.
* Unsure whether you need GPU or CPU resources?
See [Choosing between GPU and vCPU instances](/tutorials/more-guides/choosing-between-cpu-gpu).
Multiple GPUs do not automatically behave like one GPU with combined VRAM. Frameworks and models need explicit support for approaches such as tensor parallelism or distributed training.
## Managing your instance from the dashboard
Once your instance is running, you can manage it from the Compute dashboard:
* Start or stop the instance
* Monitor usage, uptime, and cost
* Terminate the instance when you’re finished
Instances are billed per second. When an instance is stopped or terminated, compute charges stop according to the instance lifecycle rules.
## How to connect to your instance
When your instance is ready, its connectivity details show the access methods you enabled during creation, such as SSH, HTTPS, TCP, UDP, or Jupyter Notebook.
For SSH, use the command provided by the console with the private key that matches the public key saved to your account.
See [Launch and connect to your first Compute instance](/documentation/essentials/create-instance) for the complete creation and connection flow.
## See also
* [GPU types and sizes](/documentation/reference/gpu-types)
* [Choosing between a virtual machine and a container](/documentation/essentials/choosing-between-a-virtual-machine-and-a-container)
* [Billing information](/documentation/account-billing/billing-info)
# Transfer files to and from your Compute instance with SFTP
Source: https://docs.hivenet.com/documentation/file-transfer/transfer-files-sftp
Move files to and from a Compute with Hivenet instance over SFTP using the sftp CLI, WinSCP, or FileZilla, with example commands and connection settings.
Use SFTP to transfer files over the instance's SSH connection.
## What you’ll need
* An instance in **Running**.
* The SSH hostname and username from its connection details in Compute.
* The private key matching the public key supplied for the instance.
* An SFTP client, such as the command-line `sftp` tool, WinSCP, or FileZilla.
The SSH endpoint uses port 22. Use the console's username, which may differ from the image's default user. Follow any additional SSH configuration supplied there.
## Transfer files from a terminal
Replace the placeholders below with the console values and your private-key path:
```text theme={null}
sftp -i /path/to/private_key YOUR_SSH_USER@YOUR_SSH_HOST
```
If you already created an SSH config entry named `hivenet`, you can use `sftp hivenet` instead.
At the `sftp>` prompt:
| Command | What it does |
| :- | :- |
| `put bigfile.zip` | Upload a local file. |
| `get results.csv` | Download a file from the instance. |
| `lcd "C:\Users\You\Downloads"` | Change the local folder on Windows. |
| `lcd ~/Downloads` | Change the local folder on macOS or Linux. |
| `lpwd` | Show the local folder. |
| `ls` / `pwd` | List files or show the current folder on the instance. |
| `exit` | Close the session. |
## Connect with WinSCP or FileZilla
Create a new SFTP connection using:
| Setting | Value |
| :- | :- |
| Protocol | SFTP |
| Host | The SSH hostname shown by Compute |
| Port | 22 |
| Username | The SSH username shown by Compute |
| Authentication | Your matching private key |
Use a private-key format supported by your client. If it requests conversion, use its supported key-import process or PuTTYgen. Never upload the private key to Compute.
Only configure a proxy or jump host if the console's connection instructions require one. Verify any host-identity prompt before accepting it; see [SSH configuration and host verification](/tutorials/more-guides/SSH-config-file-explained).
After connecting, use the local and remote file panels to upload or download files.
## Transfer a folder with rsync
If `rsync` is installed on both computers, use it to copy a folder and retain partial transfers for a later retry:
```bash theme={null}
rsync -avz --partial -e "ssh -i /path/to/private_key" ./localfolder/ YOUR_SSH_USER@YOUR_SSH_HOST:/path/to/remote-folder/
```
Use a destination folder your SSH user can write to. Rerun the command after an interruption.
## Troubleshooting
* **Permission denied:** Check the username, private-key path, and matching public key on the instance.
* **Connection timed out or closed:** Confirm the instance is Running, use the current console connection details, and check outbound port 22 on your network.
* **Host verification failed:** Verify the host identity before changing saved trust settings.
* **The client rejects the key file:** Check which key formats it supports and convert locally if needed.
If the problem continues, contact Support with the instance ID and error message. Keep your private key private.
# Create and manage API keys for Inference Service
Source: https://docs.hivenet.com/documentation/inference-api/api-keys
Create organization-scoped API keys for Inference Service, save the one-time secret, and disable, re-enable, or revoke access without stopping your endpoints.
API keys for Inference Service authenticate requests to your organization's model endpoints.
Keys are managed from the **API keys** section of the Inference Service page. They belong to the active organization rather than to a single endpoint, so one active key can be used with the organization's Inference Service endpoints.
## Create a key
1. Open **Inference Service** in the Compute console.
2. In **API keys**, select **New key**.
3. Enter a unique label using lowercase letters, numbers, and hyphens.
4. Select **Create**.
5. Copy the full key and store it securely.
6. Select **Copy and close** only after you have saved it.
The full key is shown once. You won’t be able to view it again after closing the dialog. If you lose it, create a replacement key and update the application or service that uses it.
After creation, the table keeps a masked version of the key and shows its:
* Status
* Label
* Masked key
* Last used time
* Created date
## Use a key in a request
Send the key as a bearer token when calling an endpoint:
```bash theme={null}
-H "Authorization: Bearer YOUR_INFERENCE_API_KEY"
```
The endpoint details also provide generated Python, JavaScript, and `curl` quick-start snippets.
See [Call your Inference Service endpoint](/documentation/inference-api/call-your-endpoint) for complete examples.
## Disable a key
Disable a key when you want to stop requests that use it without revoking the key permanently.
1. Open the key's options menu.
2. Select **Disable**.
3. Confirm that you understand requests using the key will fail while it is disabled.
4. Select **Disable key**.
The key remains in the table with a **Disabled** status and can be re-enabled later.
Disabling a key does not stop any endpoint. Running endpoints remain provisioned and are billed at their effective rate after any organization discount.
## Re-enable a key
To make a disabled key work again:
1. Open its options menu.
2. Select **Re-enable**.
The same stored key secret can authenticate requests again once its status returns to **Active**.
## Revoke a key
Revoke a key when it should never work again, for example when you are rotating credentials or believe the key has been exposed.
1. Open the key's options menu.
2. Select **Revoke**.
3. Review the confirmation checklist.
4. Confirm that dependent applications have been updated or no longer need the key.
5. Select **Permanently revoke**.
After revocation:
* Requests using that key fail permanently.
* The action cannot be undone.
* Running endpoints stay online and are billed at their effective rate after any organization discount.
* You need a new key for any application that still requires access.
## Store and rotate keys safely
* Give each key a label that identifies its application, environment, or purpose.
* Keep key secrets out of source code and repositories.
* Store them in environment variables or a secrets manager.
* Use separate keys when you want to be able to disable or revoke one application without affecting another.
* Check **Last used** before removing credentials that may still be active.
## Keys and organizations
Keys belong to the organization in which they were created.
If you work with more than one Compute organization, confirm the active organization before creating a key or troubleshooting authentication. Use a key from the same organization as the endpoint you are calling.
## Troubleshoot authentication
If a request is rejected:
1. Confirm you copied the complete key when it was created.
2. Check that its status is **Active**.
3. Confirm the request sends `Authorization: Bearer ...`.
4. Confirm the key and endpoint belong to the same organization.
5. Check that you are calling the endpoint URL shown by Inference Service rather than the Compute API.
If the key was lost, revoked, or exposed, create a new one rather than trying to recover or reuse the old secret.
## Next steps
* [Call your endpoint](/documentation/inference-api/call-your-endpoint).
* [Get started with Inference Service](/documentation/inference-api/get-started).
* [Manage an endpoint](/documentation/inference-api/manage-deployments).
* [Understand Inference Service billing](/documentation/inference-api/billing).
# Understand Inference Service billing
Source: https://docs.hivenet.com/documentation/inference-api/billing
Understand per-replica pricing, per-second billing, shared organization credits, and when Inference Service charges start, change, pause, and stop.
Hivenet Inference Service uses the same prepaid organization credit balance as Compute.
You pay for the fixed model-serving capacity that is running. Pricing is shown as a **per-replica hourly rate**, but usage is billed **per second** through the organization balance.
## How cost is calculated
Each model variant has a price per replica-hour. Your current endpoint rate depends on:
* The selected model variant
* The number of replicas running
Organization discounts apply to LLM model presets. Use the effective price after any applicable discount; a fully discounted preset has an effective rate of €0.
For example, increasing an endpoint from one replica to two doubles the total hourly rate for that variant. If the effective per-replica rate is €0, the total remains €0.
Before you deploy, **Review your setup** shows:
* Total cost per hour
* Estimated cost per 24 hours
* Estimated cost per week
The 24-hour and weekly figures are estimates of continuous running at the selected configuration. They are not minimum commitments or separate billing periods.
Prices shown in the live console are the source of truth. Use the current variant and review screens rather than an older screenshot or saved estimate.
## Billing is based on capacity, not tokens
The current production product is a dedicated endpoint service. You are billed for the replicas serving the model, not for each token or request sent to the endpoint.
Sending fewer requests does not automatically reduce the cost. The fixed replicas remain provisioned until you reduce the replica count, stop the endpoint, or terminate it.
Autoscaling is not available yet, so traffic volume does not automatically change replica count or hourly spend.
## When charging starts
A new or restarted endpoint enters **Starting** while Hivenet prepares its replicas.
The console says starting a model takes about 90 seconds. Serving charges begin once the endpoint is running.
## When charging changes
Changing the replica count changes the endpoint's serving rate.
* **Increase replicas:** The rate increases as the additional capacity comes online.
* **Reduce replicas:** The rate decreases after the serving capacity is reduced.
The replica editor shows the updated hourly rate before you save the change.
See [Manage replicas and capacity](/documentation/inference-api/replicas-and-capacity) for how scaling works.
## When charging pauses or stops
### Stop
Stopping an endpoint shuts down its serving replicas but keeps the endpoint configuration so you can start it again later.
Charges stop once the running replicas have been shut down and the endpoint reaches **Stopped**.
Starting it again later is subject to available capacity, and billing resumes once it is running again.
### Terminate
Termination permanently shuts down the endpoint. Serving charges stop when termination is complete.
A terminated endpoint cannot be started again. You can later use **Clear** to remove its terminated record from the Deployments list; clearing does not affect billing because the serving capacity has already been terminated.
Disabling or revoking an API key for Inference Service does **not** stop an endpoint. The endpoint remains provisioned and continues to incur charges until you reduce, stop, or terminate its serving capacity.
## Organization credits
Inference Service endpoints and Compute resources draw from the same organization balance.
If the organization does not have enough credits, the console can block a new deployment or a restart. Running Inference Service endpoints with a nonzero effective cost stop automatically when the organization balance reaches zero. Endpoints with an effective cost of €0 under a fully discounted contract are not stopped solely because the balance is zero.
Only the organization Owner can add credits or configure auto top-up. See [Billing information](/documentation/account-billing/billing-info) for payment methods, billing roles, auto top-up, and transaction history.
## Monitor spend
The Inference Service page shows product-level usage information including **Spend (24h)** and the current **Cost /h** for active endpoints.
The main Compute billing views also show the shared organization balance and current spend rate across resources.
See [Track organization spending in real time](/documentation/account-billing/track-costs-real-time) for the organization-wide view.
## Reduce serving cost
* Reduce replicas if you still need the endpoint but can run with less capacity.
* Stop the endpoint if you plan to use the same configuration again later.
* Terminate the endpoint when you no longer need it.
Stopping is usually the safer choice when you are unsure, because termination cannot be undone.
## Next steps
* [Manage replicas and capacity](/documentation/inference-api/replicas-and-capacity).
* [Manage an endpoint](/documentation/inference-api/manage-deployments).
* [Create and manage API keys](/documentation/inference-api/api-keys).
# Call your Inference Service endpoint
Source: https://docs.hivenet.com/documentation/inference-api/call-your-endpoint
Send OpenAI-compatible Chat Completions requests with Python, JavaScript, or curl using your endpoint URL, model value, and API key for Inference Service.
Each running Inference Service endpoint gives you three values you need to make a request:
* An **endpoint URL**
* A **model value** for the request
* An **API key for Inference Service** from the same organization
Open the endpoint details and use the generated **Quick-start snippets** for Python, JavaScript, or `curl`. They contain the values expected by that endpoint.
The current quick-start flow documents the OpenAI-compatible **Chat Completions** interface. Do not assume other OpenAI API routes are supported unless they are documented separately.
## Use the endpoint URL as shown
The endpoint URL already includes its API version path. It typically looks like:
```text theme={null}
https://YOUR_ENDPOINT_HOST/v1
```
Use this full value as the base URL in an SDK client.
Do not append another `/v1`. For a direct Chat Completions request, add `/chat/completions` to the endpoint URL, not another API-version segment.
## Use the exact model value from the snippet
Chat Completions requests include a `model` field. Copy the exact value generated for the endpoint.
It can differ from:
* The endpoint name you chose
* The shorter model title in the catalog
* The identifier used by another or older endpoint
If you receive a model-not-found error, check this value first.
## Python
Install the OpenAI SDK:
```bash theme={null}
pip install openai
```
Then use your endpoint values:
```python theme={null}
from openai import OpenAI
client = OpenAI(
base_url="YOUR_ENDPOINT_URL",
api_key="YOUR_INFERENCE_API_KEY",
)
response = client.chat.completions.create(
model="YOUR_MODEL_VALUE",
messages=[
{"role": "user", "content": "Hello!"}
],
)
print(response.choices[0].message.content)
```
## JavaScript
Install the OpenAI package in your Node.js project:
```bash theme={null}
npm install openai
```
Then configure the client with the same endpoint URL and key:
```javascript theme={null}
import OpenAI from 'openai'
const client = new OpenAI({
baseURL: 'YOUR_ENDPOINT_URL',
apiKey: 'YOUR_INFERENCE_API_KEY',
})
const response = await client.chat.completions.create({
model: 'YOUR_MODEL_VALUE',
messages: [{ role: 'user', content: 'Hello!' }],
})
console.log(response.choices[0].message.content)
```
## curl
For a direct request, append `/chat/completions` to the endpoint URL and send the API key as a bearer token:
```bash theme={null}
curl YOUR_ENDPOINT_URL/chat/completions \
-H "Authorization: Bearer YOUR_INFERENCE_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "YOUR_MODEL_VALUE",
"messages": [{"role": "user", "content": "Hello!"}]
}'
```
## Protect your API key
Do not commit the key to source control. For local testing, store it in an environment variable or another local secret store. For deployed applications, use the secret-management mechanism provided by your runtime or hosting platform.
If a key is exposed, create a replacement, update the applications that use it, and revoke the exposed key.
See [Create and manage API keys for Inference Service](/documentation/inference-api/api-keys) for the full key lifecycle.
## Before troubleshooting the request
Check these three things first:
* The endpoint is **Running** or **Partially running**.
* The API key is **Active** and belongs to the same organization as the endpoint.
* The endpoint URL and `model` value were copied from that endpoint's Quick-start snippet.
For authentication, capacity, latency, or endpoint-state problems, see [Troubleshoot Hivenet Inference Service](/documentation/inference-api/troubleshooting).
## Next steps
* [Create and manage API keys](/documentation/inference-api/api-keys).
* [Manage an endpoint](/documentation/inference-api/manage-deployments).
* [Manage replicas and capacity](/documentation/inference-api/replicas-and-capacity).
# Get started with Hivenet Inference Service
Source: https://docs.hivenet.com/documentation/inference-api/get-started
Deploy an Inference Service endpoint from the Compute console, create an API key, and send your first OpenAI-compatible Chat Completions request.
This guide takes you from the Compute console to a working inference request. You’ll choose where your models run, select a model and serving variant, set replica capacity, deploy the endpoint, and call it with an API key for Inference Service.
## What you’ll need
* A Compute account
* Access to a Compute organization
* Enough credits in the organization balance for the endpoint you want to run
* Python, Node.js, or `curl` if you want to test the endpoint locally
Inference Service uses the same organization balance as your Compute resources.
1. Sign in to the [Compute console](https://console.hivecompute.ai/).
2. Confirm the organization shown in the upper-left corner.
3. Open **Inference Service** from the left sidebar.
4. Select **New deployment**.
The endpoint and any API keys you create belong to the active organization.
Select where your Inference Service models should run.
The location selector shows the currently available regions and marks unavailable ones **Sold out**.
The location you choose currently applies across your Inference Service models. Per-model location selection is not available yet.
If you choose **Global**, Hivenet assigns an available region. After deployment, open the endpoint details to see where it was placed.
Read the data-handling notice shown for the selected location before continuing.
Select a model from the catalog. Use **All models** if you want to browse beyond the initial set shown on the page.
Model cards can include a short description, use-case tags, and a starting hourly price. After selecting a model, choose one of its available variants.
A variant can show:
* GPU and quantization
* Context window
* Approximate request capacity
* Time to first token
* Inter-token latency
* Output speed
* License
* Current price
The live variant card is the source of truth for the serving configuration and price you are about to deploy.
Choose how many replicas you want to keep running.
A replica is one serving copy of the selected model variant. More replicas provide more request capacity and increase hourly cost.
The current production flow supports a fixed replica count of up to four, subject to available capacity.
Autoscaling is not available yet. You can change the replica count later when capacity is available.
Keep the suggested name or enter your own using lowercase letters, numbers, and hyphens.
The endpoint name helps you identify the resource in the console. It is not necessarily the model value your application sends in API requests.
In **Review your setup**, check the selected model, location, replicas, and estimated cost.
The console shows:
* Total cost per hour
* Estimated cost per 24 hours
* Estimated cost per week
Select **Deploy model** when you’re ready.
The endpoint enters **Starting** while Hivenet prepares it. The console says this takes about 90 seconds. Charges begin once the endpoint is **Running**.
You need an active API key for Inference Service to call the endpoint.
If your organization does not already have one you want to use, select **Create API key** from the endpoint flow when it is offered, or select **New key** in the **API keys** section.
1. Enter a unique key label using lowercase letters, numbers, and hyphens.
2. Select **Create**.
3. Copy the full key and store it securely.
4. Select **Copy and close** only after you have saved it.
The full API key is shown once. You won’t be able to view it again after closing the dialog.
Open the endpoint details once its status is **Running**. The **Quick-start snippets** contain the endpoint URL and the exact model value expected by that endpoint.
Copy the endpoint URL exactly as shown. It already includes the API version path, such as `/v1`.
For Python, install the OpenAI SDK:
```bash theme={null}
pip install openai
```
Then use the values shown in your endpoint details:
```python theme={null}
from openai import OpenAI
client = OpenAI(
base_url="YOUR_ENDPOINT_URL",
api_key="YOUR_INFERENCE_API_KEY",
)
response = client.chat.completions.create(
model="YOUR_SERVED_MODEL_NAME",
messages=[
{"role": "user", "content": "Hello!"}
],
)
print(response.choices[0].message.content)
```
Copy the exact `model` value from the generated snippet. Do not substitute your endpoint name or assume the catalog title is identical.
For JavaScript and `curl` examples, see [Call your Inference Service endpoint](/documentation/inference-api/call-your-endpoint).
## When you’re done testing
A running endpoint is billed at its effective rate even when you are not sending requests. Organization discounts apply to LLM model presets; a fully discounted endpoint has an effective rate of €0.
* **Stop** it if you want to pause serving and start the same endpoint again later.
* **Terminate** it only when you no longer need the endpoint. Termination is permanent.
* **Clear** removes an already-terminated entry from the Deployments list; it does not terminate a running endpoint.
See [Manage an Inference Service endpoint](/documentation/inference-api/manage-deployments) for the full lifecycle.
## If something goes wrong
* **Location is Sold out:** Choose another available location or try again later.
* **Endpoint remains Starting:** Give provisioning about 90 seconds before treating it as a problem.
* **Authentication fails:** Confirm you are using an active API key for Inference Service from the same organization as the endpoint.
* **Model is not found:** Copy the exact `model` value from the endpoint’s generated quick-start snippet.
* **Not enough credits:** Ask the organization Owner to add credits if you cannot add them yourself.
For more cases, see [Troubleshoot Hivenet Inference Service](/documentation/inference-api/troubleshooting).
## Next steps
* [Choose a model and variant](/documentation/inference-api/models-and-variants).
* [Call your endpoint](/documentation/inference-api/call-your-endpoint).
* [Manage replicas and capacity](/documentation/inference-api/replicas-and-capacity).
* [Understand Inference Service billing](/documentation/inference-api/billing).
# Manage an Inference Service endpoint
Source: https://docs.hivenet.com/documentation/inference-api/manage-deployments
Understand Inference Service endpoint states, view endpoint details, and safely start, stop, retry, terminate, clear, or resize an endpoint.
Use the **Deployments** section of Inference Service to monitor and manage the model endpoints your organization has created.
Each row shows the endpoint status, name, model, region, replica count, request count over the last 7 days when available, and current hourly cost.
## Open endpoint details
Open an endpoint's options menu and select **Details**.
For a running endpoint, the details view can include:
* Endpoint URL
* Model
* GPU and quantization
* Context window
* License
* Region
* Cost so far and current hourly rate
* Replica count
* Requests over the last 7 days
* Input and output token counts
* p95 latency over the last 24 hours
* Error rate over the last 24 hours
* Inter-token latency
* Output speed
* Quick-start snippets for Python, JavaScript, and `curl`
The information changes with endpoint state. A stopped endpoint shows the information needed to start it again, including its stopped time. A terminated endpoint shows basic historical information and total cost, but no usable endpoint or quick-start snippets.
You can also copy the endpoint URL directly from the Deployments list while it is available.
## Understand endpoint states
| State | What it means | What you can usually do |
| - | - | - |
| **Starting** | Hivenet is preparing the endpoint. It is not ready to serve requests yet. | Wait for it to become ready or use the management actions currently offered. |
| **Running** | The endpoint is serving requests. | Call it, edit replicas, stop it, or terminate it. |
| **Partially running** | Fewer replicas are serving than requested. The endpoint still accepts requests with reduced capacity. | Retry failed replicas when available, change capacity, stop, or terminate. |
| **Error** | The endpoint has no healthy serving capacity. | Use **Retry** when available, or stop or terminate the endpoint. |
| **Stopped** | The endpoint is offline and its configuration is kept. | Start it again or terminate it. |
| **Terminated** | The endpoint has been permanently shut down. | Clear the terminated entry from the list. |
The console says starting a model takes about 90 seconds.
## Stop an endpoint
Use **Stop** when you want to take an endpoint offline but may need the same configuration again.
1. Open the endpoint's options menu.
2. Select **Stop**.
3. Review the confirmation.
4. Select **Stop model**.
The endpoint stops accepting requests as its replicas shut down. Serving charges pause once the endpoint is stopped.
Stopping keeps the endpoint configuration, but it does not reserve the underlying capacity. Starting it again later still depends on capacity being available in the selected location.
## Start a stopped endpoint
1. Open the options menu for a **Stopped** endpoint, or open its details.
2. Select **Start** or **Start model**.
3. Review the confirmation.
4. Select **Start model**.
The endpoint moves to **Starting** and begins serving again when it reaches **Running**. Billing resumes once serving capacity is running.
Starting can be blocked when the organization does not have enough credits or the required capacity is unavailable.
## Retry failed replicas
A **Retry** action can appear for endpoints that are **Partially running** or in **Error**.
Retry asks Hivenet to try the failed serving replicas again. Healthy replicas are left alone, so a Partially running endpoint can keep serving while recovery is attempted.
Retry does not start an endpoint that you deliberately stopped. Use **Start** for a **Stopped** endpoint.
If Retry is unavailable or repeatedly fails, see [Troubleshoot Hivenet Inference Service](/documentation/inference-api/troubleshooting).
## Change replica count
When the **Edit** control is available beside **Replicas** in endpoint details:
1. Select **Edit**.
2. Choose the new fixed replica count allowed by the console.
3. Review the updated capacity and price.
4. Select **Save**.
Increasing replicas can add serving capacity and raises hourly cost. Reducing replicas lowers capacity and cost after the change takes effect.
See [Manage replicas and capacity](/documentation/inference-api/replicas-and-capacity) for the full scaling behavior.
## Terminate an endpoint
Use **Terminate** only when you no longer need the endpoint. Termination is permanent.
1. Open the endpoint's options menu.
2. Select **Terminate**.
3. Review the confirmation checklist.
4. Confirm each item to acknowledge that requests will fail, the endpoint URL will no longer be usable, billing will stop when termination completes, and the action cannot be undone.
5. Select **Permanently terminate**.
After termination:
* The endpoint no longer serves requests.
* Its URL can no longer be used.
* It cannot be started again.
* Serving charges stop once termination is complete.
* The terminated entry remains visible until you clear it.
Update any application that depends on the endpoint before terminating it. You cannot restore a terminated endpoint.
## Clear a terminated endpoint
**Clear** removes an already-terminated entry from the **Deployments** list.
1. Open the options menu for a **Terminated** endpoint.
2. Select **Clear**.
3. Review the confirmation.
4. Select **Clear model**.
Clearing is only a cleanup action. It does not stop or terminate an endpoint that is still running or stopped.
## Next steps
* [Manage replicas and capacity](/documentation/inference-api/replicas-and-capacity).
* [Understand Inference Service billing](/documentation/inference-api/billing).
* [Troubleshoot Inference Service](/documentation/inference-api/troubleshooting).
# Choose an Inference Service model and variant
Source: https://docs.hivenet.com/documentation/inference-api/models-and-variants
Compare Inference Service models and serving variants by capabilities, context window, latency, request capacity, and per-replica hourly cost.
Hivenet Inference Service uses a curated model catalog. Each model can have one or more **variants** that define how that model is served.
The production console is the source of truth for what you can deploy now. Model and variant availability depends on the location selected for your Inference Service models.
## Model versus variant
A **model** is the model family or checkpoint you want to use. Its catalog card can include a description, capability tags, and a starting hourly price.
A **variant** is a deployable serving configuration for that model. Depending on the model, the variant details can show:
* GPU and quantization
* Context window
* Approximate request capacity
* Time to first token
* Inter-token latency
* Output speed
* License
* Current price
You choose the model first, then the variant, and finally the number of replicas.
## Choose for the workload
Start with what your application needs rather than automatically choosing the largest model.
Consider:
* **Capabilities:** Does the model support the kind of work you need, such as chat, tool use, structured output, coding, or multimodal input?
* **Context:** How much prompt, conversation history, or source material needs to fit into one request?
* **Latency:** Does someone wait for the response, or can the work run asynchronously?
* **Throughput:** How many requests do you expect to handle at the same time?
* **Cost:** What does the selected variant cost per replica, and how many replicas do you need?
* **License:** Does the model license fit how you plan to use and distribute your application?
Use the model cards and capability tags to narrow the catalog, then compare the available variants before deploying.
## Understand context window
The context window is the token space available to the served model for the request and generated output.
A larger context window lets you send longer prompts or retain more conversation history, but it does not mean the endpoint will perform the same way at every context length. Longer inputs require more processing before generation begins and can reduce throughput.
Hivenet characterizes serving behavior with different request shapes rather than treating every prompt as equivalent. A short chat request and a long reasoning request can produce very different latency and capacity on the same model.
Use the context value shown on the variant you are actually deploying. If your application depends on very long context, test it with realistic prompts rather than assuming performance from short-request figures.
## Understand the performance fields
Variant details can include several serving measurements:
* **Time to first token:** How long it takes before the endpoint begins returning generated text. This matters most for interactive experiences.
* **Inter-token latency:** The delay between generated tokens once output has started. Lower values generally make streamed responses feel faster.
* **Output speed:** How quickly generated tokens are returned once generation is underway.
* **Request capacity:** An approximate requests-per-minute figure for the displayed serving configuration.
These figures describe serving performance, not answer quality.
Do not treat one requests-per-minute figure as a universal limit. Input length, output length, concurrency, reasoning depth, and multimodal content can all change how much work a request requires.
## How Hivenet tests serving behavior
Hivenet's newer model-characterization work uses repeatable workload shapes so performance can be compared under more realistic conditions. These include:
* **Chat:** Short, interactive requests.
* **Agentic:** Longer reasoning or tool-oriented requests.
* **Async:** Batch-style text work where interactive first-token latency matters less.
* **Async multimodal:** Batch work that combines visual input with text on models that support it.
The purpose is to characterize serving capacity and latency for a model configuration. It does not determine which model produces the best answers for your application.
Test candidate models with your own prompts and data before choosing one for production. Use Hivenet's serving information to size the endpoint after you know which model meets your quality needs.
## Understand quantization and GPU configuration
Some variants use quantized model weights to reduce memory use or improve serving efficiency. The selected variant shows the GPU and quantization used for that endpoint when those details apply.
Because Hivenet manages the serving stack, you do not choose low-level model-server or GPU settings independently after deployment. Choose the variant whose documented characteristics fit your workload.
Organization discounts apply to LLM model preset prices. Review the effective price shown for your organization before deploying. See [Inference Service billing](/documentation/inference-api/billing).
## Choose replica capacity
After selecting the variant, choose the fixed number of replicas to run.
More replicas can increase the amount of traffic the endpoint can serve in parallel, and each replica adds to the hourly cost. The production flow supports up to four replicas, subject to available capacity.
Autoscaling is not available yet. You can change the fixed replica count later when capacity is available.
See [Manage replicas and capacity](/documentation/inference-api/replicas-and-capacity) for the full scaling behavior.
## Live availability comes from the console
The console initially shows a curated set of models and provides **All models** to browse the wider catalog.
Models, variants, prices, GPUs, context settings, and regional capacity can change independently of these docs. A model that Hivenet has benchmarked or characterized is not necessarily available for self-service deployment in every location.
Check the live console for the exact model, variant, context window, GPU configuration, quantization, price, and replica capacity you can deploy now.
## Use the served model name in API requests
Your endpoint has an exact model identifier for API calls. It can differ from the endpoint name or the shorter catalog title.
Use the `model` value shown in the endpoint's generated quick-start snippet rather than typing it from memory. Each serving variant now has its own model name, so copy the value from the specific endpoint you are calling instead of reusing an identifier from another variant.
## GPT-OSS 20B capabilities
GPT-OSS 20B supports OpenAI-compatible tool calls and reasoning output when you use a serving variant that exposes those capabilities. Use the generated endpoint examples and the exact served model name shown in the console.
## Next steps
* [Get started with Inference Service](/documentation/inference-api/get-started).
* [Manage replicas and capacity](/documentation/inference-api/replicas-and-capacity).
* [Call your endpoint](/documentation/inference-api/call-your-endpoint).
# Hivenet Inference Service overview
Source: https://docs.hivenet.com/documentation/inference-api/overview
Learn how Hivenet Inference Service serves open-weight models as managed, OpenAI-compatible endpoints with fixed replicas and shared Compute billing.
Hivenet Inference Service lets you serve supported open-weight models through managed, dedicated API endpoints without setting up and operating the inference stack yourself.
You choose the location, model, serving variant, replica count, and endpoint name in the Compute console. Hivenet provisions the serving infrastructure and gives you an endpoint you can call with OpenAI-compatible clients such as the OpenAI SDK and `curl`.
Inference Service was previously called Inference API. The rename does not change your endpoints, API keys, or billing. It remains part of the Compute console. Endpoints and API keys belong to the active organization and use the same prepaid organization credit balance as Compute resources.
## How it works
The deployment flow has five main choices:
1. **Location:** Choose where your Inference Service models run. In the current product, the selected location applies across your Inference Service models; per-model location selection is not available yet. Choosing **Global** lets Hivenet assign an available location, and the endpoint details show where it was placed.
2. **Model:** Choose a supported model from the catalog. The available catalog depends on the selected location.
3. **Variant:** Choose a preconfigured serving setup for that model. A variant can define the GPU configuration, quantization, context window, performance characteristics, and price.
4. **Replicas:** Choose the fixed number of serving replicas to run. More replicas provide more request capacity and increase hourly cost.
5. **Endpoint name:** Keep the suggested name or enter a label you can recognize in the console.
The console lists these resources under **Deployments**. Each deployment creates one callable endpoint.
Autoscaling is not available yet. You choose a fixed replica count and can change it later when capacity is available.
## Inference Service, Compute, and Hivenet Router
These products cover different parts of the inference stack.
| Product | Use it when | You manage |
| - | - | - |
| **Hivenet Inference Service** | You want a managed model endpoint for an application or service. | Model choice, replicas, API keys, and client code. |
| **Compute with Hivenet** | You want direct GPU or CPU infrastructure and control over the serving environment. | The instance, runtime, model server, configuration, and operations. |
| **Hivenet Router** | You want to run Hivenet's open-source model-routing software on infrastructure you control. | The router deployment, model backends, infrastructure, and operations. |
If you need an endpoint but do not want to operate vLLM or another serving runtime yourself, Hivenet Inference Service is the managed option.
## Endpoint lifecycle
The Inference Service page shows the current state of each endpoint.
| Status | What it means |
| - | - |
| **Starting** | Hivenet is preparing the endpoint. It is not ready to serve requests yet. |
| **Running** | The endpoint is serving requests. |
| **Partially running** | Some requested replicas are serving while others are unavailable or recovering. |
| **Stopped** | The endpoint is offline but its configuration is kept. You can start it again when capacity and credits allow. |
| **Error** | The endpoint is not currently serving. A **Retry** action can appear when recovery is possible. |
| **Terminated** | The endpoint has been permanently shut down and cannot be started again. |
The console says starting a model takes about 90 seconds. Charges begin once it is running.
**Stop** is reversible. **Terminate** permanently shuts down the endpoint and makes its URL unusable. After termination, **Clear** only removes the terminated entry from the Deployments list.
## Endpoint details
Open **Details** to see the endpoint URL, model and serving configuration, replica count, region, cost information, available usage metrics, and quick-start snippets for Python, JavaScript, and `curl`.
The endpoint URL already includes the API version path, such as `/v1`. The generated snippet also contains the exact model value expected by that endpoint.
See [Call your endpoint](/documentation/inference-api/call-your-endpoint) for request examples and [Manage endpoints](/documentation/inference-api/manage-deployments) for lifecycle controls.
## API keys and billing
API keys for Inference Service are scoped to the organization rather than to one endpoint. The full secret is shown once when you create a key, so save it before closing the dialog. Disabling or revoking a key stops requests made with that key but does not stop running endpoints.
Inference Service is billed by the fixed model-serving capacity you run. Before deployment, the console shows estimated hourly, 24-hour, and weekly cost. Stopping an endpoint pauses serving charges; terminating it ends them once termination is complete.
* [Create and manage API keys](/documentation/inference-api/api-keys)
* [Understand Inference Service billing](/documentation/inference-api/billing)
## Location and data handling
The location selector can mark a location **Sold out** when capacity is unavailable. It also shows the data-handling notice that applies to the selected location.
Read that notice before deploying. It is the source of truth in the console for where prompts and responses are processed or stored and for the other data-handling statements associated with that location.
## Next steps
* [Deploy a model and make your first request](/documentation/inference-api/get-started).
* [Choose a model and variant](/documentation/inference-api/models-and-variants).
* [Manage replicas and capacity](/documentation/inference-api/replicas-and-capacity).
* [Call your endpoint](/documentation/inference-api/call-your-endpoint).
# Manage replicas and Inference Service capacity
Source: https://docs.hivenet.com/documentation/inference-api/replicas-and-capacity
Understand fixed replicas, requested versus active capacity, live scaling limits, and how replica count affects throughput and cost.
A replica is one serving copy of the model variant behind your endpoint. More replicas let the same endpoint handle more work in parallel, but each running replica adds to the hourly cost.
The current production version uses a **fixed replica count**. You choose the initial count when you deploy the model and can change it later when capacity is available.
## Fixed capacity in production
The production replica control supports **1 to 4 replicas**, subject to available capacity for the selected model variant and location.
As you change the count, the console shows the corresponding hourly price and an approximate requests-per-minute estimate.
Autoscaling is not available yet. If you want the endpoint fully offline, use **Stop** rather than trying to reduce the replica count to zero.
## Requested and active replicas
An endpoint can have a requested replica count that is higher than the number currently serving traffic.
For example, **1/3** in the Deployments list means one replica is currently serving out of three requested.
* When all requested replicas are serving, the endpoint is **Running**.
* When only some are serving, the endpoint can be **Partially running** and continue accepting requests with reduced capacity.
* When no healthy replica is serving, the endpoint can move to **Error**.
An active replica is one that is actually available to serve requests, not simply one that was requested.
## Choose a replica count
Start with enough capacity for the traffic you expect, then adjust after observing the endpoint.
More replicas can help when you need to handle more simultaneous requests, but they do not make an individual model response inherently better. Latency and throughput also depend on the model, context length, output length, and workload shape.
The requests-per-minute figure in the console is a planning estimate for the displayed configuration, not a universal rate limit for every prompt.
See [Choose a model and variant](/documentation/inference-api/models-and-variants) for how to interpret serving performance.
## Change the replica count
When the **Edit** control is available beside **Replicas** in endpoint details:
1. Select **Edit**.
2. Choose the new replica count allowed by the console.
3. Review the updated capacity estimate and hourly price.
4. Select **Save**.
The endpoint keeps the same URL and model configuration while Hivenet adjusts its serving capacity.
If the change succeeds, the details view updates to the new replica count. When you scale down, surplus replicas are paused rather than deleted, which makes a later scale-up faster when the same capacity is reused. If capacity is no longer available, the console can reject the change and leave the existing configuration in place.
## Partially running endpoints
If fewer replicas are serving than requested, the endpoint can remain available as **Partially running**.
You can:
* Keep serving with reduced capacity while waiting for recovery
* Use **Retry** when the action is available
* Reduce the requested replica count if your workload can run with less capacity
* Stop the endpoint if you do not want it serving in the partial state
Retry asks Hivenet to recover failed replicas without deliberately stopping the healthy ones that are already serving.
## Capacity is live
Replica capacity is not reserved simply because an option was available earlier.
Availability can change while you are deploying a model, editing replicas, or restarting a stopped endpoint. The console is the source of truth for the replica count that can be provisioned at that moment.
Stopping an endpoint preserves its configuration, not its underlying GPU capacity. Starting it again later can fail if that capacity is no longer available.
## Replica count and billing
Each running replica contributes to the endpoint's serving cost.
Increasing replicas raises the hourly rate as additional capacity comes online. Reducing replicas lowers it after the change takes effect. Stopping the endpoint tears down its replicas and pauses serving charges once it reaches **Stopped**.
See [Understand Inference Service billing](/documentation/inference-api/billing) for the full billing lifecycle.
## Next steps
* [Choose a model and variant](/documentation/inference-api/models-and-variants).
* [Manage an endpoint](/documentation/inference-api/manage-deployments).
* [Understand Inference Service billing](/documentation/inference-api/billing).
# Troubleshoot Hivenet Inference Service
Source: https://docs.hivenet.com/documentation/inference-api/troubleshooting
Fix common Inference Service problems with location capacity, credits, endpoint states, replicas, API keys, endpoint URLs, and model identifiers.
Use this page when an endpoint cannot start, is only partially running, or an API request fails.
## A location is sold out
A location marked **Sold out** cannot accept another endpoint at that moment.
If you are choosing your Inference Service location for the first time, select another available location or try again later.
If your Inference Service location has already been established, new endpoints inherit that location in the current production version. In that case, try another available model or variant in the same location, reduce the replica count where possible, or wait for capacity to become available.
Per-model location selection is not available yet. The console is the source of truth for current regional capacity.
## I chose Global but the endpoint shows a specific region
This is expected.
Choosing **Global** lets Hivenet assign an available region. After deployment, the endpoint details show the region where it was actually placed.
## A model or variant is unavailable
Model and variant availability depends on your selected location and current capacity.
Try one of these options:
* Choose another available model or variant.
* Reduce the replica count if the console offers a lower count.
* Try again later after capacity has been released.
## The organization does not have enough credits
The console can block a new deployment or restart when the organization does not have enough credits.
Add credits when the option is available, or ask the organization Owner to top up the balance if you do not have billing permissions.
Inference Service and Compute resources use the same organization balance.
## An endpoint stopped when credits ran out
Running endpoints with a nonzero effective cost stop automatically at zero credits. Ask the organization Owner to add credits, then start the endpoint again when capacity is available.
An endpoint with an effective cost of €0 under a fully discounted contract is not stopped solely because the balance is zero. If one stops, check its state and error details and contact Support if the cause is unclear.
## The endpoint is still Starting
The console says starting a model takes about 90 seconds.
While the endpoint is **Starting**, it is not ready for normal traffic yet. Wait for **Running** before testing your integration.
If it remains in **Starting** well beyond the expected period, Hivenet will attempt to recover the affected replica automatically. If a **Retry** action becomes available, use it to try the failed replica again. If recovery still does not complete, note the endpoint name, model, region, and approximate start time before contacting Support.
## The endpoint is Partially running
**Partially running** means fewer replicas are serving than requested. For example, **1/3** means one replica is serving out of three requested.
The endpoint can still accept traffic, but available throughput is lower.
You can:
1. Use **Retry** when the action is available.
2. Reduce the replica count if your workload can run with less capacity.
3. Wait for capacity to recover.
4. Stop the endpoint if you do not want it serving with reduced capacity.
## The endpoint is in Error
**Error** means no healthy replica is currently serving requests.
Start with these checks:
1. Use **Retry** if the action is available.
2. Check that the organization still has enough credits.
3. Check whether the selected model configuration still has capacity in the current location.
4. If the problem continues, collect the endpoint name, region, model, replica count, and approximate failure time before contacting Support.
## The endpoint shows Retrying
After you select **Retry**, the endpoint can temporarily show **Retrying** while Hivenet attempts to recover failed serving replicas.
Wait for the state to settle. A successful retry returns the endpoint to **Running** or **Partially running**, depending on how many replicas recover.
## Retry is unavailable or keeps failing
The **Retry** action appears only when it applies to the current endpoint state.
Retry does not start a deliberately stopped endpoint. Use **Start** for an endpoint that is **Stopped**.
If Retry repeatedly fails, the underlying capacity or serving problem may still exist. Wait and try again later, reduce the requested replica count where possible, or contact Support if the endpoint remains unusable.
## A replica change cannot be saved
Capacity can change while you are editing an endpoint.
If the requested count is no longer available, choose the maximum currently offered by the console or try the change later. A failed resize leaves the existing endpoint configuration in place.
## A stopped endpoint will not start
Starting a stopped endpoint requires:
* Enough organization credits
* Enough current capacity for its existing configuration
Stopping preserves the endpoint configuration, not the underlying GPU capacity. If capacity is unavailable, wait and try again later.
## The API key is rejected
Check that:
* You are using an **API key for Inference Service**, not a Compute API key.
* The key is **Active**, not disabled or revoked.
* The key belongs to the same organization as the endpoint.
* The request sends the key as `Authorization: Bearer ...`.
If the key was lost, revoked, or exposed, create a new one and update the application.
See [Create and manage API keys for Inference Service](/documentation/inference-api/api-keys).
## The endpoint URL does not work
Copy the URL from endpoint details or from the copy control in the Deployments list rather than reconstructing it manually.
The endpoint URL already includes the API version path, such as `/v1`. Do not add another `/v1`.
For the documented Chat Completions interface, the direct request path is:
```text theme={null}
YOUR_ENDPOINT_URL/chat/completions
```
Also confirm that the endpoint is **Running** or **Partially running**. Stopped and terminated endpoints do not serve requests.
## The request cannot find the model
Do not assume the endpoint name or shorter catalog title is the model identifier expected by the API.
Copy the exact `model` value from the endpoint's generated **Quick-start snippets**.
## Requests are slower than expected
Check:
* Whether the endpoint is **Partially running**.
* How many replicas are currently serving compared with the requested count.
* Whether the request uses long input, large output, or another expensive workload shape.
* The inter-token latency and output-speed metrics in endpoint details when they are available.
The requests-per-minute figure shown for a model variant is a planning estimate for that serving configuration, not a guarantee for every request shape.
## A terminated endpoint still appears
Termination permanently shuts down the endpoint, but its record can remain in the **Deployments** list.
Use **Clear** to remove an endpoint that is already **Terminated**.
**Clear** does not stop or terminate an active endpoint. It only removes the terminated record.
## What to send Support
If you still need help, include:
* Organization name
* Endpoint name
* Model and variant
* Location
* Endpoint status
* Requested and active replica count, when visible
* Approximate time the problem started
* What action or request you were trying to perform
Do not send your full API-key secret.
## Next steps
* [Manage endpoints](/documentation/inference-api/manage-deployments).
* [Manage replicas and capacity](/documentation/inference-api/replicas-and-capacity).
* [Create and manage API keys](/documentation/inference-api/api-keys).
* [Call your endpoint](/documentation/inference-api/call-your-endpoint).
# How organizations work in Compute
Source: https://docs.hivenet.com/documentation/organizations/how-organizations-work
Understand how Compute organizations group people, Owner, Admin, and Member roles, shared credit balance, instances, and billing under one account.
Every Compute account operates within an organization. The organization defines who can use its resources, what each person can manage, and which balance pays for their usage.
Your account can belong to one organization at a time. If you used Compute before organizations were introduced, your account, existing resources, and credits were moved into an organization automatically.
An organization has one **Owner** and can also contain **Admins** and **Members**. The Owner controls billing and ownership. Admins help manage the organization. Members use its resources.
## What an organization controls
An organization brings several parts of Compute together:
* **People and roles:** Who belongs to the organization and what they can manage.
* **Resources:** The instances and other Compute resources created within the organization.
* **Credits:** A shared organization balance that pays for usage.
* **Billing:** Spending, payment methods, auto top-up, and transaction history.
Instances you create while using an organization are charged to that organization's balance. Your role determines which instances and billing information you can see.
## Find your organization
The organization currently in use appears in the upper-left corner of the Compute console.
To open its organization page, use either of these paths:
1. Select the organization name in the upper-left corner, then choose **Organization options**.
2. Open the menu next to your account at the bottom of the sidebar, then select **Organization**.
The organization page shows its Owner, Admins, and Members. Owners and Admins can also manage pending invitations. The actions available on the page depend on your role.
## Understand organization roles
| Capability | Owner | Admin | Member |
| :- | :-: | :-: | :-: |
| Use organization resources | Yes | Yes | Yes |
| Create instances | Yes | Yes | Yes |
| View all organization instances | Yes | Yes | No |
| View instances they created | Yes | Yes | Yes |
| Invite people | Yes | Yes | No |
| Change roles | Yes | Yes | No |
| Remove people | Yes | Yes | No |
| Rename the organization | Yes | Yes | No |
| View organization billing details | Yes | Yes | No |
| Add credits | Yes | No | No |
| Manage payment methods and auto top-up | Yes | No | No |
| Transfer ownership | Yes | No | No |
| Delete the organization | Yes | No | No |
| Leave the organization | After transferring ownership | Yes | Yes |
### Owner
Every organization has one Owner. The Owner has full control over the organization, including:
* People and role management
* Organization settings and name
* Credits, payment methods, and auto top-up
* Ownership transfer
* Organization deletion
The Owner can also see all instances created within the organization.
Ownership includes control of the organization's credits and payment settings. Transfer ownership only to someone you trust to manage both access and billing.
### Admin
Admins help operate the organization. They can:
* Invite people as Admins or Members
* Change people between the Admin and Member roles
* Remove Admins and Members
* Rename the organization
* See all organization instances
* View billing details and transaction history
Admins cannot add credits, manage payment methods, configure auto top-up, transfer ownership, or delete the organization.
### Member
Members can create and use organization resources. They see the instances they created, rather than every instance in the organization.
Members cannot manage people, organization settings, or billing. Instances they create are still charged to the shared organization balance.
## How the organization balance works
The organization balance is shared across the people using that organization. Usage from their running resources contributes to the organization's spend rate.
Billing access depends on role:
* The **Owner** can add credits, manage payment methods, and configure auto top-up.
* **Admins** can view billing and spending information, but cannot change billing controls.
* **Members** cannot view or manage organization billing.
When a person accepts an invitation to another organization, their remaining credits are transferred to the organization they join. Future resources are billed to the new organization balance.
## Instance visibility
Owners and Admins can see all instances created within the organization. This helps them understand active usage and identify who created a stopped instance.
Members see only the instances they created. They can continue to create and use resources, but they do not see other people's instances or organization-wide billing information.
## Invitations and membership changes
Owners and Admins can invite people by email and choose whether each person joins as an Admin or Member. Pending invitations can be resent or canceled from the organization page.
Before accepting an invitation, a person should understand that:
* Their account will move to the invited organization.
* Their remaining credits will be added to the new organization balance.
* New resources will use the new organization's credits.
* They must terminate any running or stopped instances in their current organization before they can join.
* An Owner must transfer ownership of their current organization before joining another one.
Back up any data you need before terminating an instance. Termination permanently deletes the instance and its local data.
## Leaving an organization
Admins and Members can leave an organization from the organization page. Before leaving, save any important data and terminate the running or stopped instances you created. If Compute detects instances that prevent the move, it directs you to the **Instances** page.
After leaving:
* You lose access to the organization's resources and settings.
* You no longer have the permissions associated with your role.
* You need a new invitation to rejoin.
The Owner cannot leave directly. They must transfer ownership to an Admin first. If the intended new Owner is a Member, change them to an Admin before starting the transfer.
## Renaming or deleting an organization
The Owner and Admins can rename the organization. Renaming it does not change people's roles or access.
Only the Owner can delete an organization. Deletion permanently removes the organization, its instances and data, remaining credits, and pending invitations.
Organization deletion cannot be undone. Download important data and confirm that you no longer need the remaining credits before deleting the organization.
## Next steps
* [Invite people and manage organization roles](/documentation/organizations/invite-people-manage-roles)
* [Join or leave a Compute organization](/documentation/organizations/join-leave-organization)
* [Transfer ownership or delete an organization](/documentation/organizations/transfer-ownership-delete-organization)
# Invite people and manage organization roles
Source: https://docs.hivenet.com/documentation/organizations/invite-people-manage-roles
Invite Admins and Members to your Compute organization, track pending invitations, change roles, and remove access as an Owner or Admin.
Organization Owners and Admins can invite people to the organization, choose their roles, and manage their access from the organization page.
People can join as an **Admin** or **Member**. Only the current Owner can transfer ownership to someone else.
## What you’ll need
* An **Owner** or **Admin** role in the organization
* The email addresses of the people you want to invite
* A role for each group of invitees: **Admin** or **Member**
## Invite people
1. Open the organization page:
* Select the organization name in the upper-left corner, then choose **Organization options**; or
* Open the menu next to your account and select **Organization**.
2. Select **Invite people**.
3. Choose whether the people you are inviting will join as **Admins** or **Members**.
4. Enter their email addresses, separated by commas.
5. Select **Send invites**.
You can enter up to 20 email addresses for the selected role at a time. To invite people with a different role, return to the role-selection step and send a separate set of invitations.
Invitations are tied to the email addresses you enter. The invited person should sign in or create their Compute account with the same email address.
## Choose the right role
### Invite an Admin
Admins can use organization resources and help manage the organization. They can:
* Invite people
* Change people between the Admin and Member roles
* Remove Admins and Members
* Rename the organization
* See all organization instances
* View billing and usage details
Admins cannot add credits, manage payment methods, configure auto top-up, transfer ownership, or delete the organization.
### Invite a Member
Members can create and use organization resources. Instances they create use the shared organization balance.
Members cannot manage people, organization settings, or billing. They see the instances they created rather than every instance in the organization.
## Manage pending invitations
People who have not accepted their invitations appear as pending on the organization page for Owners and Admins. Members do not see pending invitations.
Compute blocks duplicate re-invites while a matching invitation is still active.
Owners and Admins can use the menu next to a pending invitation to:
* **Resend invite** if the person still needs access
* **Cancel invite** if they should no longer be able to join
Canceling an invitation makes its existing invitation link invalid. Send a new invitation if the person needs access later.
## Change an Admin to a Member
1. Open the organization page.
2. Find the person under **Admins**.
3. Open the menu next to their name.
4. Select **Change to member**.
5. Review the change, then select **Change to member** again.
The person stays in the organization but loses Admin permissions. They can continue using organization resources as a Member.
## Change a Member to an Admin
1. Open the organization page.
2. Find the person under **Members**.
3. Open the menu next to their name.
4. Select **Change to admin**.
5. Review the permissions they will receive, then select **Change to admin** again.
The person can then manage people and organization settings, see all organization instances, and view billing and usage details.
Admins can manage people and see organization-wide instances, billing, and usage information. Assign the role only to people who need those responsibilities.
## Remove someone from the organization
Owners and Admins can remove other Admins and Members.
1. Open the organization page.
2. Find the person you want to remove.
3. Open the menu next to their name.
4. Select **Remove member**.
5. Confirm that you understand the consequences shown in the dialog.
6. Select **Remove member** again.
Removing someone has an immediate effect:
* They lose access to the organization.
* Their running and stopped instances in the organization are terminated.
* They need a new invitation to rejoin.
Terminating an instance permanently deletes its local data. Make sure the person has saved anything important before you remove them.
## Manage the Owner role
The Owner cannot be demoted or removed like an Admin or Member. To change the Owner, transfer ownership to an Admin.
If the person you want to make Owner is currently a Member, change them to an Admin first. Then follow the [ownership transfer instructions](/documentation/organizations/transfer-ownership-delete-organization).
# Join or leave a Compute organization
Source: https://docs.hivenet.com/documentation/organizations/join-leave-organization
Accept or decline a Compute organization invitation, prepare your account and existing credits for the move, and leave an organization safely.
An organization invitation moves your Compute account into the invited organization, with its people, resources, roles, and balance. Review the effects before you accept, especially if you already have credits or instances.
Your Compute account can belong to one organization at a time. Joining another organization changes where your future resources are created and billed.
## Before you accept an invitation
The invitation shows:
* The organization you were invited to join
* Its current Admins
* Whether you will join as an **Admin** or **Member**
* The changes that will apply to your account
Before accepting, check the following:
* **Instances:** Terminate any running or stopped instances in your current organization.
* **Important data:** Download anything you need before terminating an instance.
* **Credits:** Any remaining credits will be transferred to the organization you join.
* **Ownership:** If you own your current organization, transfer ownership before trying to join another one.
Terminating an instance permanently deletes its local data. Back up important files before continuing.
## Accept an invitation
1. Open the invitation link from the email you received.
2. Sign in to Compute with the invited email address. Create an account first if you do not already have one.
3. Review the organization, your new role, and the changes listed in the invitation dialog.
4. Select each confirmation checkbox when they appear.
5. Select **Accept invite**.
After you join:
* You can use the new organization's resources according to your role.
* Instances you create are charged to the new organization balance.
* Your remaining credits are added to that balance.
* You lose access to your previous personal transaction history in the Compute console.
If you join as an Admin, you can manage people and organization settings and view billing details. If you join as a Member, you can use organization resources but cannot manage people, settings, or billing.
## If your organization changes without you accepting an invitation
Auto top-up is disabled when your account is moved to another organization without you choosing to join it. Check the organization shown in the console. Its Owner should review payment details before enabling auto top-up again.
## Accept an invitation later
Select **Not now** to close the invitation without accepting or declining it. You can return while the invitation remains valid.
Select **Decline** when you do not want to join. The organization Owner or an Admin will need to send another invitation if you change your mind later.
## Why you may be unable to accept
### You still have instances
Compute blocks the invitation while you have running or stopped instances in your current organization.
1. Select **Go to instances**.
2. Download any data you need.
3. Terminate every running and stopped instance.
4. Return to the invitation and accept it again.
### You own another organization
An Owner cannot join another organization directly.
1. Select **Go to organization**.
2. Transfer ownership to an Admin.
3. Leave the organization after the transfer is complete.
4. Return to the invitation and accept it.
If the person you want to make Owner is a Member, change them to an Admin first.
### The invitation expired or was canceled
An expired or canceled invitation cannot be accepted. Ask an Owner or Admin of the organization to send you a new one.
## Leave an organization
Admins and Members can leave an organization. The Owner must transfer ownership before leaving.
Before you leave:
* Download any data you want to keep.
* Terminate your running and stopped instances in the organization.
* Make sure you no longer need access to its shared resources, settings, or billing information.
To leave:
1. Open **Organization** from the menu next to your account.
2. Find your own name on the organization page.
3. Open the menu next to your name.
4. Select **Leave organization**.
5. Review and confirm each consequence shown in the dialog.
6. Select **Leave organization** again.
After leaving:
* You lose access to the organization's resources.
* Your role and organization permissions end.
* You need a new invitation to rejoin.
If Compute reports that you still have instances, go to **Instances**, terminate them, and try leaving again.
## If you are the Owner
The Owner cannot leave while they still control the organization. Transfer ownership to an Admin first, then leave as an Admin.
See [Transfer ownership or delete an organization](/documentation/organizations/transfer-ownership-delete-organization) for the full process.
# Transfer ownership or delete an organization
Source: https://docs.hivenet.com/documentation/organizations/transfer-ownership-delete-organization
Transfer Owner control of a Compute organization to another Admin, or permanently delete the organization along with its instances, credits, and access.
Only the organization Owner can transfer ownership or delete the organization. Both actions affect access and billing, so review the consequences carefully before continuing.
## Transfer ownership
Transferring ownership gives another Admin full control of the organization and changes the current Owner to an Admin.
The new Owner controls organization credits, payment methods, auto top-up, people, settings, future ownership transfers, and organization deletion.
### Before you transfer ownership
Make sure that:
* The person is already an **Admin** in the organization.
* They understand that they will control billing and access.
* You are prepared to lose Owner-only permissions.
* You have discussed any payment method or auto top-up changes with them.
If the person is currently a Member, [change them to an Admin first](/documentation/organizations/invite-people-manage-roles#change-a-member-to-an-admin).
### Transfer ownership to an Admin
1. Open the organization page.
2. Find the Admin who will become the new Owner.
3. Open the menu next to their name.
4. Select **Transfer ownership**.
5. Review each consequence in the confirmation dialog.
6. Select every checkbox to confirm that you understand.
7. Select **Transfer ownership** again.
After the transfer:
* The selected Admin becomes the **Owner**.
* You become an **Admin**.
* The new Owner gains full control of billing and organization management.
* You can still view billing and usage details, but cannot add credits or manage payment methods.
* The organization's existing auto top-up configuration is turned off.
* The new Owner can configure auto top-up again.
You cannot reverse the transfer yourself. Ownership can be transferred back only with the new Owner's cooperation.
## Leave after transferring ownership
Once the transfer is complete, you can leave the organization as an Admin.
Before leaving, save any important data and terminate the running or stopped instances you created. Then open the menu next to your own name and select **Leave organization**.
See [Join or leave a Compute organization](/documentation/organizations/join-leave-organization#leave-an-organization) for the full process.
## Delete an organization
Deleting an organization permanently removes the organization and ends access for everyone in it.
When an organization is deleted:
* The Owner, Admins, and Members lose access.
* Organization instances and their data are deleted.
* Remaining organization credits are lost and cannot be refunded.
* Pending invitations are canceled.
* The action cannot be undone.
Download any data you need before deleting the organization. Local instance data cannot be recovered afterward.
### Delete the organization
1. Open the organization page.
2. Open the organization menu next to **Invite people**.
3. Select **Delete organization**.
4. Review every consequence in the confirmation dialog.
5. Select each checkbox to confirm that you understand.
6. Select **Delete organization** again.
Deletion is permanent. Do not continue unless you are prepared to lose the organization's resources, data, credits, and pending invitations.
## Rename instead of deleting
If you only need to change the organization name, do not delete it.
1. Open the organization menu next to **Invite people**.
2. Select **Rename organization**.
3. Enter the new name and confirm the change.
Renaming does not change roles, resources, billing, or access.
# CPU-only types and sizes
Source: https://docs.hivenet.com/documentation/reference/cpu-types
Reference for CPU-only Compute with Hivenet instances on AMD EPYC 7713 hosts, with fixed vCPU, RAM, disk, and bandwidth options for each size.
Use CPU-only instances for web services, CI, preprocessing, or light workloads that don’t need a GPU. All sizes run on **AMD EPYC 7713** hosts.
### Sizes and specs
| Size | vCPU | RAM | Disk space | Price\* |
| - | - | - | - | - |
| X-Small | 2 | 4 GB | 50 GB | €0.06/h |
| Small | 4 | 8 GB | 100 GB | €0.11/h |
| Medium | 8 | 16 GB | 200 GB | €0.22/h |
| Large | 16 | 32 GB | 400 GB | €0.45/h |
| X-Large | 32 | 64 GB | 800 GB | €0.90/h |
\* Prices shown are from internal references and may change. See the dashboard for current rates.
### Notes
* Architecture: **x86\_64** (AMD EPYC 7713).
* Billing: **per-second using credits**.
* You can [**start/stop instances**](/documentation/essentials/start-stop-instances) without extra fees
# Frequently asked questions
Source: https://docs.hivenet.com/documentation/reference/faq
Answers to frequently asked questions about Compute with Hivenet instances, GPUs, billing, credits, SSH access, and troubleshooting common issues.
A practical FAQ for running workloads on **Compute with Hivenet**. It covers billing, instances, templates, networking, and inference. If you’re new, start here. If you’re stuck, jump to **Troubleshooting** at the end.
## Billing and pricing
### How does billing work?
Compute uses **pre‑paid credits** (in euros) with **per‑second billing**. You add credits first, then start instances. Your balance decreases while instances run.
### What’s the minimum balance to start an instance?
Have at least **one hour** of credit for your chosen configuration. If your balance is lower, add funds or select a smaller instance.
### Are there hidden fees?
No. You **only pay for compute time**. Storage attached to your on‑demand instance and network traffic are included.
Auto top‑up is available after your first purchase. Set a threshold and amount so your balance refills before it hits zero.
### What happens if I run out of credits?
As the organization balance runs low, Compute instances may stop or be terminated. Top up ahead of time or enable auto top-up. Running Inference Service endpoints with a nonzero effective cost stop at zero credits; fully discounted endpoints with an effective cost of €0 are not stopped solely for that reason. See [Billing information](/documentation/account-billing/billing-info).
### How is storage billed?
For on‑demand instances, storage is included with your instance. All storage is **NVMe SSD**. If you need more space or options, contact support.
### Where can I find invoices and payment history?
Invoices and transaction history are available via **Stripe**. You can access your billing records from the **Billing** tab in the console.
## Instances and lifecycle
### Are Compute instances containers or virtual machines?
You can choose. Compute instances are not limited to a single runtime type. Depending on your setup, an instance can run as a container or as a virtual machine. Containers cover most workflows like running scripts, apps, and models. Virtual machines are available for use cases that require full OS-level control, kernel access, or custom images.
### Can I stop and start an instance later?
Yes. You can [**stop an instance and start it again**](/documentation/essentials/start-stop-instances) without losing your environment. Your files, packages, and configuration remain intact. Stopping releases the underlying capacity back to the pool. When you start again, availability depends on demand, and you may be placed on different hardware.
**Important:** Stopped instances are not kept indefinitely.
If an instance remains stopped for more than 10 days, it is automatically terminated. Once terminated, the instance and its data cannot be recovered.
Stop/Start currently has **no extra fee**. This may change; always check the latest pricing.
### Do I keep the same GPU when I stop and start?
No. Stop/Start preserves your environment, but it doesn’t reserve the underlying GPU. When you start again, Compute allocates whatever matching capacity is available in that region. If nothing matches, you’ll be asked to try again later.
### What happens to errored instances?
Compute retries failed starts a limited number of times. If the instance reaches an error state, use the retry action when the console offers it. If it keeps failing, contact Support with the instance ID, error, and approximate time. Do not use an errored instance as a backup; download important files when access is available.
If you’re not sure why the instance failed, check the instance logs in the app. They usually give enough context to understand what went wrong or what to try next.
### Is there a time limit on how long an instance can run?
There’s no fixed time limit. An instance can run as long as it stays healthy and your balance covers the runtime. In rare cases, we may need to schedule maintenance that requires a restart.
### Do my files persist when stopped?
Yes. Your environment is preserved when you stop an instance. Termination (manual or due to low balance) ends the session; use a template or image to recreate your setup quickly.
### What operating systems and images are available?
For container-based instances, choose from the templates currently shown in the console, or use a custom template. The former self-managed vLLM product flow has been retired. For managed model serving, use [Hivenet Inference Service](/documentation/inference-api/overview).
For virtual machine instances, you can choose a full operating system image such as **Ubuntu**, **Fedora**, or **Debian**.
### What are custom templates?
A [**custom template**](/documentation/essentials/custom-templates) saves your configured environment (OS, packages, dependencies, and settings) so you can relaunch the same stack quickly. It’s ideal for repeatable experiments or team workflows.
## Inference and APIs
### Do you support an OpenAI‑compatible API?
Yes. [Hivenet Inference Service](/documentation/inference-api/overview) provides managed, OpenAI-compatible endpoints. Use the endpoint URL, model name, and API key for Inference Service from your deployment’s connection details.
### Can I tune inference settings?
Choose a model and serving variant for your workload, then set its fixed replica count. Available settings depend on the model and variant. See [Models and variants](/documentation/inference-api/models-and-variants) and [Call your endpoint](/documentation/inference-api/call-your-endpoint).
## Networking and access
### How do I expose my service?
Enable the required **HTTPS**, **TCP**, or **UDP** connection option when creating your instance, then use the address in its connection details. Managed Inference Service deployments have their own endpoint URLs.
### Can I use SSH?
Yes. Wait for **Running**, which means the instance has responded over SSH, then use the username and SSH command shown in its connection details. An application inside the instance may still be starting. See [SSH configuration and host verification](/tutorials/more-guides/SSH-config-file-explained).
## Providers, regions, and reliability
### What provider options are available?
**Hive‑Certified providers** are available now, offering dedicated hardware and a **99.9% uptime SLA**. A broader **Spot** **Providers** tier for cost‑sensitive use cases is planned.
### How does Compute with Hivenet operate?
Hivenet runs on a **distributed cloud** backed by real devices and certified providers, rather than traditional centralized data centers. This design aims for efficiency and resilience.
## Security and data
### What are Hivenet‑Certified providers?
Hivenet‑Certified providers are audited hosts that run **dedicated machines** in controlled locations and agree to our security, privacy, and uptime standards (including a 99.9% uptime SLA).
### How are my workloads isolated from others?
Each instance runs in its own isolated environment with dedicated GPU and storage on the selected host. Certified providers operate single‑tenant machines per customer session to reduce cross‑tenant risk.
### Can a host or provider inspect my data?
No. Certified providers are **contractually prohibited** from inspecting user data or workload content. Operational telemetry (like health metrics) may be collected for reliability, but hosts can’t read your files, prompts, or model outputs.
### Do you encrypt data in transit and at rest?
* **In transit:** Public endpoints (e.g., inference over HTTPS) enforce TLS. Use HTTPS clients by default.
* **At rest:** Storage lives on NVMe disks attached to the host. If you need strong, documented guarantees, use **application‑level encryption** or self‑encrypting volumes and contact support for current provider‑level controls and attestations.
Never store long‑lived secrets unencrypted on disk. Prefer environment variables, short‑lived tokens, or a secrets manager you control.
### How should I handle secrets (API keys, tokens) on instances?
Use environment variables or mounted files with restricted permissions, rotate keys regularly, and avoid committing secrets to images or templates. For team workflows, script secret injection at start‑up rather than baking credentials into templates.
### Do you log or store prompts/model inputs by default?
Compute records VM serial-console output, which Support can review for boot and crash troubleshooting. Data your software writes to that console can therefore appear in support diagnostics. Avoid writing secrets or sensitive payloads there, and contact Support if you need details about log access or retention.
### Can my data stay in a specific country or region (e.g., EU)?
Yes. Pick a **region** when launching. Runs and attached storage remain in that region. For compliance reviews, document your chosen region(s) in your internal data maps.
### What security documentation can you share (e.g., GDPR posture, audits)?
We can provide current security and privacy docs on request. If you require formal certifications or DPAs, contact support, and we’ll share what’s available under the appropriate terms.
### What happens to my data after termination—any data remanence guarantees?
Terminating an instance ends the session and detaches its storage. For sensitive projects, store data in encrypted volumes you control and wipe/rotate credentials at the end of a run.
### How do I report a security issue or incident?
Click on **Chat with us** in your dashboard or email [**support@hivenet.com**](mailto:support@hivenet.com) with "Security" in the subject. Include affected instance IDs, region, timestamps (UTC), and a short description. For urgent outages, also [post in the community channel](https://discord.com/cTmPDPrMG2) for faster visibility.
* Choose a **Hivenet‑Certified provider** and select the correct **region** (e.g., EU) before launch.
* Expose only what you need: prefer **HTTPS**; close unused TCP/UDP ports.
* Use **SSH keys** (no passwords), rotate keys regularly, and restrict user access.
* Treat disks as untrusted: use **application‑level encryption** for sensitive data.
* Inject **secrets at start‑up** (env vars or mounted files with tight permissions); don’t bake them into templates.
* Keep logs minimal and **ship them to your own system** (SIEM, object storage) with retention controls.
* Enable **auto top‑up** to prevent balance‑related termination during critical runs.
* On teardown, **revoke tokens/keys** and remove any temporary credentials.
* Read **Security at Hivenet** (architecture, provider standards, isolation): [https://compute.hivenet.com/security-page](https://compute.hivenet.com/security-page)
* Request current **Terms of Service**, **SLA/uptime**, and any available **security attestations/DPAs** via [**support@hivenet.com**](mailto:support@hivenet.com).
* Document chosen **region(s)** and provider tier (Certified vs cost‑focused) in your data map.
* We can provide clarifications on **data flow**, **incident response**, and **regional residency** upon request.
## GPUs and performance
### Which GPUs can I rent?
Compute currently offers **NVIDIA RTX 5090** GPU instances. Each RTX 5090 provides 32 GB of GDDR7 VRAM. Multi-GPU configurations are available when capacity allows.
The RTX 4090 fleet has been retired and is no longer available for new Compute workloads.
Availability and preset specifications can vary by location, so check the creation screen for the GPU count, vCPU, RAM, disk, bandwidth, and price you can launch now. See [GPU types and sizes](/documentation/reference/gpu-types) for more guidance.
### Where can I find GPU performance comparisons?
Our older benchmark articles include results from hardware that was available when the tests were run, including RTX 4090 systems. Keep the publication date and tested configuration in mind when using those results to compare performance.
For current workload planning, use the hardware and pricing shown in the Compute console.
## Support
### Where can I get help?
Join our [**Discord community**](https://discord.com/cTmPDPrMG2) or contact **support** from the console. For pricing or account issues, use the **Billing** tab.
## Troubleshooting
### My instance was terminated unexpectedly
Check the organization balance and whether the instance had been stopped for more than 10 days. If neither explains the termination, contact Support with the instance ID and approximate time. Cleanup protections do not replace backups or change the documented retention limits.
### I can’t connect to my inference server
Make sure networking is **enabled** and the correct **protocol** (HTTPS/TCP/UDP) is open. Confirm the **endpoint URL**, your **API key** or headers, and that your balance is sufficient.
### SSH fails to connect
Confirm the instance is **Running**, copy its current SSH hostname and username from the console, use the matching private key, and check that your network allows outbound port 22. Verify host-identity warnings before accepting a changed identity.
## See also
* [Get started with Hivenet Inference Service](/documentation/inference-api/get-started)
* [Create and reuse custom templates](/documentation/essentials/custom-templates)
* [Stop/Start instances: how it works](/documentation/essentials/start-stop-instances)
* [Pricing and billing](/documentation/account-billing/billing-info)
* [Historical benchmark: RTX 4090/5090 vs A100](https://compute.hivenet.com/post/rtx-4090-and-5090s---up-to-2-3x-faster-than-an-a100)
> **Feedback**
Did we miss something? Use the **Suggest edits** button in the docs or ping us on Discord. We review FAQ suggestions regularly.
# Glossary
Source: https://docs.hivenet.com/documentation/reference/glossary
Alphabetical glossary of Compute with Hivenet terms, from instance and vLLM to SSH, SFTP, and vCPU, with short plain-English definitions.
*Last updated: 17 September 2025*
Use your browser’s find (Ctrl/Cmd + F) to jump to a term.
## A
**auto top‑up** — An optional setting that adds prepaid credits when your balance drops below a threshold.
## B
**benchmark** — A measurement that compares performance (e.g., tokens/sec for inference or throughput on GPUs).
**billing (per‑second)** — Compute with Hivenet charges while an instance is running, calculated per second.
## C
**Compute with Hivenet** — Hivenet’s compute platform for running workloads on GPUs/CPUs.
**Compute account (Hivenet)** — A separate account used only for Compute with Hivenet. Uses an organization balance and billing, separate from a general Hivenet account.
**concurrency (inference)** — How many requests your server can handle at the same time.
**context length** — The maximum number of tokens a model accepts in one request (prompt + response window).
**credits (prepaid)** — Funds you add in advance and spend across Hivenet services.
**custom template** — Your saved instance configuration (image, packages, ports, env) you can reuse.
## D
**delete account** — Permanently removes your Compute account and associated data after a grace period. Not the same as terminating an instance.
**distributed cloud** — Hivenet’s model that uses underutilized devices (not central data centers) to provide storage and compute.
## E
**egress** — Data that leaves Hivenet to the internet (downloads, API responses). May be subject to limits or fees depending on the feature.
**endpoint (HTTPS)** — The public URL where your running service is reachable over TLS.
**encryption at rest / in transit** — Protecting data stored on devices (at rest) and moving across networks (in transit).
## G
**GPU instance** — A container or a virtual machine with a dedicated GPU for your workload.
**GPU memory (VRAM)** — Memory on the GPU used to hold model weights, activations, and KV cache.
## H
**HTTPS** — Encrypted HTTP. All public endpoints on Compute are served over HTTPS by default.
**Hivenet ID** — The email you use to sign in. Also your owner identity for teams and access.
## I
**image (OS / container)** — The base software environment an instance boots with (e.g., Ubuntu or a CUDA image).
**inference (LLM)** — Running a trained model to generate outputs.
**Inference Service** — Hivenet’s managed service for serving supported open-weight models through dedicated API endpoints. Previously called Inference API. See the [Inference Service overview](/documentation/inference-api/overview).
**instance** — A running container or virtual machine on Compute. Billed while running; can be stopped or terminated.
**instance logs** — Console/application logs you can view or export for debugging or support.
**instance template** — A saved recipe for new instances (image, ports, startup commands, etc.). See **custom template**.
## K
**KV cache** — Key‑value cache used by LLM servers to speed up generation by reusing attention states.
## M
**memory fraction (vLLM)** — How much of the GPU VRAM the server is allowed to use.
**model (LLM)** — The neural network you run for inference, defined by name and weights.
## N
**network ports** — You can expose TCP/UDP ports on an instance. Limits apply. See instance networking.
## O
**on-demand instances** — Standard pricing. Start and stop whenever you need.
**organization (team)** — A shared workspace in Hivenet for multiple members, with separate billing and permissions.
## P
**prepaid credits** — See **credits**. Add funds in advance to control spend and enable features like auto top‑up.
**private key / public key (SSH)** — Credentials you use to securely connect to a running instance.
## Q
**quantization** — Techniques to reduce model precision (e.g., INT8/FP8) to fit in VRAM and improve throughput.
## R
**RAM (system memory)** — Memory on the instance’s CPU side. Separate from GPU VRAM.
**rate limits (API)** — Caps on how often you can call an endpoint within a window.
## S
**SSH** — Secure Shell. Use it to access your instance’s terminal.
**stop / start (instances)** — Stop pauses your instance and billing for compute; start brings it back. Data is kept temporarily while stopped; instances stopped for more than 10 days are automatically terminated.
**storage (instance)** — Local disk on the instance for your OS, packages, and temporary data. Not the same as Store.
## T
**temperature (LLM)** — Controls randomness of generated text. Higher values produce more diverse outputs.
**terminate (instance)** — Permanently ends an instance and erases its local storage. Different from **stop**.
**top‑k / top‑p (LLM)** — Decoding settings that limit the token selection space during generation.
## U
**UDP / TCP** — Transport protocols. TCP is connection‑oriented (APIs). UDP is connectionless (some services/tools).
**usage (billing)** — Your historical spend and activity for Store, Compute, and Send.
## V
**vCPU** — Virtual CPU cores available to your instance.
**vLLM** — An open‑source LLM serving engine optimized for throughput and memory efficiency.
**VRAM** — See **GPU memory**.
## W
**web console** — The browser UI for managing Hivenet services, billing, and settings.
***
# GPU types and sizes
Source: https://docs.hivenet.com/documentation/reference/gpu-types
Reference for the current Compute with Hivenet GPU fleet, including RTX 5090 memory, available multi-GPU sizes, and where to check live preset details.
Compute with Hivenet currently offers NVIDIA RTX 5090 GPU instances. Availability and the exact CPU, RAM, disk, bandwidth, and price attached to a GPU preset can vary by location and capacity.
## Current GPU family
* **NVIDIA RTX 5090** — 32 GB of GDDR7 VRAM per GPU
The RTX 4090 fleet has been retired and is no longer available for new Compute workloads.
The Compute console is the source of truth for the presets you can launch at that moment. It shows the GPU count, vCPU, system RAM, disk, bandwidth, location, availability, and active price before you create an instance.
## Multi-GPU instances
Compute can offer RTX 5090 configurations with multiple GPUs, up to 8 GPUs per instance when capacity is available.
Choose the GPU count based on the workload rather than assuming that more GPUs always make a single job faster.
* **1 GPU:** A good starting point for inference, image generation, development, and workloads that fit within 32 GB of VRAM.
* **Multiple GPUs:** Useful for workloads that explicitly support tensor parallelism, distributed training, multi-GPU rendering, or several jobs running in parallel.
VRAM is attached to each GPU. Applications do not automatically treat multiple GPUs as one larger shared memory pool. Your framework or model must support multi-GPU execution to use them together effectively.
## VRAM and system RAM
**VRAM** is memory on the GPU. It determines whether model weights, activations, image-generation pipelines, and other GPU data fit on a card.
**System RAM** is separate memory used by the operating system, runtime, data loaders, preprocessing steps, and CPU-side parts of your workload.
For example, one RTX 5090 provides 32 GB of VRAM. A four-GPU instance provides four GPUs with 32 GB each, but whether a workload can use all four depends on the software and how it distributes work.
## Choose a current preset
When you create an instance:
1. Select a location.
2. Choose **GPU** under the setup options.
3. Compare the presets currently available.
4. Check the GPU count, VRAM, vCPU, RAM, disk, bandwidth, and price shown in the console.
5. Choose the smallest configuration that comfortably fits the workload.
Start with the VRAM requirement. If the workload fits on one GPU, a larger GPU count may not help unless the software can use multiple GPUs or you want to run jobs in parallel.
For broader guidance, see [Understand and choose your Compute instance](/documentation/essentials/understand-choose-instance).
# Compute instance URLs and Bad Gateway errors
Source: https://docs.hivenet.com/documentation/troubleshooting/bad-gateway-errors
Troubleshoot Bad Gateway errors on Compute with Hivenet instance URLs, including common causes tied to instance status, ports, and app startup.
## What these URLs are
When you create a Compute instance, Hivenet generates a temporary web URL:
```text theme={null}
https://-8888..tenants.hivecompute.ai
```
UAE instances use an additional port at the end of the URL:\
\
https\://\-[8888.uae.tenants.hivecompute.ai:4443](http://8888.uae.tenants.hivecompute.ai:4443)
These are public links to help you access web interfaces like:
* Jupyter notebooks
* Fooocus
* Stable Diffusion UIs
* Dashboards running on port 8888
## Why you might see "Bad Gateway"
**Running** means the instance has responded over SSH. Your web application may still be starting or may not be listening on the expected port.
Seeing a Bad Gateway error usually means one of these:
* **Your app isn’t running yet**
* **The app is listening only on \*\*\*\***`localhost`, not on `0.0.0.0`
* **The app is running on the wrong port** (e.g. 7865 instead of 8888)
* **HTTPS rate limit issues** (rare, but happens with repeated rapid reloads)
## Quick fixes
Here’s how to troubleshoot:
1. **Make sure your app is up**
```text theme={null}
curl http://localhost:8888
```
You should see HTML or a JSON response, not a timeout or error.
2. **Check the port** Your app must run on port 8888 for the Hivenet URL to work.
3. **Update binding address** Some apps default to:
```text theme={null}
127.0.0.1:8888
```
You need:
```text theme={null}
0.0.0.0:8888
```
Add `--host 0.0.0.0` if you're launching the app from the command line.
4. **Restart the app if needed** After changing host or port configs.
## When in doubt, forward the port yourself
If you can’t get the public link working, use SSH port forwarding:
```text theme={null}
ssh -L 8888:localhost:8888 YOUR_SSH_USER@YOUR_SSH_HOST
```
Use the SSH username and hostname shown in the instance’s connection details. Keep any key or connection options from the console’s SSH command.
Then open [http://localhost:8888](http://localhost:8888) in your browser. This is usually more reliable.
# Fix certificate and HTTPS warnings on Compute
Source: https://docs.hivenet.com/documentation/troubleshooting/certificate-errors
Resolve certificate or HTTPS warnings on Compute with Hivenet caused by corporate firewalls, antivirus HTTPS scanning, or outdated system root certificates.
Sometimes a browser shows a certificate warning when you open the Compute console or API. This feels alarming, especially when everything worked fine the day before.
These errors almost always come from something on the user's network intercepting HTTPS traffic, like corporate firewalls, antivirus software, or SSL inspection tools that replace certificates during traffic scanning. The good news is that your data and our certificates are safe. The issue sits between your device and the internet.
Most cases come from corporate firewalls or antivirus programs that inspect encrypted traffic. They replace the real certificate with one of their own. Browsers react to this by warning you that the connection doesn’t match what they expected.
This page explains why it happens, how to confirm it, and how to fix it.
## What a valid certificate should look like
Compute uses certificates issued by Let’s Encrypt.
A correct certificate shows:
* **Issuer:** Let’s Encrypt (R12)
* **Root:** ISRG Root X1
* A valid, trusted status in the browser
If you see a different issuer (such as a company name or an antivirus vendor), your connection is being intercepted and rewritten locally.
## Quick checks
Start with simple tests to narrow down the issue.
### 1. Try a different network
Use mobile data or a home Wi-Fi connection.
If the warning disappears, the issue is caused by the corporate network or firewall.
### 2. Try a private/incognito window
This rules out browser extensions.
### 3. Restart the browser
A clean session can remove cached certificate states.
## Check the certificate in your browser
1. Open the page showing the warning.
2. Select the padlock icon in the address bar.
3. Open **Certificate** or **View certificate**.
4. Check the **Issuer** and **Root**.
If the issuer is **not** Let’s Encrypt, something on your network is intercepting SSL.
If the certificate issuer is unfamiliar or tied to a security appliance, do not proceed until the connection is trusted again.
## Common causes of certificate interception
The most frequent sources are:
* Corporate firewalls performing SSL inspection
* Antivirus software scanning encrypted traffic\
(Kaspersky, ESET, Avast, and similar tools)
* Security appliances configured to rewrite certificates
* Network security policies that intercept HTTPS by default
These systems act as a “man-in-the-middle” proxy and install their own certificate authority. Browsers detect the mismatch and show warnings.
## How to fix the issue
### For individual users
Check your antivirus settings for features such as:
* “HTTPS scanning”
* “SSL inspection”
* “Encrypted traffic scanning”
Disable these features or add exceptions for Hivenet domains:
* `*.hivenet.com`
* `console.hivecompute.ai`
* `api.hivecompute.ai`
* `*.tenants.hivecompute.ai`
### For corporate users
If you are on a managed network, contact your IT team and request that the above domains be whitelisted or excluded from SSL inspection.
Provide them with:
* A screenshot of the certificate details
* The exact domain you attempted to access
* The time of the error
* The expected certificate issuer (Let’s Encrypt / ISRG Root X1)
## When to contact Hivenet Support
If the certificate appears valid but you still cannot access the console or API, contact [**support@hivenet.com**](mailto:support@hivenet.com) with:
* The full error message
* Browser and operating system
* Whether the issue changes on a different network
* The certificate issuer as shown in the browser
* Any relevant screenshots
Support can confirm whether the issue is local or if something else needs investigation.
# How to get your instance ID
Source: https://docs.hivenet.com/documentation/troubleshooting/get-instance-id
Find and copy your Compute with Hivenet instance ID from the dashboard so you can reference it in support requests, API calls, and troubleshooting.
Sometimes support may ask you to share your instance ID. This unique identifier helps us quickly locate the instance you’re referring to. Here’s how to find it in the Hivenet console.
![Instance Hamburger Menu Pn]()
![Instance Details Pn]()
Your instance ID is not the same as the instance name. The name is chosen by you, while the ID is automatically generated and unique.
Do not confuse the instance ID with your **User ID** or **SSH key**. Support usually only needs the instance ID.
# Troubleshoot 'invalid SSH key' upload errors
Source: https://docs.hivenet.com/documentation/troubleshooting/invalid-SSH-key
Fix 'invalid SSH key' errors when adding your public key to Compute with Hivenet, including format, key type, and copy-paste mistakes to check.
## What causes this error?
When you paste an SSH key into the Compute dashboard and see “Invalid SSH key,” it usually means:
* You pasted the **private** key instead of the public key
* You copied only part of the public key or included extra spaces/line breaks
* Your key type isn’t recognized (e.g., an unsupported format)
1. Open your `.ssh` folder
2. Find the file ending in `.pub` (for example, `id_ed25519.pub` or `id_rsa.pub`).
3. Right‑click the `.pub` file → **Open with** → Notepad.
4. **Select and copy** the entire single line, starting with `ssh-ed25519` or `ssh-rsa` and ending with your email or comment.
Don’t open or copy the file without `.pub`. That’s your private key!
If you can’t find a `.pub` file or suspect it’s corrupted, create a fresh pair:
```
ssh-keygen -t ed25519 -C "your_email@example.com"
```
* Accept the default file location or give it a custom name (e.g., `id_hivenet`).
* When prompted, set a passphrase (optional but adds security).
Then repeat Step 1 with the new `.pub` file.
1. In the Compute dashboard, go to **Add SSH key**.
2. **Click inside** the SSH key field—avoid pasting into any other box.
3. **Paste** your copied public key in one go (Ctrl+V).
4. Click **Save** or **Add key**.
If you see line breaks or extra spaces, click inside the field and use backspace or delete.
## Common pitfalls
**Hidden newline characters:** Some editors add a newline at the end. Make sure the pasted text ends with your key comment, not an empty line.
\*\*Wrong key type: \*\*Compute supports `ssh-ed25519` and `ssh-rsa`. ECDSA keys may not work.
\*\*Mixing up accounts: \*\*If you have multiple keys, verify you copied the one linked to the current Compute account.
## Test your key locally (optional)
You can test that your key is valid by connecting to a known host (like GitHub):
```
ssh -T git@github.com
```
If GitHub accepts the key, it’s formatted correctly.
***
# Welcome to Hivenet Docs
Source: https://docs.hivenet.com/index
Start here for Hivenet technical documentation covering Compute, Hivenet Inference Service, organizations, billing, connectivity, and public APIs.
![Mainimagedocs]()
Use these docs to run GPU and CPU workloads with Compute, deploy managed model endpoints with Hivenet Inference Service, and work with the organization, billing, connectivity, and API features behind them. Start with the path that matches what you want to run.
Every Compute account operates within an **organization**. The organization controls its people, roles, resources, and shared credit balance. Your role determines which instances and billing controls you can access.
## Start here
Create a container or virtual machine, connect to it, and understand when charging begins.
Deploy a managed model endpoint, create an API key, and send your first OpenAI-compatible Chat Completions request.
Understand the Owner, Admin, and Member roles, shared credits, and resource visibility.
Understand managed endpoints, variants, replicas, API keys, regional capacity, and billing.
Work through each creation setting, review the price, and connect securely.
Decide whether a container or virtual machine fits your workload.
## Manage your Compute environment
Learn how the organization balance, billing roles, payments, and auto top-up work.
Check the live spend rate and identify which resources are contributing to it.
Pause an instance safely or remove it permanently when the work is complete.
Find the connection details and use SSH, Jupyter, or an enabled public endpoint.
Create reusable container configurations for repeated workloads.
Manage your SSH key, interface preferences, organization access, and account options.
## Build with the Compute API
Authenticate requests and manage existing instances programmatically.
Browse the available instance, region, and preset endpoints.
## Reference and troubleshooting
Compare the GPU configurations currently documented for Compute.
Review CPU-only configurations and available sizes.
Find answers about billing, instances, networking, security, and usage.
Start with instance identification, SSH issues, certificates, and gateway errors.
## Get help
Send Hivenet Support the details of an account, billing, or technical issue.
Check whether a known Hivenet service incident is in progress.
Ask questions and talk with other people using Hivenet.
# API changelog
Source: https://docs.hivenet.com/public-api/api-changelog
Track Compute API changes that may affect your integration, including new endpoints, request and response changes, authentication updates, and deprecations.
Use this page to track changes to the Compute API that may affect scripts, tools, or integrations.
## Current API version
Production base URL:
`https://api.hivecompute.ai/v1`
Staging base URL:
`https://staging-api.hivecompute.ai/v1`
The current release contains eight public endpoints. The endpoint reference shows the current request and response details.
## Latest changes
## API surface finalized for release
**Changed**
* Production base URL is now `https://api.hivecompute.ai/v1`.
* Staging is available at `https://staging-api.hivecompute.ai/v1`.
* Region values are `UAE`, `FR`, and `US`.
* Instance logs are returned newest first. `entries[0]` is the most recent line.
* Start, stop, and terminate can return `409 Conflict` with error code `CONFLICT` when the requested action conflicts with the current lifecycle state.
* `500` responses use the generic message `An internal error occurred.` Clients should use `error.code`, not `error.message`, for program logic.
* `429` responses include `Retry-After` and use the standard error envelope.
**Removed from this release**
* `POST /ssh-keys`
* `GET /ssh-keys/{id}`
SSH-key operations are not backed by the released public API and will return in a later release.
## Public API documentation prepared
Initial documentation covered instance lifecycle operations, logs, regions, presets, and planned SSH-key operations. The release surface was subsequently narrowed and finalized in the August update above.
## Current endpoints
* [`GET /instances`](/public-api/endpoints/list-instances)
* [`GET /instances/{id}`](/public-api/endpoints/get-instance)
* [`GET /instances/{id}/logs`](/public-api/endpoints/get-instance-logs)
* [`POST /instances/{id}/start`](/public-api/endpoints/start-instance)
* [`POST /instances/{id}/stop`](/public-api/endpoints/stop-instance)
* [`POST /instances/{id}/terminate`](/public-api/endpoints/terminate-instance)
* [`GET /regions`](/public-api/endpoints/list-regions)
* [`GET /presets`](/public-api/endpoints/list-presets)
## What counts as a breaking change
A breaking change may require you to update code that already works. Examples include removing an endpoint or field, changing a field type, changing authentication behavior, or making an existing request parameter required.
Don't rely on undocumented fields or behavior. Build integrations against the published API reference.
## How to stay compatible
* Use the versioned base URL shown in the docs.
* Build logic around documented fields and `error.code` values.
* Treat cursors as opaque.
* Respect `Retry-After` on `429` responses.
* Check instance state before retrying lifecycle actions.
* Review this changelog when integration behavior changes unexpectedly.
# Authenticate API requests
Source: https://docs.hivenet.com/public-api/authenticate-api-requests
Learn how to authenticate Compute API requests with a bearer token, where to generate API keys, and how to handle 401 and 403 responses in your integration.
The Compute API uses bearer-token authentication. Every request must include an API key in the `Authorization` header.
Treat API keys like passwords. Anyone with a valid key can act with the permissions of the account it belongs to.
## Get an API key
API keys are currently issued manually. Contact [support@hivenet.com](mailto:support@hivenet.com) to request one.
There is no public endpoint for creating, listing, rotating, or revoking API keys in this release. If a key needs to be replaced, contact Support.
## Send your key
Add the key to every request:
```bash theme={null}
curl --request GET \
--url "https://api.hivecompute.ai/v1/instances" \
--header "Authorization: Bearer YOUR_API_KEY" \
--header "Accept: application/json"
```
For local testing, you can store it in an environment variable:
```bash theme={null}
export HIVENET_API_KEY="YOUR_API_KEY"
```
Then reference it in requests:
```bash theme={null}
curl --request GET \
--url "https://api.hivecompute.ai/v1/instances" \
--header "Authorization: Bearer $HIVENET_API_KEY" \
--header "Accept: application/json"
```
Environment variables are convenient for local testing, but use your deployment environment's secret manager for production workloads.
## Understand access
Service access tokens stop working when the user they belong to is deleted.
An API key is scoped to the account it belongs to. It can only see and act on that account's instances. Regions and presets are shared catalogue data.
A successful [`GET /instances`](/public-api/endpoints/list-instances) response can contain an empty `data` array if the account has no matching instances.
## Common authentication errors
| Status | Code | What to check |
| :- | :- | :- |
| `401 Unauthorized` | `UNAUTHORIZED` | Make sure the `Authorization` header exists and uses `Bearer `. |
| `403 Forbidden` | `FORBIDDEN` | The resource exists, but the key's account cannot access it. |
| `404 Not Found` | `NOT_FOUND` | Check the resource ID. |
| `429 Too Many Requests` | `TOO_MANY_REQUESTS` | Wait for the number of seconds in `Retry-After` before retrying. |
## Keep API keys safe
* Don't commit API keys to source control.
* Don't put them in URLs or client-side code.
* Don't paste them into public issues, screenshots, or shared documents.
* Replace a key through Support if it may have been exposed.
## Next step
Continue with [Work with instances](/public-api/work-with-instances) to understand instance lifecycle actions.
# Get instance
Source: https://docs.hivenet.com/public-api/endpoints/get-instance
public-v1.yaml GET /instances/{id}
Returns the full detail of one of your instances.
# Get instance logs
Source: https://docs.hivenet.com/public-api/endpoints/get-instance-logs
public-v1.yaml GET /instances/{id}/logs
Returns recent console output from one of your instances, **newest
line first** (the same order as `kubectl logs --tail`). The window
reaches back at most 10 hours; older output is not retrievable through
this endpoint.
# List instances
Source: https://docs.hivenet.com/public-api/endpoints/list-instances
public-v1.yaml GET /instances
Returns a cursor-paginated list of your instances, newest first.
Only instances belonging to your account are returned. There is no way
to widen the result set to another account or organisation.
# List presets
Source: https://docs.hivenet.com/public-api/endpoints/list-presets
public-v1.yaml GET /presets
Returns a cursor-paginated list of the hardware configurations
instances can run on, with their hourly price.
A preset fixes the GPU model and count, CPU, memory and storage. The
same preset may be offered in several regions at different prices, so
filter by `region` when comparing.
# List regions
Source: https://docs.hivenet.com/public-api/endpoints/list-regions
public-v1.yaml GET /regions
Returns the region codes used across the API. Use a region's `name`
as the `region` filter on `GET /presets` and `GET /instances`.
The set is fixed — currently `UAE`, `FR` and `US` — and is returned in
full rather than paginated. It tells you which values the filters
accept, not which locations currently have capacity; use
`GET /presets` for what can actually be launched.
# Start instance
Source: https://docs.hivenet.com/public-api/endpoints/start-instance
public-v1.yaml POST /instances/{id}/start
Starts a stopped instance. The call returns as soon as the request is
accepted; the instance moves `STARTING → RUNNING` in the background, so
poll `GET /instances/{id}` to observe the transition.
Starting an already-running instance is accepted and changes nothing.
Returns `409` when the instance is `TERMINATING` or `TERMINATED`. A
terminated instance can never be started again.
# Stop instance
Source: https://docs.hivenet.com/public-api/endpoints/stop-instance
public-v1.yaml POST /instances/{id}/stop
Stops a running instance. The call returns as soon as the request is
accepted; the instance moves `STOPPING → STOPPED` in the background.
Storage is retained and the instance can be started again. Billing for
compute stops; storage may still be charged.
Stopping an already-stopped instance is accepted and changes nothing.
Returns `409` when the instance is `TERMINATING` or `TERMINATED`.
# Terminate instance
Source: https://docs.hivenet.com/public-api/endpoints/terminate-instance
public-v1.yaml POST /instances/{id}/terminate
Permanently destroys an instance and its storage.
**This cannot be undone.** The instance moves `TERMINATING → TERMINATED`
and can never be started again. Use `POST /instances/{id}/stop` if you
only want to pause billing.
Terminating one that is `STOPPING` is accepted; the stop does not have
to settle first.
Terminating one that is already `TERMINATING` is also accepted, and
re-issues the teardown. That is the way to recover a termination that
failed part-way. It is not a safe blind retry, though: once the
underlying resource is actually gone, a further call returns `500` until
the instance settles at `TERMINATED`. Poll `GET /instances/{id}` rather
than retrying on a timer.
Returns `409` only when the instance is already `TERMINATED`.
# Get started with the Compute API
Source: https://docs.hivenet.com/public-api/get-started-with-the-compute-api
Understand how the Compute API authenticates requests, what base URL to use, and where to find endpoint reference details for building integrations.
The Compute API lets you inspect and manage existing Compute resources programmatically instead of working only through the web console.
Use these guides to understand the main workflows, then use the API reference for exact endpoint details.
Use the guides for workflow context. Use the API reference for paths, parameters, schemas, and response details.
## Base URLs
Production:
`https://api.hivecompute.ai/v1`
Staging:
`https://staging-api.hivecompute.ai/v1`
For example, `GET /instances` becomes:
`https://api.hivecompute.ai/v1/instances`
## Authentication
Every request requires a bearer API key:
```text theme={null}
Authorization: Bearer
```
API keys are currently issued manually. Contact [support@hivenet.com](mailto:support@hivenet.com) to request one.
Keep API keys private. Don't paste them into public issues, shared documents, screenshots, or client-side code.
## Current API surface
This release contains eight public endpoints:
| Method | Endpoint | Use it to |
| :- | :- | :- |
| `GET` | [`/instances`](/public-api/endpoints/list-instances) | List your instances. |
| `GET` | [`/instances/{id}`](/public-api/endpoints/get-instance) | Get one instance. |
| `GET` | [`/instances/{id}/logs`](/public-api/endpoints/get-instance-logs) | Read recent logs. |
| `POST` | [`/instances/{id}/start`](/public-api/endpoints/start-instance) | Start a stopped instance. |
| `POST` | [`/instances/{id}/stop`](/public-api/endpoints/stop-instance) | Stop a running instance. |
| `POST` | [`/instances/{id}/terminate`](/public-api/endpoints/terminate-instance) | Permanently terminate an instance. |
| `GET` | [`/regions`](/public-api/endpoints/list-regions) | List supported region codes. |
| `GET` | [`/presets`](/public-api/endpoints/list-presets) | List hardware presets and pricing. |
SSH-key endpoints are not part of this release.
## Regions
The API uses these region values:
* `UAE`
* `FR`
* `US`
Use the value returned by [`GET /regions`](/public-api/endpoints/list-regions) when filtering instances or presets.
## How actions work
Start, stop, and terminate actions are asynchronous. The API can return before the instance reaches its final state.
Poll [`GET /instances/{id}`](/public-api/endpoints/get-instance) until the `status` field shows the state you expect.
Terminating an instance is permanent. A terminated instance can't be restarted, and its data is deleted.
## What you’ll need
* A Compute with Hivenet account
* An API key
* A terminal, API client, or tool that can send HTTP requests
* Access to the instance you want to inspect or manage
You don't need an SDK to get started. A `curl` request is enough.
## Where to go next
Start with [Make your first API request](/public-api/make-your-first-api-request), then use the endpoint reference for exact request and response details.
# Handle errors and rate limits
Source: https://docs.hivenet.com/public-api/handle-errors-and-rate-limits
Reference for Compute API error responses, HTTP status codes, retry guidance, and per-IP rate limits so your integration handles failures reliably.
The Compute API uses standard HTTP status codes and a consistent JSON error envelope.
## Error response format
Errors use this structure:
```json theme={null}
{
"error": {
"code": "NOT_FOUND",
"message": "Not found.",
"request_id": "3fa85f64-5717-4562-b3fc-2c963f66afa6"
}
}
```
| Field | What it means |
| :- | :- |
| `error.code` | Stable machine-readable error code. Use this in client logic. |
| `error.message` | Human-readable explanation. Don't branch on this text. |
| `error.request_id` | Identifies the request in Hivenet logs. Include it when contacting Support. |
Client logic should branch on `error.code`, never on `error.message`. Messages can change without changing the underlying error condition.
## Common error codes
| Status | Code | Meaning |
| :- | :- | :- |
| `400 Bad Request` | `VALIDATION_ERROR` | A parameter or request value is invalid. |
| `401 Unauthorized` | `UNAUTHORIZED` | The API key is missing or invalid. |
| `403 Forbidden` | `FORBIDDEN` | The resource exists but the account cannot access it. |
| `404 Not Found` | `NOT_FOUND` | The requested resource does not exist. |
| `409 Conflict` | `CONFLICT` | The action can't proceed in the current state, or a start request has insufficient credit. |
| `429 Too Many Requests` | `TOO_MANY_REQUESTS` | The rate limit was exceeded. |
| `500 Internal Server Error` | `INTERNAL_ERROR` | The server could not complete the request. |
| `503 Service Unavailable` | `INTERNAL_ERROR` | No host currently has enough capacity for the requested start operation. |
## Handle 409 conflicts
`409 Conflict` uses error code `CONFLICT`, but it can have more than one cause.
* **Start:** the instance is terminating or terminated, or the account does not have enough credit.
* **Stop:** the instance is terminating or terminated.
* **Terminate:** the instance is already terminated.
The error message does not distinguish these cases. Fetch the current instance state first. If a start request conflicts even though the instance can be started, check the account balance before retrying.
Call [`GET /instances/{id}`](/public-api/endpoints/get-instance).
Use the instance state to identify lifecycle conflicts. For start requests, also check whether the account has enough credit.
Wait for a valid state transition or add credit as needed before sending the action again.
## Handle rate limits
Rate limits apply per source IP address rather than per API key. Clients that share an egress IP also share the same request budget.
A `429 Too Many Requests` response includes a `Retry-After` header. Wait that many seconds before retrying.
```text theme={null}
Retry-After: 60
```
Don't pace requests against an assumed fixed limit. Treat the rate limit as subject to change and respond to `429` dynamically.
## Handle server errors
A `500` response uses the generic message:
```json theme={null}
{
"error": {
"code": "INTERNAL_ERROR",
"message": "An internal error occurred.",
"request_id": "3fa85f64-5717-4562-b3fc-2c963f66afa6"
}
}
```
The message is intentionally generic. Use `error.code` for program logic and keep `request_id` for troubleshooting.
For temporary server errors, retry after a short delay. If the problem continues, contact Support with the `request_id`.
## Handle temporary capacity errors
A start request can return `503 Service Unavailable` when no host currently has enough free capacity for the instance's preset. The body uses `INTERNAL_ERROR` rather than a separate capacity error code.
Retry with backoff, or choose a compatible preset in another region. This is a temporary capacity condition rather than a problem with the request itself.
## Retry safely
| Request type | Retry guidance |
| :- | :- |
| Read-only requests | Usually safe to retry after a short delay. |
| `400` | Fix the request before retrying. |
| `401` or `403` | Fix authentication or access before retrying. |
| `409` | Check the latest instance state and, for start requests, the account balance before retrying. |
| `429` | Wait for `Retry-After`. |
| `500` | Retry after a delay; contact Support if it persists. |
| `503` | Retry with backoff or choose a preset in another region. |
Before retrying a destructive action such as terminate, fetch the instance state and confirm the action is still needed.
## What to include when asking for help
Include:
* The endpoint and HTTP method
* The HTTP status
* `error.code`
* `error.request_id`
* A redacted request if useful
Never include your API key.
## Next step
Continue with [API changelog](/public-api/api-changelog) to track API changes.
# Make your first API request
Source: https://docs.hivenet.com/public-api/make-your-first-api-request
Send a read-only GET request to the Compute API to verify your API key, base URL, and JSON response handling before making state-changing calls.
Start with a read-only request before you try actions that change an instance.
This guide uses [`GET /instances`](/public-api/endpoints/list-instances) to confirm that your API key works, the base URL is correct, and your client can read a JSON response.
## Before you start
You’ll need:
* A Compute with Hivenet account
* An API key issued for that account
* A terminal or API client
Production base URL:
`https://api.hivecompute.ai/v1`
Staging base URL:
`https://staging-api.hivecompute.ai/v1`
Use the production URL for normal integrations. Use staging only when you specifically need to test against the staging API.
## Send a request
Store your key in an environment variable:
```bash theme={null}
export HIVENET_API_KEY="YOUR_API_KEY"
```
Send a `GET` request to `/instances`:
```bash theme={null}
curl --request GET \
--url "https://api.hivecompute.ai/v1/instances?size=10" \
--header "Authorization: Bearer $HIVENET_API_KEY" \
--header "Accept: application/json"
```
A successful request returns `200 OK` and a JSON response with a `data` array and pagination information.
```json theme={null}
{
"data": [
{
"instance_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"name": "my-training-run",
"status": "RUNNING",
"gpu_type": "RTX 5090",
"region": "france-2"
}
],
"pagination": {
"next": null,
"size": 10
}
}
```
An empty `data` array can still mean authentication succeeded. It may simply mean the account has no matching instances.
Region filters use codes such as `FR`, while the `region` field returned on an instance contains the datacenter location, such as `france-2`.
## Read the response
| Field | What it means |
| :- | :- |
| `data` | Instances returned by the request. |
| `instance_id` | The ID used for instance-specific requests. |
| `status` | The current lifecycle state. |
| `pagination.next` | Cursor for the next page, or `null` when there are no more pages. |
Save an `instance_id` if you want to test [`GET /instances/{id}`](/public-api/endpoints/get-instance) or [`GET /instances/{id}/logs`](/public-api/endpoints/get-instance-logs) next.
## Common first errors
| Status | Code | What to do |
| :- | :- | :- |
| `400` | `VALIDATION_ERROR` | Check query parameters and allowed values. |
| `401` | `UNAUTHORIZED` | Check the `Authorization` header and API key. |
| `429` | `TOO_MANY_REQUESTS` | Wait for the `Retry-After` value before retrying. |
Test authentication with read-only requests before using start, stop, or terminate actions.
## Next step
Continue with [Authenticate API requests](/public-api/authenticate-api-requests) for key-handling guidance.
# Use pagination and filters
Source: https://docs.hivenet.com/public-api/use-pagination-and-filters
Page through Compute API list results with cursor pagination and narrow responses using supported filter query parameters like status and region.
List endpoints can return more results than you want to handle in one response. Cursor pagination lets you move through those results safely, while filters narrow the result set.
Not every list endpoint supports the same filters. Use the endpoint reference for the exact parameters available on each endpoint.
## How cursor pagination works
A paginated response includes a `pagination` object:
```json theme={null}
{
"data": [],
"pagination": {
"next": "opaque-cursor",
"size": 20
}
}
```
If `pagination.next` contains a value, pass it back as the `cursor` query parameter. When it is `null`, you have reached the last page.
Cursors are opaque. Don't edit, parse, or construct them yourself.
## Request the first page
```bash theme={null}
curl --request GET \
--url "https://api.hivecompute.ai/v1/instances?size=20" \
--header "Authorization: Bearer $HIVENET_API_KEY" \
--header "Accept: application/json"
```
For `GET /instances`, `size` can be between `1` and `200`. The default is `50`.
## Request the next page
```bash theme={null}
curl --request GET \
--url "https://api.hivecompute.ai/v1/instances?size=20&cursor=opaque-cursor" \
--header "Authorization: Bearer $HIVENET_API_KEY" \
--header "Accept: application/json"
```
Keep using the latest `pagination.next` value until it becomes `null`.
## Filter instances
[`GET /instances`](/public-api/endpoints/list-instances) supports filters for:
| Filter | What it does |
| :- | :- |
| `status` | Filters by a lifecycle-status bucket. `running` also includes `CREATED`, `DEPLOYED`, and `STARTING`; `stopped` includes `STOPPING`; `terminated` includes `TERMINATING`; `errored` matches `ERRORED`. |
| `gpu_type` | Filters by GPU model. |
| `region` | Filters by region. |
| `date_range_begin` | Returns instances that started at or after a timestamp. |
| `date_range_end` | Returns instances that started at or before a timestamp. |
| `free_text_search` | Searches instance names and related searchable fields. |
The accepted region values are:
* `UAE`
* `FR`
* `US`
Example:
```bash theme={null}
curl --request GET \
--url "https://api.hivecompute.ai/v1/instances?status=running®ion=FR&size=20" \
--header "Authorization: Bearer $HIVENET_API_KEY" \
--header "Accept: application/json"
```
## Filter by date range
Date filters apply to `started_at`, not the time the instance record was created. An instance that has never started is excluded as soon as either date bound is used.
Use ISO 8601 timestamps in UTC:
```bash theme={null}
curl --request GET \
--url "https://api.hivecompute.ai/v1/instances?date_range_begin=2026-08-01T00:00:00Z&date_range_end=2026-08-10T23:59:59Z" \
--header "Authorization: Bearer $HIVENET_API_KEY" \
--header "Accept: application/json"
```
## Search by text
```bash theme={null}
curl --request GET \
--url "https://api.hivecompute.ai/v1/instances?free_text_search=training-run" \
--header "Authorization: Bearer $HIVENET_API_KEY" \
--header "Accept: application/json"
```
## List presets by region
[`GET /presets`](/public-api/endpoints/list-presets) is also cursor-paginated and can be filtered by supported catalogue fields such as region.
```bash theme={null}
curl --request GET \
--url "https://api.hivecompute.ai/v1/presets?region=FR&size=20" \
--header "Authorization: Bearer $HIVENET_API_KEY" \
--header "Accept: application/json"
```
## Common issues
| Issue | What to check |
| :- | :- |
| Response is empty | Remove filters one at a time and confirm the account has matching resources. |
| API returns `400` | Check parameter names, allowed values, and date formats. |
| Next page repeats results | Use the latest cursor returned by the previous response. |
| Cursor no longer works | Request a fresh first page and use the new cursor. |
## Next step
Continue with [Handle errors and rate limits](/public-api/handle-errors-and-rate-limits).
# Work with instances
Source: https://docs.hivenet.com/public-api/work-with-instances
Manage existing Compute instances through the API: list, inspect, read logs, and start, stop, or terminate them across their lifecycle statuses.
Instances are the main Compute resource exposed by the Compute API. You can list and inspect existing instances, read recent logs, and start, stop, or terminate them.
The Compute API does not create instances. Create new instances in the Compute console, then use the API to inspect or manage them.
## Instance lifecycle
Common lifecycle states include:
| Status | What it means |
| :- | :- |
| `CREATED` | The instance record exists but has not finished scheduling. |
| `DEPLOYED` | The instance has been scheduled on a host. |
| `STARTING` | The instance is booting. |
| `RUNNING` | The instance has responded over SSH. Applications inside it may still be starting. |
| `STOPPING` | Shutdown is in progress. |
| `STOPPED` | The instance is stopped and can be started again. |
| `ERRORED` | The instance entered an error state. |
| `TERMINATING` | Permanent termination is in progress. |
| `TERMINATED` | The instance has been permanently terminated. |
Start, stop, and terminate actions are asynchronous. Poll [`GET /instances/{id}`](/public-api/endpoints/get-instance) until the instance reaches the expected state.
## List instances
Use [`GET /instances`](/public-api/endpoints/list-instances):
```bash theme={null}
curl --request GET \
--url "https://api.hivecompute.ai/v1/instances?size=20" \
--header "Authorization: Bearer $HIVENET_API_KEY" \
--header "Accept: application/json"
```
The response includes a `data` array and pagination metadata.
```json theme={null}
{
"data": [
{
"instance_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"name": "my-training-run",
"status": "RUNNING",
"gpu_type": "RTX 5090",
"region": "france-2"
}
],
"pagination": {
"next": null,
"size": 20
}
}
```
## Filter instances
Supported filters include:
* `status`
* `gpu_type`
* `region`
* `date_range_begin`
* `date_range_end`
* `free_text_search`
* supported sort fields and direction
Use one of the accepted region values: `UAE`, `FR`, or `US`.
For exact allowed values and limits, use the [`GET /instances`](/public-api/endpoints/list-instances) reference.
## Get one instance
Use [`GET /instances/{id}`](/public-api/endpoints/get-instance) to read the current state of a specific instance.
```bash theme={null}
curl --request GET \
--url "https://api.hivecompute.ai/v1/instances/a1b2c3d4-e5f6-7890-abcd-ef1234567890" \
--header "Authorization: Bearer $HIVENET_API_KEY" \
--header "Accept: application/json"
```
## Start an instance
Use [`POST /instances/{id}/start`](/public-api/endpoints/start-instance) to start a stopped instance.
```bash theme={null}
curl --request POST \
--url "https://api.hivecompute.ai/v1/instances/a1b2c3d4-e5f6-7890-abcd-ef1234567890/start" \
--header "Authorization: Bearer $HIVENET_API_KEY" \
--header "Content-Type: application/json"
```
The start endpoint can return `409 Conflict` with error code `CONFLICT` if the instance is terminating or terminated, or if the account does not have enough credit to start it. Check the latest instance state first. If the instance state allows starting, check the account balance before retrying.
If no host currently has enough capacity for the instance's preset, start can return `503 Service Unavailable`. Retry with backoff or choose a preset in another region.
## Stop an instance
Use [`POST /instances/{id}/stop`](/public-api/endpoints/stop-instance) to stop a running instance without terminating it.
```bash theme={null}
curl --request POST \
--url "https://api.hivecompute.ai/v1/instances/a1b2c3d4-e5f6-7890-abcd-ef1234567890/stop" \
--header "Authorization: Bearer $HIVENET_API_KEY" \
--header "Content-Type: application/json"
```
Poll the instance until it reaches `STOPPED`. The stop endpoint returns `409 Conflict` with code `CONFLICT` if the instance is terminating or already terminated.
## Terminate an instance
Use [`POST /instances/{id}/terminate`](/public-api/endpoints/terminate-instance) to permanently terminate an instance.
Termination is irreversible. A terminated instance can't be restarted, and its data is deleted.
```bash theme={null}
curl --request POST \
--url "https://api.hivecompute.ai/v1/instances/a1b2c3d4-e5f6-7890-abcd-ef1234567890/terminate" \
--header "Authorization: Bearer $HIVENET_API_KEY" \
--header "Content-Type: application/json"
```
The terminate endpoint returns `409 Conflict` with code `CONFLICT` only when the instance is already `TERMINATED`. If it is `STOPPING` or `TERMINATING`, the request is accepted; poll the instance state instead of retrying blindly.
## Get instance logs
Use [`GET /instances/{id}/logs`](/public-api/endpoints/get-instance-logs) to fetch recent container output.
```bash theme={null}
curl --request GET \
--url "https://api.hivecompute.ai/v1/instances/a1b2c3d4-e5f6-7890-abcd-ef1234567890/logs?lines=100" \
--header "Authorization: Bearer $HIVENET_API_KEY" \
--header "Accept: application/json"
```
For VM boot or crash issues, contact Support with the instance ID and approximate failure time. Support can review VM serial-console logs; this endpoint documents recent container output.
Logs are returned **newest first**. `entries[0]` is the most recent line.
A shortened response looks like this:
```json theme={null}
{
"entries": [
{
"timestamp": "2026-08-10T10:02:15Z",
"line": "Training epoch 2/10 complete. Loss: 0.298"
},
{
"timestamp": "2026-08-10T10:01:00Z",
"line": "Training epoch 1/10 complete. Loss: 0.342"
}
],
"line_count": 2
}
```
## Suggested workflow
Call [`GET /instances`](/public-api/endpoints/list-instances) and find the instance you want to manage.
Call [`GET /instances/{id}`](/public-api/endpoints/get-instance) before sending a lifecycle action.
Start, stop, or terminate the instance.
Call `GET /instances/{id}` until the instance reaches the expected state.
## Next step
Continue with [Use pagination and filters](/public-api/use-pagination-and-filters).
# Compute quickstart
Source: https://docs.hivenet.com/quickstart
Create your first Compute container or virtual machine, pick hardware and connection settings, review costs, and connect from your organization.
This guide takes you from sign-in to a running Compute instance. You’ll confirm the organization you’re using, choose the resources and connection options, review the estimated cost, and connect when the instance is ready.
## What you’ll need
* A Compute account
* Access to a Compute organization
* Enough credits in the organization balance
* An SSH public key if you plan to connect over SSH
Only the organization **Owner** can add credits. Admins and Members should ask the Owner if the balance is too low to create an instance.
1. Open the [Compute console](https://console.hivecompute.ai/).
2. Sign in to your Compute account.
3. Check the organization shown in the upper-left corner.
Instances you create use that organization’s balance and permissions. If you belong to a shared organization, your role also determines which instances and billing information you can see.
Read [How organizations work in Compute](/documentation/organizations/how-organizations-work) if you’re unsure what the Owner, Admin, and Member roles can do.
1. Select **Create** from the left sidebar.
2. Choose a **Container** or **Virtual machine**.
Containers are suited to prepared images and application workloads. Virtual machines provide a full operating system when you need more control.
See [Choosing between a virtual machine and a container](/documentation/essentials/choosing-between-a-virtual-machine-and-a-container) for a fuller comparison.
1. Select an available location.
2. Choose **GPU** or **vCPU only**.
3. Select the resource profile and size that fit your workload.
The console shows the hardware, memory, disk, bandwidth, and active price for each available option. Sizes are filtered against host capacity, and presets with no available location are hidden. Availability updates as instances are created, but capacity can change before your launch completes.
For a container, select an available template or create a custom one. For a virtual machine, select the operating-system image you want to use.
Templates can include an operating system, drivers, libraries, and application tooling. Review the software details before continuing.
Choose how you’ll reach the instance:
* **SSH:** Use the public key saved to your Compute account, or edit it before creation.
* **HTTPS:** Enable secure browser or API access when your workload needs a public HTTPS endpoint.
* **TCP or UDP:** Enable the protocol when your application requires it.
* **Jupyter Notebook:** Enable it when the option is available and you want browser-based notebook access.
Review connection options carefully. Some settings cannot be changed after the instance is created.
1. Enter a name using the characters allowed by the console.
2. Review the location, hardware, template or OS, connection settings, and estimated cost.
3. Confirm that the organization balance can cover the instance.
If the console reports that more credits are needed, the Owner must add them before creation can continue.
Select the creation button shown for your resource type. The new instance appears under **Instances** while Compute prepares it.
The instance reaches **Running** after it responds over SSH, and charging begins at that point. Disk preparation and startup can take a few minutes. Applications inside the instance may need additional time to start.
Open the running instance and find its connection details.
For SSH, copy the command shown by the console and run it in your terminal. A typical command looks like this:
```bash theme={null}
ssh -i /path/to/private_key username@host
```
Use the username and host shown by the console, along with the private key that matches the public key supplied during creation. The username may differ from the image’s default user. If you enabled Jupyter Notebook or a public endpoint, use the link shown in the instance’s connectivity details.
* **Stop** the instance when you want to pause compute usage and continue later.
* **Terminate** it when you no longer need the instance or its local data.
Termination permanently deletes the instance and its local data. Download anything important first.
## Troubleshooting
### The creation button is unavailable
Check the warning in the review section. The organization may need more credits, or a required configuration may be incomplete. Only the Owner can add credits.
### SSH returns `Permission denied (publickey)`
Make sure that:
* The instance was created with the correct public key.
* Your SSH command uses the matching private key.
* The private-key file has restricted permissions where required.
* You are using the username shown in the instance’s connection details.
See the SSH-key guides for [Linux](/documentation/connectivity/ssh-key-linux), [macOS](/documentation/connectivity/ssh-key-macos), or [Windows](/documentation/connectivity/ssh-key-windows).
### You cannot reach an application or notebook
Confirm that the relevant HTTPS, TCP, UDP, or Jupyter option was enabled during creation. Then check the instance’s connectivity details and any firewall rules used by your application.
## Next steps
* Follow the detailed [first-instance guide](/documentation/essentials/create-instance).
* Learn how to [track organization spending](/documentation/account-billing/track-costs-real-time).
* Review how to [start and stop an instance](/documentation/essentials/start-stop-instances).
* Create [custom templates](/documentation/essentials/custom-templates) for repeatable environments.
* Learn to [manage existing instances through the Compute API](/public-api/get-started-with-the-compute-api). The API does not create new instances.
# Choose a Compute configuration for image generation
Source: https://docs.hivenet.com/tutorials/how-to/configuration-image-generation
Choose a Compute GPU configuration for Stable Diffusion, Flux, ComfyUI, Fooocus, and similar image-generation workloads based on VRAM and parallelism needs.
Image-generation workloads usually depend more on **VRAM** than raw GPU count. Start with enough GPU memory for the model and workflow, then add GPUs only when your software can use them or you want to run jobs in parallel.
Compute currently uses NVIDIA RTX 5090 GPUs with 32 GB of VRAM per GPU.
## A practical starting point
| Workload | Suggested starting point | Why |
| :- | :- | :- |
| Fooocus | 1 × RTX 5090 | One 32 GB GPU is enough for typical interactive generation workflows. |
| Stable Diffusion | 1 × RTX 5090 | Leaves room for larger models, higher resolutions, and extensions. |
| AUTOMATIC1111 or InvokeAI | 1 × RTX 5090 | Start with one GPU unless you have a workflow that explicitly supports multi-GPU execution. |
| ComfyUI | 1 × RTX 5090 | A strong default for larger graphs and image-generation pipelines that fit within 32 GB of VRAM. |
| Multiple independent jobs | 2 or more GPUs | Separate jobs can run on different GPUs when your setup assigns them explicitly. |
| Training or fine-tuning | Depends on the model | Memory requirements vary significantly. Check the training framework and model requirements before choosing a preset. |
Start with one GPU when the workload fits. A second GPU does not automatically make a single Stable Diffusion or ComfyUI job twice as fast.
## Check VRAM before adding GPUs
After starting the workload, monitor GPU memory with:
```bash theme={null}
nvidia-smi
```
If the job approaches the 32 GB VRAM limit, first check whether you can reduce memory use through the application itself. Depending on the tool, useful options can include a smaller model, lower resolution, smaller batch size, tiled processing, or memory-efficient attention.
If the workload genuinely needs more than one GPU, confirm that the application or framework supports distributing work across several cards.
Multiple GPUs have separate VRAM. Their memory is not automatically combined into one larger pool.
## When multiple GPUs help
Consider a multi-GPU instance when you:
* Run several image-generation jobs at the same time and can assign them to different GPUs.
* Use a training or fine-tuning framework with explicit distributed or multi-GPU support.
* Use rendering or compute software designed to scale across several GPUs.
* Have tested one GPU and know the workload can benefit from additional cards.
For ordinary interactive image generation, one RTX 5090 is usually the simpler place to start.
## Change configuration later
Compute does not resize an existing instance in place. To move to another GPU configuration:
1. Save any models, outputs, configuration files, or other data you need.
2. Stop or terminate the current instance as appropriate.
3. Create a new instance with the GPU preset you need.
4. Restore your files or reuse a custom template to rebuild the environment.
Terminating an instance permanently deletes its local data. Copy anything important somewhere safe before you terminate it.
## Check current availability
GPU presets depend on location and current capacity. The Compute creation screen shows the GPU count, vCPU, RAM, disk, bandwidth, availability, and active price for the presets you can launch now.
See [GPU types and sizes](/documentation/reference/gpu-types) for current fleet guidance.
# Expose a service from a Compute VM: SSH, HTTPS, TCP, and UDP
Source: https://docs.hivenet.com/tutorials/how-to/expose-a-service-from-a-compute-vm-ssh-https-tcp-and-udp
Compare the four connectivity options for Compute virtual machines—SSH, HTTPS, TCP, and UDP—and choose the right one for exposing your service.
This tutorial explains the four connectivity options you’ll see when you create a Compute virtual machine (VM): SSH, HTTPS, TCP, and UDP. You’ll learn what each one is for, what to enable, and the small set of checks that prevent most “it’s running but I can’t reach it” problems.
If you haven’t created a VM yet, start here [Launch and connect to your first Compute instance](/documentation/essentials/create-instance).\
If you’re still deciding between VM and container, read: [Choose instance type](/documentation/essentials/understand-choose-instance).
## Quick chooser
Use **SSH** when you want terminal access. It’s also the safest way to access a web UI during setup, because you can tunnel a port without exposing it publicly.
Use **HTTPS** when you want a browser-friendly URL to reach a web app. This is the usual choice for things like Jupyter, Gradio, or Streamlit when you want a public link.
Use **TCP** when you want inbound connections for a TCP service (most APIs, many databases, custom clients).
Use **UDP** when you need inbound connections for a UDP service (some game servers, streaming, realtime protocols).
One important constraint: connectivity settings are chosen during creation, and some options can’t be changed later. Plan your ports early if you know you’ll need them.
## Before you open anything: make your app reachable on the VM
Most connection issues come from one of these:
1. The app is listening on localhost only (127.0.0.1).
2. The app is listening on the wrong port.
3. The network protocol isn’t enabled in the Compute Connectivity settings.
Two simple checks from inside the VM are usually enough:
* Confirm your app is up from inside the VM:\
`curl http://localhost:`
* Make sure it’s listening on the right interface. For web apps, prefer binding to `0.0.0.0` so the network layer can reach it.
If you’re using the Hivenet browser URL for web apps, make sure you’re using the expected port and bind address. See: [Compute instance URLs and Bad Gateway errors](/documentation/troubleshooting/bad-gateway-errors).
## SSH: remote terminal access (and the safest way to test UIs)
SSH is your default way to administer a VM: install packages, run services, inspect logs, and keep long-running tasks alive (tmux helps).
### How to set it up
During VM creation, paste your SSH public key in the SSH section.
Then connect from your computer using the SSH command shown on the instance page, or use one of these OS guides:
[Connect to an instance from macOS](/documentation/connectivity/connect-instance-macos)\
[Connect to an instance from Windows](/documentation/connectivity/connect-instance-windows)
## SSH port forwarding (recommended for private access)
If your web UI is only meant for you, don’t make it public. Forward the port over SSH instead.
Example (local forwarding):
```text theme={null}
ssh -L 7865:localhost:7865 YOUR_SSH_USER@YOUR_SSH_HOST
```
Use the SSH username and hostname shown in the instance’s connection details. Keep any key or connection options from the console’s SSH command.
Then open `http://localhost:7865` in your browser.\\
Full walkthrough: [How to forward ports to reach your web app](/documentation/connectivity/forwards-ports)
## HTTPS: public browser access for web apps
HTTPS gives you a public URL to reach a web app running on your instance. This is the easiest way to share a demo link or access a UI without keeping an SSH tunnel open.
### What you need to do on the VM
Run your web app on the expected port and bind it so it’s reachable. If you use the default URL pattern, your app must run on port 8888 and bind to `0.0.0.0`.
If you see Bad Gateway, it usually means one of these is wrong: app isn’t running yet, it’s listening on localhost, or it’s on a different port. Use: [Compute instance URLs and Bad Gateway errors](/documentation/troubleshooting/bad-gateway-errors).
### A practical pattern for a quick test
If you just want to validate that HTTPS access works, you can run a simple server on port 8888 and bind to `0.0.0.0`.
Tutorial: [How to serve a simple HTTPS site on Compute with SSH port forwarding](/documentation/connectivity/https-site-ssh-port-forwarding)
## TCP: direct inbound connections for APIs and services
Enable TCP when you want inbound connections to a TCP service you’re running on the VM, such as:
* HTTP APIs (if you’re not using the HTTPS URL approach)
* custom model servers
* databases or internal services you explicitly want reachable
### How to use it
1. Enable TCP during creation under Connectivity.
2. Start your service on the VM and make sure it listens on the port you expect, and on an address reachable from outside (often `0.0.0.0`).
3. In the console, copy the generated endpoint details for that TCP service and connect from your client.
If you’re unsure whether the service is running, test it locally first with curl, then move outward.
## UDP: direct inbound connections for UDP services
Enable UDP when your application uses UDP and needs inbound traffic. This is less common for AI/ML, but it’s the right tool for UDP-native protocols.
### How to use it
The pattern is the same as TCP:
1. Enable UDP during creation under Connectivity.
2. Run the UDP service on the VM and bind it correctly.
3. Use the console’s generated endpoint details to connect.
## Security notes that save you from future pain
Open the smallest surface area you can.
* If you’re just testing a UI, use SSH port forwarding instead of a public endpoint.
* If you need public access, use HTTPS for web apps and add authentication in your app.
* Don’t expose admin dashboards, Docker APIs, or databases to the public internet unless you know exactly why you’re doing it.
If you’re on a strict network (corporate firewall, locked-down router) and things fail in odd ways, see: [Agent network and firewall basics](/documentation/connectivity/firewall-basics).
## Troubleshooting checklist
If you can’t connect:
* Confirm the instance is \*\*Running \*\*(not stopped).
* Confirm the right protocol is enabled (HTTPS/TCP/UDP).
* Confirm the app is actually running.
* Confirm the app is listening on the right port.
* Confirm it’s not bound only to localhost (use `0.0.0.0` when needed).
* If HTTPS shows Bad Gateway, use: \[[Compute instance URLs and Bad Gateway errors](/documentation/troubleshooting/bad-gateway-errors).
* If you’re trying to reach a local-only UI, skip public access and use: [How to forward ports to reach your web app](/documentation/connectivity/forwards-ports).
# How to install Docker on a Compute VM
Source: https://docs.hivenet.com/tutorials/how-to/install-docker
Launch a Compute virtual machine, connect over SSH, install Docker Engine on Ubuntu, Debian, or Fedora, and verify the daemon runs a hello-world container.
Docker is easiest when it runs on a normal Linux host. On Compute, that means using a virtual machine (VM). This tutorial walks you through launching a VM, connecting over SSH, installing Docker Engine, and verifying everything works.
If you don’t have a VM yet, start here: [Launch and connect to your first Compute instance](/documentation/essentials/create-instance). (This tutorial assumes you’re using a VM, not a container.)
## What you’ll need
* A Compute VM instance (Ubuntu, Debian, or Fedora)
* An SSH public key added when you created the VM
* SSH access from your computer
* A user account with sudo access on the VM
If you need an SSH key first, use one of these:\
[How to generate and add an SSH key on macOS](/documentation/connectivity/ssh-key-macos)\
[How to generate and add an SSH key on Windows](/documentation/connectivity/ssh-key-windows)\
[How to generate and add an SSH key on Linux](/documentation/connectivity/ssh-key-linux)
## Step 1 – Launch a VM
1. In the Compute console, select Create.
2. Choose Virtual machine.
3. Pick a location and your setup (GPU or vCPU).
4. Pick an OS (Ubuntu is usually the simplest choice if you don’t have a preference).
5. Under Connectivity, add your SSH public key.
6. Create the VM and wait until Status is Running.
## Step 2 – Connect over SSH
1. Go to Instances.
2. Open your VM and select Connectivity options.
3. Copy the SSH command and run it in your terminal.
## Step 3 – Install Docker Engine
These commands follow Docker’s official installation steps for each Linux distribution. If you’re on Ubuntu/Debian, we use the apt repository method. If you’re on Fedora, we use the rpm repository method.
### Choose your OS below and run the matching commands.
#### Ubuntu 24.04 LTS (recommended)
1. Remove conflicting packages (safe if they’re not installed):
```
sudo apt remove $(dpkg --get-selections docker.io docker-compose docker-compose-v2 docker-doc podman-docker containerd runc | cut -f1)
```
2. Add Docker’s GPG key and repository:
```
sudo apt update
sudo apt install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
sudo tee /etc/apt/sources.list.d/docker.sources <
* Sign in to your Hivenet account and go to the Compute dashboard.
* Click **Create new instance**.
* Select your desired resources (GPU, CPU, RAM, and storage).\
\_(You can start small—just make sure it fits your workload.)\_
* Under **Connectivity**, toggle on **Jupyter Lab Notebook**.
* Finalize your settings and launch the instance.
* Once your instance is running, look for the three-dot menu next to it.
* Select **Connectivity options**.
* Copy the **Notebook endpoint** URL.
* Paste the Notebook endpoint URL into a new browser tab.
* Your browser may show a security warning because of a self-signed certificate. This is normal—just confirm you want to proceed.
Most browsers let you click “Advanced” and then “Proceed anyway.”
* The Jupyter notebook interface will load in your browser.
* Create or upload a new notebook and start coding as usual.
* In Jupyter, you can open a **Terminal** tab to run command-line tasks. No need for SSH!
* This is perfect for quick file management or package installs right from your browser.
## What’s next?
* Remember to shut down your kernels and stop or terminate your instance when you’re done to avoid extra charges.
* For more tips on using Compute, see our [Getting Started with Compute](https://help.hivenet.com/en/articles/303638-launch-and-connect-to-your-first-compute-instance) guide.
# The SSH config file, known_hosts, and identity files
Source: https://docs.hivenet.com/tutorials/more-guides/SSH-config-file-explained
Understand what lives inside your .ssh folder, how known_hosts and identity files work, and how the SSH config file simplifies connecting to Compute instances.
## What is in your SSH folder?
Your SSH folder is usually `~/.ssh` on macOS and Linux, or `C:\Users\\.ssh` on Windows. It can contain:
* `id_ed25519` or `id_rsa`: your private key, which proves your identity.
* A matching `.pub` file: the public key you add to Compute.
* `known_hosts`: saved server identities and, when configured, trusted certificate authorities.
* `config`: optional connection settings for your instances.
## Use the instance's connection details
Wait for **Running**, then open the instance's SSH connection details in the Compute console. Running means the instance has responded over SSH; it does not guarantee that an application inside it has finished starting.
Copy the current hostname, username, and connection command. The instance has a stable SSH endpoint on port 22. Its login can use a configured username, so do not assume it is `ubuntu`.
A basic config entry looks like this:
```text theme={null}
Host hivenet
HostName YOUR_SSH_HOST
User YOUR_SSH_USER
IdentityFile ~/.ssh/id_ed25519
Port 22
```
Replace `YOUR_SSH_HOST` and `YOUR_SSH_USER` with the console values, and set `IdentityFile` to your matching private key. Include any additional settings supplied in the console's SSH configuration. Only add a proxy or jump-host setting if those instructions require one.
Connect with:
```bash theme={null}
ssh hivenet
```
Use a different Host alias for each instance.
## Verify the server identity
Compute instances present signed SSH host certificates. A host certificate identifies the server; your own SSH key identifies you. These are separate checks.
Certificate verification depends on your SSH client trusting the signing certificate authority. Use the SSH configuration supplied by Compute. If you need certificate-authority details that are not shown there, ask Support for the trusted configuration.
If your client asks you to accept a host identity, verify it using trusted information from Hivenet before accepting. Do not disable host checking to get past a warning.
### A saved host identity has changed
If you see `WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!`, stop and check that you are connecting to the hostname shown for the intended instance. A replaced instance can have a different identity, but the warning can also mean you reached an unexpected server.
After verifying the replacement identity with Hivenet, remove only the stale entry if needed:
```bash theme={null}
ssh-keygen -R YOUR_SSH_HOST
```
Reconnect and verify the new identity. Do not clear the entire `known_hosts` file.
## Keep your private key private
Upload only the `.pub` file contents to Compute. Never send your private key to Support or paste it into a web form.
# Choosing between GPU and vCPU instances
Source: https://docs.hivenet.com/tutorials/more-guides/choosing-between-cpu-gpu
Compare Compute with Hivenet GPU and vCPU instances, understand cost and performance trade-offs, and pick the right type for training or CPU workloads.
When creating a Compute instance, you can choose between GPU-powered and vCPU-only setups. Both work the same way in the console, but they’re built for different types of workloads.
This guide helps you decide which one fits your needs.
## The short answer
* **Choose a GPU** if you need parallel processing power for heavy workloads like AI, rendering, or simulations.
* **Choose a vCPU** if you’re running general-purpose applications, background tasks, or smaller workloads that don’t benefit from GPU acceleration.
## Key differences
| Feature | GPU instance | vCPU instance |
| - | - | - |
| Best for | Machine learning, inference, rendering, simulations | Web apps, APIs, CI/CD, databases, background jobs |
| Processing style | Parallel (many small cores at once) | Serial (fewer, faster cores) |
| Speed | Faster for math-heavy, parallel tasks | Smoother for general-purpose tasks |
| Cost per hour | Higher (specialized hardware) | Lower (cost-efficient) |
| Availability | Limited by GPU supply | Generally more available |
## When to use GPU instances
Pick a GPU instance if your workload depends on massive parallelism or requires specialized acceleration. Examples:
* Training or fine-tuning AI/ML models
* Running inference with frameworks like vLLM
* Video rendering and encoding
* Scientific modeling or simulations
* Any workload that runs faster with GPU acceleration
## When to use vCPU instances
Pick a vCPU instance if your workload doesn’t benefit from GPU acceleration. Examples:
* Hosting lightweight web servers or APIs
* Running development and test databases
* Automating builds and deployments (CI/CD pipelines)
* Running scripts and background jobs
* Always-on services that need to stay cost-efficient
## How to decide
Ask yourself two questions:
1. **Does my workload rely on parallel processing?**\
If yes → GPU is usually better.
2. **Do I need the lowest cost for general-purpose compute?**\
If yes → vCPU is the simpler and cheaper option.
You don’t need to commit forever. You can start with vCPUs for development and testing, then move to GPUs when you’re ready to train or deploy heavier workloads.
# Why Compute supports SFTP—not FTPS
Source: https://docs.hivenet.com/tutorials/more-guides/sftp-not-ftps
Understand why Compute with Hivenet supports SFTP instead of FTPS, how the two protocols differ, and how to adjust file-transfer workflows accordingly.
## FTPS vs. SFTP at a glance
| Feature | SFTP | FTPS |
| :- | :- | :- |
| Default port | 22 | 21 (control) / 990 (implicit) |
| Encryption layer | Built‑in (SSH) | TLS/SSL on top of FTP |
| Authentication | SSH keys or passwords | X.509 certs or passwords |
| Firewall friendly | ✅ Single port | 🚧 Multiple ports (control + data) |
| Supported on Compute | **Yes** | **No** |
## Why we chose SFTP
1. **Same key, same port** – Your SSH key doubles for file transfers; no extra credentials.
2. **No additional firewall rules** – Everything slips through port 22, even behind strict networks.
3. **End‑to‑end encryption** – Data and commands are encrypted by default.
\*\*Good to know: \*\*FTPS requires opening a range of data ports, which conflicts with Compute’s default security posture.
## Need an HTTPS upload instead?
Spin up a quick web server on port 8888 inside your instance:
```
python3 -m http.server 8888 --bind 0.0.0.0
```
Then open your instance URL:
```
https://-8888.tenants.hivecompute.ai
```
## Migrating scripts from FTPS to SFTP
| Old FTPS command | SFTP replacement |
| :- | :- |
| `curl --ftp-ssl -T file.zip ftp://user@host/` | `sftp user@host:~/upload <<< $'put file.zip'` |
| `lftp -u user,pass ftps://host` | `sftp user@host` then `put/get` |
For automated workflows, tools like `rsync` or `scp` provide shell‑friendly, encrypted transfers.
***
Still unsure? Drop into [Discord](https://discord.gg/cTmPDPrMG2) or open the chat widget—our team’s happy to help you switch over.