# Credit exhaustion policy
Source: https://docs.cloud.vessl.ai/admin/billing/credit-exhaustion-policy

How VESSL Cloud handles workspaces when your credits run out.

VESSL Cloud uses a **credit-based billing system**. You need an active credit balance to keep your workspaces running.

### When credits reach zero

* **All your running workspaces are paused immediately.**
* Paused workspaces enter a **24-hour grace period**.
* If you do not add credits within 24 hours, **your paused workspaces are automatically terminated**.
* After termination, **all workspace data is permanently deleted and cannot be recovered**, including:
  * Container state
  * Temporary storage

<Note>
  Data stored in **Cluster storage** or **Object storage** volumes is preserved separately from workspaces. However, from **2026-07-01**, storage access is restricted once your credits hit zero, and the data is retained for up to **30 days** before being deleted. Back up important data before your balance reaches zero. See [Storage pricing](/pricing/storage) for the underlying policy.
</Note>

<Warning>
  Back up important data to external storage before your workspaces are terminated. Terminated data cannot be recovered.
</Warning>

### Notifications

* You receive notifications **before** your credits are fully exhausted.
* VESSL Cloud sends additional alerts while workspaces are paused during the 24-hour grace period.

### Credit top-up, validity, and refunds

* Credits can be topped up with a **minimum purchase amount of \$20 USD**.
* Credits are **valid for 5 years** from the date of purchase, unless applicable law requires otherwise.
* **Credits are non-refundable**, except where refunds are required by applicable law.

### Preventing data loss

To avoid unintended data loss:

* **Back up important data to external storage** before credits are exhausted.
* Ensure your organization maintains sufficient credits for uninterrupted usage.

***

This policy is subject to the [**Terms & Conditions of VESSL**](/legal/msa).


# Credits
Source: https://docs.cloud.vessl.ai/admin/billing/credits

Top up credits, review credit charge history, and refunds.

Admins can top up credits and review charge history.

To access credits management:

1. In the sidebar, select **Settings**.
2. Select **Billing** under **Organization**.
3. Scroll to the **Credit history** section.

<Info>
  **Credit buffer policy**: VESSL Cloud provides a \$10 buffer that keeps workspaces running briefly after your balance reaches zero. Workspaces continue running until the buffer runs out. The buffer usage appears as a negative balance in the credit badge and is deducted from your next top-up.
</Info>

<Warning>
  **Credit exhaustion and termination**

  If your credit balance is exhausted beyond the buffer, running workspaces may be **terminated** to prevent further charges.

  * **Notification**: You will receive email alerts **every hour** starting **24 hours before** forced termination.
  * **Data loss**: Termination permanently deletes the workspace and its temporary data. Cluster storage and Object storage volumes are preserved.
  * **Action**: Please top up credits in advance to avoid service interruption and data loss.
</Warning>

For each entry, you can review usage breakdown, download invoices, and request refunds (with status tracking).

<div>
  <Frame>
    <img alt="Credit usage detail view with per-entry breakdown, invoice download, and refund request options" />
  </Frame>

  <small>Example: Credit usage detail</small>
</div>

<div>
  <Frame>
    <img alt="Credit charge history list with top-up dates, amounts, and refund status tracking" />
  </Frame>

  <small>Example: Credit charge history</small>
</div>


# Billing overview
Source: https://docs.cloud.vessl.ai/admin/billing/overview

Credit-based billing, at-a-glance balances, and spend rate visibility.

VESSL Cloud bills in credits (1 credit = USD 1.00). Admins can view org-wide balances, spend rates, and manage credits.

## Usage dashboard

The billing overview page provides a comprehensive view of your organization's credit usage and payment information.

<div>
  <Frame>
    <img alt="Billing overview page showing credit balance, registered card, and credit usage trends graph" />
  </Frame>

  <small>Example: Billing overview</small>
</div>

The dashboard includes:

* **Credits panel**: Displays your current credit balance, spend rate (hourly), and an **Add Credits** button to top up your account
* **Registered Card panel**: Shows your saved payment method (masked card number and expiration date) with an **Add Card** button to register a new payment method
* **Credit Usage Trends graph**: Visualizes credit usage over time with options to view trends by **Day**, **Week**, or **Month**. The graph shows current spending, prior spend, and current spending rate

## What admins can see

* Organization-level available credits and spend rate
* Charge credits using the top-up flow
* Manage payment methods (add/remove cards)
* Track org/team usage trends and download CSV reports

## Payment method registration

If you haven't registered a payment method or your credits are low, you'll see a banner prompting you to add a payment method or top up credits.

<div>
  <Frame>
    <img alt="Payment method registration banner on workspace page" />
  </Frame>

  <small>Example: Payment method registration banner</small>
</div>

## Access paths

* **Header credits badge**: Hover to view remaining credits and spend rate, then click to open **Credit usage history**
* **Billing page**: In the sidebar, select **Settings**, then select **Billing** under **Organization**

<div>
  <Frame>
    <img alt="Credit badge in the top navigation bar showing remaining credits and spend rate on hover" />
  </Frame>

  <small>Example: Credit header</small>
</div>

<Note>
  Spend rate includes currently running GPU resources. Paused workspaces contribute storage costs only.
</Note>

<Tip>
  For detailed spend trends and team-level cost breakdown, see the [Organization dashboard](../dashboard/overview).
</Tip>


# Payment methods
Source: https://docs.cloud.vessl.ai/admin/billing/payment-methods

Register cards for faster checkout and manage saved methods.

Admins can register frequently used cards for quick checkout. Saved cards can be updated or removed anytime.

<div>
  <Frame>
    <img alt="Payment method management page with saved card details and actions to update or remove" />
  </Frame>

  <small>Example: Credit payment method</small>
</div>


# Usage reports
Source: https://docs.cloud.vessl.ai/admin/billing/usage-reports

View org/team credit usage and export CSV.

Admins can review monthly credit usage across workloads and storage.

* Workload Usage: team-level trends over time
* Storage Usage: team-level storage usage trends
* Usage Report: consolidated table with export to CSV

<div>
  <Frame>
    <img alt="Workload and storage usage trends chart broken down by team over time" />
  </Frame>

  <small>Example: Usage trends</small>
</div>

<div>
  <Frame>
    <img alt="Consolidated usage report table with team and workload breakdown and CSV export option" />
  </Frame>

  <small>Example: Usage report</small>
</div>


# Cluster overview
Source: https://docs.cloud.vessl.ai/admin/cluster/overview

Clusters in VESSL Cloud.

Clusters are execution environments where VESSL Cloud schedules workspaces and allocates GPU/CPU resources. VESSL Cloud currently offers Managed clusters.

<Info>
  To create and manage Cluster storage volumes, see [Create a volume](/admin/storage/create-volume#create-cluster-storage-volume).
</Info>


# Monitor organization usage
Source: https://docs.cloud.vessl.ai/admin/dashboard/overview

Monitor GPU usage, spend trends, and team performance across your organization.

The Organization dashboard gives admins a comprehensive view of GPU utilization, spending, and workload health across the entire organization. To access the dashboard, select **Settings** in the sidebar, then select **Dashboard** under **Organization**.

<div>
  <Frame>
    <img alt="Organization dashboard showing summary cards, spend trend, team breakdown, and workloads" />
  </Frame>

  <small>Example: Organization dashboard</small>
</div>

## Summary cards

Four cards at the top provide an at-a-glance overview of organization-wide resource usage.

| Card | Description |
| - | - |
| **Running workloads** | Total number of running workloads across the organization |
| **GPUs in use** | Total GPUs currently allocated to running workspaces |
| **Organization GPU utilization** | GPU-weighted average utilization across all running workspaces, weighted by GPU count |
| **Organization spend rate** | Total hourly cost across all running workspaces (\$/hr) |

When idle workloads are detected, a banner appears showing the count of workloads with zero GPU activity for three or more hours.

<Info>
  A workload is considered idle when its GPU utilization remains at **0%** for **three consecutive hours**. Idle workloads display an `Idle (3hr)` badge.
</Info>

## Spend trend

The spend trend chart breaks down cost by team, displaying the organization total and each team as a separate line.

Chart lines:

* **All teams**: Total spend across all teams
* **Default**: The default-assigned team
* **Others**: Usage from other resources such as storage

<div>
  <Frame>
    <img alt="Spend trend chart with separate lines for all teams, the Default team, and other resources" />
  </Frame>

  <small>Example: Spend trend chart</small>
</div>

### Date range options

Click **Date range** to select a time period:

* **Last 24 hours**: Hourly granularity
* **Last 7 days**: Daily granularity
* **Last 30 days**: Daily granularity

You can also pick a custom date range by selecting start and end dates from the calendar UI.

The chart automatically adjusts the time granularity based on the selected range (hourly for up to three days, daily for up to six months, monthly beyond that).

## Team breakdown

The team breakdown table shows GPU usage and utilization by team. Click the expand arrow on any team row to drill down into individual users.

<div>
  <Frame>
    <img alt="Team breakdown table expanded to reveal per-user GPU count and average utilization" />
  </Frame>

  <small>Example: Team breakdown with user-level drill-down</small>
</div>

| Column | Description |
| - | - |
| **Team / User** | Team name (expandable) or user name (indented under team) |
| **GPUs in use** | GPU count for the team or user |
| **Avg Utilization** | One-day average GPU utilization weighted by GPU count. Workloads with 0% utilization for three or more consecutive hours are marked as Idle. |

You can sort by **Avg Utilization** and search for specific teams or users using the search box.

## Workloads

The workloads table lists all running workspaces with detailed metrics.

<div>
  <Frame>
    <img alt="Organization workloads table with team, user, and idle filters plus GPU utilization, VRAM, and spend rate columns" />
  </Frame>

  <small>Example: Workloads table</small>
</div>

### Filters

* **All teams**: Filter by a specific team
* **All users**: Filter by a specific user
* **Show idle only**: Toggle to display only idle workloads (GPU utilization at 0% for three or more hours)

### Table columns

| Column | Description |
| - | - |
| **Workload name** | Workspace name. Click to open the workspace detail page |
| **Team** | Team the workload belongs to |
| **User** | Owner of the workload |
| **GPU** | GPU type and count (for example, "A100-40GB x 2") |
| **GPU Utilization (1hr)** | One-hour average GPU utilization. Color-coded: green (**90%**+), orange (below **30%**), red (**0%** idle) |
| **VRAM** | Current VRAM usage out of total (for example, "10/80 GB") |
| **Runtime** | How long the workload has been running |
| **Spend rate** | Hourly cost (\$/hr) |

## Edge cases

| Scenario | Behavior |
| - | - |
| No running workloads | Summary cards show zero values; tables display empty states |
| No idle workloads | Idle workloads banner is hidden |
| Non-admin user | The **Organization** section, including **Dashboard**, is not visible under **Settings** |
| CPU-only workload | GPU columns show `CPU only`; VRAM shows a dash |

<Note>
  The Organization dashboard is read-only. To take action on a workload (for example, pause or edit), click the workload name to open its detail page.
</Note>

## See also

* [Organization overview](../organization/overview)
* [Billing overview](../billing/overview)
* [Home dashboard](../../member/dashboard/overview)


# Organization overview
Source: https://docs.cloud.vessl.ai/admin/organization/overview

Top-level unit for policies, volumes, billing, and team management.

Organizations are created at signup; the first user becomes Admin. To switch organizations, click your Organization name from the top navigation bar and select the Organization to manage. To open organization settings, select **Settings** in the sidebar and use the **Organization** menu. Admins manage members and teams, storage, and billing.

<Tip>
  You can belong to multiple teams and invite new members by email.
</Tip>

## Quick demo

<Tip>Use the demo below to see how to manage teams and members in the organization.</Tip>

<div>
  <iframe title="Navigate Admin Settings and View Storage, Billing, and Team Information" />
</div>

## What you can do

* Monitor GPU usage and spend across the organization from the **Dashboard**
* Manage members and teams: invite new members, create/delete teams, manage team-level permissions (coming soon)
* Manage storage: create Cluster storage and Object storage volumes, assign them to teams
* Billing: top up credits, view usage, manage payment methods
* SAML SSO: integrate your identity provider to manage organization sign-in; see [SAML SSO](/admin/organization/saml-sso)
* (Coming soon) Cluster management: register/deregister BYOC clusters; assign team access
* (Coming soon) Security & access control: org-level policies such as key expiration, invite policy

## Invite and team assignment

* Invite by email → user appears as Invited → becomes Active after verification
* You must assign at least one Team when inviting
* A member can belong to multiple Teams

## Billing details

* View remaining credits and spend rate
* Top up credits and manage saved payment methods
* Review org/team usage trends and export CSV reports
* Download invoices and request refunds
* (Coming soon) Team-level credit quotas

## Volumes and clusters

* Create Cluster storage and Object storage volumes, assign them to teams
* Expand capacity; reductions are not supported
* Manage clusters and cluster-bound storage

## Roles

| Role | Scope | Key permissions |
| - | - | - |
| Organization admin | Entire Organization | Manage members/teams/volumes/billing/(future) clusters; set policies |
| Member | Self & teams | Create/use workspaces; use team volumes; accept invites |

<Info>
  For details, see [Roles & permissions](/admin/roles-permissions).
</Info>

## See also

* [Dashboard](../dashboard/overview)
* [Teams](../teams/overview)
* [Volumes](../storage/overview)
* [Billing](../billing/overview)
* [Roles & permissions](../roles-permissions)


# SAML SSO
Source: https://docs.cloud.vessl.ai/admin/organization/saml-sso

Integrate your SAML 2.0 identity provider to manage organization membership.

Simplify organization membership by integrating your organization's identity provider (IdP) with VESSL Cloud through Security Assertion Markup Language (SAML) Single Sign-On (SSO). Once configured, members sign in to VESSL Cloud with the accounts they already use in your IdP.

## Prerequisites

VESSL Cloud integrates with any identity provider that supports the SAML 2.0 protocol. Commonly used providers include:

* [Microsoft Entra](https://www.microsoft.com/en-us/security/business/microsoft-entra) (formerly Azure Active Directory)
* [AWS IAM Identity Center](https://aws.amazon.com/iam/identity-center/)
* [Okta](https://okta.com)

Before you start, make sure that:

* You are an organization admin. Only admins can configure SAML SSO.
* SAML SSO is enabled for your organization. If the **SAML SSO** menu does not appear under **Settings**, contact [support@vessl.ai](mailto:support@vessl.ai).

<Note>
  - The Assertion Consumer Service (ACS) endpoint supports HTTP-POST bindings only.
  - IdP-initiated SSO and Single Logout (SLO) are not supported.
</Note>

## Find your SP configuration

In the sidebar, select **Settings**, then select **SAML SSO** under **Organization**.

<Frame>
  <img alt="SAML SSO settings page with SP Configuration URLs and an Add SAML SSO button" />
</Frame>

The **SP Configuration** section shows the two service provider (SP) URLs your identity provider needs. Both URLs are unique to your organization, so copy them directly from this page:

* **VESSL Cloud's metadata**: the SAML Entity ID, also called the metadata URL. Opening this URL serves the raw metadata XML, which some identity providers require during configuration.
* **SAML ACS URL**: the endpoint that receives SAML responses from your identity provider.

## Configure your identity provider

Choose the setup instructions that match your identity provider.

<Tabs>
  <Tab title="Microsoft Entra">
    <Steps>
      <Step title="Sign in to Microsoft Entra">
        Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com).
      </Step>

      <Step title="Create the VESSL Cloud application">
        Navigate to **Enterprise applications** using the search bar.

        <Frame>
          <img alt="Microsoft Entra search bar showing the Enterprise applications service" />
        </Frame>

        Click **+ New Application**, then select **+ Create your own application**.

        <Frame>
          <img alt="Enterprise applications page with the New application button highlighted" />
        </Frame>

        Enter an application name like `VESSL Cloud`, select **Non-gallery** application, and click **Create**.

        <Frame>
          <img alt="Create your own application panel with the non-gallery option selected" />
        </Frame>
      </Step>

      <Step title="Add users">
        After creating the application, you land on the **Overview** page. Click **1. Assign users and groups**, then select **+ Add user**.

        <Frame>
          <img alt="Entra application overview page with the assign users and groups step" />
        </Frame>

        Add the users who will use VESSL Cloud, then click **Assign**.
      </Step>

      <Step title="Set up SAML SSO">
        Return to the **Overview** page and click **2. Set up single sign-on**. Select **SAML** as the sign-on method.

        <Frame>
          <img alt="Single sign-on method selection page with SAML highlighted" />
        </Frame>

        In **Basic SAML Configuration** (Section 1), set **Identifier (Entity ID)** to the **VESSL Cloud's metadata** URL and **Reply URL** to the **SAML ACS URL** from [Find your SP configuration](#find-your-sp-configuration), then click **Save**.
      </Step>

      <Step title="Copy the metadata URL">
        Copy the **App Federation Metadata URL** from Section 3. You will paste it into VESSL Cloud in the next section.

        <Frame>
          <img alt="SAML certificates section showing the app federation metadata URL" />
        </Frame>
      </Step>
    </Steps>
  </Tab>

  <Tab title="AWS IAM Identity Center">
    <Steps>
      <Step title="Open Applications">
        In the AWS console, go to **IAM Identity Center** → **Applications**, then click **Add application**.

        <Frame>
          <img alt="IAM Identity Center applications page with the add application button" />
        </Frame>
      </Step>

      <Step title="Choose the application type">
        Select **I have an application I want to set up**, then choose **SAML 2.0**.

        <Frame>
          <img alt="Application type selection with SAML 2.0 chosen" />
        </Frame>
      </Step>

      <Step title="Configure the application">
        On the configuration page, set a recognizable **Display name** (for example, `VESSL Cloud`). **Download** the **IAM Identity Center SAML metadata file**; you will paste its contents into VESSL Cloud later.

        In **Application metadata**, choose **Manually type your metadata values** and fill in the fields using the URLs from [Find your SP configuration](#find-your-sp-configuration):

        | Field | Value |
        | - | - |
        | Application ACS URL | The **SAML ACS URL** |
        | Application SAML audience | The **VESSL Cloud's metadata** URL |

        <Frame>
          <img alt="Application configuration page with display name and metadata sections" />
        </Frame>
      </Step>

      <Step title="Edit attribute mappings">
        From the application detail page, go to **Actions** → **Edit attribute mappings**.

        <Frame>
          <img alt="Application actions menu with edit attribute mappings selected" />
        </Frame>

        Enter the mappings as follows:

        | User attribute | Maps to this string value | Format |
        | - | - | - |
        | `Subject` | `${user:email}` | transient |
        | `email` | `${user:email}` | basic |
        | `username` | `${user:email}` | basic |

        <Frame>
          <img alt="Attribute mappings table with subject, email, and username rows" />
        </Frame>
      </Step>
    </Steps>

    <Tip>
      After finishing the IdP setup, use `username` for **IdP User ID** and `email` for **IdP User email attribute** in VESSL Cloud. See [IdP attribute reference](#idp-attribute-reference).
    </Tip>
  </Tab>

  <Tab title="Okta">
    <Steps>
      <Step title="Sign in to Okta">
        Sign in to your Okta organization with an administrator account.
      </Step>

      <Step title="Create the VESSL Cloud application">
        In the admin console, go to **Applications** → **Applications**, then click **Create App Integration**.

        <Frame>
          <img alt="Okta applications page with the create app integration button" />
        </Frame>

        Choose **SAML 2.0** as the sign-on method, then click **Next**. Enter an app name like `VESSL Cloud`, then click **Next**.

        <Frame>
          <img alt="Okta app integration wizard with the SAML 2.0 option selected" />
        </Frame>
      </Step>

      <Step title="Set up SAML SSO">
        Fill in the required fields using the URLs from [Find your SP configuration](#find-your-sp-configuration):

        | Field | Value |
        | - | - |
        | Single sign-on URL | The **SAML ACS URL** |
        | Audience URI (SP Entity ID) | The **VESSL Cloud's metadata** URL |

        Under **Attribute Statements**, configure the following attributes:

        | Name | Name format | Value |
        | - | - | - |
        | `user.email` | `Unspecified` | `user.email` |
        | `user.login` | `Unspecified` | `user.login` |

        <Frame>
          <img alt="Okta attribute statements table with user email and user login rows" />
        </Frame>

        Click **Next**, then click **Finish** to create the application.
      </Step>

      <Step title="Add users">
        On the app settings page, go to **Assignments**. Select **Assign** → **Assign to People** to add the users who will use VESSL Cloud.

        <Frame>
          <img alt="Okta assignments tab with the assign to people option" />
        </Frame>
      </Step>

      <Step title="Copy the metadata URL">
        Navigate to the **Sign On** tab. In the **SAML 2.0** section, copy the **Metadata URL**. You will paste it into VESSL Cloud in the next section.

        <Frame>
          <img alt="Okta sign on tab showing the SAML metadata URL" />
        </Frame>
      </Step>
    </Steps>
  </Tab>

  <Tab title="Custom identity provider">
    <Steps>
      <Step title="Provide the required information">
        Access your identity provider's admin console and register VESSL Cloud using the URLs from [Find your SP configuration](#find-your-sp-configuration).
      </Step>

      <Step title="Copy the metadata URL or XML">
        After completing the setup, copy the metadata URL or XML provided by your identity provider. You will paste it into VESSL Cloud in the next section.
      </Step>
    </Steps>
  </Tab>
</Tabs>

## Configure VESSL Cloud

After setting up your identity provider, register its metadata in VESSL Cloud.

<Steps>
  <Step title="Open SAML SSO settings">
    In the sidebar, select **Settings**, then select **SAML SSO** under **Organization**.
  </Step>

  <Step title="Add SAML SSO">
    In the **IdP Configuration** section, click **Add SAML SSO**.
  </Step>

  <Step title="Enter the IdP metadata">
    In **Metadata XML**, choose **XML** to paste the metadata XML, or choose **URL** to enter the metadata URL you copied from your identity provider.

    <Frame>
      <img alt="IdP Configuration form with metadata XML, IdP user ID, and IdP user email attribute fields" />
    </Frame>
  </Step>

  <Step title="Enter the attribute names">
    Fill in **IdP User ID** and **IdP User email attribute** with the attribute names your identity provider uses in its SAML response. The correct values depend on your provider; see [IdP attribute reference](#idp-attribute-reference).
  </Step>

  <Step title="Save the configuration">
    Click **Save**. A confirmation appears when SAML SSO is configured. If saving fails with a `Failed to configure SAML SSO` error that mentions `invalid IdP metadata`, the metadata could not be parsed. Check that you pasted the complete metadata XML or entered the correct metadata URL, then try again.
  </Step>
</Steps>

<Warning>
  Saving enforces SAML SSO for the organization: members must sign in through your identity provider to access it, and sessions signed in with other methods lose access. The session you used to save the configuration switches to an SSO session automatically, so you stay signed in.
</Warning>

## Sign in with SAML SSO

Once SAML SSO is configured, members sign in to the organization through your identity provider:

<Steps>
  <Step title="Start SSO sign-in">
    On the VESSL Cloud sign-in page, click **Continue with SAML SSO**.
  </Step>

  <Step title="Enter your organization name">
    Enter your organization name in **Organization name** and submit. You are redirected to your identity provider.
  </Step>

  <Step title="Authenticate with your identity provider">
    Complete the sign-in at your identity provider. You are then redirected back to your organization.
  </Step>
</Steps>

SSO sign-in resolves organization membership as follows:

* A user without a VESSL Cloud account gets an account created and joins your organization automatically on their first SSO sign-in.
* An existing member of your organization signs in as usual.
* A user who already has a VESSL Cloud account but is not a member of your organization cannot sign in with SSO. Invite them to the organization first; see [Invite a member](/admin/teams/invite-member).

<Tip>
  SSO works for CLI sign-in too: `vesslctl auth login` signs in through the browser by default, where members can continue with SAML SSO.
</Tip>

## IdP attribute reference

Identity providers use attributes in the SAML response to pass each user's ID and email. VESSL Cloud looks up these values using the attribute names you enter in **IdP User ID** and **IdP User email attribute**, so the names must match your identity provider's configuration exactly.

Refer to the values below for your provider:

<Tabs>
  <Tab title="Microsoft Entra">
    | Field | Attribute name |
    | - | - |
    | IdP User ID | `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name` |
    | IdP User email attribute | `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress` |
  </Tab>

  <Tab title="AWS IAM Identity Center">
    | Field | Attribute name |
    | - | - |
    | IdP User ID | `username` |
    | IdP User email attribute | `email` |
  </Tab>

  <Tab title="Okta">
    The values below assume you followed the Okta setup guide on this page. If you use a custom configuration, adapt them accordingly.

    | Field | Attribute name |
    | - | - |
    | IdP User ID | `user.login` |
    | IdP User email attribute | `user.email` |
  </Tab>

  <Tab title="Custom identity provider">
    Refer to your identity provider's documentation to identify the attribute names for user ID and user email. If needed, consult your IdP administrator to confirm the configuration.
  </Tab>
</Tabs>

## See also

* [Organization overview](/admin/organization/overview)
* [Invite a member](/admin/teams/invite-member)


# Roles & permissions
Source: https://docs.cloud.vessl.ai/admin/roles-permissions

Admin vs Member responsibilities and scopes at the Organization level.

| Role | Scope | Key permissions |
| - | - | - |
| Org Admin | Organization-wide | Manage members/teams, storage (volumes), billing, policies, and (future) clusters |
| Member | Self & teams | Create/use workspaces, use team volumes, accept invites |

<Tip>
  One person can be both Admin and active user. Many orgs start with a single Admin who later invites teammates as Members.
</Tip>


# Manage secrets
Source: https://docs.cloud.vessl.ai/admin/secrets/overview

Update, rotate, and delete org-level secrets — the operations reserved for Organization admins.

Secrets are encrypted, organization-scoped credentials that any member can create and use in a batch job — see [Secrets](/member/settings/secrets) for what they are, how the encryption works, and how to create and inject them. This page covers the operations reserved for **Organization admin**: updating and deleting secrets.

## Permissions

| Operation | Who can perform it |
| - | - |
| Create | Anyone in the organization |
| View list and metadata | Anyone in the organization |
| Update (rotate value, rename key, edit description) | **Organization admin** only |
| Delete | **Organization admin** only |

There is no creator exception: a member can't update or delete a secret they created themselves. Members don't see the edit and delete controls on the secrets list — the row menu appears for admins only.

<div>
  <Frame>
    <img alt="Secrets page as an admin sees it, with a table of secrets and a row menu for editing and deleting each secret" />
  </Frame>

  <small>Example: Secrets page as an admin sees it — each row has an edit and delete menu</small>
</div>

<Tip>Watch a short demo of creating, editing, and deleting a secret on VESSL Cloud.</Tip>

<div>
  <iframe title="Create and Update a Secret on VESSL Cloud" />
</div>

## Update a secret

Rotate the value, rename the env-var key, or edit the description. Secret values are write-only: after a secret is saved, no one can view the value again, so rotation means overwriting it with a new value — the previous value can't be retrieved.

### GUI

1. In the sidebar, select **Settings**.
2. Select **Secrets** under **Account**.
3. Open the row menu on the secret and select **Edit**.
4. Edit the **Key** or enter a new **Value**, then save. Every key-value pair is overwritten in this secret. (The secret name is fixed; description editing is CLI-only.)

### CLI

```bash theme={null}
# Rotate the value (interactive prompt)
vesslctl secret update <slug>

# Rotate the value from an env var
vesslctl secret update <slug> --from-env NEW_HF_TOKEN

# Rename the env-var key (metadata-only, no value rotation)
vesslctl secret update <slug> --key NEW_KEY

# Edit the description
vesslctl secret update <slug> --description "Rotated 2026-05"
```

<Note>
  Running workloads do **not** pick up updated secret values automatically. Restart the workload to use the new value.
</Note>

## Delete a secret

### GUI

1. In the sidebar, select **Settings**.
2. Select **Secrets** under **Account**.
3. Open the row menu on the secret and select **Delete**.

### CLI

```bash theme={null}
# Delete (with confirmation)
vesslctl secret delete <slug>

# Delete without confirmation
vesslctl secret delete <slug> -y

# Include soft-deleted entries when listing
vesslctl secret list --include-deleted
```

Deletion is a **soft delete**: deleted secrets are kept for audit, and their names become available for reuse immediately.

## FAQ

<AccordionGroup>
  <Accordion title="Who can manage secrets?">
    Anyone in the organization can view secrets and create new ones. Updating or deleting a secret — including one the member created themselves — requires the **Organization admin** role, so members don't see the edit and delete controls on the secrets list.
  </Accordion>

  <Accordion title="Do running workloads see updated secret values?">
    No. Secrets are injected at container start. Restart the workload to pick up the new value.
  </Accordion>

  <Accordion title="Can I reuse a deleted secret's name?">
    Yes. Deleted secrets are soft-deleted, so the name becomes available immediately. Pass `--include-deleted` to `vesslctl secret list` to inspect the history.
  </Accordion>
</AccordionGroup>


# Create a volume
Source: https://docs.cloud.vessl.ai/admin/storage/create-volume

Create Cluster storage and Object storage volumes for your team.

Volumes are created from the **Volume** section of the sidebar and belong to the team you're working in. Both admins and members can create volumes.

## Create Object storage volume

<Info>
  Members can also create Object storage volumes directly. See [Create Object storage volume](/member/volume/create) for the member guide.
</Info>

To create an Object storage volume:

1. Click **Object storage** in the sidebar.
2. Click **Create new volume**.

<div>
  <Frame>
    <img alt="Object storage page in empty state with a Create new volume button" />
  </Frame>

  <small>Example: Object storage page</small>
</div>

| Setting | Description |
| - | - |
| **Volume name** | Name of the volume |
| **Description (Optional)** | Optional description |

There is no size to provision — Object storage is billed by actual usage, measured daily. Current rates are shown on the storage page header; see [Storage pricing](/pricing/storage) for details.

## Create Cluster storage volume

Cluster storage is provisioned per region by VESSL Cloud — you don't create the underlying storage yourself. Pick a region when creating a volume:

1. Click **Cluster storage** in the sidebar.
2. Click **Create new volume**.
3. Select a region and enter a **Volume name**.
4. Click **Create**.

<div>
  <Frame>
    <img alt="Cluster storage page with regions and a Create new volume button" />
  </Frame>

  <small>Example: Cluster storage page</small>
</div>

<Warning>
  Cluster storage volumes are bound to the region they're created in. When creating a workspace, you can only attach Cluster storage volumes from the same region as your selected GPU.
</Warning>

<Info>
  **Cluster storage pricing:** Billed at **\$0.20/GiB/month** based on actual usage, measured daily (effective 2026-07-01). You no longer need to pre-provision exact capacity — billing follows what you actually store. See [Storage pricing](/pricing/storage) for the latest rates.
</Info>

***

<Info>
  **Key differences:**

  * **Object storage**: S3-backed, accessible from any cluster. Best for cross-cluster data sharing.
  * **Cluster storage**: CephFS/NVMe, bound to one region's cluster. Best for fast, persistent storage within a cluster.
</Info>


# Storage overview
Source: https://docs.cloud.vessl.ai/admin/storage/overview

Manage Cluster storage and Object storage for your organization.

In the sidebar, select **Cluster storage** or **Object storage** under **Volume**. Each page shows all volumes of that type across your organization.

VESSL Cloud provides two types of persistent storage:

* **Cluster storage**: High-availability distributed storage (CephFS/NVMe) bound to a specific cluster. Shared across workspaces within the same cluster with RWX semantics. Data persists after workspace termination. See [Create Cluster storage volume](/admin/storage/create-volume#create-cluster-storage-volume) for setup.

* **Object storage**: POSIX-compatible, S3-backed remote storage for sharing data across teams and clusters. Both admins and members can create Object storage volumes. Admins can assign volumes to specific teams for broader collaboration.

<div>
  <Frame>
    <img alt="Admin Object storage overview listing all organization volumes" />
  </Frame>

  <small>Example: Object storage</small>
</div>

<div>
  <Frame>
    <img alt="Admin Cluster storage overview listing all organization storages and attached volumes" />
  </Frame>

  <small>Example: Cluster storage</small>
</div>

<Info>
  * **Cluster storage** uses distributed CephFS/NVMe within a cluster. Supports RWX (read-write-many) across workspaces in the same cluster. \~150 MB/s throughput.
  * **Object storage** is backed by S3 and accessible from any cluster. Supports RWX across all workspaces. \~150 MB/s throughput.
</Info>

See [Storage pricing](/pricing/storage) for current rates and the 2026-07-01 billing policy.


# Volume detail
Source: https://docs.cloud.vessl.ai/admin/storage/volume-detail

Inspect files, attached workspaces, and provide CLI guidance.

You can review volume files, see attached workspaces, and use short-lived credentials for CLI data management. Members can also access these features and delete volumes they created.

<div>
  <Frame>
    <img alt="Volume detail page with file list, attached workspaces, and CLI guide panel" />
  </Frame>

  <small>Example: Storage-VolumeDetails-Files on VESSL Cloud.</small>
</div>

<Card title="Manage volume data" icon="hard-drive" href="/member/volume/detail">
  Learn how to browse files, see attached workspaces, and use AWS CLI with temporary credentials to manage data.
</Card>

## Permissions

Volume access is controlled by team membership and organization roles.

### Who can view and use volumes

* **Organization admins**: Can view, update, and delete all volumes in the organization.
* **Team members**: Can view and use volumes that are assigned to teams they belong to.

### Who can update volumes

* **Organization admins**: Can update any volume, including changing the name, description, and team assignments.
* **Team members**: Can update volumes if they belong to at least one team assigned to the volume. When modifying team assignments:
  * You can add teams you belong to.
  * You can remove teams you belong to.
  * You cannot add or remove teams you do not belong to (admin only).

### Who can delete volumes

* **Organization admins**: Can delete any volume in the organization.
* **Team members**: Can delete volumes if they belong to at least one team assigned to the volume.
* **Unassigned volumes**: Volumes without any team assignments can only be deleted by organization admins.

## Delete volume

<Warning>
  Deleting a volume permanently removes all data. This action cannot be undone.
</Warning>

<Info>
  **Deletion restrictions:**

  * You cannot delete a volume while it is attached to active workspaces. Before deleting, you must stop or terminate all workspaces using this volume.
  * You must be an organization admin or a member of at least one team assigned to the volume.
  * This applies to both Object storage and Cluster storage volumes.
</Info>

<Tip>Watch the demo below to see the delete flow.</Tip>

<div>
  <iframe title="Delete a Storage Volume in VESSL Cloud" />
</div>

To delete a volume:

1. Go to the **Volume detail** page.
2. Click the **Delete** button.
3. Confirm the deletion by typing the volume name.


# Volume list
Source: https://docs.cloud.vessl.ai/admin/storage/volume-list

See all storage volumes and the overall storage summary.

The Volume list page shows org-wide summary (total capacity, number of volumes, monthly cost, accessible clusters) and a list of volumes with:

<div>
  <Frame>
    <img alt="Admin volume list with organization-wide storage summary and per-volume usage" />
  </Frame>

  <small>Example: Object storage volume list</small>
</div>

| Field | Description |
| - | - |
| Name | Volume name |
| Type | Storage type (Object storage or Cluster storage) |
| Usage | Current storage usage |
| Teams | Teams with access to this volume |
| Created by | User who created this volume |
| Cluster | Clusters where the volume can be mounted |
| Last accessed | Last time the volume was attached to a workspace |

<Info>
  Members also see this same volume list. For the member guide, see [View volumes](/member/volume/list).
</Info>


# Create a team
Source: https://docs.cloud.vessl.ai/admin/teams/create-team

Create a new team and set it as the default for your primary web console view.

Create teams to organize members and manage shared resources like storage volumes.

<Steps>
  <Step title="Open the Teams page">
    In the sidebar, select **Settings**, then select **Teams** under **Organization**.
  </Step>

  <Step title="Click Create team">
    Click the **Create team** button in the top right of the Teams page.
  </Step>

  <Step title="Fill in team details">
    <div>
      <Frame>
        <img alt="Create a new team dialog with team name and description fields" />
      </Frame>

      <small>Example: Create a new team</small>
    </div>

    1. Enter a **Team** name.
    2. (Optional) Add a **Description** to help identify the team's purpose.
    3. Click **Create** to finish.
  </Step>
</Steps>

<Tip>
  You can set a team as the default for your primary web console view. This helps streamline workflows by showing the most frequently used team's resources first.
</Tip>

<Info>
  After creating a team, you can:

  * Assign members to the team from the [Member list](/admin/teams/member-list) or [Invite member](/admin/teams/invite-member) page
  * Create and assign storage volumes for team collaboration
  * View team details in the [Team list](/admin/teams/team-list)
</Info>


# Invite a member
Source: https://docs.cloud.vessl.ai/admin/teams/invite-member

Invite users by email and assign them to at least one Team.

Invite users who are not part of your Organization yet.

To invite a member:

1. In the sidebar, select **Settings**.
2. Select **Members** under **Organization**.
3. Click **Invite member**.

<Steps>
  <Step title="Send an invite">
    Enter the user's email and select at least one Team. The user will appear as `Invited` until they verify their email, then become `Active`.
  </Step>

  <Step title="Manage team memberships">
    A member can belong to multiple Teams. Adjust team assignments anytime.
  </Step>
</Steps>

<Warning>
  You cannot invite an external user directly to a specific Team. First invite them to the **Organization**, then add them to a Team.
</Warning>

<div>
  <Frame>
    <img alt="Invite member dialog with email input and team selection fields" />
  </Frame>

  <small>Example: Invite a member</small>
</div>


# Member list
Source: https://docs.cloud.vessl.ai/admin/teams/member-list

View Organization members, their teams, and last login.

The Members view shows Organization members, their team memberships, and recent activity.

* Username: name and email
* Joined org: date joined the Organization
* Last login: last sign-in time
* Teams: teams the member belongs to (multiple allowed)

<div>
  <Frame>
    <img alt="Members list showing username, join date, last login, and team assignments" />
  </Frame>

  <small>Example: Members list</small>
</div>


# Teams overview
Source: https://docs.cloud.vessl.ai/admin/teams/overview

Collaboration units with shared resources and standardized environments.

Teams are collaboration units. Members in a team work with shared resources and standardized environments.

Members and teams are managed on two pages. In the sidebar, select **Settings**, then select **Members** or **Teams** under **Organization**.

<div>
  <Frame>
    <img alt="Members page listing organization members with their team assignments and login activity" />
  </Frame>

  <small>Example: Members page</small>
</div>

<div>
  <Frame>
    <img alt="Teams page showing each team with its members and shared resources" />
  </Frame>

  <small>Example: Teams page</small>
</div>

## Shared team resources

* Object storage (S3-backed, POSIX-compatible) and Cluster storage for sharing data/models/artifacts
* (Coming soon) Workspace visibility: standard images/spec guidance across the team
* (Coming soon) Collaborative workspaces

## Key operational points

* Multiple team membership: a member can belong to multiple teams
* Invite/join flow: email invite → Invited → becomes Active after verification
* Usage-based billing: storage is billed based on actual usage, no pre-allocation needed


# Team list
Source: https://docs.cloud.vessl.ai/admin/teams/team-list

View teams, their members, and invite members to a team.

The Teams view shows all teams and their members. You can invite Organization members into a specific team.

<div>
  <Frame>
    <img alt="Teams view showing all teams in the organization with their members" />
  </Frame>

  <small>Example: Team list</small>
</div>

<Warning>
  You cannot invite an external user directly to a team. Invite them to the **Organization** first, then add them to the team.
</Warning>


# Updates
Source: https://docs.cloud.vessl.ai/changelog/overview/updates

Release notes for the VESSL Cloud platform

<Update label="Sep 28, 2026" description="VM Clusters is now generally available">
  ### **VM Clusters is generally available**

  **VM Clusters** is out of Beta and now generally available. You can rent a dedicated multi-node GPU cluster with full root access, InfiniBand, and NFS shared storage for production workloads.

  #### Key updates

  * **Beta label removed**: VM Clusters no longer carries the Beta label in the docs.
  * **Service terms and SLA**: Contract, storage, billing, maintenance, and data retention terms are defined in the [VM Cluster service terms](/legal/vm-cluster). Availability commitments, where they apply, are defined in the [Service Level Agreement (SLA)](/legal/sla). The updated terms take effect on October 5, 2026.
  * **Sales-led setup**: Clusters are scoped with our sales team. See [Request a VM cluster](/vm-clusters/order).

  See [Understand VM Clusters](/vm-clusters/overview).
</Update>

<Update label="Sep 14, 2026" description="Provisioned Throughput: reserve guaranteed model-serving capacity in PTUs with an SLA">
  ### **Provisioned Throughput**

  **Provisioned Throughput** is a new inference service on VESSL Cloud. You reserve serving capacity for a stock open-weight model in Provisioned Throughput Units (PTUs) and get a guaranteed throughput in tokens per minute, with throughput, reliability, and latency targets set in your contract, on an endpoint compatible with the OpenAI Chat Completions API and the Anthropic Messages API.

  <div>
    <Frame>
      <img alt="Model page header with the model ID and a copy button next to the name, above the Model information card showing parameters, modality, context length, and a Hugging Face link" />
    </Frame>
  </div>

  #### Key updates

  * **Guaranteed capacity in PTUs**: Reserve capacity per model at \$0.05 per PTU per minute, the same rate for every model. The PTU quantity and contract term are arranged individually with sales. See [Understand PTUs and billing](/inference/ptu).
  * **Drop-in API**: Keep your existing OpenAI or Anthropic SDK code and change only the base URL, API key, and model ID. See [Send your first request](/inference/send-requests).
  * **Model pages with a cost calculator**: Browse MiniMax M3 and GLM 5.2 under **Inference** → **Models**, and use **Estimate total cost** to size your PTUs and compare the cost with a frontier model.
  * **Usage monitoring**: Each model page shows peak token usage, cost by token type, and a daily usage trend, with token, performance, and reliability metrics on the **Monitoring** page.
  * **Sales-led setup**: Capacity is scoped with our sales team and confirmed in a proof of concept (PoC) on your real traffic. See [Request Provisioned Throughput](/inference/request).

  See [Understand Provisioned Throughput](/inference/overview).
</Update>

<Update label="Jul 22, 2026" description="SAML SSO: members sign in to your organization with your identity provider">
  ### **SAML SSO**

  Organizations can now integrate their SAML 2.0 identity provider (IdP) with VESSL Cloud. Once configured, members sign in with the accounts they already use in your IdP, and new members are onboarded automatically on their first sign-in.

  <div>
    <Frame>
      <img alt="SAML SSO settings page with SP Configuration URLs and an Add SAML SSO button" />
    </Frame>
  </div>

  #### Key updates

  * **Works with any SAML 2.0 provider**: Step-by-step setup guides for Microsoft Entra, AWS IAM Identity Center, and Okta, plus instructions for any other SAML 2.0 identity provider.
  * **Self-service configuration**: Organization admins register the IdP metadata as XML or a URL under **Settings** → **Organization** → **SAML SSO**.
  * **Automatic onboarding**: A user without a VESSL Cloud account gets an account created and joins the organization automatically on their first SSO sign-in.
  * **CLI sign-in included**: `vesslctl auth login` signs in through the browser by default, where members can continue with SAML SSO.

  SAML SSO is enabled per organization. If the **SAML SSO** menu does not appear under **Settings**, contact [support@vessl.ai](mailto:support@vessl.ai).

  See [SAML SSO](/admin/organization/saml-sso).
</Update>

<Update label="Jul 16, 2026" description="Reorganized sidebar navigation and secrets creation open to all members">
  ### **Reorganized sidebar navigation**

  The sidebar is now split into a main view for everyday work and a **Settings** view for account and organization management, so day-to-day pages stay uncluttered.

  <div>
    <Frame>
      <img alt="Main sidebar with Home, Compute, Volume, and Manage groups next to the Settings view with Account and Organization menus" />
    </Frame>

    <small>Main view (left) and Settings view (right) of the sidebar</small>
  </div>

  #### Key updates

  * **Settings view**: Select **Settings** at the bottom of the sidebar to switch the sidebar to a dedicated settings view. Select the back control at the top to return to the main view.
  * **Account menu**: **Profile**, **SSH Keys**, and **Secrets** now live under **Account** in the Settings view.
  * **Organization menu**: **Dashboard**, **Billing**, **Members**, and **Teams** are now separate pages under **Organization** in the Settings view, alongside **SAML SSO**. This menu is visible to Organization admins only.
  * **Main view unchanged for daily work**: **Home**, **Compute** (**Workspaces**, **Jobs**, **VM Clusters**), and **Volume** (**Cluster storage**, **Object storage**) stay in the main sidebar.

  ### **Secrets creation open to all members**

  Any member can now create a secret — no admin request needed to register an API token for a batch job.

  #### Key updates

  * **Create and view for everyone**: Anyone in the organization can view secrets and create new ones.
  * **Update and delete stay admin-only**: Only **Organization admin** can update or delete a secret, including secrets that members created; members don't see the edit and delete controls on the secrets list.
  * **New location**: Secrets moved from the Organization menu to **Settings** → **Account** → **Secrets**.

  See [Secrets](/member/settings/secrets).
</Update>

<Update label="Jul 2, 2026" description="In-app notification center and a redesigned Billing page">
  ### **In-app notifications**

  A new **notification center** in the header surfaces key events in real time, so you no longer have to rely on email.

  #### Key updates

  * **Notification center**: See workspace, job, monitoring, firewall, and credit events in the header, and click any one to jump to the related resource.
  * **Inbox and Archive**: New notifications land in **Inbox**; archive the ones you've handled and restore them anytime. All are kept for 30 days.
  * **Per-category preferences**: Choose whether each category reaches you by **Email**, **Inbox**, or both, and mute the **Workspace** or **Job** groups with a section toggle.
  * **Always-on for billing and security**: Credit alerts and firewall rule changes are always emailed and can't be turned off.

  See [Manage notifications](/member/settings/notifications).

  ### **Redesigned Billing page**

  The **Billing** page is simpler: the three separate credit tabs (Overview, Usage report, Credit history) are merged into one **Credits** page.

  #### Key updates

  * **One Credits tab**: Balance, payment method, usage trends, breakdown, and credit history now sit on a single page — no more tab-hopping.
  * **Same info, less clicking**: Every panel, chart, and table carries over unchanged, just reorganized.
  * **Credits only**: VM cluster contracts are invoiced separately and don't draw down your credit balance.

  See [Billing overview](/admin/billing/overview).
</Update>

<Update label="Jun 10, 2026" description="VM Clusters (Beta): rent a dedicated multi-node GPU cluster with full root access, InfiniBand, and NFS shared storage">
  ### **VM Clusters (Beta)**

  With **VM Clusters** (also called VMaaS, short for VM as a Service), you rent a dedicated cluster of high-performance GPU nodes — 1–8 nodes with 8 GPUs each — and get full root access on every node, with no other customers sharing your hardware. H100 clusters are self-service from the dashboard; for 9+ nodes or other GPUs (H200, B200, GB200, B300, GB300), [talk to sales](https://vessl.ai/en/talk-to-sales?utm_source=docs\&utm_medium=referral\&utm_campaign=vm_clusters_en\&utm_content=changelog).

  <div>
    <Frame>
      <img alt="VM Clusters page listing active, provisioning, in review, and confirmed clusters with GPU, nodes, and contract dates" />
    </Frame>
  </div>

  #### Key updates

  * **Multi-node clusters with InfiniBand**: Rent 1–8 nodes (8–64 GPUs) with InfiniBand provisioned between nodes by default for distributed training. See [Understand VM Clusters](/vm-clusters/overview).
  * **Self-service ordering**: Order an H100 SXM cluster from the dashboard with an SSH key and billing information, then track it from review to active on the **VM Clusters** page. Orders are placed at the organization level by **Admin** members. See [Order a VM cluster](/vm-clusters/order).
  * **Full root access, near bare-metal performance**: Each VM gets its GPUs directly using GPU passthrough and ships as Ubuntu 24.04 with CUDA preinstalled. Swap drivers, load kernel modules, and bring your own stack — Slurm, Kubernetes, or security agents.
  * **NFS shared storage**: Attach an optional 1–200 TiB shared filesystem mounted across every node. Boot disks are not durable, so keep datasets and checkpoints here. See [Use NFS storage](/vm-clusters/nfs-storage).
  * **Health checks and metrics**: A per-node health verdict with GPU, InfiniBand, and ECC checks, plus time-series GPU and system charts, refreshed every minute. Manage inbound access with [firewall rules](/vm-clusters/firewall-rules) and [reboot a node](/vm-clusters/reboot) yourself. See [Health checks](/vm-clusters/health-checks) and [Metrics](/vm-clusters/metrics).
  * **Contracts and data retention**: Contracts run 4–52 weeks. When a contract expires, boot disks and NFS storage are permanently deleted, so back up or [extend the contract](/vm-clusters/extend-contract) before the end date. See [Plan for data retention](/vm-clusters/data-retention).

  If you're deciding between a workspace and a VM cluster, see [Compare with Workspace](/vm-clusters/vs-workspace).
</Update>

<Update label="May 28, 2026" description="Secrets: encrypted, org-level credentials with CLI and GUI management, plus job injection with --secret">
  ### **Secrets**

  Store API tokens, database URLs, and other sensitive strings as encrypted, organization-scoped credentials, and inject them into batch jobs as environment variables. Values are sealed on your machine with the organization's public key (libsodium sealed-box) before they leave the browser or CLI, so VESSL Cloud stores only ciphertext.

  <div>
    <Frame>
      <img alt="Secrets management page with a table of secret name, key, masked value, slug, last editor, and edit time, plus a New Secret button" />
    </Frame>
  </div>

  #### Key updates

  * **Encrypted, org-scoped credentials**: Create a secret once and reference it from any batch job in the organization. Plaintext values are sealed client-side and stored only as ciphertext, never exposed in request bodies, access logs, or to other members. See [Secrets](/member/settings/secrets).
  * **GUI and CLI workflows**: Manage secrets from the **Organization > Secrets** page or with `vesslctl secret create | list | update | delete`. The CLI supports interactive masked prompts, `--from-env`, and `--from-stdin` so plaintext never appears in your shell history.
  * **Job injection with `--secret`**: Attach secrets to a batch job with `vesslctl job create ... --secret HF_TOKEN`, or remap to a different env var with `--secret KEY=NAME`. The job-create form exposes the same controls. See [Use a secret in a job](/member/settings/secrets#use-a-secret-in-a-job).
  * **Organization admin only**: Only **Organization admin** users can create, update, or delete secrets — anyone in the organization can reference them by name when running a batch job.
  * **Workspaces on the roadmap**: Secrets ship for batch jobs today; Workspace support is planned for a follow-up release.
</Update>

<Update label="May 27, 2026" description="GPU selection is now organized by region instead of internal cluster names">
  ### **Region replaces Cluster in GPU selection**

  GPU options are now grouped by region instead of internal cluster names. Pick a region (for example, `us-west-2`, `eu-north1`, `kr-west`), then pick the GPU count and tier. Workspace and job views — including the compute spec card, cluster storage screens, and the volume picker — now show **Region** wherever they used to show **Cluster**.

  <div>
    <Frame>
      <img alt="Select region step with us-west-2 selected and pill buttons for eu-north1 and kr-west, followed by a Select GPU count step listing a CPU only card with availability and pricing" />
    </Frame>
  </div>

  #### Key updates

  * **Region-first GPU picker**: Pick a region first, then a GPU count and tier. The flow is shorter than scrolling through a flat list of cluster-and-GPU combinations.
  * **Region everywhere**: Workspace and job details, the compute spec card, cluster storage screens, and the volume picker all show **Region** instead of the internal cluster name.
  * **Same hardware, clearer label**: The underlying resources are unchanged — only how they're surfaced in the UI.
</Update>

<Update label="May 27, 2026" description="Heads-up: storage pricing and billing model change effective Jul 1, 2026">
  ### **Storage pricing & policy update — effective Jul 1, 2026**

  On **2026-07-01 at 09:00 UTC**, two storage changes take effect:

  * **Object storage** moves from free preview to paid usage at **\$0.03/GiB/month** (\$0.001/GiB/day, billed daily pay-as-you-go).
  * **Cluster storage** keeps the same **\$0.20/GiB/month** rate, but billing switches from **provisioned capacity** (monthly) to **actual usage** (daily, pay-as-you-go) — you no longer need to pre-provision exact capacity.

  If your credits run out, storage data is retained for up to **30 days** while access is restricted, then deleted. Back up important data before your balance reaches zero.

  See [Storage pricing](/pricing/storage) and the [FAQ](/pricing/storage#faq) for full details.
</Update>

<Update label="May 26, 2026" description="Clone a workspace's image, resource spec, and volumes into a Job in one click">
  ### **Convert a workspace to a Job**

  Workspace detail pages now have a **Convert to Job** button. It clones the workspace's runtime — image, resource spec, and mounted volumes — into a Job and drops the interactive pieces a Job doesn't use (SSH keys, custom ports, init script, root volume). You add the command and any env vars or secrets, then submit. The original workspace stays exactly as it was.

  <div>
    <Frame>
      <img alt="Workspace detail page header for a Queued workspace showing the Convert to Job and View history buttons in the top-right action bar" />
    </Frame>
  </div>

  #### Key updates

  * **One-click clone**: Click **Convert to Job** on the workspace detail page to pre-fill image, resource spec, and volumes for a new Job. Pick a command and submit.
  * **What carries over**: Container image, resource spec, and mounted Object and Cluster volumes. SSH keys, custom ports, init script, and the root volume are dropped since Jobs run to completion.
  * **Overridable before submit**: Swap the resource spec, image, or volumes for the run if you need a different runtime.
  * **Source workspace untouched**: The workspace stays exactly as it was — keep iterating in it while the Job runs. See [Convert a workspace to a Job](/member/workspace/convert-to-job).
</Update>

<Update label="May 14, 2026" description="Full workspace details and the Metrics tab stay visible after you pause, plus new Active volumes columns">
  ### **More visibility into paused workspaces**

  Paused workspaces now show the same level of detail as running ones — init script, container image, mounted volumes, compute specs, pricing summary, and the **Metrics** tab are all visible. The **Active volumes** list also gains new columns so you can see at a glance which volumes are in use and who created them.

  <div>
    <Frame>
      <img alt="Paused workspace detail page with init script, container image, attached volumes, compute specs, and pricing summary all visible side by side" />
    </Frame>
  </div>

  #### Key updates

  * **Full workspace details while paused**: Init script, container image, mounted volumes, compute specs, and pricing summary all stay visible after you pause a workspace, so you can verify configuration before resuming.
  * **Metrics tab in paused state**: The **Metrics** tab remains available on paused workspaces, so you can review the most recent run's CPU, memory, and GPU utilization without restarting.
  * **New columns on Active volumes**: The **Active volumes** list now shows **Workload count**, **Created by**, and **Last attached** alongside each volume so you can spot unused volumes and trace ownership at a glance.

  <div>
    <Frame>
      <img alt="Active volumes list with Name, Workload count, Created by, and Last attached columns in the table header" />
    </Frame>
  </div>
</Update>

<Update label="Apr 30, 2026" description="Run vesslctl inside workspaces, manage SSH keys and ports from the CLI, tag batch jobs, and more">
  ### **April 30, 2026 release**

  This release lets you run `vesslctl` directly inside running workspaces, manage SSH keys and custom ports without leaving the terminal, and tag batch jobs with custom labels. We also shipped a stack of reliability fixes.

  <div>
    <Frame>
      <img alt="Home dashboard summary card showing active workspace count, active job count, and total GPU usage side by side" />
    </Frame>
  </div>

  #### Key updates

  * **vesslctl inside running workspaces**: Run any `vesslctl` command from a JupyterLab terminal or SSH session in a running workspace, with no re-auth step. See [Run vesslctl inside a running workspace](/cli/commands/workspace#ssh).
  * **SSH keys and custom ports from the CLI**: `vesslctl workspace create` now accepts `--ssh-key` and `--port` flags, and a new [`vesslctl ssh-key`](/cli/commands/ssh-key) command tree lets you list, add, and delete keys from the terminal.
  * **Slug column in `workspace list`**: `vesslctl workspace list` shows the slug as the first column so you can copy it straight into other commands.
  * **Tag jobs with custom labels**: Add or remove tags inline from the **Jobs** list and job details, and filter the list by tag. See [List batch jobs](/member/job/list).
  * **Job metrics on the home dashboard**: The summary card now reports active job counts and GPU usage alongside workspaces, with idle detection covering both workload types.
  * **Cleaner job lifecycle**: `vesslctl job terminate` now stops the run while preserving its configuration, logs, and metrics for review. See [Clean up jobs](/member/job/cleanup).
  * **Smoother onboarding**: The workspace creation page is now accessible without credits (submission is still gated), and the organization creation page has been redesigned for a clearer flow.
  * **Reliability fixes**: Admin invitations to brand-new users no longer disappear, organization creation errors now surface in the UI, and Object storage uploads larger than 5 GiB no longer get corrupted.
</Update>

<Update label="Apr 15, 2026" description="Batch jobs: submit training and inference jobs using the CLI">
  ### **Batch jobs**

  Submit batch training and inference jobs from the CLI, then monitor and manage them on VESSL Cloud. Jobs run a command to completion on the cluster and resource spec you choose, with logs, metrics, and termination reasons surfaced in the UI.

  <div>
    <Frame>
      <img alt="Jobs list in VESSL Cloud showing job name, state, cluster, resource spec, and creator" />
    </Frame>
  </div>

  #### Key updates

  * **Submit using the CLI**: Submit a batch job in one line with `vesslctl job create`. Monitor status and logs from the **Jobs** section in the console.
  * **Image, command, and environment**: Bring your own container image, specify the command to run, and pass environment variables (such as `WANDB_API_KEY`) for experiment tracking.
  * **Volume mounting**: Mount object volumes and cluster volumes by slug to share datasets, checkpoints, and artifacts with your jobs.
  * **Lifecycle visibility**: Track state transitions from queued through running to completed or terminated, and review termination reasons for failures.
  * **Tags**: Attach tags to jobs to keep them organized and filterable.
</Update>

<Update label="Apr 15, 2026" description="vesslctl CLI documentation and command reference">
  ### **vesslctl CLI documentation**

  We've published comprehensive documentation for `vesslctl`, the VESSL Cloud command-line tool. You can now manage workspaces, batch jobs, storage, and team settings entirely from your terminal.

  <div>
    <Frame>
      <img alt="Welcome banner for VESSL Cloud CLI showing a VESSL ASCII wordmark, the supported GPU lineup (A100, H100, H200, B200, GB200, B300, Ada), and three starter commands: vesslctl auth login, vesslctl workspace create, vesslctl --help" />
    </Frame>
  </div>

  #### Key updates

  * **Installation guide**: One-command install, browser-based OAuth login, and shell completion setup. See [CLI overview](/cli/overview).
  * **CLI quickstart**: Three step-by-step scenarios covering workspace creation, dataset upload, and batch job submission. See [CLI quickstart](/cli/quickstart).
  * **Command reference**: Detailed documentation for every command and flag, including `workspace`, `job`, `volume`, `storage`, `org`, `team`, `cluster`, `config`, and `auth`. See [Command reference](/cli/commands/workspace).
  * **Cheat sheet**: A single-page quick reference for all commands. See [Cheat sheet](/cli/cheatsheet).
</Update>

<Update label="Mar 27, 2026" description="Redesigned resource spec selection for workspace creation">
  ### **New resource spec selection**

  Choosing hardware for your workspace is now simpler. Instead of scrolling through a flat list of spec cards, you select your resource in three clear steps: GPU product, region, and GPU count.

  <div>
    <Frame>
      <img alt="New resource spec selection with three-step flow" />
    </Frame>
  </div>

  #### Key updates

  * **Step-by-step selection**: Pick a GPU product (such as A100 SXM, H100 SXM, or CPU only), then choose a region, and finally select how many GPUs you need.
  * **Region-based selection**: Resources are now organized by region instead of cluster name, making it easier to understand where your workspace will run.
  * **Availability at a glance**: Each GPU count card shows availability (High or Low) along with hourly cost, vCPU, RAM, and Temporary storage details.

  See [Create a workspace](/member/workspace/create) for the full walkthrough.
</Update>

<Update label="Mar 13, 2026" description="Launch confirmation modal for workspace creation">
  ### **Launch confirmation modal**

  When creating a workspace, a confirmation modal now appears to help you understand how persistent storage affects your data.

  <div>
    <Frame>
      <img alt="Launch confirmation without persistent volume" />
    </Frame>
  </div>

  * **No persistent volume**: If no volume is attached, the modal warns that all files will be permanently deleted when you pause. It suggests adding a Cluster storage volume and saving important files to the mounted path.

  <div>
    <Frame>
      <img alt="Launch confirmation with persistent volume" />
    </Frame>
  </div>

  * **With persistent volume**: If a volume is mounted, the modal shows the mounted path and explains that files inside will be preserved on pause, while files outside will not.
</Update>

<Update label="Mar 5, 2026" description="Dashboards, GPU availability indicator, and enhanced workspace metrics">
  ### **Dashboard, GPU availability, and workspace metrics**

  VESSL Cloud now provides dedicated dashboards for individual users and organization admins, plus a new GPU availability indicator during workspace creation.

  <div>
    <Frame>
      <img alt="Organization dashboard showing GPU utilization, spend trends, and team breakdown" />
    </Frame>
  </div>

  #### Key updates

  * **Home dashboard**: View your active workloads, GPU utilization, and spend rate across all teams. Under-utilization alerts help you optimize resource usage. See [Home dashboard](/member/dashboard/overview).
  * **Organization dashboard**: Monitor organization-wide GPU utilization, spend trends, team breakdown with drill-down, and idle workload detection. See [Organization dashboard](/admin/dashboard/overview).
  * **GPU availability indicator**: Each resource spec card now shows availability level (High, Low, or Checking) when creating a workspace, helping you anticipate wait times. See [Create a workspace](/member/workspace/create).
  * **Enhanced workspace metrics**: Track VRAM usage and GPU temperature alongside existing metrics. New time range selector (1h–7d) and display settings for flexible monitoring. See [Monitor metrics](/member/workspace/metrics).
</Update>

<Update label="Feb 26, 2026" description="Storage system update: Cluster storage and Object storage">
  ### **New storage system**

  We've restructured VESSL Cloud's storage to give you faster, more reliable options.

  #### Key updates

  * **Workspace volume → Cluster storage**: High-availability distributed storage (CephFS/NVMe) shared across workspaces in the same cluster. Data persists even after workspace termination.
  * **Shared volume → Object storage**: Same S3-backed storage, now called Object storage. No functional changes.
  * **Data persists after terminate**: Your code, virtualenvs, and data survive workspace termination.
  * **Shared within cluster**: Multiple workspaces on the same cluster can mount the same volume (RWX).
  * **High-availability**: Distributed storage protects against node failures.
  * **Pricing**: Cluster storage at \$0.20/GiB/month.
  * **Migration**: Existing Workspace volume data can be migrated to Cluster storage. Contact [support@vessl.ai](mailto:support@vessl.ai) for assistance.

  See [Understand storage](/member/volume/overview) for details.
</Update>

<Update label="Feb 12, 2026" description="Simpler SSH key download experience">
  ### **Simpler SSH key downloads**

  Previously, generating an SSH key opened a file picker dialog, letting you choose where to save the key. This often led to forgetting the save location when connecting later. Now, SSH keys download directly to your `~/Downloads` folder, and the SSH connection guide shows the expected key path.

  #### Key updates

  * **Direct download to \~/Downloads**: SSH keys now download automatically to your default download folder instead of opening a file picker.
  * **Key path hint in SSH connection guide**: The SSH connection tab now shows "usually in `~/Downloads`" so you know where to find your key.
</Update>

<Update label="Jan 28, 2026" description="Improved navigation and team workspace visibility">
  ### **Better navigation and team collaboration**

  We've unified the admin menu structure and added visibility into your team's workspaces and members.

  #### Key updates

  * **Unified admin menu**: The admin menu is now integrated into the main navigation, making it easier to find and access admin features.

  <div>
    <img alt="Unified admin menu in navigation" />
  </div>

  * **View other team members' workspaces**: Previously, you could only view your own workspaces. Now you can see workspaces belonging to your team members and track which team member is working on which workspace.

  <div>
    <img alt="Workspace list showing environments owned by other team members" />
  </div>

  * **Team member visibility in top bar**: View who's on your team directly from the top bar. See who you're collaborating with at a glance.

  <div>
    <img alt="Team member list accessible directly from the top navigation bar" />
  </div>

  <div>
    <img alt="Team member profile and role in the detail panel" />
  </div>
</Update>

<Update label="Jan 21, 2026" description="Teams/Members role assignment improvements">
  ### **Teams & Members role management**

  Members list now shows each member's role, and admins can update roles between Admin and Member.

  <div>
    <img alt="Member role editor toggling between Admin and Member" />
  </div>

  #### Key updates

  * **Role column on members list**: View each member's role (Admin/Member) directly in the list.
  * **Admins can edit roles**: Admins can change a member's role from the Edit action (Admin ↔ Member).
  * **Multiple admins supported**: Assign multiple Admins when your team needs it.
</Update>

<Update label="Jan 7, 2026" description="Credit and payment method improvements">
  ### **Safer workspace creation when credits run out**

  We've tightened how workspace creation behaves when you have no credits, so you don't end up with workspaces that start and immediately terminate.

  <div>
    <img alt="Payment method registration banner and credit warning on workspace page" />
  </div>

  #### Key updates

  * **Credit validation for workspace creation**: Previously, workspaces could start and then immediately terminate when you had no credits. Now, if you have no credits, workspace creation is blocked and a toast notification prompts you to purchase or add credits before starting.
  * **Payment method registration banner**: Previously, there was no clear signal when you didn’t have a registered payment method. Now, if you have no payment method and no credits, a banner appears prompting you to register a payment method. Admins can register a payment method directly from the banner.
</Update>

<Update label="Dec 18, 2025" description="Workspace history improvements">
  ### **Better workspace history**

  These updates were previously listed in Coming Soon and are now available, along with a storage mount path update.

  <Tip>Use the demo below to see how to open **Event history** in the workspace details page and review the event timeline.</Tip>

  <div>
    <iframe title="View Event History for a Workspace" />
  </div>

  <Tip>Also use the demo below to see how to review terminated workspaces with **View Terminated** and delete them manually when you're ready.</Tip>

  <div>
    <iframe title="Pause and Permanently Delete a Workspace" />
  </div>

  #### Key updates

  * **Event feed**:
    * **Event history**: View a complete timeline of workspace events directly on the **Details** page. Track key lifecycle events and states, including **Running**, image pulling, and termination reasons such as Out of Memory Killed (OOMKilled), credit exhaustion, or Temporary storage exceeded.
    * **Terminated workspace view**: Terminated workspaces are no longer auto-deleted after 24 hours. Use the **View Terminated** toggle to access their history and delete them manually when ready.
  * **Workspace volume mount path**: Workspace volume mount path is fixed to `/root` (`$HOME`) and cannot be changed.
</Update>

<Update label="Dec 11, 2025" description="New CUDA 13.0.1 and Torch 2.9.1 images">
  ### **Updated GPU images**

  We've added refreshed CUDA and Torch images for broader Python coverage.

  #### Key updates

  * **CUDA 13.0.1 images**:
    * `quay.io/vessl-ai/cuda:13.0.1-py3.10-slim`
    * `quay.io/vessl-ai/cuda:13.0.1-py3.11-slim`
    * `quay.io/vessl-ai/cuda:13.0.1-py3.12-slim`
    * `quay.io/vessl-ai/cuda:13.0.1-py3.13-slim`

  * **Torch 2.9.1 (CUDA 13.0.1) images**:
    * `quay.io/vessl-ai/torch:2.9.1-cuda13.0.1-py3.10-slim`
    * `quay.io/vessl-ai/torch:2.9.1-cuda13.0.1-py3.11-slim`
    * `quay.io/vessl-ai/torch:2.9.1-cuda13.0.1-py3.12-slim`
    * `quay.io/vessl-ai/torch:2.9.1-cuda13.0.1-py3.13-slim`
</Update>

<Update label="Dec 5, 2025" description="User-managed volumes, workspace visibility, and simplified resource selection">
  ### **Enhanced control, visibility, and simplicity**

  We've empowered users with direct volume management, deeper workspace insights, and a simplified resource selection flow.

  #### Key updates

  * **User-managed volumes**: You can now create and manage shared volumes directly.
    * **No admin quota needed**: Create volumes instantly without waiting for admin allocation.
    * **Team sharing**: Share volumes across your team effortlessly.

  * **Storage pricing update**:
    * **Pay-as-you-go**: Workspace volumes are billed based on usage (\$0.0070/hr per 50GB).
    * **No quota limits**: Pre-allocated quotas for shared volumes have been removed.

  * **Workspace visibility**:
    * **Detailed status**: Workspace states are now clearly defined: Queued, Initializing, Running, Paused, Failed, and Terminated. "Queued" shows *Waiting for GPU*, and "Initializing" shows *Downloading image*.

  * **Simplified resource selection**:
    * **Cluster selector removed**: No need to select a cluster first. Browse all available resource specs across clusters in a single view.
    * **Unified resource view**: See every GPU and CPU option you have access to, regardless of cluster.
</Update>

<Update label="Nov 28, 2025" description="Workspace creation revamp and new features">
  ### **A new way to create workspaces**

  We've completely redesigned the workspace creation experience to be more intuitive and powerful. The new flow guides you through essential steps while offering deeper customization options for advanced needs.

  <Tip>Take a quick tour of the new workspace creation flow with the demo below.</Tip>

  <div>
    <iframe title="A New Way To Create Workspace" />
  </div>

  #### Key updates

  * **Streamlined creation flow**: The process is now split into three clear steps:
    * **Step 1 (Select resource)**: Choose your hardware specifications.
    * **Step 2 (Deployment settings)**: Configure image, SSH keys, ports, and volumes.
    * **Step 3 (Review)**: Review your settings and estimated cost before deploying.

  * **SSH key generation**: You can now generate SSH keys directly within the workspace creation page and save them locally. Manage your keys anytime in **Settings > SSH Keys**.

  * **Custom port opening**: Open specific custom ports during creation to perfectly replicate your local environment. Verify connection details in the **Detail > Connect** page.
</Update>

<Update label="Nov 13, 2025" description="VESSL Cloud Launch">
  ### **Introducing VESSL Cloud**

  We're launching **VESSL Cloud**, a dedicated service designed to streamline the research workflow with clearer billing and an optimized developer experience.

  #### Key updates

  * **GPUaaS**: On-demand access to GPU instances. Select the exact specs you need and pay only for what you use.

  * **Enhanced Workspace**: Launch Jupyter or SSH environments in clicks.
    * Select your preferred container image.
    * Monitor logs and resource metrics in real-time.
    * Easily stop or terminate instances to manage costs.
</Update>


# Use with AI tools
Source: https://docs.cloud.vessl.ai/cli/ai-tools

Connect vesslctl to Claude Code, Cursor, and other AI-powered development tools.

There are two complementary ways to connect VESSL Cloud to AI coding tools. Install the **`vesslctl` skill** so your agent can create workspaces, submit jobs, and manage volumes on your behalf. Connect the **MCP server** so your agent can look up commands, flags, and workflows directly from the docs while you work.

## Install the vesslctl skill

The `vesslctl skill` command installs a bundled skill file that teaches AI coding agents (such as Claude Code, Codex, Gemini CLI, and Cursor) how to operate VESSL Cloud through `vesslctl`. Skills follow the [Agent Skills open standard](https://agentskills.io/home).

Run it interactively and pick a target:

```bash theme={null}
vesslctl skill install
```

**Available targets:**

| Target | Default directory | Works with |
| - | - | - |
| `cross-client` | `~/.agents/skills` | Codex, Gemini CLI, Cursor, and other Agent-Skills-compatible agents |
| `claude-code` | `~/.claude/skills` | Claude Code (native) |

Non-interactive install:

```bash theme={null}
vesslctl skill install --target claude-code
vesslctl skill install --target cross-client
vesslctl skill install --dir ~/my-skills
```

The command is idempotent — re-running it skips files that are already up to date.

Once the skill is installed, the agent can act on VESSL Cloud without any further prompting. Try:

> Create a GPU workspace on VESSL Cloud

For the full flag reference and the `skill show` subcommand, see [`vesslctl skill`](/cli/commands/skill).

## Connect the docs through MCP

Give your AI tool live access to VESSL Cloud docs so it can look up commands, flags, and workflows while you work. Connect this URL to any MCP-compatible AI tool:

```text theme={null}
https://docs.cloud.vessl.ai/mcp
```

The server exposes two tools:

| Tool | Description |
| - | - |
| `search_vessl_ai` | Search across all VESSL Cloud documentation for relevant content |
| `query_docs_filesystem_vessl_ai` | Run shell-like commands (`rg`, `grep`, `cat`, `head`, `tree`, `ls`) on a virtual filesystem of VESSL Cloud docs to inspect structure and read specific pages |

### Claude Code

Add the MCP server to your project's `CLAUDE.md` or Claude Code settings:

```json theme={null}
{
  "mcpServers": {
    "vessl-docs": {
      "type": "url",
      "url": "https://docs.cloud.vessl.ai/mcp"
    }
  }
}
```

Once connected, Claude Code can look up `vesslctl` commands, check available flags, and reference common workflows while helping you write scripts or debug issues.

#### Example CLAUDE.md for `vesslctl` projects

```markdown theme={null}
# Project Setup

This project uses VESSL Cloud for GPU workloads.

## Tools
- `vesslctl` CLI for managing workspaces and batch jobs
- VESSL docs available through MCP at https://docs.cloud.vessl.ai/mcp

## Common tasks
- Create workspace: `vesslctl workspace create --name <name> --resource-spec <spec> --image <image>`
- Submit batch job: `vesslctl job create --name <name> --resource-spec <spec> --image <image> --cmd "<command>"`
- Check job logs: `vesslctl job logs <slug> --follow`
```

### Cursor

1. Open **Settings**
2. Go to **MCP Servers**
3. Add a new server with URL: `https://docs.cloud.vessl.ai/mcp`

### Windsurf

1. Open **Settings**
2. Navigate to **Cascade** > **MCP**
3. Add a new MCP server with URL: `https://docs.cloud.vessl.ai/mcp`

### VS Code (with Copilot or Continue)

Add to your `.vscode/mcp.json`:

```json theme={null}
{
  "servers": {
    "vessl-docs": {
      "type": "url",
      "url": "https://docs.cloud.vessl.ai/mcp"
    }
  }
}
```

### Other tools

Any tool that supports MCP can connect using the server URL. Check your tool's documentation for how to add an MCP server, then use:

```text theme={null}
https://docs.cloud.vessl.ai/mcp
```

### Per-page MCP links

Each page in the VESSL Cloud docs has a **Copy MCP link** option in the context menu. Use this to share a direct MCP reference to a specific page with your AI tool.


# CLI Cheat Sheet
Source: https://docs.cloud.vessl.ai/cli/cheatsheet

Every vesslctl command at a glance with quick copy-paste examples.

## Authentication

| Command | Description |
| - | - |
| `vesslctl auth login` | Log in using browser OAuth (falls back to email/password) |
| `vesslctl auth logout` | Log out and clear stored credentials |
| `vesslctl auth status` | Show the currently authenticated user |

## Organization & Team

| Command | Description |
| - | - |
| `vesslctl org list` | List organizations you belong to |
| `vesslctl org show` | Show details of the current organization |
| `vesslctl org switch <name>` | Switch default organization |
| `vesslctl org create --name <name>` | Create a new organization |
| `vesslctl team list` | List teams in the current organization |
| `vesslctl team show` | Show details of the current team |
| `vesslctl team switch <name>` | Switch default team |
| `vesslctl team create --name <name>` | Create a new team |

## Configuration

| Command | Description |
| - | - |
| `vesslctl config show` | Display current CLI configuration |
| `vesslctl config set default_org <name>` | Set the default organization |
| `vesslctl config set default_team <name>` | Set the default team |
| `vesslctl config set output_format <fmt>` | Set default output format (`table`, `json`, `csv`) |

## Workspace

Alias: `vesslctl ws`

| Command | Description |
| - | - |
| `vesslctl workspace list` | List workspaces in the current team |
| `vesslctl workspace show <slug>` | Show workspace details and status |
| `vesslctl workspace create` | Create a new workspace (see flags below) |
| `vesslctl workspace ssh <slug>` | SSH into a running workspace |
| `vesslctl workspace logs <slug>` | View workspace logs |
| `vesslctl workspace metrics <slug>` | Show GPU/CPU/memory metrics summary |
| `vesslctl workspace pause <slug>` | Pause a workspace (preserves environment) |
| `vesslctl workspace start <slug>` | Resume a paused workspace |
| `vesslctl workspace terminate <slug>` | Terminate and delete a workspace |

**Common create flags:**

```bash theme={null}
vesslctl workspace create \
  --name <name> \
  --cluster <cluster> \
  --resource-spec <spec> \
  --image <image> \
  --ssh-key <ssh-key-slug> \
  --port api:8000:http
```

<Tip>
  Inside a running workspace, `vesslctl` is pre-authenticated with a workload token (`VESSLCTL_ACCESS_TOKEN`/`ORG`/`TEAM`), so commands like `vesslctl workspace list` or `vesslctl job create` work straight from the JupyterLab terminal.
</Tip>

## SSH keys

| Command | Description |
| - | - |
| `vesslctl ssh-key list` | List SSH keys registered to your account |
| `vesslctl ssh-key add --name <name> --public-key-file <path>` | Register a public key from a file |
| `vesslctl ssh-key add --name <name> --generate` | Generate a keypair on the server (private key printed once) |
| `vesslctl ssh-key delete <ssh-key-slug>` | Delete an SSH key by slug (use `-y` to skip confirmation) |

## Job

| Command | Description |
| - | - |
| `vesslctl job list` | List jobs in the current team |
| `vesslctl job show <slug>` | Show job details and status |
| `vesslctl job create` | Submit a new batch job (see flags below) |
| `vesslctl job logs <slug>` | View job output logs |
| `vesslctl job metrics <slug>` | Show GPU/CPU/memory metrics summary |
| `vesslctl job export <slug>` | Export job configuration as JSON |
| `vesslctl job terminate <slug>` | Cancel a running job |
| `vesslctl job tag attach <slug> <tag>` | Attach a tag to a job |
| `vesslctl job tag detach <slug> <tag>` | Detach a tag from a job |

**Common create flags:**

```bash theme={null}
vesslctl job create \
  --name <name> \
  --resource-spec <spec> \
  --image <image> \
  --cmd "<command>"
```

## Cluster & Resources

| Command | Description |
| - | - |
| `vesslctl cluster list` | List available clusters |
| `vesslctl resource-spec list` | List resource specs (GPU/CPU configurations) |
| `vesslctl resource-spec list --cluster <slug>` | List specs for a specific cluster |

## Storage & Volumes

Alias: `vesslctl vol`

| Command | Description |
| - | - |
| `vesslctl storage list` | List storage backends |
| `vesslctl storage show <slug>` | Show storage backend details |
| `vesslctl storage create` | Create a cluster storage (requires `--name`, `--cluster`, `--capacity`) |
| `vesslctl storage delete <slug>` | Delete a storage backend |
| `vesslctl volume list` | List volumes |
| `vesslctl volume show <slug>` | Show volume details |
| `vesslctl volume create --name <n> --storage <slug> --teams <team>` | Create a new volume (`--name`, `--storage`, `--teams` are required) |
| `vesslctl volume ls <slug> --prefix /` | List files in a volume (use `/` for root) |
| `vesslctl volume token <slug>` | Get temporary S3 credentials for a volume |
| `vesslctl volume upload <slug> <local_path>` | Upload local files to a volume |
| `vesslctl volume download <slug> <local_path>` | Download files from a volume |
| `vesslctl volume update <slug>` | Update volume metadata (pass `--name`, `--description`, or `--teams`) |
| `vesslctl volume delete <slug>` | Delete a volume |

## Tags

| Command | Description |
| - | - |
| `vesslctl tag list` | List tags in the current organization |
| `vesslctl tag create <value>` | Create a tag (optional: `--color "#ff0000"`) |
| `vesslctl tag delete <value>` | Delete a tag by value (or `-s <slug>`) |

## AI Skills

| Command | Description |
| - | - |
| `vesslctl skill install` | Install skills for AI coding agents |
| `vesslctl skill show` | Display the bundled skill content |

## Utility

| Command | Description |
| - | - |
| `vesslctl update` | Update vesslctl to the latest version (`-y` to skip the confirmation prompt) |
| `vesslctl version` | Print vesslctl version |
| `vesslctl install` | Install vesslctl to a directory in your PATH |
| `vesslctl completion install` | Auto-detect shell and install completion script |
| `vesslctl completion bash\|zsh\|fish\|powershell` | Generate shell completion script manually |

***

## Common Workflows

### First-time setup

```bash theme={null}
# Install
curl -fsSL https://api.cloud.vessl.ai/cli/install.sh | bash

# Authenticate
vesslctl auth login

# Set defaults
vesslctl config set default_org <your-org>
vesslctl config set default_team <your-team>

# Verify
vesslctl auth status
vesslctl config show
```

### Launch and connect to a workspace

```bash theme={null}
vesslctl workspace create \
  --name dev-box \
  --cluster <cluster-name> \
  --resource-spec <spec-name> \
  --image pytorch/pytorch:2.3.0-cuda12.1-cudnn8-devel

# Copy the workspace slug from `vesslctl workspace list` (for example, dev-box-abc123).
vesslctl workspace show <workspace-slug>    # wait for "running"
vesslctl workspace ssh <workspace-slug>     # connect
vesslctl workspace pause <workspace-slug>   # done for now
```

### Submit a batch job

```bash theme={null}
vesslctl job create \
  --name train-v2 \
  --resource-spec <spec-name> \
  --image pytorch/pytorch:2.3.0-cuda12.1-cudnn8-devel \
  --cmd "python train.py --epochs 50"

vesslctl job logs train-v2 --follow
```

### Upload data to object storage

```bash theme={null}
# Create a volume (--name, --storage, --teams are required)
vesslctl volume create --name my-dataset --storage <storage-name> --teams <team>

# Copy the volume slug from `vesslctl volume list` (for example, my-dataset-abc123).
vesslctl volume upload <volume-slug> ./data/

# Verify
vesslctl volume ls <volume-slug> --prefix /
```

If you need to integrate with an S3-compatible tool (DVC, `aws s3 cp`, custom pipelines), use `vesslctl volume token <volume-slug>` to get temporary S3 credentials and an endpoint URL.


# vesslctl cluster & resource-spec
Source: https://docs.cloud.vessl.ai/cli/commands/cluster

Discover available clusters, GPU types, and resource configurations.

Use these commands to explore what compute infrastructure is available before creating workspaces or jobs.

## Cluster commands

### cluster list

List all clusters available in your organization. Shows each cluster's slug, display name, region, and available GPU types.

```bash theme={null}
vesslctl cluster list
```

**Example output:**

```text theme={null}
SLUG                  NAME                    REGION        GPUS
betelgeuse-na         VESSL Cloud US West     us-west-2     A100 SXM, L40S, CPU-Only
capella-emea          VESSL Cloud EU North    eu-north-1    H100 SXM, A100 SXM
```

## Resource spec commands

The `resource-spec` command has an alias: `rs` (for example, `vesslctl rs list`).

### resource-spec list

List all resource specifications available in your organization. Shows the slug, GPU type, GPU count, CPU cores, memory, hourly cost, and current availability.

```bash theme={null}
vesslctl resource-spec list
```

| Flag | Description |
| - | - |
| `--cluster` | Filter resource specs by cluster slug |
| `--usable-only` | Show only resource specs available for provisioning |

**Example:**

```bash theme={null}
# List all specs for a specific cluster
vesslctl resource-spec list --cluster betelgeuse-na

# Show only usable specs
vesslctl resource-spec list --usable-only
```

**Example output:**

```text theme={null}
SLUG               NAME             CPU    MEMORY     GPU          COUNT   COST/HR   AVAILABILITY
a100-sxm-1         VESSL A100 SXM   12     80 GiB     A100 SXM     1       $1.55     high
a100-sxm-4         VESSL A100 SXM   48     320 GiB    A100 SXM     4       $6.20     high
h100-sxm-1         VESSL H100 SXM   12     80 GiB     H100 SXM     1       $2.39     low
l40s-1             VESSL L40S       8      48 GiB     L40S         1       $1.80     high
cpu-only           VESSL CPU Only   4      16 GiB     -            -       $0.20     -
```

<Tip>
  Use the slug from `resource-spec list` as the value for the `--resource-spec` flag when creating workspaces or jobs.
</Tip>


# vesslctl completion
Source: https://docs.cloud.vessl.ai/cli/commands/completion

Enable shell tab completion for vesslctl commands and flags.

`vesslctl` ships with completion scripts for bash, zsh, fish, and PowerShell. The fastest way to enable completion is to let `vesslctl completion install` detect your shell and place the script in the standard location.

## completion install

Detect the current shell from `$SHELL` and write the completion script to the appropriate path. The command is idempotent — re-run it whenever you upgrade `vesslctl`.

```bash theme={null}
vesslctl completion install
```

Supported shells: bash, zsh, and fish. For PowerShell, use the manual setup below.

**Default install paths:**

| Shell | Path |
| - | - |
| bash | `~/.local/share/bash-completion/completions/vesslctl` |
| zsh | `~/.zsh/completions/_vesslctl` |
| fish | `~/.config/fish/completions/vesslctl.fish` |

After installing, open a new terminal, or reload your shell config in place (for example, `source ~/.zshrc` or `source ~/.bashrc`). For zsh, if your `~/.zshrc` does not yet include the completions directory, the installer prints the snippet you need to add:

```bash theme={null}
fpath=(~/.zsh/completions $fpath)
autoload -U compinit; compinit
```

## completion bash | zsh | fish | powershell

Print a completion script for the requested shell to stdout. Use this when you want to manage the script location yourself.

```bash theme={null}
vesslctl completion bash
vesslctl completion zsh
vesslctl completion fish
vesslctl completion powershell
```

**Manual setup examples:**

<CodeGroup>
  ```bash Bash (Linux) theme={null}
  vesslctl completion bash > /etc/bash_completion.d/vesslctl
  ```

  ```bash Bash (macOS, Homebrew) theme={null}
  vesslctl completion bash > $(brew --prefix)/etc/bash_completion.d/vesslctl
  ```

  ```bash Zsh theme={null}
  vesslctl completion zsh > "${fpath[1]}/_vesslctl"
  ```

  ```bash Fish theme={null}
  vesslctl completion fish > ~/.config/fish/completions/vesslctl.fish
  ```

  ```powershell PowerShell theme={null}
  vesslctl completion powershell > vesslctl.ps1
  # Then dot-source it from your PowerShell profile (for example, . .\vesslctl.ps1).
  ```
</CodeGroup>

<Tip>
  Argument and flag values benefit from completion too — once enabled, pressing **Tab** after `--cluster`, `--resource-spec`, `--org`, or a workspace/job slug prompts for the live values from your current org and team.
</Tip>


# vesslctl config, auth, billing & utility
Source: https://docs.cloud.vessl.ai/cli/commands/config

Configure the CLI, manage authentication, check billing, and update vesslctl.

These commands handle CLI configuration, authentication, account billing, and utility operations.

## Config commands

### config show

Display the current CLI configuration, including the config file path, authentication status, and resolved context (organization, team, API URL) with their sources.

```bash theme={null}
vesslctl config show
```

**Example output:**

```text theme={null}
Config File:       ~/.config/vesslctl/config.yaml
Auth Status:       logged in

default_org (config):    vessl-ai
default_team (config):   ml-research
API URL (resolved):      https://api.cloud.vessl.ai (from default)
Output (resolved):       table (from default)
Org (resolved):          vessl-ai (from config)
Team (resolved):         ml-research (from config)
```

### config set

Set a configuration value.

```bash theme={null}
vesslctl config set <key> <value>
```

| Key | Description |
| - | - |
| `default_org` | Default organization for all commands |
| `default_team` | Default team for all commands |
| `output_format` | Output format (`table`, `json`, or `csv`) |
| `api_url` | VESSL Cloud API endpoint URL |

**Example:**

```bash theme={null}
vesslctl config set output_format json
vesslctl config set default_org vessl-ai
```

## Auth commands

### auth login

Authenticate with VESSL Cloud. The default flow opens a browser for OAuth and falls back to email and password if the browser is unavailable.

```bash theme={null}
vesslctl auth login
```

| Flag | Short | Description |
| - | - | - |
| `--web` | | Use browser OAuth only — disable the password fallback |
| `--password` | | Use email and password login instead of browser OAuth |

**Example:**

```bash theme={null}
# Default browser OAuth (with password fallback)
vesslctl auth login

# Password-based login
vesslctl auth login --password
```

<Note>
  **Inside a VESSL Cloud workspace.** When `VESSLCTL_ACCESS_TOKEN` or `SIDECAR_INITIAL_ACCESS_TOKEN` is set, `vesslctl auth login` is a no-op — the CLI uses the workload token directly and prints a notice instead. Pass `--web` or `--password` to override and start a fresh interactive login.
</Note>

### auth logout

Remove saved credentials from the local machine.

```bash theme={null}
vesslctl auth logout
```

### auth status

Display your current authentication status, including username, email, token validity, org/team context, and organization list.

```bash theme={null}
vesslctl auth status
```

**Example output:**

```text theme={null}
Username:       wayne
Email:          wayne@vessl.ai
Token:          Valid (expires 2026-05-01)
Organization:   vessl-ai
Team:           ml-research

ORGANIZATIONS
  vessl-ai (current)
  personal
```

## Billing command

### billing show

Display your current credit balance, burn rate, and estimated remaining hours.

```bash theme={null}
vesslctl billing show
```

## Utility commands

### version

Print the vesslctl version.

```bash theme={null}
vesslctl version
```

You can also use the `--version` flag on the root command:

```bash theme={null}
vesslctl --version
```

### install

Copy the current vesslctl binary to a directory in your PATH for permanent use. Useful after downloading vesslctl for the first time through the install script.

```bash theme={null}
vesslctl install
```

| Flag | Description |
| - | - |
| `--dir` | Target directory (default: `/usr/local/bin` or `~/.local/bin`) |

**Example:**

```bash theme={null}
# Install to default location
vesslctl install

# Install to a custom directory
vesslctl install --dir ~/bin
```

<Note>
  If the default directory requires root access, use `sudo vesslctl install`.
</Note>


# vesslctl job
Source: https://docs.cloud.vessl.ai/cli/commands/job

Submit, monitor, and manage batch training and inference jobs.

The `job` command lets you create and manage batch compute jobs on VESSL Cloud. Jobs run a command to completion on a specified cluster and resource configuration.

<div>
  <Frame>
    <img alt="vesslctl job create command showing all available flags" />
  </Frame>
</div>

## list

List jobs in the current team.

```bash theme={null}
vesslctl job list
```

| Flag | Short | Description |
| - | - | - |
| `--state` | `-s` | Filter by job state (for example, `running`, `succeeded`, `failed`) |
| `--page` | | Page number for pagination |
| `--per-page` | | Number of results per page |
| `--hide-deleted` | | Hide cancelled and terminated jobs |

**Example:**

```bash theme={null}
vesslctl job list --state running --per-page 20
```

## show

Display detailed information about a specific job.

```bash theme={null}
vesslctl job show <slug>
```

| Argument | Description |
| - | - |
| `slug` | Unique identifier of the job |

## create

Create and submit a new job. You can provide configuration inline with flags or using a JSON file.

```bash theme={null}
vesslctl job create --name my-job --resource-spec <slug> --image <image> --cmd "python train.py"
```

| Flag | Short | Required | Description |
| - | - | - | - |
| `--file` | `-f` | No | Path to a JSON config file (alternative to inline flags) |
| `--name` | `-n` | Yes | Name for the job |
| `--resource-spec` | `-r` | Yes | Resource spec slug (cluster is derived automatically) |
| `--image` | `-i` | Yes | Container image to use |
| `--cmd` | | Yes | Command to execute |
| `--env` | `-e` | No | Environment variable in `KEY=VALUE` format (repeatable) |
| `--object-volume` | | No | Mount an object volume as `SLUG:MOUNT_PATH` (repeatable) |
| `--cluster-volume` | | No | Mount a cluster volume as `SLUG:MOUNT_PATH` (repeatable) |
| `--image-pull-policy` | | No | Image pull policy: `Always` or `IfNotPresent` |
| `--tag` | | No | Tag value to attach (repeatable, auto-creates if not exists) |

**Example with inline flags:**

```bash theme={null}
vesslctl job create \
  --name my-training-job \
  --resource-spec <spec-name> \
  --image quay.io/vessl-ai/torch:2.9.1-cuda13.0.1-py3.13-slim \
  --cmd "python train.py --epochs 10" \
  --env WANDB_API_KEY=<your-key> \
  --object-volume <volume-slug>:/data
```

<Tip>
  Run `vesslctl cluster list` and `vesslctl resource-spec list` to see available clusters and GPU specs.
</Tip>

**Example with a JSON config file:**

```bash theme={null}
vesslctl job create --file job-config.json
```

<Note>
  **Pricing summary and credit balance.** `job create` shows the resource spec, hourly cost, current credit balance, and estimated remaining hours before submitting. Creation is blocked when the balance is zero or negative — run `vesslctl billing show` to inspect, or top up before retrying.
</Note>

## terminate

Terminate a running job.

```bash theme={null}
vesslctl job terminate <slug>
```

| Flag | Short | Description |
| - | - | - |
| `--yes` | `-y` | Skip confirmation prompt |

## export

Export a job's configuration as JSON. Useful for reusing or version-controlling job configs.

```bash theme={null}
vesslctl job export <slug>
```

Pipe the output to a file to save it:

```bash theme={null}
vesslctl job export my-job-abc123 > job-config.json
```

## logs

View logs from a job.

```bash theme={null}
vesslctl job logs <slug>
```

| Flag | Short | Default | Description |
| - | - | - | - |
| `--limit` | | `100` | Number of log lines to return |
| `--follow` | `-f` | | Stream logs in real time |

**Example:**

```bash theme={null}
vesslctl job logs my-job-abc123 --follow
```

## metrics

Show a summary of job metrics (GPU, VRAM, temperature, CPU, memory, network, and storage) over a time range.

```bash theme={null}
vesslctl job metrics <slug>
```

| Flag | Short | Default | Description |
| - | - | - | - |
| `--since` | | `1h` | Look back this far from now (e.g. `30m`, `6h`, `7d`); cannot be combined with `--from` |
| `--from` | | | Range start (RFC 3339 or epoch seconds) |
| `--to` | | now | Range end (RFC 3339 or epoch seconds); requires `--from` |

The range must be shorter than 90 days. The default table (and `-o csv`) shows one row per metric series with the latest, average, and maximum value and the sample count; it is a summary, not the time series. Use `-o json` for the raw series: `gpu` and `cpu` values are ratios from 0 to 1, byte metrics (`vramUsage`, `memory`, `network`, `temporaryStorage`, `persistentStorage`) are raw bytes, and `temperature` is in Celsius. If no samples exist in the range (for example, a stopped job), rows show `-` with `0` samples and a notice is written to stderr; the command still exits successfully.

**Example:**

```bash theme={null}
# Summary table for the last hour
vesslctl job metrics my-job-abc123

# Summary table for the last 6 hours
vesslctl job metrics my-job-abc123 --since 6h

# Explicit range
vesslctl job metrics my-job-abc123 --from 2026-09-20T00:00:00Z --to 2026-09-21T00:00:00Z

# Latest GPU 0 utilization as a percentage (prints nothing when the range has no GPU samples)
vesslctl job metrics my-job-abc123 -o json | jq '(.gpu.series[0].points[-1].value // empty) * 100'
```

## tag

Manage tags on a job. See [vesslctl tag](/cli/commands/tag#job-tag-commands) for details on `job tag attach` and `job tag detach`.


# vesslctl org & team
Source: https://docs.cloud.vessl.ai/cli/commands/org-team

Manage organizations and teams for access control and resource scoping.

VESSL Cloud uses a two-level hierarchy for access control: **organizations** contain **teams**. Most commands operate within the context of your currently selected org and team.

## Organization commands

### org list

List all organizations you belong to.

```bash theme={null}
vesslctl org list
```

### org show

Display details about an organization. Defaults to the current org if no name is provided.

```bash theme={null}
vesslctl org show [name]
```

| Argument | Description |
| - | - |
| `name` | Organization name (optional, defaults to current) |

### org switch

Switch your default organization context. Subsequent commands will operate under this org.

```bash theme={null}
vesslctl org switch <name>
```

| Argument | Description |
| - | - |
| `name` | Organization name to switch to |

**Example:**

```bash theme={null}
vesslctl org switch vessl-ai
```

### org create

Create a new organization.

```bash theme={null}
vesslctl org create --name <name>
```

| Flag | Required | Description |
| - | - | - |
| `--name` | Yes | Organization name |

**Example:**

```bash theme={null}
vesslctl org create --name my-org
```

<Note>
  The `organization` alias can be used interchangeably with `org` (for example, `vesslctl organization list`).
</Note>

## Team commands

### team list

List all teams in your current organization.

```bash theme={null}
vesslctl team list
```

### team show

Display details about a team. Defaults to the current team if no name is provided.

```bash theme={null}
vesslctl team show [name]
```

| Argument | Description |
| - | - |
| `name` | Team name (optional, defaults to current) |

### team switch

Switch your default team context.

```bash theme={null}
vesslctl team switch <name>
```

| Argument | Description |
| - | - |
| `name` | Team name to switch to |

**Example:**

```bash theme={null}
vesslctl team switch ml-research
```

### team create

Create a new team in your current organization.

```bash theme={null}
vesslctl team create --name <name>
```

| Flag | Required | Description |
| - | - | - |
| `--name` | Yes | Team name |
| `--description` | No | Team description |

**Example:**

```bash theme={null}
vesslctl team create --name ml-research --description "Machine learning research team"
```


# vesslctl skill
Source: https://docs.cloud.vessl.ai/cli/commands/skill

Install vesslctl skills for AI coding agents.

The `skill` command lets you install and inspect vesslctl skill files so AI coding agents — such as Claude Code, Codex, Gemini CLI, and Cursor — can manage VESSL Cloud resources directly.

Skills follow the [Agent Skills open standard](https://agentskills.io/home).

## install

Install vesslctl skill files to a target location. When run interactively, it prompts you to choose a target. In non-interactive mode, use `--target`.

```bash theme={null}
vesslctl skill install
```

| Flag | Short | Description |
| - | - | - |
| `--target` | | Target location: `cross-client` (`~/.agents/skills`) or `claude-code` (`~/.claude/skills`) |
| `--dir` | `-d` | Custom target directory (overrides the target default) |
| `--force` | | Overwrite existing files without prompting |

**Available targets:**

| Target | Default Directory | Description |
| - | - | - |
| `cross-client` | `~/.agents/skills` | Works with all coding agents |
| `claude-code` | `~/.claude/skills` | Claude Code native |

**Examples:**

```bash theme={null}
# Interactive selection
vesslctl skill install

# Install to Claude Code
vesslctl skill install --target claude-code

# Install to a custom directory
vesslctl skill install --dir ~/my-skills

# Force overwrite existing files
vesslctl skill install --target cross-client --force
```

The command is idempotent — running it again skips files that are already up to date.

## show

Display the raw contents of the bundled vesslctl skill file.

```bash theme={null}
vesslctl skill show
```

Use `--output json` to get the skill content as a JSON object with name, description, and content fields.

```bash theme={null}
vesslctl skill show --output json
```


# vesslctl ssh-key
Source: https://docs.cloud.vessl.ai/cli/commands/ssh-key

List, add, and delete SSH public keys from the CLI.

The `ssh-key` command (alias: `ssh-keys`) lets you manage the SSH public keys associated with your VESSL Cloud account. Keys are referenced by slug (unique identifier) — pass that slug to `vesslctl workspace create --ssh-key` to attach a key when launching a workspace.

## list

List all SSH keys registered to your account.

```bash theme={null}
vesslctl ssh-key list
```

The output shows each key's slug, name, fingerprint, and creation time. Copy the slug to use with other commands.

| Column | Description |
| - | - |
| `SLUG` | Unique identifier — pass to `--ssh-key` flags |
| `NAME` | Human-readable name you set when adding the key |
| `FINGERPRINT` | SHA-256 fingerprint of the public key |
| `CREATED` | When the key was registered, in RFC 3339 format |

## add

Register a new SSH public key. You can either upload an existing public key file or have VESSL generate a new keypair on the server.

```bash theme={null}
vesslctl ssh-key add --name <name> --public-key-file <path>
```

| Flag | Required | Description |
| - | - | - |
| `--name` | Yes | Human-readable name for the key (for example, `macbook-personal`) |
| `--public-key-file` | Conditional | Path to a public key file (typically `~/.ssh/id_ed25519.pub` or `~/.ssh/id_rsa.pub`). Required unless `--generate` is used. |
| `--generate` | Conditional | Generate a new keypair on the server. The private key is printed once and not stored — save it immediately. Mutually exclusive with `--public-key-file`. |

**Example — upload an existing public key:**

```bash theme={null}
vesslctl ssh-key add \
  --name macbook-personal \
  --public-key-file ~/.ssh/id_ed25519.pub
```

**Example — generate a new keypair on the server:**

```bash theme={null}
vesslctl ssh-key add --name temporary-runner --generate
```

The command prints the slug of the newly registered key. Use that slug with `vesslctl workspace create --ssh-key <ssh-key-slug>`.

<Warning>
  The `--generate` option prints the private key to your terminal exactly once and does not store it on the server. Save the output to a file (for example, `~/.ssh/<key-name>`) and `chmod 600` it before closing the session, or you will lose access to the key.
</Warning>

## delete

Delete an SSH key by slug.

```bash theme={null}
vesslctl ssh-key delete <ssh-key-slug>
```

| Flag | Short | Description |
| - | - | - |
| `--yes` | `-y` | Skip the confirmation prompt |

**Example:**

```bash theme={null}
vesslctl ssh-key delete macbook-personal-abc123 --yes
```

<Note>
  Deleting a key only removes it from your VESSL Cloud account. Workspaces that already had the key attached at creation continue to accept it until they are terminated.
</Note>


# vesslctl storage
Source: https://docs.cloud.vessl.ai/cli/commands/storage

View and manage storage backends that host volumes.

The `storage` command lets you manage storage backends in your VESSL Cloud organization. Storage backends are the underlying infrastructure (for example, GCS buckets, NFS mounts) where volumes are created.

## list

List all storage backends available in your organization.

```bash theme={null}
vesslctl storage list
```

| Flag | Short | Description |
| - | - | - |
| `--team-filter` | | Filter Object storage by team. Cluster storage is always returned unfiltered. |

**Example:**

```bash theme={null}
vesslctl storage list --team-filter ml-team
```

## show

Display detailed information about a storage backend.

```bash theme={null}
vesslctl storage show <slug>
```

| Argument | Description |
| - | - |
| `slug` | Unique identifier of the storage backend |

## create

Create a new Cluster storage backend.

```bash theme={null}
vesslctl storage create --name <name> --cluster <slug> --capacity <gib>
```

| Flag | Required | Description |
| - | - | - |
| `--name` | Yes | Storage name |
| `--cluster` | Yes | Cluster slug to create the storage on |
| `--capacity` | Yes | Capacity in GiB |
| `--description` | No | Storage description |

**Example:**

```bash theme={null}
vesslctl storage create \
  --name team-storage \
  --cluster betelgeuse-na \
  --capacity 500 \
  --description "Shared storage for ML team"
```

## delete

Delete a storage backend.

```bash theme={null}
vesslctl storage delete <slug>
```

| Flag | Short | Description |
| - | - | - |
| `--yes` | `-y` | Skip confirmation prompt |

**Example:**

```bash theme={null}
vesslctl storage delete clusterstorage-abc123 --yes
```

<Note>
  See [Storage management](/admin/storage/overview) for more details on storage administration, and [Storage pricing](/pricing/storage) for current rates and the 2026-07-01 billing policy.
</Note>


# vesslctl tag
Source: https://docs.cloud.vessl.ai/cli/commands/tag

Create and manage tags to organize and filter jobs.

The `tag` command lets you create, list, and delete tags at the organization level. Tags can be attached to jobs for filtering and categorization.

## create

Create a new tag in your organization.

```bash theme={null}
vesslctl tag create <value>
```

| Argument | Description |
| - | - |
| `value` | Display name for the tag |

| Flag | Default | Description |
| - | - | - |
| `--color` | `#808080` | Tag color in hex format (for example, `#ff0000`) |

**Example:**

```bash theme={null}
vesslctl tag create "experiment-v2" --color "#3b82f6"
```

## list

List all tags in your organization.

```bash theme={null}
vesslctl tag list
```

**Example output:**

```
SLUG                VALUE            COLOR     CREATOR    CREATED
tag-abc123          experiment-v2    #3b82f6   wayne      2026-04-15T09:00:00Z
tag-def456          baseline         #808080   alice      2026-04-14T15:30:00Z
```

## delete

Delete a tag by its value or slug.

```bash theme={null}
vesslctl tag delete [value]
```

| Argument | Description |
| - | - |
| `value` | Tag value to delete (positional, mutually exclusive with `--slug`) |

| Flag | Short | Description |
| - | - | - |
| `--slug` | `-s` | Delete tag by slug instead of value |

**Example:**

```bash theme={null}
# Delete by value
vesslctl tag delete "experiment-v2"

# Delete by slug
vesslctl tag delete -s tag-abc123
```

***

## Job tag commands

Tags can be attached to and detached from jobs using `vesslctl job tag`. When you attach a tag value that does not exist yet, it is created automatically.

### job tag attach

Attach a tag to a job.

```bash theme={null}
vesslctl job tag attach <slug> [tagValue]
```

| Argument | Description |
| - | - |
| `slug` | Slug of the job |
| `tagValue` | Tag value to attach (auto-creates if not exists) |

| Flag | Short | Description |
| - | - | - |
| `--slug` | `-s` | Attach tag by slug instead of value |

**Example:**

```bash theme={null}
# Attach by value (auto-creates the tag if needed)
vesslctl job tag attach job-abc123 "nightly-run"

# Attach by slug
vesslctl job tag attach job-abc123 -s tag-def456
```

### job tag detach

Detach a tag from a job.

```bash theme={null}
vesslctl job tag detach <slug> [tagValue]
```

| Argument | Description |
| - | - |
| `slug` | Slug of the job |
| `tagValue` | Tag value to detach |

| Flag | Short | Description |
| - | - | - |
| `--slug` | `-s` | Detach tag by slug instead of value |

**Example:**

```bash theme={null}
vesslctl job tag detach job-abc123 "nightly-run"
```

<Tip>
  Use `vesslctl job create --tag "my-tag"` to attach tags at job creation time. The `--tag` flag is repeatable and auto-creates tags that don't exist.
</Tip>


# vesslctl update
Source: https://docs.cloud.vessl.ai/cli/commands/update

Upgrade vesslctl in place to the latest released version.

The `update` command checks for a newer release of `vesslctl` and replaces the running binary in place. The CLI also prints an "update available" notice on every command when a newer version is detected, so you can run `vesslctl update` whenever you see the prompt.

## update

```bash theme={null}
vesslctl update
```

| Flag | Short | Description |
| - | - | - |
| `--yes` | `-y` | Skip the confirmation prompt and update immediately. Useful for scripts and CI. |

When you run `vesslctl update`:

1. The CLI fetches the latest release version.
2. If you are already on the latest version, it prints a confirmation and exits.
3. Otherwise, it shows the current and target versions and asks for confirmation. Pass `--yes` to skip the prompt.
4. The new binary is downloaded and replaces the current one in place.

**Examples:**

```bash theme={null}
# Interactive update (default)
vesslctl update

# Skip the prompt — useful for scripts
vesslctl update --yes
```

<Note>
  `vesslctl update` always replaces the binary at its current location. You don't need to redownload through the install script after the first install.
</Note>

<Tip>
  If `vesslctl update` reports that it cannot write to the install path, re-run with the elevated permissions you used when installing (for example, `sudo vesslctl update`), or reinstall to a path you own with `vesslctl install --dir ~/.local/bin`.
</Tip>


# vesslctl volume
Source: https://docs.cloud.vessl.ai/cli/commands/volume

Manage data volumes for persistent storage across workspaces and jobs.

The `volume` command (alias: `vol`) lets you create and manage data volumes on VESSL Cloud. Volumes provide persistent storage that can be mounted into workspaces and jobs.

## list

List all volumes in the current team.

```bash theme={null}
vesslctl volume list
```

| Flag | Short | Description |
| - | - | - |
| `--storage` | | Filter volumes by storage slug |
| `--type` | | Restrict to a single volume kind: `object` or `cluster` |
| `--page` | | Page number (1-based) |
| `--per-page` | | Items per page |

## show

Display detailed information about a volume.

```bash theme={null}
vesslctl volume show <slug>
```

| Argument | Description |
| - | - |
| `slug` | Slug of the volume |

## create

Create a new volume on a specified storage backend.

```bash theme={null}
vesslctl volume create --name my-volume --storage <slug> --teams <team>
```

| Flag | Short | Required | Description |
| - | - | - | - |
| `--name` | | Yes | Name for the volume |
| `--storage` | | Yes | Storage slug to create the volume on |
| `--teams` | | Yes | Comma-separated list of teams that will have access to the volume |
| `--description` | | No | Human-readable description |

**Example:**

```bash theme={null}
vesslctl volume create \
  --name training-data \
  --storage gcs-us-central1 \
  --teams ml-team,data-team \
  --description "ImageNet training dataset"
```

## ls

List file contents within an object volume. Cluster volumes are not supported.

```bash theme={null}
vesslctl volume ls <slug> --prefix /
```

| Flag | Short | Description |
| - | - | - |
| `--prefix` | | Path prefix to list. Use `/` to list from the volume root. |

**Example:**

```bash theme={null}
vesslctl volume ls training-data-abc123 --prefix checkpoints/
```

## token

Get temporary S3-compatible credentials for direct access to an object volume. Returns the endpoint, bucket name, access key, and secret key. Cluster volumes are not supported.

```bash theme={null}
vesslctl volume token <slug>
```

**Example:**

```bash theme={null}
vesslctl volume token training-data-abc123
```

This is useful for integrating with tools that support S3 (for example, `aws s3 cp`, DVC, or custom data pipelines).

## update

Update an existing volume's metadata. Pass at least one of the flags below to apply a change.

```bash theme={null}
vesslctl volume update <slug> [flags]
```

| Flag | Short | Description |
| - | - | - |
| `--name` | | New name for the volume |
| `--description` | | Updated description |
| `--teams` | | Updated comma-separated list of teams |

**Example:**

```bash theme={null}
vesslctl volume update training-data-abc123 \
  --description "ImageNet + COCO combined dataset" \
  --teams ml-team,data-team,research
```

## delete

Permanently delete a volume and its data.

```bash theme={null}
vesslctl volume delete <slug>
```

| Flag | Short | Description |
| - | - | - |
| `--yes` | `-y` | Skip confirmation prompt |

**Example:**

```bash theme={null}
vesslctl volume delete training-data-abc123 --yes
```

## upload

Upload local files to an object volume. Cluster volumes are not supported.

```bash theme={null}
vesslctl volume upload <slug> <local_path>
```

| Flag | Short | Required | Description |
| - | - | - | - |
| `--remote-prefix` | | No | Path prefix within the volume (for example, `datasets/training/`) |
| `--exclude` | | No | Glob patterns to exclude (for example, `*.pyc`). Repeatable. |
| `--dry-run` | | No | Print list of files without uploading |
| `--overwrite` | | No | Overwrite existing remote files |

**Example:**

```bash theme={null}
vesslctl volume upload training-data-abc123 ./local-dataset \
  --remote-prefix datasets/v1/ \
  --exclude "*.pyc" \
  --exclude "__pycache__"
```

## download

Download files from an object volume to a local directory. Cluster volumes are not supported.

```bash theme={null}
vesslctl volume download <slug> <local_path>
```

| Flag | Short | Required | Description |
| - | - | - | - |
| `--remote-prefix` | | No | Path prefix within the volume to download from |
| `--exclude` | | No | Glob patterns to exclude. Repeatable. |
| `--dry-run` | | No | Print list of files without downloading |
| `--overwrite` | | No | Overwrite existing local files |

**Example:**

```bash theme={null}
vesslctl volume download training-data-abc123 ./local-copy \
  --remote-prefix checkpoints/ \
  --overwrite
```


# vesslctl workspace
Source: https://docs.cloud.vessl.ai/cli/commands/workspace

Create, manage, and connect to interactive development workspaces.

The `workspace` command (alias: `ws`) lets you manage interactive development environments on VESSL Cloud. Workspaces provide persistent compute sessions you can pause and resume without losing data.

<div>
  <Frame>
    <img alt="vesslctl workspace command showing available subcommands" />
  </Frame>
</div>

## list

List all workspaces in the current team.

```bash theme={null}
vesslctl workspace list
```

| Flag | Default | Description |
| - | - | - |
| `--all` | `false` | Show all workspaces in the team (not just yours) |

## show

Display detailed information about a specific workspace.

```bash theme={null}
vesslctl workspace show <slug>
```

| Argument | Description |
| - | - |
| `slug` | Slug of the workspace to inspect |

## create

Create a new workspace with a specified cluster, resource spec, and container image.

```bash theme={null}
vesslctl workspace create --name my-workspace --cluster <slug> --resource-spec <slug> --image <image>
```

| Flag | Required | Description |
| - | - | - |
| `--name` | Yes | Name for the workspace |
| `--cluster` | Yes | Cluster slug to run the workspace on |
| `--resource-spec` | Yes | Resource spec slug (GPU type, count, CPU, memory) |
| `--image` | No | Container image to use |
| `--init-script` | No | Shell script to run on workspace startup |
| `--object-volume` | No | Mount an Object storage volume as `SLUG:MOUNT_PATH` (repeatable) |
| `--cluster-volume` | No | Mount a Cluster storage volume as `SLUG:MOUNT_PATH` (repeatable) |
| `--ssh-key` | No | SSH key slug to attach (repeatable). Run `vesslctl ssh-key list` to find slugs. |
| `--port` | No | Additional port as `NAME:PORT:PROTOCOL` (repeatable). Protocol is `http`, `tcp`, or `udp`. |

**Example:**

```bash theme={null}
vesslctl workspace create \
  --name my-workspace \
  --cluster <cluster-slug> \
  --resource-spec <spec-slug> \
  --image quay.io/vessl-ai/torch:2.9.1-cuda13.0.1-py3.13-slim \
  --ssh-key <ssh-key-slug> \
  --port tensorboard:6006:http \
  --port api:8000:tcp
```

<Tip>
  Run `vesslctl cluster list` and `vesslctl resource-spec list` to see available clusters and GPU specs. Run `vesslctl ssh-key list` to see SSH key slugs.
</Tip>

<Note>
  **Pricing summary and credit balance.** `workspace create` and `workspace start` show the resource spec, hourly cost, current credit balance, and estimated remaining hours before launching. Creation is blocked when the balance is zero or negative — run `vesslctl billing show` to inspect, or top up before retrying.
</Note>

<Info>
  **Run vesslctl inside a running workspace.** Every workspace ships with the following environment variables already set, so `vesslctl` is ready to use from a JupyterLab terminal or SSH session without re-authenticating:

  * `VESSLCTL_ACCESS_TOKEN` — a workload-scoped token used as the bearer for API calls
  * `VESSLCTL_ORG` — the organization that owns the workspace
  * `VESSLCTL_TEAM` — the team that owns the workspace

  Commands like `vesslctl workspace list`, `vesslctl job create`, and `vesslctl volume upload` work straight away. The workload token has two restrictions worth knowing:

  * **Scoped to a single team.** It can only see and modify resources in the team that owns the workspace. It cannot list other teams or change context with `vesslctl team switch`.
  * **Cannot manage SSH keys.** Registering or deleting SSH keys is an account-level action and is rejected for workload tokens. Run [`vesslctl ssh-key add`](/cli/commands/ssh-key#add) from your local machine first, then attach the key at create time with `vesslctl workspace create --ssh-key <ssh-key-slug>`.
</Info>

## start

Resume a previously paused workspace.

```bash theme={null}
vesslctl workspace start <slug>
```

| Argument | Description |
| - | - |
| `slug` | Slug of the workspace to resume |

## pause

Pause a running workspace. Billing stops while paused, but all data is preserved.

```bash theme={null}
vesslctl workspace pause <slug>
```

| Argument | Description |
| - | - |
| `slug` | Slug of the workspace to pause |

## terminate

Permanently delete a workspace and all associated data.

```bash theme={null}
vesslctl workspace terminate <slug>
```

| Flag | Short | Description |
| - | - | - |
| `--yes` | `-y` | Skip confirmation prompt |

**Example:**

```bash theme={null}
vesslctl workspace terminate my-workspace-abc123 --yes
```

## logs

View logs from a workspace.

```bash theme={null}
vesslctl workspace logs <slug>
```

| Flag | Short | Default | Description |
| - | - | - | - |
| `--limit` | | `100` | Number of log lines to return |

**Example:**

```bash theme={null}
vesslctl workspace logs my-workspace-abc123 --limit 500
```

## metrics

Show a summary of workspace metrics (GPU, VRAM, temperature, CPU, memory, network, and storage) over a time range.

```bash theme={null}
vesslctl workspace metrics <slug>
```

| Flag | Short | Default | Description |
| - | - | - | - |
| `--since` | | `1h` | Look back this far from now (e.g. `30m`, `6h`, `7d`); cannot be combined with `--from` |
| `--from` | | | Range start (RFC 3339 or epoch seconds) |
| `--to` | | now | Range end (RFC 3339 or epoch seconds); requires `--from` |

The range must be shorter than 90 days. The default table (and `-o csv`) shows one row per metric series with the latest, average, and maximum value and the sample count; it is a summary, not the time series. Use `-o json` for the raw series: `gpu` and `cpu` values are ratios from 0 to 1, byte metrics (`vramUsage`, `memory`, `network`, `temporaryStorage`, `persistentStorage`) are raw bytes, and `temperature` is in Celsius. If no samples exist in the range (for example, a stopped workspace), rows show `-` with `0` samples and a notice is written to stderr; the command still exits successfully.

**Example:**

```bash theme={null}
# Summary table for the last hour
vesslctl workspace metrics my-workspace-abc123

# Summary table for the last 6 hours
vesslctl workspace metrics my-workspace-abc123 --since 6h

# Explicit range
vesslctl workspace metrics my-workspace-abc123 --from 2026-09-20T00:00:00Z --to 2026-09-21T00:00:00Z

# Latest GPU 0 utilization as a percentage (prints nothing when the range has no GPU samples)
vesslctl workspace metrics my-workspace-abc123 -o json | jq '(.gpu.series[0].points[-1].value // empty) * 100'
```

## ssh

Open an SSH session into a running workspace.

```bash theme={null}
vesslctl workspace ssh <slug>
```

| Flag | Short | Description |
| - | - | - |
| `--key` | `-i` | Path to SSH private key file |

**Example:**

```bash theme={null}
vesslctl workspace ssh my-workspace-abc123 -i ~/.ssh/id_rsa
```

The command launches your local `ssh` binary against the workspace's SSH endpoint and authenticates with a registered SSH key — there is no browser OAuth step. Register a key first with [`vesslctl ssh-key add`](/cli/commands/ssh-key#add) or in the console under **Settings > SSH Keys**.

<Tip>
  **Prefer the browser, JupyterLab, or VS Code?** The console **Connect** tab on each workspace lists every HTTP service (JupyterLab and any custom ports) as clickable URLs and provides a copy-paste SSH config block for VS Code Remote-SSH. See [Connect to a workspace](/member/workspace/connect) for the full set of connection methods.
</Tip>


# Understand vesslctl
Source: https://docs.cloud.vessl.ai/cli/overview

Install and configure the VESSL Cloud command-line tool.

`vesslctl` is the command-line interface for VESSL Cloud. Manage workspaces, batch jobs, storage, and team settings from your terminal.

<div>
  <Frame>
    <img alt="vesslctl help output showing all available commands" />
  </Frame>
</div>

### Why `vesslctl`

* **Develop and train in one tool**: Launch interactive workspaces for development, then submit batch jobs for training, all with the same CLI
* **Built for teams**: Org and team scoping ensures workloads, volumes, and billing are isolated where they need to be
* **Flexible storage**: Choose Object storage for cross-cluster access or Cluster storage for high-performance local I/O, and mount volumes into any workload
* **AI-native**: Connect VESSL Cloud docs to Claude Code, Cursor, or any MCP-compatible tool so your AI assistant references accurate CLI documentation. See [Use with AI tools](/cli/ai-tools)
* **Scriptable**: Combine commands in shell scripts to build hyperparameter sweeps, data pipelines, or autonomous experiment loops

## Installation

<Info>
  **Supported platforms** — macOS 15+, Ubuntu 20.04+, or Windows 10+. No other environment dependencies.
</Info>

<Steps>
  <Step title="Install vesslctl">
    ```bash theme={null}
    curl -fsSL https://api.cloud.vessl.ai/cli/install.sh | bash
    ```
  </Step>

  <Step title="Log in">
    ```bash theme={null}
    vesslctl auth login
    ```

    This opens your browser for OAuth authentication. If no browser is available, the command falls back to email and password login.
  </Step>

  <Step title="Verify installation">
    ```bash theme={null}
    vesslctl auth status
    ```
  </Step>
</Steps>

## Global Flags

Every command supports these flags:

| Flag | Short | Description |
| - | - | - |
| `--org` | | Override the default organization |
| `--team` | `-t` | Override the default team |
| `--output` | `-o` | Output format: `table` (default), `json`, or `csv` |

## Set Defaults

After logging in, `vesslctl` prompts you to select a default organization and team. You can change them anytime:

```bash theme={null}
vesslctl config set default_org <your-org>
vesslctl config set default_team <your-team>
```

To view your current configuration:

```bash theme={null}
vesslctl config show
```

## Environment variables

`vesslctl` reads these environment variables. Flags take precedence over env vars, which take precedence over the config file:

| Variable | Description |
| - | - |
| `VESSLCTL_ORG` | Default organization (overrides `default_org` from config) |
| `VESSLCTL_TEAM` | Default team (overrides `default_team` from config) |
| `VESSLCTL_OUTPUT` | Default output format: `table`, `json`, or `csv` |
| `VESSLCTL_API_URL` | Override the API endpoint (defaults to the production URL) |
| `VESSLCTL_ACCESS_TOKEN` | Long-lived access token. When set, `vesslctl` skips the interactive login flow. |
| `SIDECAR_INITIAL_ACCESS_TOKEN` | Auto-injected inside VESSL Cloud workspaces so you can run `vesslctl` without logging in. Used as a fallback when `VESSLCTL_ACCESS_TOKEN` is unset. |

<Tip>
  Inside a VESSL Cloud workspace, `vesslctl` is preconfigured with `SIDECAR_INITIAL_ACCESS_TOKEN`. Run `vesslctl auth status` to confirm — you do not need to run `vesslctl auth login` from a workspace terminal.
</Tip>

## Shell Completion

The easiest way to enable tab completion is the `install` subcommand — it detects your shell automatically and writes the script to the right place:

```bash theme={null}
vesslctl completion install
```

The command is idempotent, so you can safely re-run it after CLI updates. For zsh, it will let you know if your `~/.zshrc` needs an `fpath` entry.

<Accordion title="Manual setup">
  If you prefer to manage completion scripts yourself:

  <CodeGroup>
    ```bash Bash theme={null}
    vesslctl completion bash > /etc/bash_completion.d/vesslctl
    ```

    ```bash Zsh theme={null}
    vesslctl completion zsh > "${fpath[1]}/_vesslctl"
    ```

    ```bash Fish theme={null}
    vesslctl completion fish > ~/.config/fish/completions/vesslctl.fish
    ```
  </CodeGroup>
</Accordion>

## Update

Keep `vesslctl` up to date:

```bash theme={null}
vesslctl update
```

## Command Overview

| Command | Description |
| - | - |
| [`workspace`](/cli/commands/workspace) | Manage GPU workspaces (create, SSH, pause, terminate) |
| [`job`](/cli/commands/job) | Submit and manage batch jobs |
| [`volume`](/cli/commands/volume) | Manage storage volumes |
| [`storage`](/cli/commands/storage) | List and inspect storage backends |
| [`org`](/cli/commands/org-team) | Switch and manage organizations |
| [`team`](/cli/commands/org-team) | Switch and manage teams |
| [`cluster`](/cli/commands/cluster) | List available clusters |
| [`resource-spec`](/cli/commands/cluster) | List GPU/CPU resource configurations (alias: `rs`) |
| [`tag`](/cli/commands/tag) | Create, list, and attach tags to jobs |
| [`skill`](/cli/commands/skill) | Install vesslctl skills for AI coding agents |
| [`config`](/cli/commands/config) | Manage CLI configuration |
| [`auth`](/cli/commands/config) | Log in, log out, check auth status |
| [`billing`](/cli/commands/config) | View credit balance and burn rate |
| [`completion`](/cli/commands/completion) | Shell tab completion — `install` for auto-setup, or generate scripts manually for bash, zsh, fish, or PowerShell |
| [`update`](/cli/commands/update) | Update `vesslctl` to the latest version |
| [`install`](/cli/commands/config#install) | Install `vesslctl` to a directory in your PATH |


# CLI Quickstart
Source: https://docs.cloud.vessl.ai/cli/quickstart

Three common workflows to get productive with vesslctl in minutes.

<div>
  <Frame>
    <img alt="Welcome banner for VESSL Cloud CLI showing a VESSL ASCII wordmark, the supported GPU lineup (A100, H100, H200, B200, GB200, B300, Ada), and three starter commands: vesslctl auth login, vesslctl workspace create, vesslctl --help" />
  </Frame>
</div>

This page walks through three real scenarios you will encounter when working with VESSL Cloud from the terminal.

## Prerequisites

* **VESSL Cloud account**: [Sign up](https://cloud.vessl.ai/~/signup) if you do not have one.
* **`vesslctl` installed**: One-line install from the [CLI overview](/cli/overview#installation).
* **Authenticated**: Run `vesslctl auth login` to complete the browser OAuth flow.
* **SSH key** (optional, for workspace access): Register a key with `vesslctl ssh-key add`, or manage them via [SSH key commands](/cli/commands/ssh-key).
* **Credit balance**: Add a payment method and top up from [Billing](/admin/billing/credits). Workspace and job creation are blocked when the balance is zero or negative.

## Launch a GPU instance

Launch an interactive GPU workspace, connect over SSH, and pause it when you are done.

<Steps>
  <Step title="Create the workspace">
    ```bash theme={null}
    vesslctl workspace create \
      --name my-dev-box \
      --cluster <cluster-name> \
      --resource-spec <spec-name> \
      --image pytorch/pytorch:2.3.0-cuda12.1-cudnn8-devel
    ```

    Replace `<cluster-name>` and `<spec-name>` with values from `vesslctl cluster list` and `vesslctl resource-spec list`. After creation, copy the workspace slug from `vesslctl workspace list` (for example, `my-dev-box-abc123`) — you will use it in the next steps.
  </Step>

  <Step title="Check workspace status">
    ```bash theme={null}
    vesslctl workspace show <workspace-slug>
    ```

    Wait until the status shows **running**.
  </Step>

  <Step title="Connect using SSH">
    ```bash theme={null}
    vesslctl workspace ssh <workspace-slug>
    ```
  </Step>

  <Step title="Pause to save cost">
    When you are finished for the day, pause the workspace. Your files and environment are preserved at a lower cost.

    ```bash theme={null}
    vesslctl workspace pause <workspace-slug>
    ```
  </Step>

  <Step title="Resume later">
    Pick up where you left off:

    ```bash theme={null}
    vesslctl workspace start <workspace-slug>
    ```
  </Step>
</Steps>

***

## Upload a dataset

Create a volume, upload data from the CLI, and verify the contents.

<Steps>
  <Step title="Create a volume">
    ```bash theme={null}
    vesslctl volume create \
      --name training-data \
      --storage <storage-name> \
      --teams <team-name> \
      --description "ImageNet subset for fine-tuning"
    ```

    Replace `<storage-name>` with a storage backend from `vesslctl storage list` and `<team-name>` with a team from `vesslctl team list`. `--name`, `--storage`, and `--teams` are all required. After creation, copy the volume slug from `vesslctl volume list` (for example, `training-data-abc123`).
  </Step>

  <Step title="Upload your dataset">
    ```bash theme={null}
    vesslctl volume upload <volume-slug> ./dataset/
    ```

    Upload individual files or entire directories in one command. Use `--remote-prefix datasets/v1/` to place files under a specific path, or `--exclude "*.pyc"` to skip patterns.
  </Step>

  <Step title="Verify the upload">
    ```bash theme={null}
    vesslctl volume ls <volume-slug> --prefix /
    ```
  </Step>
</Steps>

<Info>
  Need S3-compatible access for DVC, `aws s3 cp`, or a custom pipeline? Run `vesslctl volume token <volume-slug>` to get temporary S3 credentials and an endpoint URL.
</Info>

***

## Submit a batch job

Submit a batch job, watch its progress, and pull the logs.

<Steps>
  <Step title="Submit the job">
    ```bash theme={null}
    vesslctl job create \
      --name nightly-train \
      --resource-spec <spec-name> \
      --image pytorch/pytorch:2.3.0-cuda12.1-cudnn8-devel \
      --cmd "python train.py --epochs 10 --lr 3e-4"
    ```
  </Step>

  <Step title="Check job status">
    ```bash theme={null}
    vesslctl job list
    ```
  </Step>

  <Step title="Stream the logs">
    ```bash theme={null}
    vesslctl job logs <job-slug> --follow
    ```

    Copy the job slug from `vesslctl job list` (such as `nightly-train-abc123`). The `--follow` flag streams logs in real time until the job completes.
  </Step>
</Steps>


# Run autoresearch in parallel
Source: https://docs.cloud.vessl.ai/examples/autoresearch

Use VESSL Cloud batch jobs to run karpathy/autoresearch with K experiments in parallel against one shared cache volume.

[karpathy/autoresearch](https://github.com/karpathy/autoresearch) is the "AI agent runs LLM training experiments overnight" experiment. The original loop is sequential. One local GPU, one experiment at a time.

This guide walks through the same workload on VESSL Cloud, where every experiment is a batch job and you can fan K of them out at once. The example is a vehicle for three VESSL Cloud patterns you can reuse for any agent-driven training loop:

* **One Object storage volume as a shared, read-only cache** so per-experiment startup pays no data-prep cost.
* **A batch job per experiment** instead of an interactive workspace, so submission is scriptable and the agent never holds a GPU lease.
* **K-way fan-out** to compress an N-experiment cycle into roughly N/K wall time.

The full code (agent program, helper scripts, results notebook) lives in the [autoresearch cookbook recipe](https://github.com/vessl-ai/vessl-cloud-cookbook/tree/main/autoresearch). This page focuses on the VESSL Cloud workflow.

<div>
  <Frame>
    <img alt="Comparison diagram: karpathy's sequential loop versus VESSL Cloud K-parallel fan-out" />
  </Frame>

  <small>Top: karpathy's original — single local GPU, strictly sequential agent loop. Bottom: VESSL adaptation — K parallel jobs sharing one read-only cache volume.</small>
</div>

## Why experiments run faster on the cloud

karpathy's loop has the agent edit code, train for \~5 minutes, check `val_bpb`, keep or revert, repeat. On a single local GPU the bottleneck is sequencing: one experiment at a time, no matter how cheap each one is.

On VESSL Cloud the same code runs as a batch job. Each job:

* Mounts a shared Object storage volume that holds the \~10 GB data cache.
* Boots in 3-4 minutes (image pull, dependency install, JIT compile).
* Trains for \~5 minutes and writes `val_bpb` to the log.

Because each job is independent, you can submit K of them at once. With K=4 on H100 SXM ×1, a 16-experiment cycle drops from \~2 hours of sequential compute to \~40 minutes of wall time. Same dollars, \~5× the throughput. The compute didn't get faster; the scheduling got parallel.

<Info>
  **The arithmetic.** On a single H100, sequential autoresearch lands roughly 12 experiments per hour. With K=4 fan-out on VESSL, the agent submits 4 jobs in parallel each round and waits for the slowest, landing about 28 experiments per hour aggregate. The cap shifts from "GPU availability" to "how many parallel jobs you choose to allow."
</Info>

## Prerequisites

* A VESSL Cloud account with credits ([sign up](https://cloud.vessl.ai/~/signup))
* An organization with access to **H100 SXM ×1** (or A100 SXM ×1; numbers below are for H100)
* `vesslctl` installed and authenticated (`vesslctl auth status`)
* Git, Python 3.11+, and a coding agent that can run shell commands (Claude Code, Codex, Cursor, and so on)

<Tip>
  New to VESSL Cloud? Complete the [Member quickstart](/guides/get-started/quickstart-user) first to set up your account, payment, and storage.
</Tip>

## Set up the recipe

<Steps>
  <Step title="Create a shared Object storage volume for the data cache">
    Every experiment in the loop reads the same \~10 GB pretraining data. Putting it on an Object storage volume means you download it once and every job after that mounts the cache read-only.

    ```bash theme={null}
    vesslctl volume create \
      --name autoresearch-cache \
      --storage <your-object-storage-slug> \
      --teams <your-team>

    vesslctl volume list
    export AUTORESEARCH_CACHE_VOLUME=objvol-...
    ```

    Find your object storage slug with `vesslctl storage list`. See [Create a volume](/member/volume/create) for the full creation flow.

    <Note>
      Object storage is the right fit here precisely because reads are slow but cheap, and the data is read-only after the initial population. For a training data hot path you would pick faster storage; for a cache that's filled once and reused thousands of times, you want shareability.
    </Note>
  </Step>

  <Step title="Run data prep once">
    Clone the cookbook locally and run the data-prep script. It downloads the FineWeb-Edu shard and writes it into the volume.

    ```bash theme={null}
    git clone https://github.com/vessl-ai/vessl-cloud-cookbook.git
    cd vessl-cloud-cookbook/autoresearch
    bash batch-job/prep.sh
    ```

    `prep.sh` submits a one-off batch job that mounts your cache volume and runs `prepare.py`. Once it finishes, every subsequent training job skips the download entirely.

    <Tip>
      You only need to re-run `prep.sh` if the data itself changes. The agent loop never touches the cache after this step.
    </Tip>
  </Step>

  <Step title="Submit a single experiment to verify the wiring">
    Before turning the agent loose, run one experiment by hand to confirm the recipe works in your account:

    ```bash theme={null}
    git checkout -b autoresearch/sanity-check
    bash batch-job/submit.sh > run.log 2>&1
    grep "^val_bpb:\|^peak_vram_mb:" run.log
    ```

    `submit.sh` pushes your branch, calls `vesslctl job create` with the cache volume mounted, polls until the job hits a terminal state, and pulls the logs back. If `val_bpb` shows up in `run.log`, the recipe is wired up correctly.
  </Step>

  <Step title="Fan out to K parallel experiments">
    Once a single job works, the agent can submit K candidates at once. The cookbook ships two helpers:

    | Script | What it does |
    | - | - |
    | `batch-job/submit-async.sh` | Submit one job and return the slug immediately. |
    | `batch-job/wait-jobs.sh slug1 slug2 ...` | Poll N slugs until all are terminal, then print each job's `val_bpb` and `peak_vram_mb`. |

    A typical "Mode B" round looks like:

    ```bash theme={null}
    SLUGS=$(for cfg in cfg1 cfg2 cfg3 cfg4; do
      git commit --allow-empty -m "try $cfg"
      bash batch-job/submit-async.sh
    done)

    bash batch-job/wait-jobs.sh $SLUGS
    ```

    The four jobs run on four independent GPUs simultaneously. The round finishes when the slowest one does.

    <Warning>
      Cap your concurrency in the VESSL Cloud console if you don't want every parallel round to use the full available GPU pool. The submitter does not enforce a limit; the cloud schedules whatever you submit.
    </Warning>
  </Step>
</Steps>

## What a research cycle looks like

A real 16-experiment, 4-round Mode B cycle (K=4) on H100 SXM ×1 (deneb-kr) is bundled with the recipe. The full data is in [`results.example.tsv`](https://github.com/vessl-ai/vessl-cloud-cookbook/blob/main/autoresearch/results.example.tsv); here is the summary:

| Round | Knob the agent tried | Best `val_bpb` | Verdict |
| - | - | - | - |
| 1 | `EMBEDDING_LR`, `WEIGHT_DECAY`, `WINDOW_PATTERN` | 1.0107 | None beat baseline |
| 2 | `MATRIX_LR 0.04 → 0.05` | 1.0081 | First improvement |
| 3 | `TOTAL_BATCH_SIZE 2^19 → 2^18` | 0.9986 | Smaller batch wins |
| 4 | On top of round 3, `DEPTH 8 → 10` | **0.9856** | Beats karpathy's 0.9979 reference |

Total spend: **\~\$5.10** (16 experiments × \~\$0.33 each at \$2.39/hr H100). Wall time: **\~40 minutes** (4 rounds × \~10 min each, K=4 jobs per round). The same work would take \~2 hours of sequential compute on a single local H100.

<div>
  <Frame>
    <img alt="Progress chart: best val_bpb per round across 16 experiments, K=4 fan-out, versus baseline" />
  </Frame>

  <small>Best `val_bpb` per round across the 16-experiment cycle. Starts at the baseline (1.0107) and lands at 0.9856 in round 4 — past karpathy's 0.9979 reference.</small>
</div>

<Tip>
  The analysis notebook ([`analysis.ipynb`](https://github.com/vessl-ai/vessl-cloud-cookbook/blob/main/autoresearch/analysis.ipynb)) is in the cookbook recipe. Drop your own `results.tsv` into the notebook to regenerate the chart for your run.
</Tip>

## Things worth knowing

* **Per-experiment overhead.** Each VESSL job pays \~3-4 minutes of startup (image pull, `uv sync` / torch reinstall, `train.py` compile) on top of the \~5-minute training budget. Sequential mode lands \~7 experiments/hour against \~12/hour on a dedicated local GPU; the win comes from K-way fan-out, not from per-experiment speed.
* **Branch hygiene.** The agent runs entirely on an `autoresearch/<tag>` branch and force-pushes to origin. Do not point two agents at the same tag; the second one will clobber the first's commits. Use one tag per agent session (for example, `opt-may7`, `arch-may7`).
* **Cost is unbounded by default.** A runaway loop is real spend. Set a daily concurrency cap in the cloud console and check `vesslctl billing show` if you're nervous.
* **GPU choice.** The cookbook defaults to H100 SXM ×1 (deneb-kr, \$2.39/hr). For a cheaper run set `AUTORESEARCH_RESOURCE_SPEC` to an A100 spec; numbers won't be directly comparable to the karpathy reference because flash-attn falls back on non-Hopper GPUs.

## Next steps

* **Read the full recipe** -- Code, agent program, and analysis notebook live in [vessl-ai/vessl-cloud-cookbook/autoresearch](https://github.com/vessl-ai/vessl-cloud-cookbook/tree/main/autoresearch).
* **Run multiple agents at once** -- Spawn N agent sessions on N different tags to research different directions in parallel. Combined with K-way fan-out per agent, you get N × K experiments per round.
* **Adapt the pattern to your own loop** -- The submit/wait scripts are generic. Swap `train.py` for any single-GPU training entrypoint, point the cache volume at your data, and the same K-fan-out approach works for hyperparameter sweeps, neural architecture search (NAS), or any agent-driven experiment loop.
* **Submit jobs from your CLI** -- See [`vesslctl job create`](/cli/quickstart) for the full job submission flow.


# Fine-tune Gemma 4
Source: https://docs.cloud.vessl.ai/examples/fine-tuning-gemma-4

A complete walkthrough for fine-tuning Gemma 4 E4B with QLoRA and Unsloth on a single A100 GPU.

This guide walks you through fine-tuning **Gemma 4 E4B** using **QLoRA** and **Unsloth** on VESSL Cloud. By the end, you will have a fine-tuned adapter saved to shared storage, ready for inference or team collaboration.

<Frame>
  <img alt="Google Gemma 4 official image" />
</Frame>

## Prerequisites

Before starting, make sure you have:

* A VESSL Cloud account with credits ([sign up](https://cloud.vessl.ai/~/signup))
* An organization with access to **A100 SXM 80 GB** GPU instances
* Basic familiarity with Python and Hugging Face Transformers

<Tip>
  New to VESSL Cloud? Complete the [Member quickstart](/guides/get-started/quickstart-user) first to set up your account, payment, and storage.
</Tip>

## Create a workspace

<Steps>
  <Step title="Set up storage volumes">
    You need two types of storage for this workflow:

    | Storage type | Mount path | Purpose |
    | - | - | - |
    | **Cluster storage** | `/root` | Home directory. Pip packages and conda environments persist across workspace restarts. |
    | **Object storage** | `/shared` | Model checkpoints and outputs. Accessible from any cluster, shareable with teammates. |

    **Why Cluster storage at `/root`?** Your home directory (`$HOME`) is where pip installs packages by default. Mounting Cluster storage here means you only run `pip install` once -- packages survive workspace pause/resume cycles.

    **Why Object storage at `/shared`?** Fine-tuned model weights need to be accessible from other workspaces or clusters. Object storage is S3-backed and reachable from anywhere, making it easy to share results with your team or deploy from a different region.

    Create both volumes before launching the workspace:

    * **Cluster storage**: Go to **Cluster storage** in the sidebar and click **Create new volume**. See [Storage overview](/admin/storage/overview) for details.
    * **Object storage**: Go to **Object storage** in the sidebar and click **Create new volume**. See [Create a volume](/member/volume/create) for details.

    <Warning>
      Do not mount Object storage at `/root`. Object storage is slower than Cluster storage and is not suitable as your primary workspace path. Use `/shared` or another separate mount point.
    </Warning>
  </Step>

  <Step title="Launch the workspace">
    Create a new workspace with the following configuration:

    | Setting | Value |
    | - | - |
    | **GPU** | A100 SXM 80 GB |
    | **GPU count** | 1 |
    | **Image** | `pytorch/pytorch:2.5.1-cuda12.4-cudnn9-devel` |
    | **Cluster storage** | Your cluster volume mounted at `/root` |
    | **Object storage** | Your object volume mounted at `/shared` |

    See [Create a workspace](/member/workspace/create) for the full creation flow.

    <Info>
      4-bit quantization (QLoRA) keeps VRAM usage around **18-22 GB** for the E4B model, well within the 80 GB available on an A100. This leaves headroom for larger batch sizes or longer sequences if needed.
    </Info>
  </Step>

  <Step title="Connect to the workspace">
    Once the workspace shows **Running**, connect using JupyterLab or SSH. See [Connect to a workspace](/member/workspace/connect).
  </Step>
</Steps>

## Install packages

Open a terminal in your workspace and install the required libraries:

```bash theme={null}
pip install unsloth trl transformers datasets
```

<Note>
  If you mounted Cluster storage at `/root`, these packages persist across workspace pause/resume. You only need to run this once.
</Note>

## Load the model

```python theme={null}
from unsloth import FastModel

model, tokenizer = FastModel.from_pretrained(
    model_name="unsloth/gemma-4-E4B-it",
    max_seq_length=2048,
    load_in_4bit=True,
    full_finetuning=False,
)
```

**What `load_in_4bit=True` does:** Instead of loading each parameter as a 16-bit float (the default), 4-bit quantization compresses the weights to 4 bits using the QLoRA (NF4) technique. This reduces the model's memory footprint by roughly 4x, allowing a model that would normally require \~32 GB of VRAM to fit in \~8-10 GB. The quality loss is minimal because only the frozen base weights are quantized -- the LoRA adapter trains in full precision.

<div>
  <Frame>
    <img alt="nvidia-smi during training, peak VRAM around 11 GB on an A100 80 GB" />
  </Frame>

  <small>Peak VRAM running this guide on an A100 80 GB — about 11 GB (13.7%). Plenty of headroom to grow the batch size or sequence length.</small>
</div>

## Configure LoRA adapter

```python theme={null}
model = FastModel.get_peft_model(
    model,
    finetune_vision_layers=False,
    finetune_language_layers=True,
    finetune_attention_modules=True,
    finetune_mlp_modules=True,
    r=8,
    lora_alpha=8,
    lora_dropout=0,
    bias="none",
    random_state=3407,
)
```

### Hyperparameter reference

| Parameter | Value | Explanation |
| - | - | - |
| `r` | `8` | **LoRA rank** -- controls the capacity of the low-rank adapter. Higher values (16, 32) capture more complex patterns but use more memory and risk overfitting on small datasets. Start with 8 for general tasks. |
| `lora_alpha` | `8` | **Scaling factor** -- controls how much the adapter output is amplified. Typically set equal to `r`. The effective learning rate of the adapter scales as `lora_alpha / r`. |
| `lora_dropout` | `0` | **Dropout rate** -- probability of zeroing adapter outputs during training. Set to 0 for small datasets; increase to 0.05-0.1 if you see overfitting on larger datasets. |
| `finetune_vision_layers` | `False` | Gemma 4 is a multimodal model. Set to `False` for text-only training to skip vision encoder layers entirely. |
| `finetune_language_layers` | `True` | Train the language model layers. |
| `finetune_attention_modules` | `True` | Train the attention (Q, K, V, O) projection matrices. |
| `finetune_mlp_modules` | `True` | Train the feed-forward (MLP) layers. Together with attention modules, this covers the most impactful parts of the model. |
| `bias` | `"none"` | Do not train bias terms. Keeps the adapter small without measurable quality loss. |
| `random_state` | `3407` | Random seed for reproducibility. |

<Tip>
  **When to increase `r`:**

  * **Complex domain adaptation** (medical, legal, code): try `r=16`
  * **Large, diverse datasets** (100k+ samples): try `r=16` or `r=32`
  * **Simple style transfer or format following**: `r=8` is usually sufficient
</Tip>

## Prepare the dataset

This example uses the **FineTome-100k** dataset with 3,000 samples for a quick demo. For production use, train on the full dataset or substitute your own data.

```python theme={null}
from unsloth.chat_templates import get_chat_template, standardize_data_formats
from datasets import load_dataset

tokenizer = get_chat_template(tokenizer, chat_template="gemma-4")
dataset = load_dataset("mlabonne/FineTome-100k", split="train[:3000]")
dataset = standardize_data_formats(dataset)

def formatting_prompts_func(examples):
    convos = examples["conversations"]
    texts = [
        tokenizer.apply_chat_template(
            convo, tokenize=False, add_generation_prompt=False
        ).removeprefix("<bos>")
        for convo in convos
    ]
    return {"text": texts}

dataset = dataset.map(formatting_prompts_func, batched=True)
```

<Accordion title="Using your own data">
  Your dataset should be a JSON file where each entry has a `conversations` field -- a list of message objects with `role` and `content`:

  ```json theme={null}
  [
    {
      "conversations": [
        {"role": "user", "content": "What is the capital of France?"},
        {"role": "assistant", "content": "The capital of France is Paris."}
      ]
    },
    {
      "conversations": [
        {"role": "user", "content": "Explain photosynthesis briefly."},
        {"role": "assistant", "content": "Photosynthesis is the process by which plants convert sunlight, water, and CO2 into glucose and oxygen."}
      ]
    }
  ]
  ```

  Load it with:

  ```python theme={null}
  dataset = load_dataset("json", data_files="/shared/my-data.json", split="train")
  dataset = standardize_data_formats(dataset)
  dataset = dataset.map(formatting_prompts_func, batched=True)
  ```
</Accordion>

<Note>
  The 3,000-sample subset is for demonstration only. For meaningful quality improvements, use the full 100k dataset or at least 10k-20k high-quality samples of your own data.
</Note>

## Train

```python theme={null}
from trl import SFTTrainer, SFTConfig
from unsloth.chat_templates import train_on_responses_only

trainer = SFTTrainer(
    model=model,
    tokenizer=tokenizer,
    train_dataset=dataset,
    args=SFTConfig(
        dataset_text_field="text",
        per_device_train_batch_size=1,
        gradient_accumulation_steps=4,
        warmup_steps=5,
        max_steps=60,
        learning_rate=2e-4,
        logging_steps=1,
        optim="adamw_8bit",
        weight_decay=0.001,
        lr_scheduler_type="linear",
        seed=3407,
        report_to="none",
        output_dir="/shared/gemma4-finetuned",
    ),
)

trainer = train_on_responses_only(
    trainer,
    instruction_part="<|turn>user\n",
    response_part="<|turn>model\n",
)

trainer_stats = trainer.train()
```

### Training parameter reference

| Parameter | Value | Explanation |
| - | - | - |
| `per_device_train_batch_size` | `1` | Number of samples per GPU per forward pass. Kept at 1 to fit within VRAM. |
| `gradient_accumulation_steps` | `4` | Accumulate gradients over 4 steps before updating weights. **Effective batch size = 1 x 4 = 4.** |
| `warmup_steps` | `5` | Linearly ramp up learning rate for the first 5 steps to stabilize early training. |
| `max_steps` | `60` | Total training steps. This is for demo purposes -- for full training runs, remove `max_steps` and set `num_train_epochs=1` (or more). |
| `learning_rate` | `2e-4` | Standard learning rate for QLoRA fine-tuning. |
| `optim` | `"adamw_8bit"` | 8-bit AdamW optimizer. Uses quantized optimizer states to save \~2 GB of VRAM compared to standard AdamW. |
| `weight_decay` | `0.001` | L2 regularization to prevent overfitting. |
| `lr_scheduler_type` | `"linear"` | Linearly decay the learning rate to zero over training. |
| `report_to` | `"none"` | Disable external logging such as Weights & Biases. Set to `"wandb"` if you want experiment tracking. |
| `output_dir` | `"/shared/gemma4-finetuned"` | Save checkpoints to Object storage so they persist and are shareable. |

**What `train_on_responses_only` does:** By default, the loss is computed over the entire conversation (user + assistant turns). This option masks the user turns so the model only learns to generate the assistant responses. This improves training efficiency and prevents the model from memorizing user prompts.

## Evaluate

After training, check how the model performs qualitatively and quantitatively.

### Check training loss

The `trainer_stats` object contains the training log. A decreasing loss curve indicates the model is learning:

```python theme={null}
import json

# Print final training loss
print(f"Final training loss: {trainer_stats.training_loss:.4f}")

# Inspect per-step loss from the log history
for entry in trainer_stats.log_history[-5:]:
    if "loss" in entry:
        print(f"  Step {entry['step']}: loss = {entry['loss']:.4f}")
```

<Tip>
  A healthy loss curve starts high (2-3+) and decreases steadily. If loss plateaus very early, consider increasing `r` or using more data. If loss spikes or diverges, reduce the learning rate.
</Tip>

<div>
  <Frame>
    <img alt="60-step training loss decreasing steadily from around 2.37" />
  </Frame>

  <small>Actual 60-step training log from this guide. Starts around 2.37 and trends down — the textbook shape for a small SFT run.</small>
</div>

### Compare before and after

Run the same prompt through the fine-tuned model to see the effect:

```python theme={null}
from transformers import TextStreamer

messages = [
    {"role": "user", "content": [
        {"type": "text", "text": "Explain quantum computing in simple terms."}
    ]}
]

_ = model.generate(
    **tokenizer.apply_chat_template(
        messages,
        add_generation_prompt=True,
        tokenize=True,
        return_dict=True,
        return_tensors="pt",
    ).to("cuda"),
    max_new_tokens=256,
    use_cache=True,
    temperature=0.7,
    streamer=TextStreamer(tokenizer, skip_prompt=True),
)
```

<Accordion title="Evaluating on a held-out test split">
  For a more rigorous evaluation, split your data upfront and compute loss on the held-out portion:

  ```python theme={null}
  # Before training, split the dataset
  split = dataset.train_test_split(test_size=0.1, seed=3407)
  train_dataset = split["train"]
  eval_dataset = split["test"]

  # Pass eval_dataset to SFTTrainer
  trainer = SFTTrainer(
      model=model,
      tokenizer=tokenizer,
      train_dataset=train_dataset,
      eval_dataset=eval_dataset,
      args=SFTConfig(
          # ... same args as above, plus:
          eval_strategy="steps",
          eval_steps=20,
          # ...
      ),
  )
  ```

  This reports evaluation loss at regular intervals, letting you detect overfitting (training loss decreases but eval loss increases).
</Accordion>

## Save the model

Save the fine-tuned adapter and tokenizer to Object storage:

```python theme={null}
model.save_pretrained("/shared/gemma4-finetuned/final")
tokenizer.save_pretrained("/shared/gemma4-finetuned/final")
```

Since `/shared` is backed by Object storage, the saved model is:

* **Persistent** -- survives workspace termination
* **Cross-cluster** -- accessible from workspaces in any region
* **Team-shareable** -- any team member with access to the volume can load the adapter

<div>
  <Frame>
    <img alt="Adapter and tokenizer files written to /shared/gemma4-finetuned/final/ after training" />
  </Frame>

  <small>Adapter and tokenizer files saved to `/shared/gemma4-finetuned/final/` after training. Backed by Object storage, so any teammate's workspace — in any region — can mount and load them as-is.</small>
</div>

To load the adapter later from another workspace:

```python theme={null}
from unsloth import FastModel

model, tokenizer = FastModel.from_pretrained(
    model_name="unsloth/gemma-4-E4B-it",
    max_seq_length=2048,
    load_in_4bit=True,
    full_finetuning=False,
)

from peft import PeftModel
model = PeftModel.from_pretrained(model, "/shared/gemma4-finetuned/final")
```

## Gemma 4 model comparison

Choose the right Gemma 4 variant based on your GPU and task complexity:

| Model | Parameters | Recommended GPU | QLoRA VRAM estimate | Best for |
| - | - | - | - | - |
| **Gemma 4 E2B** | 2B | T4 16 GB, L4 24 GB | \~6-8 GB | Quick experiments, edge deployment |
| **Gemma 4 E4B** | 4B | A100 40/80 GB, L4 24 GB | \~10-14 GB | Best balance of quality and efficiency |
| **Gemma 4 12B** | 12B | A100 80 GB | \~18-24 GB | Higher quality, single-GPU fine-tuning |
| **Gemma 4 27B** | 27B | A100 80 GB (tight), 2xA100 | \~32-40 GB | Near-frontier quality, requires more VRAM |

<Info>
  VRAM estimates assume 4-bit quantization with QLoRA, batch size 1, and sequence length 2048. Actual usage varies with batch size, sequence length, and gradient accumulation settings.
</Info>

## Next steps

* **Get the runnable recipe** -- A packaged version of this workflow (an interactive notebook plus a `vesslctl` batch-job path, trained on a small domain QA dataset) lives in the [gemma4-finetuning cookbook recipe](https://github.com/vessl-ai/vessl-cloud-cookbook/tree/main/gemma4-finetuning), with measured cost and VRAM benchmarks.
* **Use your own data** -- Replace FineTome-100k with domain-specific conversation data for targeted improvements.
* **Try DPO or ORPO** -- After SFT, apply preference optimization (DPO/ORPO) to further align the model with desired behavior.
* **Scale up** -- Move to the 12B or 27B model for higher quality. Use `r=16` or `r=32` with larger datasets.
* **Export to GGUF** -- Convert the fine-tuned model to GGUF format for local inference with llama.cpp or Ollama.
* **Deploy as a batch job** -- Use [VESSL Cloud batch jobs](/member/job/overview) to run fine-tuning as a scheduled, reproducible pipeline.
* **Automate with vesslctl** -- Turn this interactive run into a one-line command with [`vesslctl job create`](/cli/quickstart). Swap the Jupyter cells for a `train.py` and submit it from your terminal or a CI pipeline.


# Train a point-in-time finance LLM
Source: https://docs.cloud.vessl.ai/examples/point-in-time-finance-llm

Continue pretraining Qwen3.5-35B on a date-clipped corpus with VESSL Cloud batch jobs, then measure how much look-ahead leakage inflates a financial prediction score.

Open-web LLMs look better at financial prediction than they are: their pretraining corpus already contains future information relative to any historical test window, so part of the score is look-ahead leakage rather than skill. The remedy studied in [Kelly, Malamud, Schwab & Xu, "Scaling Point-in-Time Language Models" (SSRN 6681860)](https://ssrn.com/abstract=6681860) is point-in-time training: only train on text published before a hard cutoff date.

This guide walks through a small, reproducible version of that idea on VESSL Cloud. The recipe continues pretraining `Qwen/Qwen3.5-35B-A3B-Base` on a FineWeb slice clipped to Common Crawl dumps published on or before 2017-06-30, then measures the **leakage premium** on Japanese equities -- the R² gap between an honest chronological split and a stock-disjoint split that lets temporal leakage back in.

The example is a vehicle for three VESSL Cloud patterns you can reuse for any long-running training workload:

* **One Object storage volume as the persistent backbone.** The tokenized corpus, the evaluation data, and the trained checkpoints all live on a single volume that every batch job mounts.
* **Terminal-driven training with `vesslctl`.** Edit `train.py` locally, submit with a wrapper script, and read metrics back from the job logs. No notebook, and no GPU lease held while you think.
* **Two arms on the same primitives.** A single-H100 LoRA arm and an 8-GPU full-weight arm share the base model, the data, and the evaluation, so "train 2.6% of the parameters" and "train 100% of the parameters" can be compared head-to-head.

The full code lives in the [aqr-finance cookbook recipe](https://github.com/vessl-ai/vessl-cloud-cookbook/tree/main/aqr-finance). This page focuses on the VESSL Cloud workflow.

<div>
  <Frame>
    <img alt="Diagram of the two recipe arms: a single-H100 LoRA job and an 8-GPU full-weight FSDP2 job, both mounting one Object storage volume and scored by the same leakage evaluation" />
  </Frame>

  <small>One recipe, two arms. Both training jobs mount the same Object storage volume, and the same `eval.py` scores the LoRA adapter and the full-weight checkpoint, so the two arms are directly comparable.</small>
</div>

<Info>
  **What this experiment found.**

  1. **Leakage is real.** Both the base model and the continued-pretrained checkpoint show a statistically significant leakage premium on Kaggle JPX equities (both 95% CIs exclude zero).
  2. **One continued-pretraining pass does not significantly reduce it.** Both the LoRA and full-weight arms have a `premium_reduction` CI that includes zero.
  3. **The evaluation protocol is the next lever.** A ChronoGPT control showed the premium is nearly independent of the base model's knowledge cutoff year, which implies evaluation construction drives much of the signal.

  The [companion blog post](https://vessl.ai/en/blog/point-in-time-finance-llm-8xh100?utm_source=docs\&utm_medium=cross-link\&utm_campaign=aqr-multigpu-2026-06\&utm_content=intro-findings) covers the full analysis — ChronoGPT control, robustness checks, and what it means for a trading firm.
</Info>

## Prerequisites

* A VESSL Cloud account with credits ([sign up](https://cloud.vessl.ai/~/signup))
* An organization with access to **H100 SXM ×1** for the LoRA arm; the full-weight arm additionally needs a single-node **H100 SXM ×8** spec
* `vesslctl` installed and authenticated (`vesslctl auth status`)
* Git and a local shell -- the submit scripts run on your machine and shell out to `vesslctl`
* Kaggle credentials for the evaluation data -- export `KAGGLE_USERNAME` and `KAGGLE_KEY` before data prep so the job can download the [JPX Tokyo Stock Exchange Prediction](https://www.kaggle.com/competitions/jpx-tokyo-stock-exchange-prediction) dataset

<Tip>
  New to VESSL Cloud? Complete the [Member quickstart](/guides/get-started/quickstart-user) first to set up your account, payment, and storage.
</Tip>

## Run the single-H100 LoRA arm

<Steps>
  <Step title="Create the cache volume">
    Everything that must survive between jobs -- the tokenized FineWeb shards, the JPX prices, the trained adapter -- lives on one Object storage volume:

    ```bash theme={null}
    vesslctl volume create \
      --name aqr-finance-cache \
      --storage <your-object-storage-slug> \
      --teams <your-team>

    vesslctl volume list
    export AQR_CACHE_VOLUME=objvol-...
    ```

    Then pick a single-H100 resource spec for the training job:

    ```bash theme={null}
    vesslctl resource-spec list
    export AQR_RESOURCE_SPEC=resourcespec-...
    ```

    <Warning>
      The volume mount is a hard prerequisite, not an optimization. A batch job's own disk is ephemeral -- anything written there is gone when the pod terminates. A 23-hour training run that saves its checkpoint to ephemeral disk produces nothing you can evaluate.
    </Warning>
  </Step>

  <Step title="Run data prep once">
    Clone the cookbook and submit the one-off prep job. It streams FineWeb, keeps only Common Crawl dumps published on or before 2017-06-30, tokenizes the text with the Qwen3.5 tokenizer, and writes the shards to the volume:

    ```bash theme={null}
    git clone https://github.com/vessl-ai/vessl-cloud-cookbook.git
    cd vessl-cloud-cookbook/aqr-finance
    bash batch-job/prep.sh
    ```

    The prep job runs on a CPU spec in 30-60 minutes. Every training job after this mounts the same cache and skips data prep entirely.
  </Step>

  <Step title="Submit the training batch job">
    Each run lives on its own branch, so the container clones exactly the code you submitted:

    ```bash theme={null}
    git checkout -b aqr-finance/my-run
    bash batch-job/submit.sh > run.log 2>&1
    grep "^r2_leakage_off:\|^r2_leakage_on:\|^val_loss_final:\|^peak_vram_mb:" run.log
    ```

    `submit.sh` pushes your branch, calls `vesslctl job create` with the cache volume mounted at `/root/.cache/aqr-finance`, polls until the job reaches a terminal state, and writes the full job log to `run.log`. Inside the container, the job clones your branch, installs dependencies, runs `python train.py` (about 23 hours on one H100), then `python eval.py` (about 2 hours). To try a variant, edit `train.py`, commit on a fresh `aqr-finance/<tag>` branch, and rerun `submit.sh`.

    <Note>
      The 35B Mixture-of-Experts (MoE) base trains as a single process on one H100 80 GB: LoRA touches about 945M parameters (\~2.6%) and VRAM peaks around 74 GB. The LoRA target list is the recipe's main gotcha -- Qwen3.5 mixes Gated DeltaNet and standard attention layers, and targeting only the standard `q/k/v/o` projections freezes 75% of the model, so the loss diverges. The [cookbook README](https://github.com/vessl-ai/vessl-cloud-cookbook/tree/main/aqr-finance#lora-target-list--why-it-has-12-entries-instead-of-4) documents the verified 12-entry target list.
    </Note>
  </Step>
</Steps>

## What a run costs and reports

Measured on VESSL Cloud, H100 SXM ×1. The full table is in the cookbook's [`benchmarks.md`](https://github.com/vessl-ai/vessl-cloud-cookbook/blob/main/aqr-finance/benchmarks.md):

| Metric | Value |
| - | - |
| Wall time | \~23 h train + \~2 h eval |
| Cost | \~\$60 (\~\$56 train + \~\$4 eval at \$2.39/hr) |
| Peak VRAM | \~74 GB |
| Trained parameters | \~945M (\~2.6%) |
| Final train loss | 2.26 |

The evaluation builds a date-conditional embedding for each (stock, date) pair, fits a Ridge regression to next-day returns, and reports R² on two splits:

* **Chronological split** -- train on years up to 2020, test on 2021 and later. This is the honest score; no future information can leak in.
* **Stock-disjoint GroupKFold split** -- a stock never appears in both train and test, so memorizing stock identities earns nothing, but time periods mix freely, which lets temporal leakage back in.

The gap between the two is the leakage premium, and a clustered bootstrap over stocks puts a 95% confidence interval (CI) on it:

* **Leakage is real.** The premium is statistically significant for both the base model (0.22) and the LoRA adapter (0.14); both CIs exclude zero.
* **One pass does not remove it.** The premium reduction (0.08) has a CI of \[-0.04, 0.32], which crosses zero. Treat the recipe as a measuring instrument, not a leakage fix.

## Scale up to the 8-GPU full-weight arm

A single 80 GB H100 physically cannot full-weight train a 35B model: weights, gradients, and optimizer state alone exceed 140 GB. The companion [multigpu recipe](https://github.com/vessl-ai/vessl-cloud-cookbook/tree/main/aqr-finance/multigpu) shards them with FSDP2 (PyTorch Fully Sharded Data Parallel) across a single H100 SXM ×8 node using axolotl, training all 35B parameters at about 51 GB per GPU:

```bash theme={null}
export AQR_CACHE_VOLUME=objvol-...        # the same volume as the LoRA arm
export AQR_RESOURCE_SPEC=resourcespec-... # an 8-GPU H100 SXM single-node spec
bash multigpu/stage3_real_v2_submit.sh
```

From the platform side this is the same pattern as the LoRA arm -- one batch job, one volume mount, metrics from the job logs:

| | LoRA arm | Full-weight arm |
| - | - | - |
| GPU | H100 SXM ×1 | H100 SXM ×8 (single node) |
| Trained parameters | \~945M (\~2.6%) | 35B (100%) |
| Wall time | \~23 h | \~18.6 h |
| Cost | \~\$60 | \~\$386 |
| Peak VRAM | \~74 GB | \~51 GB per GPU |

<Note>
  The FSDP2 configuration that makes a 35B full-weight run fit on 8×80 GB is non-obvious: gradient accumulation must stay at 1 (anything higher accumulates unsharded full-model gradients and blows the VRAM budget), 8-bit optimizers fail on FSDP2's DTensor, turning activation checkpointing off trades \~9 GB of headroom for about +32% throughput, and the checkpoint merge has to run as a separate single-GPU batch job to avoid NCCL watchdog timeouts. The [multigpu README](https://github.com/vessl-ai/vessl-cloud-cookbook/tree/main/aqr-finance/multigpu#key-fsdp2-config-invariants) documents each invariant.
</Note>

Because both arms share `eval.py`, the full-weight checkpoint and the LoRA adapter are scored on an identical measurement:

<div>
  <Frame>
    <img alt="Forest plot of the leakage premium with bootstrap 95% confidence intervals: base model 0.20, full-weight checkpoint 0.13, and a reduction of 0.07 whose interval crosses zero" />
  </Frame>

  <small>Bootstrap median and 95% CI from the full-weight arm's evaluation (1,000 stocks). The premium is significant for both models, but the reduction's interval crosses zero -- even training all 35B parameters did not significantly cut the premium relative to the base model, matching the LoRA arm's result.</small>
</div>

## Things worth knowing

* **Per-run cost is real.** \~\$60 for the LoRA arm and \~\$386 for the full-weight arm, per run. At \~23 hours, a LoRA run is effectively a full-day slot -- treat each run as expensive, and check spend with `vesslctl billing show`.
* **This is a measurement, not an alpha recipe.** Both arms' chronological R² values are negative -- neither model predicts JPX returns out-of-sample, which is expected for a leakage probe.
* **More trainable parameters did not reduce leakage.** The full-weight arm's premium reduction (0.07, CI \[-0.06, 0.22]) also crosses zero. On this measurement, the lever is the evaluation protocol, not the trainable-parameter count.
* **The leakage measurement has its own precision limits.** GroupKFold separates by stock identity but lets dates mix across folds, so the measured premium includes both temporal leakage and evaluation-construction noise. Embargoed and walk-forward robustness checks confirm the premium is real and not a split-edge artifact -- but replacing the leaky-side GroupKFold with a purged time-series CV (a rolling window with a date-embargo gap) is still the open refinement lever. The [companion blog post](https://vessl.ai/en/blog/point-in-time-finance-llm-8xh100?utm_source=docs\&utm_medium=cross-link\&utm_campaign=aqr-multigpu-2026-06\&utm_content=things-to-know) covers the ChronoGPT control experiment and the robustness checks in detail.
* **Kaggle credentials must be staged before prep.** If `prep.sh` skipped the JPX download, `eval.py` refuses to run. Export `KAGGLE_USERNAME` and `KAGGLE_KEY` before running `prep.sh` (the script forwards them into the container), or stage `stock_prices.csv` on the cache volume manually.
* **The base model needs `trust_remote_code=True`.** Qwen3.5's hybrid DeltaNet and Gated Attention architecture is not yet upstream in `transformers`. Pin the model revision for production use.
* **Branch hygiene.** Every run pushes its own `aqr-finance/<tag>` branch to origin. Use a fresh tag per run so reruns don't clobber an earlier run's commits.

## Next steps

* **Read the full analysis** -- The [companion blog post](https://vessl.ai/en/blog/point-in-time-finance-llm-8xh100?utm_source=docs\&utm_medium=cross-link\&utm_campaign=aqr-multigpu-2026-06\&utm_content=next-steps) covers the ChronoGPT control experiment, the embargoed and walk-forward robustness checks, the LoRA vs full-weight comparison, and what the results mean for a trading firm.
* **Read the full recipe** -- Training scripts, submit helpers, and measured benchmarks live in [vessl-ai/vessl-cloud-cookbook/aqr-finance](https://github.com/vessl-ai/vessl-cloud-cookbook/tree/main/aqr-finance), with the full-weight arm in [aqr-finance/multigpu](https://github.com/vessl-ai/vessl-cloud-cookbook/tree/main/aqr-finance/multigpu).
* **Read the background** -- Kelly, Malamud, Schwab & Xu, ["Scaling Point-in-Time Language Models"](https://ssrn.com/abstract=6681860), and He, Lv, Manela & Wu, ["Chronologically Consistent Large Language Models"](https://arxiv.org/abs/2502.21206).
* **Port the pattern to your domain** -- A date-clipped corpus on a shared volume, batch-job continued pretraining, and a leakage check on a downstream task apply anywhere look-ahead bias matters: news sentiment, medical records, recommendation logs.
* **Submit batch jobs from your CLI** -- See [`vesslctl job create`](/cli/quickstart) for the full job submission flow.


# Glossary
Source: https://docs.cloud.vessl.ai/guides/get-started/glossary

Canonical terms used in VESSL Cloud docs.

## Organization

The top-level entity that owns billing, clusters, teams, and policies. Admins manage organization-wide settings and resources.

## Team

A logical grouping of members who share resources such as storage volumes and cost controls. Teams enable collaboration within an organization.

## Admin

An organization-level role with permissions to manage members, teams, volumes, billing, and policies. Admins have organization-wide scope.

## Member

A user role with permissions to create and use workspaces, use team volumes, and accept team invites. Members operate within their assigned teams.

## Workspace

An isolated, containerized environment with GPU/CPU where you develop and run code. You can open Jupyter notebooks or connect using SSH in a workspace.

## Job

A batch compute task that runs a command to completion on specified resources. Unlike workspaces, jobs are non-interactive: they execute, produce output, and terminate automatically. Use jobs for training, batch inference, data preprocessing, and hyperparameter sweeps. (Formerly called "Run.")

## Workload

A generic term for any compute unit that runs on VESSL Cloud. Covers both workspaces and jobs. When specificity matters, prefer "workspace" or "job."

## Volume

A persistent storage resource managed by VESSL Cloud. Volumes can be attached to workspaces to store data, datasets, models, and artifacts.

## Cluster storage

High-availability distributed storage (CephFS/NVMe) bound to a specific cluster. Supports read-write-many (RWX) semantics — multiple workspaces on the same cluster can share the storage simultaneously. Data persists even after workspace termination. \~150 MB/s throughput. Replaces the legacy "Workspace volume."

## Object storage

S3-backed, POSIX-compatible storage that can be shared across teams and multiple workspaces across any cluster. Uses read-write-many (RWX) semantics for concurrent access. \~150 MB/s throughput. Previously called "Shared volume."

## Workspace volume (deprecated)

A legacy per-workspace persistent volume with read-write-once (RWO) semantics. Replaced by Cluster storage. Contact [support@vessl.ai](mailto:support@vessl.ai) for migration assistance.

## Temporary storage

Ephemeral storage included in every workspace session. Data is cleared when the workspace stops or terminates.

## Cluster

The compute backend that schedules GPU/CPU resources for your workspaces. Clusters provide the infrastructure for running workspaces.

## Jupyter Notebook

An interactive environment for writing and running code cells. On VESSL Cloud, Jupyter runs inside a workspace and is accessible in the browser.

## SSH

Secure Shell protocol for terminal access to your workspace. Useful for CLI workflows and advanced debugging.

## Connect

The workspace tab from which you open JupyterLab or fetch SSH connection instructions.

## Billing states

Workspaces have three billing states that affect cost:

* **Running**: compute is billed while the workspace is active
* **Paused**: compute is stopped; Cluster storage charges continue to apply
* **Terminated**: the workspace is deleted; no further charges accrue

## GPU

Graphics Processing Unit, a specialized processor originally designed for rendering graphics but now widely used for machine learning. GPUs can perform many calculations in parallel, making them ideal for training and running AI models. VESSL Cloud provides on-demand access to various GPU types (like NVIDIA A100, H100) for your workloads.

## Docker

A container platform for packaging and running workspace environments. Docker images help ensure consistent environments across teams and projects.

## Resource spec

A predefined hardware configuration specifying GPU type, CPU cores, memory, and Temporary storage. When creating a workspace, you select a resource spec in three steps — GPU product, region, and GPU count — to match your computational needs. Each option shows availability status and estimated hourly cost.

## Credit

Prepaid balance used to pay for VESSL Cloud resources. Credits are consumed based on workspace runtime and resource usage. You can top up credits through the billing page.

## Credit buffer

A **\$10** negative balance allowance before workspace termination. If your credits run out, workspaces continue running until the balance reaches **-\$10**. This buffer amount is deducted from your next top-up.

## Container image

A packaged environment containing the operating system, libraries, and tools needed to run your code. VESSL Cloud offers official images such as PyTorch and CUDA, or you can use custom images. Images ensure consistent, reproducible environments.

## Port

A network endpoint for accessing services running inside your workspace. You can expose custom ports (HTTP, TCP) to access web servers, APIs, or other applications from outside the workspace.

## Mount path

The directory location where storage is attached in your workspace file system. Cluster storage mount paths are user-configurable (common choices: `/root`, `/data`). Object storage must not be mounted at `/root`; use `/shared` or another separate path.

## PyTorch

A popular open-source deep learning framework developed by Meta. VESSL Cloud provides pre-configured PyTorch images so you can start training models immediately without setup.

## CUDA

NVIDIA's parallel computing platform and toolkit for GPU acceleration. CUDA enables software to use NVIDIA GPUs for general-purpose processing, essential for most deep learning workloads.

## pip

The standard package manager for Python. Use pip to install libraries and dependencies (for example, `pip install numpy`). Install packages in a persistent volume to preserve them across workspace restarts.

## conda

An open-source environment and package manager for Python and other languages. Conda can create isolated environments with specific Python versions and dependencies, useful for managing complex ML projects.

## OOMKilled

Out of Memory Killed. An error that occurs when your workspace exceeds its allocated memory, causing the system to terminate the process. If you see this error, consider using a resource spec with more memory.

## NVMe

Non-Volatile Memory Express, a high-performance storage protocol. Cluster storage uses NVMe/CephFS for fast read/write speeds (\~150 MB/s), ideal for loading large datasets and model checkpoints.

## S3

Amazon Simple Storage Service, a cloud Object storage service. Object storage in VESSL Cloud is backed by S3, providing scalable and durable storage that can be accessed from multiple workspaces and clusters simultaneously.

## Home dashboard

A personal overview page showing your active workloads, GPU usage, and spend rate across all teams you belong to.

## Organization dashboard

An admin-only overview page showing organization-wide GPU utilization, spend trends, team breakdown, and workload status.

## GPU Idle

A workload state where GPU utilization remains at **0%** for **three or more hours**. Displayed as an `Idle (3hr)` badge on the Organization dashboard.

## GPU under-utilization

A workload state where GPU utilization falls below a configured threshold. Triggers an alert banner on the Home dashboard recommending resource adjustment.

## Spend rate

The current hourly cost of running GPU resources, expressed in \$/hr. Visible on both the Home dashboard and Organization dashboard.

## vesslctl

The VESSL Cloud command-line interface. Use `vesslctl` to manage workspaces, jobs, storage, organizations, and teams from your terminal. Always written in `inline code` in prose. See the [CLI overview](/cli/overview) to get started.

## slug

A human-readable unique identifier for resources (for example, `my-workspace-abc123`). Slugs appear in CLI commands and URLs instead of numeric IDs. Prefer "slug" over "ID" when documenting CLI commands.


# Introduction
Source: https://docs.cloud.vessl.ai/guides/get-started/introduction

What VESSL Cloud is, why it matters, and how it works at a glance.

<div>
  <img alt="" />

  <img alt="" />

  <div>
    ## <span>VESSL Cloud<br />Documentation</span>
  </div>
</div>

VESSL Cloud lets you access GPUs on demand without managing infrastructure. Launch a workspace, connect using JupyterLab or SSH, and collaborate using shared storage.

### Why VESSL Cloud

* **Instant**: launch GPU instances with JupyterLab and SSH in a few clicks
* **Consistent**: Docker-based images ensure identical environments across teams and projects
* **Scalable**: scale GPU specs or count as needed; pause or terminate when done
* **Collaborative**: share data and models with team volumes
* **Cost visibility**: clear billing states for running, paused, and terminated workspaces

<CardGroup>
  <Card title="Quickstart" icon="rocket" href="/guides/get-started/quickstart-user">
    Create your first Workspace in minutes.
  </Card>

  <Card title="Organization" icon="users" href="/admin/organization/overview">
    Admin scope, policies, billing, responsibilities.
  </Card>

  <Card title="Team" icon="users" href="/admin/teams/overview">
    Collaboration model and shared resources.
  </Card>

  <Card title="Workspace (Run GPU instances)" icon="layer-group" href="/member/workspace/overview">
    GPU/CPU containers and cost controls.
  </Card>

  <Card title="vesslctl CLI" icon="terminal" href="/cli/overview">
    Manage everything from your terminal — workspaces, batch jobs, storage, and more.
  </Card>
</CardGroup>

## More in introduction

<CardGroup>
  <Card title="Roles & permissions" icon="shield" href="/admin/roles-permissions">
    Admin vs Member responsibilities and scopes.
  </Card>

  <Card title="Cluster" icon="clouds" href="/admin/cluster/overview">
    GPU/CPU execution environments for workspaces.
  </Card>

  <Card title="Storage" icon="database" href="/member/volume/overview">
    Cluster storage vs Object storage.
  </Card>

  <Card title="Billing" icon="credit-card" href="/admin/billing/overview">
    Credit model and cost states.
  </Card>
</CardGroup>


# Admin
Source: https://docs.cloud.vessl.ai/guides/get-started/quickstart-admin

Set up org-wide Storage and invite teammates after initial signup.

<Note>
  This quickstart covers org-wide admin setup. If you haven't created your account yet, start with the [Member quickstart](/guides/get-started/quickstart-user) first.
</Note>

<Info>
  [Admins](/guides/get-started/glossary#admin) manage org-level resources like Storage, Billing, and [Teams](/guides/get-started/glossary#team).
</Info>

<Steps>
  <Step title="Select your organization">
    Log in to [cloud.vessl.ai](https://cloud.vessl.ai). Click your [organization](/guides/get-started/glossary#organization) name in the top navigation bar to open the dropdown, then select the organization you want to manage.

    <div>
      <Frame>
        <img alt="Organization dropdown in the top navigation bar for choosing which organization to manage" />
      </Frame>
    </div>
  </Step>

  <Step title="Select your team">
    Next to the organization dropdown, click the team selector to choose which team's resources you want to view. You can switch teams anytime to manage different workspaces and volumes.

    <div>
      <Frame>
        <img alt="Team selector next to the organization dropdown for switching between team resources" />
      </Frame>
    </div>
  </Step>

  <Step title="View organization storage">
    In the sidebar, select **Cluster storage** or **Object storage** under **Volume** to see all volumes of that type across your organization. You can check each volume's cluster, capacity, and team assignments at a glance.

    <div>
      <Frame>
        <img alt="Organization storage page listing Cluster storage and Object storage volumes with cluster, capacity, and team assignments" />
      </Frame>
    </div>
  </Step>

  <Step title="Create a new volume">
    Click the **Object storage** tab, then click **Create new volume** to create a new [Object storage](/guides/get-started/glossary#object-storage) volume. You can create Cluster storage volumes the same way.

    <div>
      <Frame>
        <img alt="Empty-state Object storage tab highlighting the Create new volume button" />
      </Frame>
    </div>
  </Step>

  <Step title="Fill in the form">
    Enter a <strong>Volume name</strong>, select one or more <strong>teams</strong> to attach, and click <strong>Create</strong> to complete.

    <div>
      <Frame>
        <img alt="New volume dialog with fields for volume name and attached teams" />
      </Frame>
    </div>

    <Tip>
      You can change team assignments later from the **Volume detail** page.
    </Tip>
  </Step>

  <Step title="Review volume details">
    Review volume details in **Volume detail** (capacity, assignments, created date, and more).

    <div>
      <Frame>
        <img alt="Volume detail page showing capacity, team assignments, and created date" />
      </Frame>
    </div>
  </Step>

  <Step title="Invite teammates">
    Invite by email. Invited users are in Invited state until they verify their email, then become Active. You must assign at least one Team when inviting. A [member](/guides/get-started/glossary#member) can belong to multiple Teams.

    <div>
      <Frame>
        <img alt="Invite members form for adding teammates by email and assigning them to teams" />
      </Frame>
    </div>
  </Step>
</Steps>


# Member
Source: https://docs.cloud.vessl.ai/guides/get-started/quickstart-user

Create your first GPU instance, connect with JupyterLab or SSH, and control costs.

<Note>
  This quickstart is for Members (end users). If you're the first person in your org, you're also the Admin. See the [Admin quickstart](/guides/get-started/quickstart-admin) after completing this flow.
</Note>

<Steps>
  <Step title="Create account">
    Go to [cloud.vessl.ai](https://cloud.vessl.ai) and create an account. Verify your email to activate your account.

    <div>
      <Frame>
        <img alt="VESSL Cloud sign-up form for creating a new account with email and password" />
      </Frame>
    </div>
  </Step>

  <Step title="Complete your profile">
    After verifying your email, enter your **ID** (username), select your **Occupation** and **Use case**. Check the required boxes to agree to the Terms of Service and confirm your age, then click **Let's get started!**

    <div>
      <Frame>
        <img alt="Profile completion form for entering ID, Occupation, and Use case with terms and age confirmation" />
      </Frame>
    </div>
  </Step>

  <Step title="Create organization">
    Enter your [organization](/guides/get-started/glossary#organization) name and click **Create** to set up your workspace.

    <div>
      <Frame>
        <img alt="Create organization dialog with a name field and Create button" />
      </Frame>
    </div>
  </Step>

  <Step title="Explore the dashboard">
    After creating your organization, you'll land on the main Workspaces dashboard. This is where you can manage all your compute environments.

    <div>
      <Frame>
        <img alt="Main Workspaces dashboard for managing compute environments in a new organization" />
      </Frame>
    </div>
  </Step>

  <Step title="Register payment method">
    Before creating workspaces, register a payment method. In the sidebar, select **Settings**, then select **Billing** under **Organization**. Click **Manage payment method** to add your card, then use **Add credits** to top up your [credit](/guides/get-started/glossary#credit) balance.

    <div>
      <Frame>
        <img alt="Organization Billing page with Manage payment method and Add credits controls" />
      </Frame>
    </div>
  </Step>

  <Step title="Create a storage volume">
    VESSL Cloud offers three storage types. Picking the right one up front avoids I/O bottlenecks and accidental data loss later.

    | Storage | Speed | Data on pause | Best for |
    | - | - | - | - |
    | **Cluster storage** | Fast (CephFS/NVMe) | Preserved | Code, virtual environments, and anything you want to keep across pauses — mount at `/root` |
    | **Object storage** | Slower (S3-backed) | Preserved | Datasets, model checkpoints, and files shared across teams or clusters — mount at `/shared` |
    | **Temporary storage** | Fast (local disk) | Cleared | Scratch work only; everything here disappears the moment you pause or terminate |

    <Warning>
      If you rely only on Temporary storage, your code and data disappear when you pause the workspace. Always attach at least one persistent volume (Cluster storage or Object storage) before running important work.
    </Warning>

    **For this quickstart, create an Object storage volume** — it works even before your admin provisions Cluster storage. Click **Object storage** in the sidebar and click **Create new volume**. Enter a **Volume name** and **Description** to create an [Object storage](/guides/get-started/glossary#object-storage) volume.

    <div>
      <Frame>
        <img alt="Member-side Object storage page with Create new volume action, name, and description fields" />
      </Frame>
    </div>

    <Info>
      Cluster storage volumes are managed by Organization Admins. If Cluster storage is available for your team, you can also create volumes under **Cluster storage** in the sidebar.

      * **Mount Cluster storage at `/root`** so code, `~/.cache`, and pip/conda packages survive pauses.
      * **Mount Object storage at `/shared`** — VESSL Cloud rejects `/root` as an Object storage mount path because Object storage is slower and has different filesystem semantics. Other paths that overlap with your Cluster storage mount are also blocked.
      * Cluster storage is region-bound: only volumes from the same region as your selected GPU appear when creating a workspace.
    </Info>
  </Step>

  <Step title="Create a workspace">
    Open the **Workspaces** tab in the sidebar and click **New Workspace**. Enter a name, then select a GPU product, region, and GPU count under [Resource spec](/guides/get-started/glossary#resource-spec) for testing.

    Attach the **Object storage** volume you just created, then click **Create**.

    <div>
      <Frame>
        <img alt="New Workspace form for selecting GPU product, region, count, and attaching an Object storage volume" />
      </Frame>
    </div>

    You can run Jupyter notebooks directly in this workspace.
  </Step>

  <Step title="Explore workspace details">
    <div>
      <Frame>
        <img alt="Workspace detail page with Connect, Details, Logs, and Metrics tabs" />
      </Frame>
    </div>

    * Connect: In the workspace detail page, open the **Connect** tab to access using Jupyter (port 8888) or SSH (port 22). See [Connect](/member/workspace/connect).
    * Details: view GPU, volumes, image and other specs.
    * Logs: view container logs in real time.
    * Metrics: monitor CPU/GPU/Memory graphs.
  </Step>

  <Step title="Run code in JupyterLab">
    In the workspace detail page, open the **Connect** tab and click **JupyterLab**.

    <div>
      <Frame>
        <img alt="Workspace Connect tab with JupyterLab and SSH options for accessing the environment" />
      </Frame>
    </div>

    In **JupyterLab**, create a `Notebook → Python 3 (ipykernel)`. Run the following code:

    ```python theme={null}
    print("Hello, VESSL Cloud!")
    ```

    If the output prints successfully, your environment is ready.

    <Tip>
      To connect with SSH instead, follow [Connect](/member/workspace/connect) to generate/select an SSH key and copy the SSH command.
    </Tip>
  </Step>

  <Step title="Clean up">
    To avoid charges: go to the **Workspaces** tab in the sidebar and open the kebab menu on a running workspace. Click **Pause** to stop billing for compute. To delete the workspace permanently, pause it first — **Terminate** appears in the kebab menu once the workspace is paused.

    <div>
      <Frame>
        <img alt="Running workspace card with a pause control next to a paused workspace card with a restart control" />
      </Frame>
    </div>

    <Warning>
      Paused workspaces may still incur storage charges (Cluster storage is billed at \$0.20/GiB/month). Terminated workspaces incur no cost. Data in Temporary storage is not preserved when paused.
    </Warning>

    To permanently remove a workspace: Click **Terminate** from the kebab menu and confirm by typing the workspace name and clicking **Delete**.
  </Step>
</Steps>


# Support
Source: https://docs.cloud.vessl.ai/guides/get-started/support

Learn how to contact support and submit a ticket from VESSL Cloud.

## Contact support

If you need help with billing, workspace issues, or anything else, you can contact our support team:

* **Email**: [support@vessl.ai](mailto:support@vessl.ai)

## Submit a support ticket in VESSL Cloud

You can also submit a ticket directly from `cloud.vessl.ai` using the in-app support widget.

<Tip>Watch the demo below to see how to submit a ticket.</Tip>

<div>
  <iframe title="Submit a Support Ticket on VESSL Cloud" />
</div>


# Managed software stack
Source: https://docs.cloud.vessl.ai/guides/platform/managed-software-stack

Which parts of the software stack VESSL Cloud manages, which parts you are responsible for, and how security patching works.

VESSL Cloud manages a layered software stack for Container Compute Services (workspaces and batch jobs). This page describes which components VESSL Cloud is responsible for, which components you are responsible for, and how security patching works.

## Components VESSL Cloud manages

| Layer | Component |
| - | - |
| Cluster | Kubernetes control plane and worker nodes |
| Node OS | Cloud provider's GPU-optimized image (patched by the underlying cloud provider) |
| Container runtime | containerd, provided through the node OS |
| GPU stack | NVIDIA driver, CUDA libraries, and the NVIDIA GPU Operator |
| Platform | VESSL Cloud control plane, agents, and monitoring components |

<Info>
  These components run in the region of the cluster you select when you launch a workload.
</Info>

## VESSL Cloud-provided base images

VESSL Cloud publishes prebuilt container images you can use as a starting point for your workspaces and batch jobs.

| Image family | Description | Example tag |
| - | - | - |
| Python (CPU) | Slim Python base for CPU workloads | `quay.io/vessl-ai/python:3.13-slim` |
| CUDA + Python | CUDA toolkit and Python, no ML framework | `quay.io/vessl-ai/cuda:13.0.1-py3.13-slim` |
| PyTorch | PyTorch on CUDA, ready for training and inference | `quay.io/vessl-ai/torch:2.9.1-cuda13.0.1-py3.13-slim` |

Each family ships in multiple CUDA and Python version combinations. The image selector shows the available variants when you create a Workspace or Job.

Updates to these images are announced in the [changelog](/changelog/overview/updates).

You can also bring your own container images. Responsibility for images you supply is governed by the [Container Compute service terms](/legal/container-compute).

## Security patching

VESSL Cloud applies security patches to the components it manages; you keep the images and code you bring up to date.

| Component | Patched by |
| - | - |
| Kubernetes control plane | VESSL Cloud (with the underlying cloud provider) |
| Worker node OS | Cloud provider, applied by VESSL Cloud |
| Container runtime (containerd) | VESSL Cloud |
| NVIDIA driver and CUDA libraries | VESSL Cloud |
| VESSL Cloud platform components | VESSL Cloud |
| Container images you supply | **You** |
| Application code, libraries, and dependencies inside your images | **You** |
| Packages you install inside a running container | **You** |

<Note>
  If your workload uses a container image you supplied, keeping that image up to date is your responsibility. VESSL Cloud does not modify your images.
</Note>

Severity-based response times, advance notice for disruptive patches, and notification procedures are defined in the [Service Level Agreement (SLA)](/legal/sla).

Notable stack updates, including new VESSL Cloud-provided base images, are announced in the [changelog](/changelog/overview/updates).

## Related

* [Resource limits](/guides/platform/resource-limits) — how the platform enforces resource limits and recovers workloads
* [Container Compute service terms](/legal/container-compute) — contractual basis for the managed software stack
* [Service Level Agreement](/legal/sla) — patching response times and notification commitments


# Resource limits
Source: https://docs.cloud.vessl.ai/guides/platform/resource-limits

Which resource limits VESSL Cloud enforces, what happens when a workload exceeds one, and which data survives.

VESSL Cloud enforces resource limits on workspaces and batch jobs based on the resource spec you select at launch. This page describes which limits apply and how the platform behaves when a workload exceeds one.

## Which limits apply

| Resource | Where the limit comes from |
| - | - |
| CPU | Resource spec (for example, 8 vCPUs) |
| Memory (RAM) | Resource spec (for example, 64 GiB) |
| GPU memory (VRAM) | GPU model (for example, H100 80 GB) |
| Temporary storage | Allocated per container at launch |

<Info>
  You select a resource spec when you create a Workspace or Job. To review available specs, see [Create a workspace](/member/workspace/create) or [Create a job](/member/job/create).
</Info>

## What happens when a limit is exceeded

| Limit exceeded | Result |
| - | - |
| Memory | The container is killed (Out of Memory Killed, `OOMKilled`) |
| Temporary storage | The container is removed from the node |
| CPU | The workload slows down but keeps running |
| GPU memory (VRAM) | The process receives a CUDA out-of-memory (OOM) error; what happens next depends on your application code |

## How workloads recover

When a container is killed by the Memory or Temporary storage limit, recovery depends on the workload type.

| Workload | Recovery behavior |
| - | - |
| Workspace | The platform restarts the container on a healthy node and re-attaches Cluster storage and Object storage volumes. Temporary data and in-memory state are lost. |
| Job | The job is marked as `failed`. There is no automatic retry — submit a new batch job to try again. |

## Which data survives

| Data location | After the limit is exceeded |
| - | - |
| Container memory state | Lost |
| Temporary storage | Lost |
| Cluster storage volumes | Preserved |
| Object storage volumes | Preserved |

<Note>
  Data on Cluster storage and Object storage volumes is unaffected when a workload exceeds a resource limit. Store anything you can't afford to lose on one of these volumes.
</Note>

## Check resource usage

Track usage in real time and review historical patterns:

* [Monitor workspace metrics](/member/workspace/metrics) — GPU, VRAM, CPU, memory, and network usage
* [Monitor job metrics](/member/job/metrics) — the same metrics for batch jobs
* [Workspace logs](/member/workspace/logs) — review `OOMKilled` and eviction events
* [Job logs](/member/job/logs) — review failure causes

## Related

* [Credit exhaustion policy](/admin/billing/credit-exhaustion-policy) — what happens when your credit balance reaches zero
* [Container Compute service terms](/legal/container-compute) — contractual terms for resource limits


# Manage your contract
Source: https://docs.cloud.vessl.ai/inference/contracts

Check your reserved PTUs and contract period, change models, add capacity, and review contract history.

Your contract details are on the model page, in the **Deploy options** section.

<div>
  <Frame>
    <img alt="Deploy options card showing Provisioned capacity is live with an Active badge and a Get started button, above the reserved PTU count and the contracted period, with a Need more capacity? link and an Estimate total cost button" />
  </Frame>

  <small>Example: the Deploy options card for a model with an active contract</small>
</div>

## Contract status

While a contract is active, the **Deploy options** card shows **Provisioned capacity is live** with an **Active** badge, plus:

* **Reserved PTU** — the Provisioned Throughput Units (PTUs) you contracted.
* **Contracted period** — the start and end dates of the term.

**Get started** opens a ready-to-copy sample request for the model, with the model ID already filled in. See [Send your first request](/inference/send-requests).

## Add capacity

Click **Need more capacity?** on the model page, or [talk to sales](https://vessl.ai/en/talk-to-sales?utm_source=docs\&utm_medium=referral\&utm_campaign=inference_en\&utm_content=contracts_more_capacity), to add PTUs. Traffic above your contracted capacity is served on a best-effort basis up to a set limit above that capacity and isn't covered by the SLA. See [Understand the SLA](/inference/sla).

## Change models

You can switch to another model in the same model family during the contract term. For other changes, [talk to sales](https://vessl.ai/en/talk-to-sales?utm_source=docs\&utm_medium=referral\&utm_campaign=inference_en\&utm_content=contracts_change_model).

## Renew or extend

The contract term is arranged individually with sales. To extend or renew, [talk to sales](https://vessl.ai/en/talk-to-sales?utm_source=docs\&utm_medium=referral\&utm_campaign=inference_en\&utm_content=contracts_renew).

## Contract history

The **Previous contracts** table at the bottom of the model page lists every Provisioned Throughput contract for the model, with its contracted period, reserved PTUs, SLA terms, and creation date.


# Browse models
Source: https://docs.cloud.vessl.ai/inference/models

The models you can serve with Provisioned Throughput, and what a model page shows.

Provisioned Throughput serves stock open-weight models. Each model has a page under **Inference** → **Models** in the sidebar, with its specifications, deploy options, usage, and contract history.

## Available models

| Model | Provider |
| - | - |
| **GLM 5.3 Flash** | Z.ai |
| **DeepSeek V4.1 Flash** | DeepSeek |

More models may be added over time. **Inference** → **Models** in VESSL Cloud always shows the current list.

Within your contract term, we roll out newer versions of your model in step with its release cycle.

In the model list, each card shows the modality, the Provisioned Throughput Unit (PTU) rate, and the context length. A model you already hold a contract for carries an **Active · N PTU** badge.

Need a model that isn't listed? [Talk to sales](https://vessl.ai/en/talk-to-sales?utm_source=docs\&utm_medium=referral\&utm_campaign=inference_en\&utm_content=models_other_model).

## The model page

<div>
  <Frame>
    <img alt="Model page header with the model ID and a copy button next to the name, above the Model information card showing parameters, modality, context length, and a Hugging Face link" />
  </Frame>

  <small>Example: a model page header and its Model information card</small>
</div>

* **Model ID** — shown next to the model name, with a copy button. Use it as the `model` value in API requests. See [Send your first request](/inference/send-requests).
* **Model information** — parameters, supported modalities, context length, and a link to the model's Hugging Face page. Expand **Details** below it for the provider, category, supported features (such as JSON mode and tool calling), and release date.
* **Deploy options** — before you have a contract, the **Provisioned Throughput** card shows the billing unit, the SLA, and the PTU rate, with **Estimate total cost** and **Contact sales**. See [Request Provisioned Throughput](/inference/request). Once your contract is active, the same card shows **Provisioned capacity is live**, your reserved PTUs, and the contracted period. See [Manage your contract](/inference/contracts).
* **Usage summary** — unlocked once your contract is active. See [Monitor inference status](/inference/monitor-usage).
* **Previous contracts** — the history of this model's Provisioned Throughput contracts. See [Manage your contract](/inference/contracts).


# Monitor inference status
Source: https://docs.cloud.vessl.ai/inference/monitor-usage

Track token usage, cost breakdown, performance, and reliability for each model under contract.

Once your API key is active, two places show your numbers: the **Usage summary** card on each model page, which defaults to the current month, and the **Monitoring Dashboard**, opened from **Monitoring** under **Inference** in the sidebar, which tracks token usage, performance, and reliability over a date range you pick.

<Tip>Use the demo below to see how to open the **Monitoring Dashboard** from a model page and read the metrics under each tab.</Tip>

<div>
  <iframe title="Monitor Model Usage and Performance Metrics in VESSL Cloud" />
</div>

## Usage summary

This card sits on the model page. Use the month picker at the top of the card to move between billing months, and **View details in Monitoring** to open the Monitoring Dashboard.

<div>
  <Frame>
    <img alt="Usage summary card with the month picker, peak token usage in tokens per minute, total cost with the share of cached input, input, and output tokens, and the daily token usage trend chart" />
  </Frame>

  <small>Example: one month of usage on a model under contract</small>
</div>

| | |
| - | - |
| **Peak token usage** | The highest throughput reached in the month, in tokens per minute (TPM). Compare it with the capacity your contracted Provisioned Throughput Units (PTUs) guarantee to see how much headroom you have. |
| **Total cost** | The month's usage priced at the model's per-token rates, with the share of cached input, input (uncached), and output tokens. Under a Provisioned Throughput contract you pay for the PTUs you reserve, so read this as a usage figure rather than your invoice. |
| **Token usage trend** | Daily token usage, stacked by cached input, input (uncached), and output. Hover a bar for that day's exact numbers. |

## Monitoring Dashboard

Open **Inference** → **Monitoring** in the sidebar, or click **View details in Monitoring** on a model page. Pick a date range and one model or all of them, then read the metrics under three tabs.

<div>
  <Frame>
    <img alt="Monitoring Dashboard with the Token, Performance, and Reliability tabs, a date range picker, a model selector, and the Total Tokens per Minute chart" />
  </Frame>

  <small>Example: token usage across all models over a one-week range</small>
</div>

| | |
| - | - |
| **Token** | Tokens per minute, split into total, input, and output. |
| **Performance** | Time to first token (TTFT) and time per output token (TPOT), each at p50, p90, and p99, alongside per-request generation speed and cache hit rate. |
| **Reliability** | Requests per minute, and the share of requests that failed with a 4xx or 5xx error. |

## When you need more capacity

If **Peak token usage** is approaching the capacity your contracted PTUs guarantee, add PTUs: [talk to sales](https://vessl.ai/en/talk-to-sales?utm_source=docs\&utm_medium=referral\&utm_campaign=inference_en\&utm_content=monitor_more_capacity) or click **Need more capacity?** on the model page. See [Manage your contract](/inference/contracts).


# Understand Provisioned Throughput
Source: https://docs.cloud.vessl.ai/inference/overview

Reserve guaranteed model-serving capacity in PTUs, with an SLA, on OpenAI- and Anthropic-compatible endpoints.

With **Provisioned Throughput**, you reserve serving capacity for a model in contract units called Provisioned Throughput Units (PTUs). VESSL Cloud serves the model at the throughput you contract, in tokens per minute (TPM), under an SLA, so large, predictable workloads get production-grade latency without you operating any inference infrastructure.

## Why Provisioned Throughput

* **Guaranteed throughput** — the throughput you contract holds even when the fleet is busy. It's a guarantee, not a best-effort target.
* **SLA without operations** — VESSL Cloud operates the serving stack against the SLA in your contract, covering throughput, reliability, and latency, measured as time per output token (TPOT).
* **Lower cost per token** — Provisioned Throughput costs on average about **70%** less than a comparable frontier model, so you spend less to run an LLM. The **Estimate total cost** calculator on each model page works the number out for your own traffic.

## Who it's for

* **Model providers** that need to grow serving capacity in steps as customer demand grows.
* **Enterprises** rolling out AI agents company-wide that want to adopt open-source models and cut internal operating costs.
* **AI service companies** that need to serve growing traffic reliably as the business grows.

## What you get

| | |
| - | - |
| **Capacity unit** | PTU, a normalized unit of serving capacity. See [Understand PTUs and billing](/inference/ptu). |
| **Price** | \$0.05 per PTU per minute, the same rate for every model |
| **PTU quantity** | Arranged individually with sales |
| **Contract term** | Arranged individually with sales; billed monthly |
| **Models** | GLM 5.3 Flash, DeepSeek V4.1 Flash. See [Browse models](/inference/models). |
| **Model changes** | Switch to another model in the same family during your contract term. See [Manage your contract](/inference/contracts). |
| **API** | Compatible with the OpenAI Chat Completions API and the Anthropic Messages API. See [Send your first request](/inference/send-requests). |
| **SLA** | Throughput, reliability, and latency targets set in your contract. See [Understand the SLA](/inference/sla). |
| **Data retention** | Zero data retention by default: prompts and outputs aren't stored unless you opt in to content logging. See [Inference service terms](/legal/inference). |

## How it works

1. **Consultation** — we profile your model, volume, traffic pattern, and target SLA with you.
2. **Contract** — we fix the guaranteed TPM, SLA, and price, and agree on the terms.
3. **Proof of concept (PoC)** — you benchmark your real traffic with a sample API key and confirm performance and cost.
4. **Endpoint and operations** — your OpenAI- and Anthropic-compatible endpoint goes live, you monitor usage and performance on the dashboard, and billing settles monthly.

## Provisioned Throughput vs other service types

Provisioned Throughput sits between serverless and dedicated endpoints: guaranteed capacity for a stock model, without operating hardware yourself. See [Compare inference service types](/inference/vs-service-types).

## Core pages

* **[Browse models](/inference/models)** — the models available under Provisioned Throughput and what the model page shows.
* **[Send your first request](/inference/send-requests)** — base URL, authentication, and an example request.
* **[Monitor inference status](/inference/monitor-usage)** — token usage, cost breakdown, performance, and reliability.
* **[Manage your contract](/inference/contracts)** — reserved PTUs, contract period, model changes, and contract history.

<Card title="Request Provisioned Throughput" icon="bolt" href="/inference/request">
  Tell us about your traffic and we'll scope the capacity with you.
</Card>


# Understand PTUs and billing
Source: https://docs.cloud.vessl.ai/inference/ptu

What a PTU is, how much capacity one PTU gives you per model, and how a contract is billed.

A **Provisioned Throughput Unit (PTU)** is a normalized unit of serving capacity. Every model is priced at the same rate per PTU; what differs per model is how many tokens one PTU can process per minute. When you contract, you decide how many PTUs to reserve based on your traffic.

## Billing

| | |
| - | - |
| **Rate** | \$0.05 per PTU per minute |
| **PTU quantity** | Arranged individually with sales |
| **Contract term** | Arranged individually with sales |
| **Billing cycle** | Monthly |

The rate is the same for every model and every workload shape. Within your contracted capacity, you're billed for the PTUs you reserve, not per token.

## Capacity per PTU

One PTU processes up to the following number of tokens per minute (TPM). Capacity is set per model and per token type: uncached input, cached input, and output.

| Model | Input (TPM) | Cached input (TPM) | Output (TPM) |
| - | - | - | - |
| **GLM 5.3 Flash** | 333,333 | 1,666,667 | 100,000 |
| **DeepSeek V4.1 Flash** | 166,667 | 7,142,857 | 41,667 |

These are each model's default capacity. A contract can set a different capacity per PTU, and the model page and the **Estimate total cost** calculator then use the contract's values.

## Estimate your PTUs and savings

Every model page has an **Estimate total cost** calculator. Enter your peak requests per second, cache hit rate, and average input and output tokens per request to see how many PTUs you need, the estimated monthly cost, and the estimated savings against a frontier model you pick.

<div>
  <Frame>
    <img alt="Estimate your PTUs & cost panel with the model and comparison selectors, traffic inputs, PTUs required, estimated monthly cost, and estimated monthly savings" />
  </Frame>

  <small>Example: the calculator's inputs and results for a sample workload</small>
</div>

## Example

For example, 8 PTUs on GLM 5.3 Flash give you up to:

* 2,666,664 uncached input tokens per minute, or
* 13,333,336 cached input tokens per minute, or
* 800,000 output tokens per minute.

Real traffic mixes all three, so each type uses a share of the capacity. At \$0.05 per PTU per minute, 8 PTUs cost \$576 per day. The **Estimate total cost** calculator counts a month as 730 hours, which puts the same 8 PTUs at about \$17,520 per month.

<Note>
  The PTU count you contract is confirmed during the proof of concept (PoC), with a benchmark on your real traffic. The calculator gives you a planning number, not a quote. See [Request Provisioned Throughput](/inference/request).
</Note>

## Traffic above your capacity

The PTUs you reserve set the capacity the SLA guarantees. Traffic above that capacity falls outside the SLA. See [Understand the SLA](/inference/sla).

If you regularly run above capacity, [talk to sales](https://vessl.ai/en/talk-to-sales?utm_source=docs\&utm_medium=referral\&utm_campaign=inference_en\&utm_content=ptu_more_capacity) to add PTUs.


# Request Provisioned Throughput
Source: https://docs.cloud.vessl.ai/inference/request

How to get Provisioned Throughput: estimate your PTUs, talk to sales, run a PoC on your real traffic, and go live.

Provisioned Throughput is set up with our sales team. Tell us about your traffic and we size the capacity with you. After a proof of concept (PoC) on your real traffic, your endpoint goes live.

## Estimate your PTUs first

Before you reach out, get a planning number of Provisioned Throughput Units (PTUs) from the calculator. Open **Inference** → **Models** in the sidebar, pick a model, and click **Estimate total cost**.

<Tip>Use the demo below to see how to enter your traffic and read the PTUs you need alongside the estimated cost.</Tip>

<div>
  <iframe title="Estimate and Compare Model Inference Costs" />
</div>

The calculator sizes the raw capacity your traffic needs. The PTU quantity you contract is arranged individually with sales. See [Understand PTUs and billing](/inference/ptu).

## How to request

[Talk to sales](https://vessl.ai/en/talk-to-sales?utm_source=docs\&utm_medium=referral\&utm_campaign=inference_en\&utm_content=request_intro), or open any model you haven't contracted yet and click **Contact sales**. It helps to share:

| | |
| - | - |
| **Model** | The base model you want to serve. See [Browse models](/inference/models). |
| **Volume** | Expected daily tokens and peak tokens per minute (TPM) |
| **Workload profile** | Average input and output length per request, and the cache hit rate you expect |
| **Target SLA** | The time per output token (TPOT) you need |

## What happens next

1. **Consultation and profiling** — we go through your model, volume, traffic pattern, and target SLA.
2. **Terms and contract** — we fix the guaranteed TPM, SLA, and price, and agree on the terms.
3. **PoC** — you get a sample API key. We optimize the model for the agreed throughput and SLA goals, then you benchmark on your own traffic and confirm performance and cost.
4. **Go live** — your endpoint is provisioned and the model's **Deploy options** card shows **Provisioned capacity is live**. See [Send your first request](/inference/send-requests).


# Send your first request
Source: https://docs.cloud.vessl.ai/inference/send-requests

Call your Provisioned Throughput endpoint by changing the base URL, the API key, and the model ID in the SDK you already use.

Your endpoint is compatible with the **OpenAI Chat Completions API** and the **Anthropic Messages API**. Keep the SDK you already use and change the base URL and the API key, then pass the model ID in the `model` field.

## Prerequisites

* An active contract. The model's **Deploy options** card shows **Provisioned capacity is live**. See [Manage your contract](/inference/contracts).
* Your API key, issued when the contract starts (or the sample key during the proof of concept).
* The model ID, copied from the model page. See [Browse models](/inference/models).

## Endpoint

| | |
| - | - |
| **Base URL** | `https://inference.cloud.vessl.ai/v1` |
| **Authentication** | Your API key, sent as a bearer token (`Authorization: Bearer <api-key>`) |
| **Model** | The model ID shown next to the model name on the model page |

## Example request

Set your API key as the `VESSL_API_KEY` environment variable first:

```bash theme={null}
export VESSL_API_KEY="<api-key>"
```

<CodeGroup>
  ```bash cURL theme={null}
  curl https://inference.cloud.vessl.ai/v1/chat/completions \
    -H "Authorization: Bearer $VESSL_API_KEY" \
    -H "Content-Type: application/json" \
    -d '{
      "model": "<model-id>",
      "messages": [
        {"role": "user", "content": "Hello! Who are you?"}
      ]
    }'
  ```

  ```python Python theme={null}
  import json
  import os
  import urllib.request

  request = urllib.request.Request(
      "https://inference.cloud.vessl.ai/v1/chat/completions",
      method="POST",
      headers={
          "Authorization": f"Bearer {os.environ['VESSL_API_KEY']}",
          "Content-Type": "application/json",
      },
      data=json.dumps({
          "model": "<model-id>",
          "messages": [
              {"role": "user", "content": "Hello! Who are you?"},
          ],
      }).encode(),
  )

  with urllib.request.urlopen(request, timeout=120) as response:
      body = json.load(response)

  print(body["choices"][0]["message"]["content"])
  ```

  ```typescript TypeScript theme={null}
  const response = await fetch("https://inference.cloud.vessl.ai/v1/chat/completions", {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.VESSL_API_KEY}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      model: "<model-id>",
      messages: [
        { role: "user", content: "Hello! Who are you?" },
      ],
    }),
  });

  if (!response.ok) {
    throw new Error(`Request failed: ${response.status} ${await response.text()}`);
  }

  const body = await response.json();
  console.log(body.choices[0].message.content);
  ```
</CodeGroup>

<Tip>
  **Get started** on the model page opens these same requests with that model's ID already filled in.
</Tip>

## Check the dashboard

Once traffic flows through your endpoint, the model page's **Usage summary** shows token usage and cost, and the **Monitoring Dashboard** tracks token usage, performance, and reliability. See [Monitor inference status](/inference/monitor-usage).


# Understand the SLA
Source: https://docs.cloud.vessl.ai/inference/sla

What the Provisioned Throughput SLA covers, which requests are eligible, and how traffic above your capacity is handled.

The SLA applies to eligible traffic sent within your purchased Provisioned Throughput Unit (PTU) capacity and the product limits. It covers three areas.

## What the SLA covers

| | |
| - | - |
| **Throughput** | For your chosen model or model family, eligible traffic is served up to the maximum throughput (in tokens per minute, TPM) that your purchased PTUs guarantee. |
| **Reliability** | A minimum share of eligible requests completes successfully each month. Failures caused by errors on VESSL Cloud's side count against the target; failures caused by client-side errors are excluded. |
| **Latency** | A target for time per output token (TPOT). |

<Info>
  The specific targets and the remedies for missing them are agreed in a Custom SLA Addendum when you contract.
</Info>

## Eligible requests

An eligible request is any request made within your purchased PTU capacity and the product limits. The following are excluded from the SLA:

* Errors on your side, malformed requests, and authentication failures
* Requests cancelled by the client
* Traffic above your purchased capacity
* Requests that violate abuse or product-protection limits

## Traffic above your capacity

Traffic above your contracted capacity is served on a best-effort basis up to a set limit above that capacity, and traffic in that band isn't covered by the SLA. To raise your capacity, [talk to sales](https://vessl.ai/en/talk-to-sales?utm_source=docs\&utm_medium=referral\&utm_campaign=inference_en\&utm_content=sla_more_capacity).

## Monitor usage and performance

Usage and performance for each model are on its model page and on the **Monitoring Dashboard**. See [Monitor inference status](/inference/monitor-usage).


# Compare inference service types
Source: https://docs.cloud.vessl.ai/inference/vs-service-types

How Provisioned Throughput differs from the serverless and dedicated endpoints offered across the industry.

Inference providers generally offer three kinds of service. **Provisioned Throughput** sits between the other two: you reserve guaranteed capacity for a stock model, without renting and operating hardware yourself.

## Comparison

| | Provisioned Throughput | Serverless | Dedicated endpoints |
| - | - | - | - |
| **What you reserve** | Committed capacity for a chosen model or model family | Nothing; shared resources | GPUs reserved for you alone |
| **Billing unit** | Per Provisioned Throughput Unit (PTU), over the contract term you agree with sales | Per token, per second, or per output unit | Per minute of reserved hardware |
| **SLA** | Throughput, reliability, and latency targets set in your contract | Best effort, with dynamic rate limits | No shared-fleet rate limits; performance depends on the hardware configuration and settings |
| **Best for** | Production workloads on stock models | Prototyping, highly variable traffic | Fine-tuned models, custom hardware, fine-grained latency and throughput control |
| **How to get it** | Contact sales | Self-serve | Self-serve |

<Note>
  Provisioned Throughput is the inference service VESSL Cloud offers today, and **Serverless Endpoint** is on the way. The serverless and dedicated endpoint columns describe service types you'll find across inference providers, so you can see where Provisioned Throughput fits.
</Note>

## When to choose Provisioned Throughput

* Your traffic is large and predictable, and you need a throughput floor you can plan against rather than a rate limit that moves with everyone else's traffic.
* You run a stock open-weight model as-is and don't need custom hardware or a fine-tuned checkpoint.
* You want an SLA on throughput, reliability, and latency without operating GPUs, serving engines, or autoscaling yourself.
* You want a lower, predictable cost per token than a frontier closed-model API for the same volume.

## When another type fits better

* **Serverless** — you're prototyping, or your traffic is too spiky and low-volume to justify a commitment. Pay per token and accept best-effort performance.
* **Dedicated endpoints** — you serve your own fine-tuned model, need a specific hardware configuration, or need to tune the serving stack yourself. Rent the hardware and take on the operations.

For a stock model at production scale, see [Request Provisioned Throughput](/inference/request).


# Master services agreement
Source: https://docs.cloud.vessl.ai/legal/msa

VESSL Cloud master services agreement (MSA).

<Info>
  Effective date: August 18, 2026 · Last updated: August 18, 2026
</Info>

This Master Services Agreement ("Agreement" or "MSA") is entered into between **VESSL AI, Inc.**, a Delaware corporation with an office at 535 Mission Street, Ste 1550, San Francisco, CA 94105, United States, **or, where the applicable Order Form so specifies, the VESSL Affiliate identified therein (including VESSL AI KOREA Inc., a Korean corporation)** (collectively, "VESSL", "we", "us", or "our"), and the entity or person agreeing to these terms ("Customer" or "you"). Where Customer registers for or uses the Services without executing an Order Form, the contracting VESSL entity is VESSL AI, Inc. **Where an Order Form has been executed, the contracting VESSL entity and the applicable governing law are as specified in that Order Form and Section 14.1 of this Agreement.** This Agreement governs Customer's access to and use of the Services. By creating an account, executing an Order Form referencing this Agreement, or otherwise using the Services, Customer agrees to this Agreement.

<Info>
  **Applicability**. These Core Terms apply to all Customers. If Customer registers for or uses the Services without executing an Order Form, Annex A (Self-Service Terms) also applies, whether Customer is an individual or an organization. If Customer executes an Order Form, any enterprise or B2B addendum applies only if it is provided to Customer and expressly incorporated through the applicable private transaction package. Conflicts are resolved under Section 2.2.
</Info>

## 1. Definitions

**"Acceptable Use Policy"** or "AUP" means the policy located at [https://docs.cloud.vessl.ai/legal/acceptable-use](/legal/acceptable-use), as updated from time to time.

**"Affiliate"** means an entity that, directly or indirectly, controls, is controlled by, or is under common control with a party, where "control" means ownership of more than fifty percent (50%) of the equity or voting interests.

**"Authorized User"** means an individual employee, contractor, or agent whom Customer authorizes to access the Services on Customer's behalf. Customer is responsible for ensuring that each Authorized User complies with this Agreement and the AUP.

**"Beta Services"** means Services that VESSL labels as "Beta," "Preview," "Early Access," "Experimental," or similar.

**"B2B Customer"** means a Customer that has executed an Order Form with VESSL.

**"Confidential Information"** means non-public information disclosed by one party (the "Disclosing Party") to the other (the "Receiving Party"), in any form, that is marked or reasonably understood from the circumstances to be confidential. Confidential Information includes the terms of any Order Form, the Services architecture, security measures, and Customer Content.

**"Customer Content"** means data, software, code, models, Inputs, resource names, labels, tags, configuration values, and other materials submitted to or processed by the Services by or on behalf of Customer. Customer Content does not include billing identifiers or Usage Data generated by VESSL.

**"Documentation"** means the technical and user documentation made available by VESSL for the Services at [https://docs.cloud.vessl.ai](https://docs.cloud.vessl.ai) or in the Services console, as updated from time to time. Documentation forms part of the parties' agreement only to the extent it states technical or operational instructions applicable to Customer's use of the Services or supplies a specific fact or value that this Agreement expressly delegates to an identified Documentation page. An update to Documentation does not by itself amend Fees or payment obligations, liability, Intellectual Property Rights, rights to use Customer Content, the Subscription Term, termination rights, data-retention or deletion periods, or the amendment requirements of this Agreement.

**"DPA"** means the Data Processing Agreement located at [https://docs.cloud.vessl.ai/legal/dpa](/legal/dpa), as updated from time to time (for Self-Service Customers), or as separately executed by the parties (for B2B Customers).

**"Effective Date"** means the date on which Customer first agrees to this Agreement, whether by executing an Order Form, accepting these terms electronically, or otherwise using the Services.

**"End User"** means any person who accesses or uses products or services made available by Customer using the Services, other than an Authorized User.

**"Fees"** means the fees applicable to Customer's use of the Services, as set forth in the applicable Order Form or self-service pricing published by VESSL.

**"Force Majeure Event"** means any cause beyond a party's reasonable control, including acts of God, natural disasters, war, terrorism, pandemics, epidemics, governmental actions, civil unrest, labor disputes, failures of essential public infrastructure, and failures of third-party telecommunications, internet, or power providers.

**"Inputs"** means prompts, instructions, code, data, or other content provided by Customer (or its Authorized Users or End Users) to the Services for processing.

**"Intellectual Property Rights"** means all patents, copyrights, trademarks, service marks, trade secrets, know-how, moral rights, database rights, and all other proprietary rights recognized in any jurisdiction, whether registered or unregistered.

**"Order Form"** means an ordering document, online order, statement of work, or addendum executed by the parties that references this Agreement.

**"Output"** means any content, prediction, classification, generation, or other result produced by the Services from Customer Content.

**"Personal Data"** has the meaning given in the DPA.

**"Purchased Credits"** means prepaid value purchased by a Self-Service Customer and applied to Fees in accordance with Annex A.

**"Promotional Credits"** means complimentary, trial, promotional, or other non-purchased value issued by VESSL, subject to the conditions and expiration stated when issued.

**"Service Credits"** means non-cash credits issued as a remedy under the applicable SLA. Service Credits are not Purchased Credits or Promotional Credits.

**"SCCs"** means the Standard Contractual Clauses as incorporated under the DPA.

**"Self-Service Customer"** means a Customer that registers for or uses the Services without executing an Order Form. A Self-Service Customer may be an individual or an organization.

**"Services"** means VESSL Cloud and the related products and services VESSL makes available under this Agreement, including Container Compute, VM Cluster Services, Storage Services, and Inference Services, as further described in the Documentation, the applicable Service-Specific Terms, and any applicable Order Form.

**"Service Level Agreement"** or "SLA" means the SLA located at [https://docs.cloud.vessl.ai/legal/sla](/legal/sla), as updated from time to time. That SLA applies to a Self-Service Customer and, for a B2B Customer, applies by default except to the extent a Custom SLA Addendum or Order Form applicable to the transaction expressly provides otherwise.

**"Service-Specific Terms"** means the additional terms applicable to a particular Service, as published at [https://docs.cloud.vessl.ai/legal/service-terms](/legal/service-terms) or referenced in the Documentation, in each case as updated from time to time, including the Container Compute Service Terms, the VM Cluster Service Terms, the Inference Service Terms, and the Storage Service Terms.

**"Sub-processor"** means any third-party processor engaged by VESSL to process Personal Data on behalf of Customer.

**"Subscription Term"** means: (a) for B2B Customers, the period specified in the applicable Order Form during which Customer is authorized to access the Services; and (b) for Self-Service Customers, the period from account creation until Customer's account is terminated or deleted in accordance with this Agreement.

**"Support Policy"** means the support policy located at [https://docs.cloud.vessl.ai/legal/support-policy](/legal/support-policy), as updated from time to time.

**"Usage Data"** means telemetry, performance, operational, security, and aggregated statistical data generated by or in connection with Customer's use of the Services, excluding Customer Content.

## 2. Services

### 2.1 Provision of Services

Subject to this Agreement and payment of applicable Fees, VESSL grants Customer a non-exclusive, non-transferable right during the Subscription Term to access and use the Services for Customer's lawful purposes, including to build, operate, and provide products and services to Customer's End Users. The right granted in this Section 2.1 is non-sublicensable, except that Customer may permit its End Users to interact with the Services solely as necessary to access products or services that Customer builds on or with the Services. Customer remains responsible for End Users' use of the Services as if such use were Customer's own.

### 2.2 Order of Precedence

The documents constituting the parties' agreement control only the subjects assigned to them below. If two provisions conflict, the provision assigned to the more specific subject controls only to the extent of that conflict:

* the SCCs or another binding transfer mechanism incorporated under the DPA control transfers of Personal Data that they cover;
* the DPA controls the processing of Customer Personal Data;
* an executed Order Form or separately executed supplemental agreement controls the transaction-specific commercial, technical, or legal terms that it expressly addresses, and an executed Custom SLA Addendum controls the service levels for the Covered Services it identifies;
* Annex A controls Self-Service account, billing, payment, and other Self-Service commercial terms;
* the applicable Service-Specific Terms control the technical and operational conditions specific to that Service;
* the SLA controls availability measurements, service-level objectives, exclusions, claims, and Service Credits;
* these Core Terms control general legal terms not assigned above; and
* the AUP controls prohibited use and related enforcement, the Support Policy controls support procedures, the Sub-processor List identifies authorized Sub-processors, and Documentation controls only the limited subjects stated in the definition of Documentation.

An enterprise or B2B addendum applies only if it is provided to Customer and incorporated through the applicable private transaction package. An Order Form does not modify the DPA, the SCCs, or another document outside the Order Form's assigned subject merely because it contains a general inconsistency clause. Any separately executed amendment must expressly identify the provision it modifies, and the DPA and applicable transfer mechanism continue to control Customer Personal Data and covered transfers.

### 2.3 Beta Services

Beta Services are provided "AS IS," are excluded from the SLA except to the extent the SLA or an applicable Order Form expressly provides otherwise, and may be modified or discontinued at any time. Sections 9.1 (Authority and Applicable-Law Warranty), 9.3 (Customer Warranty), 10 (Disclaimers), and 11 (Limitation of Liability) apply to Beta Services. Section 9.2 (VESSL Service Warranty) and Section 13 (Service Levels) do not apply to Beta Services, except that Section 13 applies to a Beta Service to the extent the SLA or an applicable Order Form expressly designates it as a Covered Service.

Section 12.1 (By VESSL) does not apply to Beta Services unless an applicable Order Form or separately executed supplemental agreement expressly states otherwise. VESSL has no defense or indemnity obligation for a third-party claim relating to Beta Services except as expressly stated in that document.

Customer may use Beta Services for production workloads at Customer's discretion and risk, but must not use them for a prohibited High-Risk Use under Section 14.19. An applicable Order Form may impose a narrower workload restriction. Beta Services, and non-public performance data, benchmarks, or evaluation results relating to Beta Services, are VESSL Confidential Information and may not be disclosed without VESSL's prior written consent.

### 2.4 Modifications

VESSL may make non-material technical or operational changes to the Services from time to time. Such changes may take effect when implemented and may be communicated through the VESSL console, Documentation, release notes, or email.

A change that materially decreases the functionality of a Service or materially adversely affects Customer's contracted use of that Service is subject to the applicable Annex and, for a B2B Customer, the applicable Order Form and private transaction terms.

VESSL may make a change on shorter notice, including immediately where reasonably necessary, if the change is required by applicable law or a regulatory authority or is reasonably necessary to address an urgent security, integrity, fraud, or third-party-rights issue. VESSL will provide as much advance notice as is reasonably practicable and use commercially reasonable efforts to minimize material adverse impact.

Price changes are governed by the applicable Annex or Order Form. Amendments to legal or commercial terms are governed by Section 14.10.

### 2.5 Availability of On-Demand and Uncommitted Resources

Certain Services, including on-demand and other uncommitted compute, are offered subject to availability. VESSL does not guarantee that on-demand or uncommitted capacity will be available at any particular time, and VESSL may decline, queue, or delay a request for such capacity where capacity is constrained, without liability and without such action constituting a breach of this Agreement. This Section 2.5 does not apply to committed capacity, reserved capacity, or minimum-commitment resources expressly provisioned to Customer under an Order Form.

### 2.6 Support

VESSL provides support for the Services in accordance with the Support Policy. A Customer support request, and any authorization recorded through the support process, constitutes a documented Customer instruction only within its stated purpose, systems, data scope, permitted actions, and duration. Access to Customer Content in connection with support remains subject to Section 6.2 and the DPA.

## 3. Customer Responsibilities

### 3.1 Acceptable Use

Customer will use the Services in accordance with this Agreement, the AUP, applicable law, and the technical and operational instructions in the Documentation that reasonably apply to Customer's use of the Services. Customer is responsible for the acts and omissions of its Authorized Users and End Users. Without limiting the foregoing, Customer may not use the Services to:

* access or use any system, network, or account without authorization, conduct denial-of-service attacks, distribute malware or other malicious code, or otherwise compromise the security or integrity of any system or network;
* engage in cryptocurrency mining, blockchain-consensus participation, or related activities, except where expressly permitted in the applicable Order Form;
* generate, distribute, or facilitate the creation of weapons of mass destruction, or content that materially uplifts the development or use of chemical, biological, radiological, nuclear, or high-yield explosive ("CBRN") weapons;
* generate, store, or distribute child sexual abuse material ("CSAM"), including AI-generated CSAM, or any content that sexualizes minors; or
* create non-consensual synthetic content (including deepfakes) of real persons, or content intended to impersonate or defraud.

### 3.2 Authorized Users

Customer is responsible for (a) maintaining the security of account credentials, (b) all activity occurring under its account, and (c) ensuring that Authorized Users comply with this Agreement. VESSL has no obligation to monitor, verify, or supervise the identity, authority, or conduct of any Authorized User.

### 3.3 Customer Content

Customer is solely responsible for (a) the accuracy, quality, and legality of Customer Content, (b) obtaining all rights and consents necessary to provide Customer Content to the Services, and (c) the use of any Outputs generated through the Services. Customer represents that Customer Content does not violate any third-party rights or applicable law. Customer is solely responsible for ensuring that its collection, use, storage, and processing of Customer Content complies with all applicable laws and regulations, including data protection, privacy, and sector-specific regulations (such as GDPR and equivalent national laws). VESSL has no obligation to review, monitor, or assess the legality, regulatory compliance, or appropriateness of any Customer Content, and shall have no liability arising from Customer's failure to comply with applicable laws or regulations in connection with Customer Content.

### 3.4 Suspension

VESSL may suspend, throttle, or limit Customer's access to all or part of the Services without liability where:

* Customer's use poses a material security risk to the Services, VESSL's other customers, or any third party;
* Customer materially breaches the AUP or applicable law, or breaches any other material provision of this Agreement and fails to cure within seven (7) days after VESSL's notice (except where the breach is incapable of cure or where immediate suspension is necessary to address a security, legal, or third-party-rights issue);
* Customer fails to pay undisputed Fees when due and such failure continues for thirty (30) days after notice;
* suspension is required by applicable law, court order, or governmental authority;
* Customer's use threatens or impairs, or could reasonably be expected to threaten or impair, the integrity, performance, or availability of the Services for other customers (including resource exhaustion, abuse of shared infrastructure, or denial-of-service-like patterns);
* VESSL reasonably suspects fraud, unauthorized access to Customer's account, or use of the Services in connection with prohibited activities under the AUP;
* Customer or its Authorized Users fail to respond, within a reasonable period, to VESSL's reasonable requests for information necessary to investigate suspected violations of this Agreement; or
* VESSL must suspend Customer's access in response to a legitimate operational, security, or legal directive from an upstream Sub-processor.

Where practicable and not prohibited by law, VESSL will provide prior notice and a reasonable opportunity to cure. VESSL will limit any suspension to the scope reasonably necessary to address the underlying issue and will reinstate access promptly once the issue is resolved. Suspension under this Section 3.4 is independent of, and does not shorten, the cure periods applicable to termination under Section 5.2. The financial consequences of suspension are governed by the applicable Annex and any applicable private transaction terms. Customer will not be charged usage-based Fees for the affected Service to the extent that Service is unavailable during the suspension. Fees for unaffected Services or resources that remain available or continue to be retained may continue to accrue. Any availability Service Credit is governed exclusively by the SLA.

### 3.5 Affiliate Use

Customer may permit its Affiliates to use the Services under this Agreement, provided that (a) Customer remains primarily responsible for compliance with this Agreement by such Affiliates, including all Fees incurred, (b) the Affiliate agrees to be bound by this Agreement (whether by executing an Order Form, by the account holder accepting these terms in the VESSL console on the Affiliate's behalf, or by another written or electronic means), and (c) any breach of this Agreement by an Affiliate is deemed a breach by Customer. Customer's Affiliates may execute Order Forms directly with VESSL or its Affiliates, in which case the executing entity is the contracting party for that Order Form.

### 3.6 Security Cooperation

Customer will reasonably cooperate with VESSL in investigating and responding to any actual or suspected security incident, vulnerability, or unauthorized access affecting the Services or Customer's account, including by providing relevant logs, configuration details, and other information within Customer's control and by taking reasonable remediation steps VESSL recommends. Where a security incident arises from Customer's environment, Customer Content, or Customer's configuration or use of the Services, Customer is responsible for investigating and remediating within its own environment.

### 3.7 No Telecommunication Services

VESSL does not provide telecommunications or internet-access services. Customer is responsible for procuring and maintaining the network connectivity, bandwidth, and equipment required to access the Services, and VESSL is not responsible for performance, security, or availability issues arising from Customer's own network or from the public internet outside VESSL's reasonable control.

### 3.8 Restricted Data

Unless expressly agreed in writing by VESSL (including in an Order Form), Customer will not submit to the Services any (a) special categories of personal data as defined under GDPR Article 9 or equivalent law; (b) data subject to HIPAA, including protected health information; (c) payment card data subject to PCI-DSS; (d) government-issued identifiers (such as Social Security numbers); or (e) personal data of children under the age of 16 (or the applicable age of consent in the relevant jurisdiction) **(collectively, "Restricted Data")**. VESSL does not act as a HIPAA Business Associate, and the Services are not configured for regulated workloads. Customer is solely responsible for any Restricted Data it submits in breach of this Section 3.8.

## 4. Fees and Payment

Payment terms differ by Customer type and are set out in Annex A (Self-Service Customers) and Annex B (B2B Customers). The following provisions apply to all Customers.

### 4.1 Currency and Non-Refundability

Unless stated otherwise, Fees are stated in U.S. dollars and are non-refundable, except as expressly set forth in this Agreement (including Section 12.1) or the applicable Annex.

### 4.2 Taxes and Withholding

Fees are exclusive of taxes. Customer is responsible for all sales, use, value-added, withholding, and similar taxes, excluding taxes based on VESSL's net income. If applicable law requires Customer to deduct or withhold any amount from Fees payable to VESSL, Customer will (a) where the applicable tax authority permits VESSL to claim a foreign tax credit or refund, promptly provide VESSL with official documentation of the withholding sufficient to support such claim, and (b) where Customer is entitled to a reduced or zero rate of withholding under an applicable tax treaty, take all reasonable steps required of Customer to apply that reduced rate. Where Customer fails to satisfy (a) or (b), Customer will gross up the payment so that VESSL receives the amount it would have received absent the withholding.

### 4.3 Credit Categories

Purchased Credits are governed by Annex A, including its purchase, use, validity, refund, and forfeiture rules. Promotional Credits are governed by the conditions stated when they are issued. Service Credits are governed exclusively by the applicable SLA. Each category is non-transferable and not redeemable for cash except to the extent this Agreement or mandatory law expressly requires otherwise. Holding more than one category in the same account or displayed balance does not change the rules applicable to each category.

## 5. Term and Termination

### 5.1 Term

This Agreement begins on the Effective Date and continues until terminated in accordance with its terms. For B2B Customers, the Agreement continues until all Order Forms have expired or been terminated.

### 5.2 Termination for Cause

Either party may terminate this Agreement or any Order Form immediately upon written notice if the other party (a) materially breaches this Agreement and fails to cure within thirty (30) days after notice, or (b) becomes the subject of bankruptcy or insolvency proceedings that are not dismissed within sixty (60) days.

### 5.3 Effect of Termination

Upon termination: (a) Customer's right to access the Services ceases; (b) each party will return or destroy the other's Confidential Information (subject to any retention required by law); and (c) the following provisions will survive: Sections 1, 4, 5.3, 5.4, 6, 7, 8, 10, 11, 12, 13, and 14. Fee obligations upon termination are further addressed in the applicable Annex.

### 5.4 Data Return

Following termination, Customer Content may be recovered or exported only for the period and through the process stated in the applicable Annex, Order Form, and DPA. Termination ends ordinary account, credential, workload, and console access and does not by itself preserve access to self-service export tools. For voluntary termination by a Self-Service Customer, Annex A provides a controlled fourteen (14)-day recovery/export period. A different period may apply to a B2B Customer if expressly stated in its private Order Form. After the applicable period, VESSL will delete remaining Customer Content in accordance with the DPA; where legally and technically appropriate, VESSL may irreversibly de-identify Personal Data instead of retaining it in identifiable form.

### 5.5 Termination for Convenience by VESSL

VESSL may terminate this Agreement, or any Order Form or Service, for convenience upon at least ninety (90) days' prior written notice to Customer. VESSL may also terminate upon thirty (30) days' prior written notice (or shorter where necessary to comply with a third-party requirement or applicable law) if an agreement with an upstream infrastructure provider on which the affected Service materially depends expires or is terminated. Upon any termination under this Section 5.5, VESSL will refund to Customer a pro-rated portion of any pre-paid Fees for the terminated Service attributable to the period after the effective date of termination. During the applicable notice period under this Section 5.5, Customer may continue to use the affected Services and may export Customer Content using available self-service tools; such notice period constitutes the transition period for the affected Services.

## 6. Intellectual Property

### 6.1 VESSL IP

As between the parties, VESSL owns all right, title, and interest in and to the Services, the Documentation, Usage Data, and all derivatives, modifications, and improvements to any of the foregoing. No license is granted except as expressly set forth in this Agreement. VESSL may use Usage Data, in aggregated and de-identified form, to operate, secure, monitor, support, improve, and develop the Services. VESSL's ownership does not extend to Customer Content, Outputs, or any third-party models or open-source software made available through the Services.

### 6.2 Customer Content

As between the parties, Customer owns all right, title, and interest in and to Customer Content. Customer instructs and grants VESSL a worldwide, non-exclusive, royalty-free right to host, copy, transmit, display, and otherwise process Customer Content solely as necessary to provide, operate, support, and secure the Services in accordance with this Agreement, the DPA, the applicable Service-Specific Terms, and Customer's other documented instructions. VESSL will not use Customer Content, Inputs, or Outputs to train, fine-tune, or update any machine learning or artificial-intelligence model, whether internal or externally available, unless Customer affirmatively opts in in writing. VESSL may apply existing automated security, malware, fraud, and AUP-enforcement tools where reasonably necessary to provide or secure the Services, but may not use Customer Content processed by those tools to train or update a model without that written opt-in. Human access to Customer Content is permitted only to the minimum extent and for the limited purposes authorized under the DPA and Support Policy.

### 6.3 Outputs

As between the parties, Customer owns the Outputs generated by the Services from Customer Content (subject to any third-party model licenses applicable to Outputs of specific models). Customer is responsible for evaluating Outputs prior to use and bears all risk arising from use of Outputs.

### 6.4 Feedback

If Customer provides suggestions, feedback, or recommendations to VESSL regarding the Services ("Feedback"), Customer grants VESSL a perpetual, irrevocable, worldwide, royalty-free, fully paid-up license (sublicensable solely to subcontractors and service providers acting on VESSL's behalf in connection with the Services) to use, reproduce, modify, and incorporate the Feedback into the Services and reasonably related VESSL offerings, without attribution or other obligation to Customer.

### 6.5 Third-Party Models and Software

The Services may make available third-party machine learning models or open-source software, which are subject to their respective licenses. Customer is responsible for compliance with such licenses.

## 7. Confidentiality

### 7.1 Obligations

Each party will (a) use the other party's Confidential Information solely to exercise its rights and perform its obligations under this Agreement, (b) protect such information using at least the same degree of care it uses to protect its own confidential information of similar sensitivity (and in no event less than reasonable care), and (c) not disclose such information except to its personnel, professional advisors, and agents who have a need to know and who are bound by confidentiality obligations no less protective than this Section 7. The obligations in this Section 7 survive for three (3) years following termination or expiration of the Agreement, except that obligations with respect to (i) information that constitutes a trade secret survive for so long as such information retains trade-secret status under applicable law, and (ii) Customer Personal Data continue for as long as VESSL or any Sub-processor retains such data.

### 7.2 Exclusions

Confidentiality obligations do not apply to information that (a) is or becomes publicly available without breach of this Agreement, (b) was rightfully known prior to disclosure, (c) is rightfully obtained from a third party without confidentiality obligation, or (d) is independently developed.

### 7.3 Compelled Disclosure

A party may disclose Confidential Information as required by law, provided it gives the other party reasonable advance notice (where legally permitted) and reasonable assistance in seeking a protective order.

## 8. Data Protection and Security

### 8.1 DPA

The DPA is incorporated by reference into this Agreement and applies to processing of personal data on Customer's behalf.

### 8.2 Security

VESSL will implement and maintain technical and organizational measures designed to protect Customer Content against unauthorized access, disclosure, alteration, or destruction, consistent with the SOC 2 Type II framework and, where maintained by VESSL, ISO/IEC 27001, as referenced in Section 14.14. Notice of a Personal Data Breach affecting Customer Personal Data, and assistance relating to that breach, are governed exclusively by Section 8 of the DPA.

## 9. Warranties

### 9.1 Authority and Applicable-Law Warranties

Each party warrants that: (a) it has the legal authority to enter into this Agreement; and (b) it will comply with the laws and regulations applicable to its own performance under, or use of the Services under, this Agreement.

### 9.2 VESSL Service Warranty

For paid, generally available Services, VESSL warrants that the Services will perform materially in accordance with the Documentation expressly applicable to those Services when Customer uses them as authorized. This warranty does not apply to Beta Services or free, trial, promotional, or complimentary Services.

Availability, uptime, latency, capacity, response time, and other express service-level commitments are governed exclusively by the applicable SLA and are not part of this Section 9.2 warranty.

Customer must notify VESSL of a claimed material non-conformity with reasonable detail. VESSL will use commercially reasonable efforts to correct the non-conformity or re-perform the affected Service. If VESSL does not cure the material non-conformity within thirty (30) days after receiving notice, Customer may terminate the affected Service and receive the unused portion of pre-paid Fees or Purchased Credits reasonably allocated to that Service. This is Customer's sole monetary remedy for breach of this Section 9.2, subject to rights that cannot lawfully be limited.

### 9.3 Customer Warranty

Customer warrants that (a) it has obtained all rights and consents necessary to provide Customer Content to the Services, and (b) Customer Content and Customer's use of the Services will not violate this Agreement, the AUP, third-party rights, or applicable law.

## 10. Disclaimers

EXCEPT AS EXPRESSLY SET FORTH IN SECTION 9, THE SERVICES, INCLUDING ANY OUTPUTS, ARE PROVIDED "AS IS" AND "AS AVAILABLE." VESSL DISCLAIMS ALL OTHER WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, AND ANY WARRANTY ARISING OUT OF COURSE OF DEALING OR USAGE OF TRADE. VESSL DOES NOT WARRANT THAT THE SERVICES WILL BE UNINTERRUPTED OR ERROR-FREE, OR THAT OUTPUTS WILL BE ACCURATE, COMPLETE, OR APPROPRIATE FOR ANY USE.

VESSL IS NOT LIABLE FOR ANY SERVICE INTERRUPTIONS, PERFORMANCE DEGRADATION, OR DATA LOSS ARISING FROM FAILURES OF THIRD-PARTY INFRASTRUCTURE PROVIDERS, INCLUDING CLOUD PROVIDERS, NETWORK OPERATORS, OR POWER SUPPLIERS, EXCEPT TO THE EXTENT DIRECTLY CAUSED BY VESSL'S OWN NEGLIGENCE OR WILLFUL MISCONDUCT. VESSL IS NOT LIABLE FOR ANY LOSS, DAMAGE, OR SECURITY INCIDENT ARISING FROM CUSTOMER'S MISCONFIGURATION, IMPROPER USE, OR FAILURE TO IMPLEMENT ADEQUATE SECURITY MEASURES WITHIN CUSTOMER'S OWN ENVIRONMENT.

EXCEPT TO THE EXTENT OF VESSL'S INDEMNIFICATION OBLIGATIONS UNDER SECTION 12.1, VESSL DISCLAIMS ALL LIABILITY ARISING FROM ANY INTELLECTUAL PROPERTY CLAIMS RELATING TO OUTPUTS GENERATED THROUGH THE SERVICES.

## 11. Limitation of Liability

### 11.1 Excluded Damages

TO THE MAXIMUM EXTENT PERMITTED BY LAW, NEITHER PARTY WILL BE LIABLE FOR INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, EXEMPLARY, OR PUNITIVE DAMAGES, OR FOR LOSS OF PROFITS, REVENUE, DATA, GOODWILL, OR BUSINESS, ARISING OUT OF OR RELATING TO THIS AGREEMENT, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. This Section 11.1 does not exclude an amount payable to a third party under an indemnity expressly covered by Section 12, but the applicable monetary cap remains in effect.

### 11.2 General Cap

Except as stated in Sections 11.3 and 11.4, VESSL's aggregate liability arising out of or relating to this Agreement will not exceed the Fees paid or payable for the affected Services giving rise to the claim during the twelve (12) months preceding the first event giving rise to liability. For paid Services, Customer's ordinary aggregate liability is subject to the same cap unless an approved exception applies. For VESSL liability arising solely from a free, trial, promotional, or complimentary Service, VESSL's aggregate liability will not exceed the lesser of Customer's proven direct damages or USD 100. No zero-spend or USD 100 cap limits Customer's obligations arising from free, trial, promotional, or complimentary use, except to the extent mandatory law requires otherwise.

### 11.3 VESSL Enhanced Cap

VESSL's aggregate liability for: (a) breach of Section 7 (Confidentiality); (b) breach of VESSL's obligations under the DPA or Section 8 relating to data protection or security; and (c) VESSL's obligations under Section 12.1 will not exceed two (2) times the cap calculated under the first sentence of Section 11.2.

### 11.4 Matters Outside the Caps

Sections 11.1 through 11.3 do not exclude or limit: (a) Customer's payment obligations as a debt; (b) a party's fraud or willful misconduct; (c) gross negligence to the extent liability for it cannot lawfully be limited; (d) death or personal injury caused by negligence to the extent liability cannot lawfully be limited; (e) liability that cannot be excluded or limited under applicable law; or (f), for a Customer that is not a consumer, Customer's knowing prohibited safety-critical High-Risk Use under Section 14.19 or Customer's willful infringement or misappropriation of VESSL's Intellectual Property Rights.

### 11.5 Mandatory Rights and Private Terms

Nothing in this Agreement limits a consumer right that cannot lawfully be waived. An applicable Order Form or separately executed supplemental agreement may state a different liability allocation for the transaction it expressly covers.

## 12. Indemnification

### 12.1 By VESSL

VESSL will defend Customer against a third-party claim alleging that a paid, generally available Service developed by VESSL, when used as authorized under this Agreement, infringes or misappropriates the third party's Intellectual Property Rights, and will pay damages finally awarded by a court of competent jurisdiction or agreed in a settlement approved by VESSL.

VESSL's obligations do not apply to a claim arising from: (a) Customer Content, Customer instructions, or a Customer-provided model, application, product, or material; (b) a third-party model or third-party Output; (c) a Beta, free, trial, promotional, or complimentary Service; (d) a modification not made by VESSL; (e) combination with an item not provided or required by VESSL, where the claim would not otherwise have arisen; (f) use outside this Agreement or the Documentation; or (g) continued use after VESSL instructs Customer to cease the allegedly infringing use.

If a covered Service is or is likely to be enjoined, VESSL may, at its option: (i) procure the right for continued use; (ii) modify or replace the affected Service with materially equivalent non-infringing functionality; or (iii) terminate the affected Service and refund the unused portion of pre-paid Fees or Purchased Credits reasonably allocated to that Service.

### 12.2 By Customer

Customer will defend VESSL and its Affiliates against a third-party claim to the extent arising from an allegation that: (a) Customer Content, a Customer-provided model, instruction, application, product, or other material infringes or misappropriates a third party's rights; (b) Customer's material breach of the AUP or an express use restriction, or Customer's unlawful use of the Services, caused the claim; or (c) Customer knowingly engaged in prohibited safety-critical High-Risk Use or failed to implement a safety control that this Agreement expressly assigns to Customer for Customer's deployment. Customer will pay damages finally awarded by a court of competent jurisdiction or agreed in a settlement approved by Customer.

Customer has no obligation under this Section 12.2 to the extent the claim was caused by VESSL's breach of this Agreement, a defect in the Services, or infringement for which VESSL is responsible under Section 12.1.

### 12.3 Procedure

The indemnified party will (a) promptly notify the indemnifying party of the claim (provided that failure to give prompt notice will not relieve the indemnifying party of its obligations except to the extent it is materially prejudiced by such failure), (b) give sole control of defense and settlement to the indemnifying party (provided that no settlement requiring an admission of liability or a non-monetary obligation may be made without the indemnified party's consent), and (c) provide reasonable cooperation at the indemnifying party's expense.

### 12.4 Indemnification Cap

VESSL's liability under Section 12.1 is subject to the enhanced cap in Section 11.3. Customer's liability under Section 12.2 is subject to Section 11.2, except that the non-consumer Customer liabilities identified in Section 11.4(f) are outside the caps. A private Order Form or separately executed supplemental agreement may state a different indemnification cap for the transaction it expressly covers.

### 12.5 Sole and Exclusive Remedy

The indemnification obligations in this Section 12 state each party's sole and exclusive liability, and the indemnified party's sole and exclusive remedy, for the third-party claims described herein.

## 13. Service Levels

The applicable SLA exclusively governs availability measurements, service-level objectives, exclusions, claims, and Service Credits. Service Credits are Customer's sole monetary remedy for a failure to meet an SLA metric. This does not limit: (a) Customer's right to terminate for an uncured material breach under Section 5.2; (b) liability arising from VESSL's willful misconduct or gross negligence to the extent it cannot lawfully be limited; or (c) a right that cannot lawfully be excluded.

Customer may not recover both a Service Credit and another monetary remedy for the same loss or event. A Service Credit does not become a Purchased Credit and does not alter the validity or refund treatment of Purchased Credits.

## 14. General

### 14.1 Governing Law and Venue

For a B2B Customer, the governing law and forum stated in the applicable Order Form control. If the Order Form does not specify both matters, or if Customer uses the Services without an Order Form, the following rules apply based on the contracting VESSL entity:

* where the contracting entity is VESSL AI, Inc., this Agreement is governed by the laws of the State of Delaware, United States of America, without regard to conflict-of-laws principles, and any dispute will be subject to the exclusive jurisdiction of the state and federal courts located in the State of Delaware; and
* where the contracting entity is VESSL AI KOREA Inc., this Agreement is governed by the laws of the Republic of Korea, without regard to conflict-of-laws principles, and any dispute will be subject to the exclusive jurisdiction of the Seoul Central District Court.

Each party irrevocably submits to the personal jurisdiction of the applicable courts. The United Nations Convention on Contracts for the International Sale of Goods does not apply.

If Customer is a consumer, this Section does not deprive Customer of any protection or right to bring proceedings in another court that cannot lawfully be waived under the law of Customer's habitual residence.

### 14.2 Notices

Notices to VESSL must be sent to [legal@vessl.ai](mailto:legal@vessl.ai). Notices to Customer will be sent to the email address on file or designated in the applicable Order Form. Notices are deemed given upon receipt.

### 14.3 Assignment

Neither party may assign this Agreement without the other party's prior written consent, except to an Affiliate or in connection with a merger, acquisition, or sale of substantially all assets. VESSL will provide Customer with written notice of any such assignment.

### 14.4 Force Majeure

Neither party will be liable for failure or delay in performance (other than payment obligations) caused by a Force Majeure Event. The affected party will use commercially reasonable efforts to mitigate the impact and resume performance. If a Force Majeure Event continues for more than ninety (90) consecutive days, the unaffected party may terminate the affected Order Form or Services on written notice.

### 14.5 Independent Contractors

The parties are independent contractors. This Agreement does not create any agency, partnership, or joint venture.

### 14.6 Export Control and Sanctions

**(a) Compliance.** Customer represents that it is not, and is not majority-owned or controlled by, and will not use the Services from or for the benefit of, any country, person, or entity subject to U.S., EU, U.K., United Nations, or other applicable national trade sanctions or export restrictions, including OFAC sanctions and the U.S. Export Administration Regulations. Customer will comply with all applicable export control and sanctions laws and will not export, re-export, or transfer the Services or any related technology in violation of such laws.

**(b) Restricted End Uses.** Customer will not use the Services, and will not knowingly permit any third party to use the Services: (i) for any military, military-intelligence, or weapons-related end use; (ii) for training AI models by or for the benefit of any entity whose ultimate parent entity is headquartered in a country listed in Country Group D:5 of the U.S. Export Administration Regulations; or (iii) through any structure designed to circumvent this Section 14.6.

**(c) KYC Verification.** VESSL may, at any time, request that Customer provide information and documentation reasonably necessary to verify Customer's compliance with Sections 14.6(a) and (b), including evidence of Customer's identity, beneficial ownership structure, and the intended use and location of use of the Services. Customer will respond to such requests promptly and in good faith, and will provide accurate and complete information. VESSL may suspend access to the Services pending Customer's response to a request under this Section 14.6(c).

**(d) Suspension and Forfeiture.** If Customer (or any of its Affiliates using the Services) becomes subject to any sanctions or export-restriction list referenced in Section 14.6(a), if Customer fails to provide the information requested under Section 14.6(c), if information provided under Section 14.6(c) indicates that Customer's representation under Section 14.6(a) was inaccurate, if Customer breaches Section 14.6(b), or if VESSL's continued provision of the Services would violate applicable export control or sanctions laws, VESSL may immediately suspend or terminate the Services and the Agreement without liability. In such case: (i) Customer remains liable for all Fees accrued through the date of suspension or termination; (ii) any pre-paid or upfront Fees attributable to the suspended or terminated period are forfeited and non-refundable, except to the extent a refund is permitted by applicable sanctions, export control, and other laws; and (iii) VESSL is not required to return, transfer, or facilitate the export of Customer Content if doing so would violate applicable laws.

### 14.7 No Third-Party Beneficiaries

This Agreement is for the sole benefit of the parties and their permitted successors and assigns. Nothing in this Agreement creates or implies any right in any third party.

### 14.8 Severability

If any provision is held unenforceable, it will be modified to the minimum extent necessary to make it enforceable; the remaining provisions will remain in full force and effect.

### 14.9 Entire Agreement

This Agreement, together with the documents that apply under Section 2.2, constitutes the entire agreement between the parties concerning its subject matter and supersedes all prior agreements and understandings concerning that subject matter. Documentation is included only within the limited scope stated in its definition. Any pre-printed or incorporated terms on a Customer purchase order or similar document are of no force or effect unless expressly accepted in writing by authorized representatives of both parties.

### 14.10 Amendments

VESSL may update these Core Terms, the AUP, the SLA, the DPA, the Support Policy, the Service-Specific Terms, and the Sub-processor List from time to time. A non-material administrative, clarifying, technical, or operational update that does not materially adversely affect Customer's legal or commercial rights or obligations may take effect when published.

A materially adverse change to legal or commercial terms will be communicated in advance and will apply prospectively. For a Self-Service Customer, VESSL will provide at least seven (7) days' notice and the change is subject to Annex A. For a B2B Customer, the effect of a change on an active Order Form is governed by the applicable private transaction terms; absent Customer's written consent or an applicable exception in those terms, a materially adverse change applies at renewal rather than during the then-current Subscription Term.

A change required by applicable law or a regulatory authority, or reasonably necessary to address an urgent security, integrity, fraud, or third-party-rights issue, may take effect on shorter notice, including immediately where reasonably necessary. VESSL will provide as much notice as is reasonably practicable.

Price changes are governed by Annex A Section A2.1 or the applicable Order Form. Changes to Sub-processors are governed by the DPA. No amendment retroactively alters accrued rights, existing claims, or the expiration date of Purchased Credits grandfathered under Annex A. Changes to Documentation do not amend this Agreement except within the limited scope stated in the definition of Documentation.

### 14.11 Anti-Corruption

Each party will comply with all applicable anti-corruption and anti-bribery laws, including (where applicable) the U.S. Foreign Corrupt Practices Act, the UK Bribery Act 2010, and equivalent national laws.

### 14.12 Insurance

During the Subscription Term, VESSL will maintain commercially reasonable insurance coverage, including (a) commercial general liability, (b) professional liability / errors and omissions, (c) cyber and privacy liability, and (d) workers' compensation as required by law. Upon Customer's reasonable written request (no more than once per year), VESSL will provide a certificate of insurance evidencing such coverage.

### 14.13 No Most Favored Nation

VESSL is not obligated to extend to Customer any pricing, discount, term, or condition that VESSL may offer to other customers.

### 14.14 Compliance Reports and Customer Audit

VESSL maintains an information security and privacy program supported by third-party audits, including SOC 2 Type II and, where maintained by VESSL, ISO/IEC 27001. For B2B Customers, audit report summaries and security questionnaire responses are available as set out in Annex B.

### 14.15 Counterparts and Electronic Signatures

This Agreement and any Order Form may be executed in counterparts. Electronic signatures and signatures via electronic-signature platforms (such as DocuSign) are valid and enforceable to the same extent as original handwritten signatures.

### 14.16 Publicity

VESSL may use Customer's name, logo, trademarks, or relationship with VESSL in marketing, customer lists, case studies, or similar publicity only with Customer's affirmative permission. For a Self-Service Customer that is an organization, VESSL may obtain that permission through a separate opt-in in the Services or another written or electronic record. No publicity permission arises automatically for an individual Self-Service Customer. For a B2B Customer, any publicity permission must be stated in the applicable private Order Form or another written agreement. A press release concerning Customer requires Customer's express prior approval; silence or failure to object is not consent.

### 14.17 Benchmarking and Competitive Use

Customer may conduct benchmarks and performance tests of the Services for its internal evaluation. Customer will not publish or disclose to any third party the results of any benchmark or performance test without VESSL's prior written consent. Customer will not access the Services for the purpose of building a substantially similar managed AI infrastructure platform that directly substitutes for the Services.

### 14.18 Reverse Engineering and Derivative Works

Customer will not, and will not permit any third party to, reverse engineer, decompile, disassemble, modify, translate, or create derivative works of the Services or remove any proprietary notice on the Services, except (a) to the extent applicable law expressly permits notwithstanding this restriction, or (b) for use, modification, or fine-tuning of third-party machine learning models that are made available through the Services under their respective licenses.

### 14.19 High-Risk Use and AI-Law Responsibilities

The Services are not designed, intended, or authorized for use as a real-time component in the safety-critical operation, control, or decision-making layer of an application where a failure could foreseeably cause death, personal injury, or severe environmental damage ("High-Risk Use"). Customer must not engage in such High-Risk Use unless an applicable Order Form or separately executed supplemental agreement expressly authorizes the use and states the required safeguards and risk allocation.

Each party is responsible for obligations under AI-related laws and regulations that apply to that party in its actual role. Customer is responsible for its deployment context, intended use, Customer Content and input data, instructions, model and Output evaluation, human oversight, notices and consents, downstream decisions, and compliance controls assigned to Customer under applicable law or this Agreement. Any indemnity relating to High-Risk Use is governed exclusively by Sections 12.2 through 12.4.

### 14.20 Waiver

No failure or delay by either party in exercising any right or remedy under this Agreement will operate as a waiver of that right or remedy. Any waiver must be in writing and signed by the waiving party to be effective.

### 14.21 Limitation of Actions

To the extent permitted by applicable law, any claim or cause of action arising out of or relating to this Agreement or the Services must be commenced within one (1) year after the claim or cause of action accrues; otherwise it is permanently barred. This Section 14.21 does not apply where the Customer is a consumer and mandatory law provides a longer non-waivable period.

***

VESSL AI, Inc. — [legal@vessl.ai](mailto:legal@vessl.ai)


# Self-Service terms
Source: https://docs.cloud.vessl.ai/legal/msa-annex-a

Annex A to the VESSL Cloud master services agreement, applying to Self-Service customers without an Order Form.

<Info>
  Effective date: August 6, 2026 · Last updated: August 6, 2026
</Info>

These Self-Service Terms apply to each individual or organization that registers for or uses the Services without executing an Order Form. These Self-Service Terms supplement the Core MSA Terms. Any conflict is resolved under Section 2.2 of the Core MSA Terms.

## A1. Account Registration

### A1.1 Eligibility

Self-Service Customers who are natural persons must be at least eighteen (18) years of age, or the age of majority in their jurisdiction if higher. By completing registration, Customer represents and warrants that they meet this eligibility requirement. VESSL reserves the right to require age verification and to suspend or terminate accounts where eligibility cannot be confirmed.

### A1.2 Account Creation

The account is established upon completion of the online registration process, including email verification. No Order Form or signature is required for access under this Annex A.

### A1.3 Accurate Information

Customer must provide accurate, current, and complete registration information and must keep such information updated throughout the term of their account. VESSL may suspend or terminate accounts found to contain materially inaccurate or misleading registration information.

### A1.4 One Account Per Individual

Unless otherwise agreed, each individual may maintain only one personal account. Creating duplicate or multiple accounts to circumvent usage limits, trial restrictions, or suspensions is a material breach of this Agreement.

### A1.5 Account Security

Customer is solely responsible for maintaining the confidentiality of its account credentials and for all activity that occurs under its account. Customer must (a) use a strong, unique password and, where available, enable multi-factor authentication; (b) not share credentials with any unauthorized person; and (c) notify VESSL promptly at [security@vessl.ai](mailto:security@vessl.ai) upon becoming aware of any unauthorized access. VESSL will not be liable for any loss arising from unauthorized access resulting from Customer's failure to maintain adequate credential security.

## A2. Fees, Billing, and Payment

### A2.1 Pricing

Self-Service Customers are billed according to the pricing published on VESSL's website and in the Services console, as updated from time to time. VESSL will provide at least seven (7) days' advance notice through the VESSL console or by email before an increase to pricing applicable to Customer takes effect. A price increase applies prospectively and does not alter Fees accrued before its effective date.

### A2.2 Payment Method and Purchased Credit Balance

Self-Service Customers must maintain a valid credit card or other VESSL-accepted payment method on file via VESSL's payment processor (Stripe). Customer may use this payment method to purchase Purchased Credits, which are added to Customer's account balance. By providing a payment method, Customer authorizes VESSL, through Stripe, to charge that payment method for Purchased Credit purchases and any other Fees incurred.

Purchased Credits acquired before the effective date of this version of Annex A retain the expiration date displayed when they were acquired, or any later expiration date VESSL previously granted. Purchased Credits acquired on or after that effective date expire twelve (12) months from the date of acquisition, unless a longer period is stated in the terms under which they are issued.

VESSL will provide at least thirty (30) days' advance notice through the VESSL console or by email before Purchased Credits expire and may provide additional reminders closer to expiration. Expired Purchased Credits are forfeited except as set out in Section A5. Promotional Credits expire as stated in the conditions under which they are issued. Service Credits expire as stated in the SLA.

### A2.3 Usage-Based Deduction

Fees for usage-based Services are deducted from available Purchased Credits and Promotional Credits as the Services are consumed, in each case in accordance with the terms applicable to that category. Service Credits are applied only as stated in the SLA. If the available Purchased Credits and Promotional Credits are insufficient to cover accrued Fees, VESSL may suspend access to the affected Services until Customer adds sufficient Purchased Credits or another accepted payment method. Customer is responsible for maintaining sufficient available value to avoid service interruption.

## A3. Modifications to the Services

### A3.1 Non-material Technical and Operational Changes

VESSL may make a technical or operational change that does not materially decrease the functionality of a Service or materially adversely affect Customer's contracted use when the change is implemented. VESSL may communicate such a change through the VESSL console, Documentation, release notes, or email.

**A3.2 Material Changes**

VESSL will provide at least thirty (30) days' prior notice through the VESSL console or by email before a change that materially decreases the functionality of a Service or materially adversely affects Customer's contracted use takes effect. The change will apply prospectively. Customer may reject the change by terminating its account before the effective date. If the change materially reduces Customer's contractual rights or materially increases Customer's obligations, VESSL will refund the unused balance of Customer's Purchased Credits following termination. Continued use of the affected Service after the effective date constitutes acceptance of the change.

### A3.3 Urgent Changes

VESSL may make a change on shorter notice, including immediately where reasonably necessary, if the change is required by applicable law or a regulatory authority or is reasonably necessary to address an urgent security, integrity, fraud, or third-party-rights issue. VESSL will provide as much advance notice as is reasonably practicable and use commercially reasonable efforts to minimize material adverse impact.

### A3.4 Reserved Subjects

Price changes are governed by Section A2.1. Amendments to legal or commercial terms are governed by Section A7.

## A4. Term, Termination, and Account Management

### A4.1 Termination by Customer

Customer may terminate its account at any time by using the account-deletion function in the VESSL console or by submitting a written request to [support@vessl.ai](mailto:support@vessl.ai). Termination is effective upon Customer's request, and ordinary account, token, credential, workload, and console access ends immediately. During the fourteen (14)-day period described in Section A4.3, Customer may request controlled account recovery or export of eligible Customer Content. Fees already paid, including Purchased Credits, are non-refundable except as set out in Section A5.

### A4.2 Termination by VESSL

VESSL's rights to suspend or terminate Customer's access to the Services are set out in Sections 3.4 and 5 of the Core MSA Terms. Where applicable consumer protection law in Customer's jurisdiction imposes specific procedural requirements or limitations on termination of consumer accounts, VESSL will comply with such requirements to the extent they are mandatory.

### A4.3 Voluntary Termination: Recovery, Export, and Deletion

Upon voluntary account termination under Section A4.1: (a) ordinary account, token, credential, workload, and console access ends immediately, and active Workspace compute is terminated; (b) unless Customer gives an action-specific instruction for earlier irreversible deletion or earlier deletion is required by law or an applicable Service-Specific Term, VESSL will retain eligible Customer Content in active systems for fourteen (14) days solely to support controlled account recovery or export; (c) during that period, Customer may request recovery or export through the process stated in the Support Policy or another controlled process made available by VESSL, and VESSL may verify the requester's identity and authority; (d) VESSL is not required to restore billable workloads or ordinary account access solely to provide an export; and (e) after the fourteen (14)-day period, VESSL will delete remaining Customer Content from active systems in accordance with the DPA and will delete or, where legally and technically appropriate, irreversibly de-identify applicable account data.

Termination of an individual user account does not cause deletion of Customer Content belonging to an organization that retains another authorized member. Temporary or ephemeral data may be deleted earlier under the applicable Service-Specific Terms. Separately managed Cluster Storage and Object Storage remain subject to their expressly stated lifecycle, and backups, security records, transaction records, and legal holds remain subject to the limited retention rules in the DPA and applicable law.

### A4.4 Suspension — Fee Consequences

During a suspension, VESSL will preserve Customer's remaining Purchased Credits, Promotional Credits, and Service Credits. VESSL will not deduct Purchased Credits or Promotional Credits for use of an affected Service to the extent that Service is unavailable, but may deduct them for unaffected Services or resources that remain available or continue to be retained at Customer's direction, in each case under their applicable terms. Service Credits may be applied only as stated in the SLA. VESSL will not forfeit any Purchased Credits, Promotional Credits, or Service Credits solely because of the suspension, but the expiration rules applicable to each category continue to apply. A suspension does not itself create a time-based pro-rata credit or a Service Credit. Refunds or other remedies arising from VESSL's material breach remain governed by the Core Terms and Section A5, and availability Service Credits remain governed exclusively by the SLA.

### A4.5 Dormant Account Management

**(a) Dormancy Threshold.** An account becomes dormant when there has been no login, API call, or billable activity for a continuous period of twelve (12) months. For an organization account, activity by any Authorized User associated with that organization prevents the organization account from becoming dormant.

**(b) Notice of Dormancy.** At least sixty (60) days before taking any action on a dormant account, VESSL will send a notice to the email address on file. VESSL will send a second reminder notice no later than thirty (30) days before scheduled deletion.

**(c) Reactivation.** Customer may reactivate a dormant account at any time prior to deletion by logging into the account or by contacting VESSL at [support@vessl.ai](mailto:support@vessl.ai). Reactivation resets the dormancy period.

**(d) Deletion.** If Customer does not reactivate within the notice period, VESSL may permanently delete the dormant account and associated Customer Content in accordance with the DPA. Termination or dormancy of one individual user does not cause deletion of Customer Content belonging to an organization that retains another Authorized User. VESSL will not be liable for loss of Customer Content resulting from deletion completed in accordance with this Section A4.5 and the DPA. Any remaining Purchased Credits may be forfeited only to the extent permitted by applicable mandatory law. Promotional Credits expire under the conditions on which they were issued, and Service Credits expire under the SLA. The notices provided under this Section A4.5 will state the scheduled deletion date and explain the proposed treatment of each remaining category.

## A5. Refunds and Consumer Protections

All Fees paid by Self-Service Customers, including amounts represented by Purchased Credits, are non-refundable. Purchased Credits, Promotional Credits, and Service Credits are not redeemable for cash. This Section A5 does not limit: (a) refunds expressly provided for in this Agreement, including Sections 5.5 and 12.1 of the Core MSA Terms and Section A3.2 of this Annex A; or (b) the rights of Customers who are consumers under applicable mandatory consumer protection law that cannot be waived by contract, with which VESSL will comply. For purposes of the provisions referenced in clause (a), "pre-paid Fees" includes the unused balance of Customer's Purchased Credits, but excludes Promotional Credits and Service Credits.

## A6. Publicity

No publicity permission arises merely because Customer creates an account or uses the Services. If Customer is an organization, VESSL may request a separate affirmative opt-in to use Customer's name or logo as described in Core Section 14.16. If Customer is an individual, VESSL will not use Customer's name or other identifying information for publicity without Customer's separate express permission.

## A7. Amendments

VESSL may update these Self-Service Terms and the other public terms incorporated into the Agreement. A non-material administrative, clarifying, technical, or operational update that does not materially adversely affect Customer's legal or commercial rights or obligations may take effect when published.

VESSL will provide at least seven (7) days' advance notice through the VESSL console or by email before a materially adverse change to legal or commercial terms takes effect. The change will apply prospectively. Customer may reject the change by terminating its account before the effective date. If the change materially reduces Customer's contractual rights or materially increases Customer's obligations, VESSL will refund the unused balance of Customer's Purchased Credits following termination. Continued use of the Services after the effective date constitutes acceptance of the change.

A change required by applicable law or a regulatory authority, or reasonably necessary to address an urgent security, integrity, fraud, or third-party-rights issue, may take effect on shorter notice, including immediately where reasonably necessary. VESSL will provide as much notice as is reasonably practicable.

Price changes are governed by Section A2.1, and changes to Sub-processors are governed by the DPA. No amendment retroactively alters accrued rights, existing claims, or the expiration date of Purchased Credits grandfathered under Section A2.2.

***

VESSL AI — [legal@vessl.ai](mailto:legal@vessl.ai) — Annex A — Self-Service Terms


# Legal
Source: https://docs.cloud.vessl.ai/legal/overview

VESSL AI legal agreements, service-specific terms, and public policies for VESSL Cloud.

This section gathers the public legal documents that govern the use of VESSL Cloud — the agreements that frame our relationship with customers, the service-specific terms that apply to individual products, and the public policies that cover acceptable use, privacy, cookies, and support.

## Agreements

* [Master service agreement (MSA)](/legal/msa)
  * [Annex A — Self-Service terms](/legal/msa-annex-a)
* [Service level agreement (SLA)](/legal/sla)
* [Data processing agreement (DPA)](/legal/dpa)
* [Sub-processor list](/legal/sub-processors)

Customers who access the Services under an executed Order Form are governed by additional enterprise terms provided with their transaction package rather than by Annex A.

## [Service-specific terms](/legal/service-terms)

* [Container Compute service](/legal/container-compute)
* [VM Cluster service](/legal/vm-cluster)
* [Storage service](/legal/storage)
* [Inference service](/legal/inference)

## Public policies

* [Acceptable use policy](/legal/acceptable-use)
* [Privacy policy](/legal/privacy)
* [Cookie policy](/legal/cookie)
  * [Cookie list](/legal/cookie-list)
* [Support policy](/legal/support-policy)


# Monitor workloads
Source: https://docs.cloud.vessl.ai/member/dashboard/overview

View your active workloads, GPU usage, and spend rate at a glance.

The Home dashboard gives you a single view of all your running workloads across every team you belong to. Click **Home** in the sidebar to open the dashboard.

<div>
  <Frame>
    <img alt="Home dashboard showing summary cards and workloads table" />
  </Frame>

  <small>Example: Home dashboard with summary cards and workload list</small>
</div>

## Summary cards

Four cards at the top provide an at-a-glance overview of your workloads.

| Card | Description |
| - | - |
| **Active workloads** | Total number of your workloads excluding terminated ones (running, paused, queued, and initializing) |
| **GPUs in use** | Number of GPUs currently allocated to your running workspaces |
| **GPU utilization** | One-hour GPU-weighted average across your running workspaces. If runtime is under one hour, the card stays in a temporary collecting state (for example, `Collecting...`) |
| **Spend rate** | Current hourly cost across all your running workspaces (\$/hr). Excludes storage costs |

<div>
  <Frame>
    <img alt="Summary card with tooltip hover revealing how each metric is calculated" />
  </Frame>

  <small>Example: Hover over tooltip icons to see how each metric is calculated</small>
</div>

<Info>
  Hover over the tooltip icon on each card to see how the metric is calculated.
</Info>

## Workloads

The workloads table lists your active workspaces grouped by team.

<div>
  <Frame>
    <img alt="Workloads table grouped by team with under-utilization warning icons" />
  </Frame>

  <small>Example: Workloads table</small>
</div>

### Filters

* **Team**: Show workloads from a specific team or all teams
* **Status**: Filter by workload status (for example, Running, Paused)
* **Clear**: Reset all filters

### Table columns

| Column | Description |
| - | - |
| **Workload name** | Workspace name. Workloads with low GPU utilization show an under-utilization warning. Click to open the workspace detail page. |
| **Status** | Current status (Running, Paused, Stopped, and so on) |
| **Team** | Team the workload belongs to |
| **GPU** | GPU type and count (for example, "A100-80GB x 4") |
| **GPU Utilization (1hr)** | One-hour average GPU utilization, weighted by GPU count. Color-coded: green (**90%**+), gray (**30**–**90%**), orange (below **30%**) |
| **Spend rate** | Hourly cost for this workload (\$/hr) |

When you filter by a specific team, a **Total** row appears at the bottom showing combined GPU count, average utilization, and total spend rate.

## Quickstart cards

When you have no running workloads, the dashboard shows three quickstart cards to help you get started:

<div>
  <Frame>
    <img alt="Home dashboard quickstart cards linking to Workspaces, Cluster storage, and Object storage setup" />
  </Frame>

  <small>Example: Quickstart cards</small>
</div>

* **Get started with workspaces** — Launch a GPU environment and start developing
* **Connect Cluster storage** — Set up high-performance shared storage for fast, large-scale data loading
* **Use Object storage** — Store and retrieve data with cost-efficient S3-based storage for archiving and long-term preservation

## Edge cases

| Scenario | Behavior |
| - | - |
| No running workloads | Quickstart cards are displayed instead of the workload table |
| No metric data | Workloads running for less than one hour stay in a temporary collecting state |
| No matches after filtering | The table shows an empty-state hint suggesting filter adjustment |
| CPU-only workload | GPU columns show `-` |


# Clean up jobs
Source: https://docs.cloud.vessl.ai/member/job/cleanup

Terminate a running job and hide finished jobs from the default list.

VESSL Cloud's job lifecycle now separates **stopping** a running job from **hiding** finished jobs in your views. Use **Terminate** to cancel work mid-run; use the `--hide-deleted` filter to keep your list focused on what's still active.

<Note>
  The [Apr 30, 2026 release](/changelog/overview/updates) split **terminate** and **delete** into separate actions. Terminating a job now only stops compute — the run record (configuration, logs, metrics) is preserved, and the job stays in your list. Use the `--hide-deleted` filter to keep terminated jobs out of the default view.
</Note>

## Terminate a running job

From the console: open the job's detail page and click **Terminate**.

From the CLI:

```bash theme={null}
vesslctl job terminate <job-slug>
```

| Flag | Short | Description |
| - | - | - |
| `--yes` | `-y` | Skip the confirmation prompt |

Termination stops compute billing immediately. Data already written to mounted volumes is preserved, and the run record (configuration, logs, metrics) stays available for review on the [details page](/member/job/details).

## Hide cancelled or terminated jobs in the CLI list

`vesslctl job list --hide-deleted` filters cancelled and terminated jobs out of the default output, which is useful when you only want to see jobs that are still active or recently scheduled:

```bash theme={null}
vesslctl job list --hide-deleted
```

## See also

* [List batch jobs](/member/job/list)
* [`vesslctl job terminate`](/cli/commands/job#terminate)
* [`vesslctl job list`](/cli/commands/job#list)


# Create a batch job
Source: https://docs.cloud.vessl.ai/member/job/create

Create a batch job from the console or with vesslctl.

## Overview

A job runs a command in a container and exits when the command finishes. Use it for training, inference, and batch processing workloads.

There are three ways to create a job:

* **Console** — fill in the **Create Job** form and submit. Best for your first few jobs.
* **CLI** — run `vesslctl job create`. Best for automation, scripting, and reproducible runs.
* **Convert a workspace** — clone a workspace's image, resource spec, and volumes into a job. See [Convert a workspace to a Job](/member/workspace/convert-to-job).

## Prerequisites

* **Available credit balance**: Job creation is blocked when the balance is zero or negative. Add a payment method and top up from [Billing](/admin/billing/credits).
* **(CLI only) Authenticated `vesslctl`**: Run `vesslctl auth login` to complete the browser OAuth flow. See the [CLI Quickstart](/cli/quickstart#prerequisites) for the full setup.
* **(Optional) Persistent volume for outputs**: Create an [Object storage or Cluster storage volume](/member/volume/create) ahead of time if you need to keep model checkpoints or other artifacts.

## Create from the console

Open **Jobs** in the sidebar and click **Create Job**, then fill in the form. Most fields match the workspace creation flow — a job adds a command to run and drops the interactive pieces (SSH, ports).

<div>
  <Frame>
    <img alt="Create a new Job form showing job name, command, working directory, environment variables with organization secrets, hardware configuration (GPU product, region, and count), persistent volume, container image, and a pricing summary with a Create button" />
  </Frame>

  <small>Example: the Create a new Job form</small>
</div>

| Field | Description |
| - | - |
| **Job name** | A name for the job. A random name is generated by default. |
| **Command** | The command that runs when the job starts, for example `python train.py --epochs 10`. |
| **Working directory** | (Optional) Where the command runs. Defaults to the image's working directory. |
| **Environment variables** | Add key-value variables, and link [organization secrets](/member/settings/secrets) instead of pasting credentials in plain text. |
| **Hardware Configuration** | Choose the GPU product (A100, H100, or CPU only), region, and GPU count. Each count shows its hourly price and availability. |
| **Persistent volume** | Attach an Object storage or Cluster storage volume with a mount path to keep data across runs. |
| **Container image** | A **Managed** image (PyTorch, CUDA, Python) or your own **Custom** image. |

Review the **Pricing summary** on the right and click **Create** to submit. You're taken to the job's detail page, where you can watch status, logs, and metrics.

## Create from the CLI

Provide a cluster, resource spec, container image, command to run, and any volumes or environment variables you need.

```bash theme={null}
vesslctl job create \
  --name my-training-job \
  --resource-spec <spec-slug> \
  --image quay.io/vessl-ai/torch:2.9.1-cuda13.0.1-py3.13-slim \
  --cmd "python train.py --epochs 10" \
  --env WANDB_API_KEY=<your-key> \
  --object-volume <volume-slug>:/output \
  --tag training-run-2026-04
```

<Tip>
  Run `vesslctl cluster list` and `vesslctl resource-spec list` to discover available clusters and GPU specs. See [`vesslctl job create`](/cli/commands/job#create) for the full flag reference.
</Tip>

## Persist job output

Jobs run in ephemeral containers — anything written outside a mounted volume disappears when the job ends. Attach at least one Object storage or Cluster storage volume so your outputs survive.

* **Object storage** (`--object-volume`): Shared across clusters, ideal for final artifacts like trained models and evaluation metrics. Mount at a dedicated path such as `/output`.
* **Cluster storage** (`--cluster-volume`): Fast in-cluster storage, ideal for intermediate checkpoints during long training. Mount at `/workspace` or similar.

```bash theme={null}
vesslctl job create \
  --name my-training-job \
  --resource-spec <spec-slug> \
  --image quay.io/vessl-ai/torch:2.9.1-cuda13.0.1-py3.13-slim \
  --object-volume <output-volume-slug>:/output \
  --cmd "python train.py --output /output"
```

<Warning>
  Temporary storage is cleared when a job ends, even after `succeeded`. If your training script writes to `/tmp` or the current directory without a mounted volume, the results are lost.
</Warning>

## Reuse a job configuration

Export an existing job's configuration as JSON and resubmit it later:

```bash theme={null}
vesslctl job export my-job-abc123 > job-config.json
vesslctl job create --file job-config.json
```

## Submit a job from inside a workspace

Workspaces ship with `vesslctl` pre-authenticated with a workload token, so you can iterate on a script in JupyterLab and submit the same code as a batch job from the same shell. See [`vesslctl workspace`](/cli/commands/workspace#create) for details.

## See also

* [Convert a workspace to a Job](/member/workspace/convert-to-job)
* [List batch jobs](/member/job/list)
* [View job details](/member/job/details)
* [Create a volume](/member/volume/create)


# View job details
Source: https://docs.cloud.vessl.ai/member/job/details

Compute specs, pricing summary, command, image, environment variables, volumes, and tags.

The job details page summarizes everything VESSL Cloud uses to run the batch job and lets you manage tags inline. Click any job from the **Jobs** list to open it.

<div>
  <Frame>
    <img alt="Job details page with status header, Command, Container image, Environment variables, Volumes, Compute Specs, Pricing Summary, and Tags sections" />
  </Frame>

  <small>Example: Job details</small>
</div>

<Info>
  The details page shows the following sections:

  * **Status header**: Current state, job name, ID, creator, duration, and created at
  * **Command**: Shell command executed by the container
  * **Container image**: Docker image used for the run
  * **Environment variables**: Name and value pairs passed to the container at runtime
  * **Volumes**: Object storage and Cluster storage volumes mounted into the job, with mount paths
  * **Compute Specs**: Cluster, GPU, CPU, memory, and Temporary volume size
  * **Pricing Summary**: Hourly GPU cost
  * **Tags**: Custom labels attached to the job (add or remove inline)
</Info>

## Tabs

The details page has three tabs:

* **Details** (this page) — configuration and tags
* **[Logs](/member/job/logs)** — execution logs
* **[Metrics](/member/job/metrics)** — GPU, VRAM, CPU, memory, network, and storage usage

## Tags

Click **Add tag** in the Tags card to attach a custom label inline. Existing tags appear as colored chips and can be removed with the X icon next to each tag. Tags also drive filtering on the [Jobs list](/member/job/list).

<div>
  <Frame>
    <img alt="Job details page with the tags popover open, showing existing tags and an input field to add a new tag" />
  </Frame>

  <small>Example: Tag editor on the job details page</small>
</div>

<Tip>
  Create tags in advance with `vesslctl tag create <value>` to standardize tag values across the team. See [`vesslctl tag`](/cli/commands/tag) for details.
</Tip>

## See also

* [View logs](/member/job/logs)
* [Monitor metrics](/member/job/metrics)
* [Clean up jobs](/member/job/cleanup)


# List batch jobs
Source: https://docs.cloud.vessl.ai/member/job/list

Browse, filter, and search jobs in your team.

The **Jobs** page lists every batch job in your team and lets you filter by status and tags.

<div>
  <Frame>
    <img alt="Jobs list page with name, slug, status, tags, requested resources, duration, creator, and created-at columns" />
  </Frame>

  <small>Example: Jobs list page</small>
</div>

<Info>
  The list shows the following columns:

  * **Name**: Job name
  * **Slug**: Unique identifier used by `vesslctl` commands
  * **Status**: Current lifecycle state (`scheduling`, `running`, `succeeded`, `failed`, `terminated`)
  * **Tags**: Tags on the job, shown as colored chips (extra tags collapse to `+N`).
  * **Requested Resources**: Requested GPU type and count
  * **Duration**: Time elapsed since the job started
  * **Creator**: User who submitted the job
  * **Created at**: When the job was created
</Info>

## Filter by status

Use the status dropdown above the list to filter by `scheduling`, `running`, `succeeded`, `failed`, or `terminated`. By default, all statuses are shown.

## Filter by tag

A tag filter sidebar on the left of the **Jobs** list narrows results to jobs that carry one or more selected tags. Tags are managed inline on each job's details page (see [View job details](/member/job/details)).

<div>
  <Frame>
    <img alt="Jobs list with a tag filter sidebar on the left and colored tag chips on individual job rows" />
  </Frame>

  <small>Example: Tag filter sidebar</small>
</div>

## From the CLI

```bash theme={null}
vesslctl job list                        # all jobs in the current team
vesslctl job list --state running        # only running jobs
vesslctl job list --hide-deleted         # skip cancelled and terminated jobs
vesslctl job list --per-page 50          # paginate
```

See [`vesslctl job list`](/cli/commands/job#list) for the full reference.

## See also

* [Create a batch job](/member/job/create)
* [View job details](/member/job/details)
* [Clean up jobs](/member/job/cleanup)


# View logs
Source: https://docs.cloud.vessl.ai/member/job/logs

Stream and review batch job execution logs.

Use the **Logs** tab on a job's detail page to watch container output as it runs and to scroll back through past lines after the job finishes.

<div>
  <Frame>
    <img alt="Job Logs tab streaming timestamped INFO entries with Filter and Go to latest controls" />
  </Frame>

  <small>Example: Job execution logs</small>
</div>

## Controls

* **Filter**: Search and highlight matching lines.
* **Go to latest**: Jump to the most recent line; useful when the log scrolls fast during long runs.

Logs are retained for the lifetime of the job record, so you can review them after the job completes, fails, or terminates.

## From the CLI

Stream logs in real time, or fetch a fixed number of recent lines:

```bash theme={null}
vesslctl job logs <job-slug> --follow         # stream as they arrive
vesslctl job logs <job-slug> --limit 500      # last 500 lines
```

See [`vesslctl job logs`](/cli/commands/job#logs) for the full reference.

## Common debugging patterns

* **`OOMKilled` in the status header**: GPU or system memory limit was exceeded. Inspect the [Metrics](/member/job/metrics) tab around the failure time and consider a larger resource spec or smaller batch size.
* **Image pull errors at the top of the log**: Re-check the image URI and registry credentials.
* **Silent hang**: Confirm the entry command actually exits. Long-running daemons should be submitted as workspaces, not jobs.

## See also

* [View job details](/member/job/details)
* [Monitor metrics](/member/job/metrics)


# Monitor metrics
Source: https://docs.cloud.vessl.ai/member/job/metrics

Track GPU, VRAM, temperature, CPU, memory, network, and storage usage for your batch job.

The **Metrics** tab shows timeseries charts for GPU, VRAM, temperature, CPU, memory, network, and storage so you can confirm that hardware is being used efficiently and spot waste while the job runs or after it finishes.

<div>
  <Frame>
    <img alt="Job metrics tab with GPU, VRAM, temperature, CPU, memory, network, and storage charts" />
  </Frame>

  <small>Example: Job metrics</small>
</div>

## Charts

Job metrics use the same chart families as workspaces. See [Workspace metrics](/member/workspace/metrics) for the full chart reference, including threshold values, axis units, and interpretation rules:

* **GPU utilization** (0–100%): Compute usage. Below **30%** can indicate over-provisioned resources.
* **VRAM usage** (GB): Video memory consumption. Above **95%** risks Out of Memory (OOM) errors.
* **Temperature** (°C): Sustained values above **85°C** can indicate thermal throttling.
* **CPU and memory**: Allocated CPU cores and system RAM in use.
* **Network I/O**: Data transferred in (Rx) and out (Tx).
* **Storage**: Temporary, Cluster storage, and Object storage usage for volumes attached to the job.

## Time range

Use the time range selector at the top of the charts to choose a window: **1h** (default), **6h**, **12h**, **1d**, or **7d**. All charts update together.

## Idle detection

Jobs running below **30%** GPU utilization for a sustained window (one-hour average) are flagged as idle on the [Home dashboard](/member/dashboard/overview). Review the metrics and decide whether to terminate the job to stop billing or let it continue.

## See also

* [Workspace metrics](/member/workspace/metrics) — full chart reference and thresholds
* [Clean up jobs](/member/job/cleanup) — terminate idle runs to stop billing
* [View job details](/member/job/details)


# Understand jobs
Source: https://docs.cloud.vessl.ai/member/job/overview

What batch jobs are and when to use them on VESSL Cloud.

<Tip>
  **Create and manage jobs from the console or the CLI.** Click **Create Job** on the Jobs page for a guided form, or use `vesslctl job` to submit, monitor, terminate, and tag jobs entirely from your terminal — bring your own image, mount volumes, and set environment variables in a single command. See the [CLI cheat sheet](/cli/cheatsheet) for a one-page command reference, or [vesslctl job](/cli/commands/job) for the full flag reference.
</Tip>

A **[job](/guides/get-started/glossary#job)** runs a command to completion on a specified GPU or CPU resource. Unlike workspaces, jobs are non-interactive — submit a fine-tuning script or evaluation pipeline and let it run to completion.

Jobs are ideal for:

* Model training and fine-tuning
* Batch inference and evaluation
* Data preprocessing pipelines
* Hyperparameter sweeps (submit multiple jobs in parallel)

<div>
  <Frame>
    <img alt="VESSL Cloud Jobs list page showing job name, status, requested resources, duration, and creator" />
  </Frame>

  <small>Example: Jobs list page</small>
</div>

## Jobs vs Workspaces

| | Job | Workspace |
| - | - | - |
| **Interaction** | Non-interactive (runs a command) | Interactive (SSH, JupyterLab) |
| **Lifecycle** | Starts → runs → completes automatically | Stays running until you pause or terminate |
| **Billing** | Only while running | While running (GPU + storage); while paused (storage only) |
| **Best for** | Training, batch processing, sweeps | Development, debugging, exploration |

## Job statuses

| Status | Meaning |
| - | - |
| `scheduling` | Waiting for resources to become available. The job shows a reason like *Waiting for GPU capacity* while it queues. |
| `running` | Your command is actively executing on the allocated resources. |
| `succeeded` | The command exited successfully (exit code `0`). Output in mounted volumes is preserved. |
| `failed` | The command exited with a non-zero code, or the container crashed (for example, `OOMKilled`). Check logs to debug. |
| `terminated` | You manually cancelled the job before it finished. |

## Next steps

* [List batch jobs](/member/job/list) — browse, filter, and search jobs
* [Create a batch job](/member/job/create) — create from the console or CLI
* [Convert a workspace to a Job](/member/workspace/convert-to-job) — reuse a workspace's image, resources, and volumes
* [View job details](/member/job/details) — inspect command, image, environment, volumes, and tags
* [View logs](/member/job/logs) — stream container output in real time
* [Monitor metrics](/member/job/metrics) — track GPU, VRAM, CPU, and memory usage
* [Clean up jobs](/member/job/cleanup) — terminate a running job and hide finished ones from the list
* Full CLI reference: [`vesslctl job`](/cli/commands/job)


# Notifications
Source: https://docs.cloud.vessl.ai/member/settings/notifications

Check events in the notification center and choose how each category reaches you.

Stay on top of what's happening in your organization with the **notification center**, and control which notifications you receive from **Notification preferences**.

## Notification center

Open the notification center from the bell icon in the global header. An unread badge shows how many notifications you haven't read yet, and new notifications arrive in real time while you're signed in.

Notifications cover events across your workspaces, jobs, VM clusters, and billing — see [Notification preferences](#notification-preferences) for the full list by category. Click any notification to jump to the related resource. Notifications are kept for 30 days, then removed automatically.

### Inbox and Archive

* **Inbox**: The default tab. New notifications land here, read or unread. Use **Mark all as read** to clear the unread badge.
* **Archive**: Notifications you've archived. Hover a notification in Inbox and select the archive icon to move it here, then restore it to Inbox anytime.

Notifications from the same resource are grouped together, with the latest one shown and older ones collapsed under a **+N more events** link.

## Notification preferences

Open **Notification preferences** from the gear icon in the notification center to choose how each category reaches you.

Categories are organized into four groups, each with its own channels:

| Group | Category | Notified when | Channels |
| - | - | - | - |
| **Workspace** | Status changes | A workspace is running, interrupted, or paused by an admin | Email, Inbox |
| **Workspace** | Monitoring alerts | Resource thresholds are exceeded or runtime issues occur, such as OOMKilled | Email, Inbox |
| **Job** | Status changes | A job is running, succeeded, or failed | Inbox |
| **Job** | Monitoring alerts | Resource thresholds are exceeded or runtime issues occur, such as OOMKilled | Inbox |
| **VM Cluster** | Firewall rules | Firewall rule changes are applied | Email, Inbox |
| **Billing** | Credit alerts | Credit balance is running low or depleted | Email, Inbox |

* **Channels per category**: For each category, choose to receive notifications by **Email**, **Inbox**, or both.
* **Section toggles**: Turn the **Workspace** and **Job** groups on or off as a whole. When a group is off, its categories are disabled. **VM Cluster** and **Billing** have no toggle — they're always on.
* **Always-on email**: **Billing** credit alerts and **VM Cluster** firewall rules are always sent by email and can't be turned off, since missing them can interrupt your workloads or affect account security.

<Note>
  Notification preferences apply to your account only. Changing them doesn't affect other members in your organization. Some categories, such as credit alerts and VM cluster firewall rules, appear only for organization admins.
</Note>


# Profile
Source: https://docs.cloud.vessl.ai/member/settings/profile

View your account information and change your password.

View your **User ID** and account email, and change your password from the **Security** section. To open the page, select **Settings** in the sidebar, then select **Profile** under **Account**.

<div>
  <Frame>
    <img alt="Profile page with an Account information card showing User ID and Email, and a Security card with a Change password button" />
  </Frame>

  <small>Example: Profile</small>
</div>


# Secrets
Source: https://docs.cloud.vessl.ai/member/settings/secrets

Store API tokens and credentials as encrypted, org-level secrets, and inject them into batch jobs as environment variables.

A **secret** is an encrypted, organization-scoped credential — an API token, password, database URL, or any other sensitive string. Use secrets instead of pasting plaintext into commands, image configs, or repo files. At runtime, VESSL Cloud injects the secret into your container as an environment variable. The value is encrypted on your machine before it's sent, kept out of request bodies and access logs, and stored only as ciphertext.

<Note>
  Anyone in the organization can view secrets, create new ones, and reference a secret by name when creating a batch job. Updating or deleting a secret requires the **Organization admin** role — see [Manage secrets](/admin/secrets/overview).
</Note>

<Info>
  VESSL Cloud has completed a **SOC 2 Type II** security attestation. See [trust.vessl.ai](https://trust.vessl.ai) for the full report and our security posture.
</Info>

<div>
  <Frame>
    <img alt="Secrets page with a table of secrets showing Secret Name, Key, masked Value, Slug, Last edited by, and Edited at columns, plus a New Secret button" />
  </Frame>

  <small>Example: Secrets page as a member sees it — no edit or delete menu on the rows</small>
</div>

## Common use cases

| Env var | Used for |
| - | - |
| `HF_TOKEN` | Hugging Face |
| `OPENAI_API_KEY` | OpenAI |
| `ANTHROPIC_API_KEY` | Anthropic |
| `WANDB_API_KEY` | Weights & Biases |
| `GITHUB_TOKEN` | GitHub |
| `DATABASE_URL` | Database connection string |

## How it works

* **Encrypted before it leaves your machine** — when you create a secret, the value is sealed with your organization's public key locally (libsodium sealed-box), so the plaintext never appears in request bodies or access logs. VESSL Cloud re-encrypts it at rest with a master key and stores only the ciphertext.
* **Injected at submission time** — when you submit a workload, VESSL Cloud decrypts the value server-side and delivers it to your container as a Kubernetes Secret, surfaced as an environment variable when your container starts.
* **Write-only values** — after a secret is saved, VESSL Cloud never shows its value again to anyone, member or admin; the list and detail views show only metadata. To change a value, an admin rotates it by overwriting it with a new one — the previous value can't be retrieved.
* **Organization-scoped** — secrets are shared across all teams in the organization. Every batch job in the org can reference any secret by name.
* **Open to create, admin-gated to change** — anyone in the organization can view secrets and create new ones. Only **Organization admin** can [update or delete](/admin/secrets/overview) a secret, including secrets that members created; members don't see the edit and delete controls on the secrets list.

## Create a secret

A secret has three core fields:

| Field | What it is |
| - | - |
| **Secret name** | Your identifier for the secret. Unique per organization. |
| **Key** | The default env var name when the secret is injected into a workload. Must match `^[A-Za-z_][A-Za-z0-9_]*$` (env-var format, ≤256 chars). |
| **Value** | The plaintext credential. Encrypted before it leaves your machine. |

Keep **Secret name** and **Key** identical (`HF_TOKEN`/`HF_TOKEN`) for simplicity, or use a different **Secret name** when you need multiple secrets that share the same env var — for example `hf-prod` and `hf-staging`, both with key `HF_TOKEN`.

### GUI

1. In the sidebar, select **Settings**.
2. Select **Secrets** under **Account**.
3. Click **New Secret**.
4. Fill in **Secret name**, **Key**, and **Value**.
5. Click **Create**.

<div>
  <Frame>
    <img alt="Create new Secret modal with Secret name, Key, and Value fields, plus Cancel and Create buttons" />
  </Frame>

  <small>Example: new secret modal</small>
</div>

### CLI

```bash theme={null}
# Interactive masked prompt (when stdin is a TTY)
vesslctl secret create HF_TOKEN HF_TOKEN

# Read the value from an env var
vesslctl secret create HF_TOKEN HF_TOKEN --from-env LOCAL_HF_TOKEN

# Read from stdin
echo "$HF_TOKEN" | vesslctl secret create HF_TOKEN HF_TOKEN --from-stdin

# Add a description
vesslctl secret create HF_TOKEN HF_TOKEN -d "Hugging Face token (prod)"
```

The plaintext value never appears on the command line — `--from-env` and `--from-stdin` keep it out of your shell history.

## Use a secret in a job

### GUI

In the **Environment variables** section of the job-create form, pick a secret from the **Secrets** dropdown. Click **Add secret** to attach more. Plain variables and secrets coexist, but if a plain variable uses the same env-var key as a secret, the plain variable's value takes precedence.

<div>
  <Frame>
    <img alt="Environment variables section of the job-create form with a Secrets dropdown, an Add secret button, and a Variables table for plain key-value pairs" />
  </Frame>

  <small>Example: linking a secret on the job-create form</small>
</div>

### CLI

Inject one or more secrets into a batch job with `--secret`:

```bash theme={null}
# Inject as env var HF_TOKEN, referencing the secret named HF_TOKEN
vesslctl job create ... --secret HF_TOKEN

# Inject as env var OPENAI_API_KEY, referencing the secret named openai-prod
vesslctl job create ... --secret OPENAI_API_KEY=openai-prod

# Multiple secrets
vesslctl job create ... --secret HF_TOKEN --secret OPENAI_API_KEY
```

* `--secret NAME` injects the secret as an env var with the same name.
* `--secret KEY=NAME` injects the secret as env var `KEY`, referencing the secret named `NAME`.
* A key can't appear in both `--env` and `--secret` — the CLI rejects the command, so pick one flag per env var.

<Note>
  Workspaces don't support secret injection yet. Secrets ship for jobs today; workspace support is on the roadmap.
</Note>

## List secrets

```bash theme={null}
# List active secrets
vesslctl secret list

# Include soft-deleted entries
vesslctl secret list --include-deleted
```

Updating and deleting secrets is admin-only — see [Manage secrets](/admin/secrets/overview).

## FAQ

<AccordionGroup>
  <Accordion title="Who can manage secrets?">
    Anyone in the organization can view secrets and create new ones. Updating or deleting a secret — including one you created yourself — requires the **Organization admin** role, so members don't see the edit and delete controls on the secrets list. Members can reference a secret by name when creating a batch job — they don't need admin access to use one. (A saved value can't be viewed again by anyone, member or admin; this isn't a member-only limit.)
  </Accordion>

  <Accordion title="How does VESSL Cloud protect my secret value?">
    The value is sealed with your organization's public key on your machine (libsodium sealed-box) before it's sent, so the plaintext never appears in request bodies or access logs. VESSL Cloud stores only the ciphertext — re-encrypted at rest with a master key — and decrypts it server-side only to inject it into your workload when you submit a job. Access is governed by our [SOC 2 Type II](https://trust.vessl.ai) controls.
  </Accordion>

  <Accordion title="Why are Secret name and Key separate fields?">
    **Secret name** is your identifier (unique per organization). **Key** is the env-var-shaped reference used by default when injecting into a workload. Keep them identical for simplicity (`HF_TOKEN`/`HF_TOKEN`), or use distinct names when you need multiple secrets that map to the same env var (for example, `hf-prod` and `hf-staging`, both with key `HF_TOKEN`).
  </Accordion>

  <Accordion title="What happens if --env and --secret use the same env-var key?">
    The CLI rejects the command — `vesslctl job create` errors when a key appears in both flags, so pick one per env var. In the GUI, the two can coexist: a plain variable with the same key as a secret takes precedence, and the secret reference is ignored.
  </Accordion>

  <Accordion title="Do running workloads see updated secret values?">
    No. Secrets are injected at container start. Restart the workload to pick up the new value.
  </Accordion>
</AccordionGroup>


# SSH Keys
Source: https://docs.cloud.vessl.ai/member/settings/ssh-keys

View SSH public keys stored in VESSL Cloud, add existing keys, or generate new key pairs.

View SSH public keys associated with your account. Use **Add key** to register an existing key, or **Generate Key** to create a new key pair for SSH access to workspaces.

<div>
  <Frame>
    <img alt="SSH keys list showing key name, fingerprint, and last update time" />
  </Frame>

  <small>Example: SSH keys list</small>
</div>

| Field | Description |
| - | - |
| Key name | User-defined name for identification |
| Fingerprint | Unique identifier used to validate key pairs (public/private) |
| Updated at | Last update time |
| Action | Edit or delete the key |

## Use in workspaces

* SSH keys registered here are used when connecting to workspaces using SSH.
* In a workspace's **Connect** tab, copy the SSH command and replace `/path/to/key` with your private key path.
* See [Connect](/member/workspace/connect) for step-by-step instructions.
  * If you use VS Code Remote-SSH, see the “Connect using VS Code Remote-SSH” section on that page.

<div>
  <Frame>
    <img alt="Dialog for adding an existing SSH public key" />
  </Frame>

  <small>Example: Add SSH public key</small>
</div>

## Generate a new SSH key

Click **Generate Key** to create a new SSH key pair:

<Note>
  You can also generate SSH keys directly during the **Workspace creation** process (Step 2).
</Note>

<div>
  <Frame>
    <img alt="Dialog for generating a new SSH key pair" />
  </Frame>

  <small>Example: Generate SSH key</small>
</div>

1. Enter a unique name for your SSH key.
2. Click **Generate SSH Key**.
3. The private key is automatically downloaded to your device, and the public key is saved to your VESSL Cloud account.


# Create Object storage volume
Source: https://docs.cloud.vessl.ai/member/volume/create

Create an Object storage volume to share data across your team.

<Tip>
  **Prefer the terminal?** Create the same volume from the CLI with `vesslctl volume create --name <name> --storage <storage-slug> --teams <team>`. See [`vesslctl volume create`](/cli/commands/volume#create) for the full flag reference.
</Tip>

You can create **Object storage** volumes to store datasets, models, and other files that need to be accessed by multiple workspaces or team members.

<Info>
  This page covers creating **Object storage** volumes (self-service for all members). Cluster storage volumes can only be created by organization admins from the [admin storage page](/admin/storage/create-volume).
</Info>

<div>
  <Frame>
    <img alt="Object storage volume list with a Create new volume button" />
  </Frame>

  <small>Example: Volume list</small>
</div>

<Info>
  Object storage volumes are backed by S3 with **Read-Write-Many (RWX)** support. They can be mounted to multiple workspaces simultaneously across any cluster in your organization, making them ideal for collaborative work.
</Info>

## Steps to create

1. Go to the **Object storage** tab in the sidebar.
2. Click **Create new volume**.
3. Configure the volume settings:
   * **Name**: A unique name for your volume.
   * **Description**: Optional details about the volume's purpose.
   * **Storage**: Select the Object storage backend for this volume.
   * **Size (GiB)**: The storage capacity. You can increase this later, but cannot decrease it.
   * **Access**: Select one or more **teams** that will have access to this volume.
4. Click **Create**.

## Pricing

Object storage is billed daily based on actual usage (effective 2026-07-01). See [Storage pricing](/pricing/storage) for the latest rates and FAQ.

* **Pay-as-you-go**: You pay for what you actually store, measured daily.
* **No quota limits**: You don't need to request a quota from an admin. You can create volumes as needed, subject to your organization's billing policies.

## Next steps

* [Mount the volume](/member/workspace/create) to your workspace.
* Manage files using the [File Manager](/member/volume/detail) or by connecting to a workspace.


# Manage volume data
Source: https://docs.cloud.vessl.ai/member/volume/detail

View files, active workspaces, and manage data with the CLI.

## Files

<div>
  <Frame>
    <img alt="Volume file list with name, size, and last-modified columns" />
  </Frame>

  <small>Example: Files in a volume</small>
</div>

See files stored in the volume.

* Name: file name
* Size: file size
* Last modified: last modification timestamp

## Details

View volume metadata and status information.

* **Cluster availability**: Clusters where this volume can be mounted.
* **Size**: Total provisioned storage capacity.
* **Teams**: Teams that have access to this volume.
* **Last attached**: Last time the volume was attached to a workspace.

## Active workspaces

View workspaces currently attached to this volume. Active workspaces can read/write files. Data is automatically synchronized across sessions at the configured mount paths.

## Data management (CLI)

Use short-lived credentials to manage data on Object storage volumes with the AWS CLI.

<div>
  <Frame>
    <img alt="Volume detail page with the Guide button that opens the AWS CLI guide modal" />
  </Frame>

  <small>Example: Volume detail page</small>
</div>

### Access guide

On the **Volume detail** page, click the **Guide** button (book icon) to open the CLI guide modal. The modal includes:

* **AWS Credentials**: Temporary credentials are automatically generated (expire after 36 hours). Click **Copy All** to copy all credentials at once. Use the **Regenerate** button to create new credentials if needed.
* **AWS S3 Commands**: Common commands for managing files. Each command has a copy button for easy use.

### CLI operations

<Steps>
  <Step title="List files">
    ```bash theme={null}
    aws s3 ls s3://dora-managed-storage-prod/<storage-id>/<volume-id>/
    ```
  </Step>

  <Step title="Upload files">
    ```bash theme={null}
    aws s3 cp my_file.txt s3://dora-managed-storage-prod/<storage-id>/<volume-id>/my_directory/my_file.txt
    ```
  </Step>

  <Step title="Download files">
    ```bash theme={null}
    aws s3 cp s3://dora-managed-storage-prod/<storage-id>/<volume-id>/my_directory/my_file.txt .
    ```
  </Step>

  <Step title="Delete files">
    ```bash theme={null}
    aws s3 rm s3://dora-managed-storage-prod/<storage-id>/<volume-id>/my_directory/my_file.txt
    ```
  </Step>
</Steps>

<Info>
  Replace `<storage-id>` and `<volume-id>` with the actual values shown in the Guide modal. Refer to [AWS S3 CLI docs](https://docs.aws.amazon.com/cli/latest/reference/s3/) for advanced operations.
</Info>

## Permissions

Volume access is controlled by team membership.

* **View and use**: You can view and use volumes that are assigned to teams you belong to.
* **Update**: You can update volumes (name, description, team assignments) if you belong to at least one team assigned to the volume. When modifying team assignments, you can only add or remove teams you belong to.
* **Delete**: You can delete volumes if you belong to at least one team assigned to the volume.

Organization admins can view, update, and delete all volumes regardless of team membership.

## Delete volume

<Warning>
  Deleting a volume permanently removes all data. This action cannot be undone.
</Warning>

<Info>
  **Deletion restrictions:**

  * You cannot delete a volume while it is attached to active workspaces. Before deleting, you must stop or terminate all workspaces using this volume.
  * You must belong to at least one team assigned to the volume, or be an organization admin.
  * This applies to both Object storage and Cluster storage volumes.
</Info>

<Tip>Watch the demo below to see the delete flow.</Tip>

<div>
  <iframe title="Delete a Storage Volume in VESSL Cloud" />
</div>

To delete a volume:

1. Go to the **Volume detail** page.
2. Click the **Delete** button.
3. Confirm the deletion by typing the volume name.


# View volumes
Source: https://docs.cloud.vessl.ai/member/volume/list

View team-assigned storage volumes and their usage.

<Tip>
  **Prefer the terminal?** `vesslctl volume list` shows the same volumes; use `vesslctl volume upload`/`download` to move files. See [`vesslctl volume`](/cli/commands/volume) for the full reference.
</Tip>

The volume list shows all storage volumes available to your team(s). Click **Object storage** or **Cluster storage** in the sidebar to view each type.

<div>
  <Frame>
    <img alt="Object storage volume list with name, usage, and team columns" />
  </Frame>

  <small>Example: Object storage volumes</small>
</div>

<div>
  <Frame>
    <img alt="Cluster storage volume list showing volumes bound to specific clusters" />
  </Frame>

  <small>Example: Cluster storage volumes</small>
</div>

<Tip>
  If you don't see any volumes, you can [create one yourself](/member/volume/create) or ask your Organization Admin to create and assign one to your team.
</Tip>

## Quick demo

Explore how to view and access storage volumes with the quick demo below.

<div>
  <iframe title="View volume details" />
</div>

<Info>
  The volume list shows the following columns:

  * **Name**: Volume name
  * **Type**: Storage type (Object storage or Cluster storage)
  * **Usage**: Current storage usage
  * **Teams**: Teams with access to this volume
  * **Created by**: User who created this volume
  * **Cluster**: Clusters where the volume can be mounted (Object storage is accessible across all clusters)
  * **Last accessed**: Last time it was attached to any workspace
</Info>


# Load data into a volume
Source: https://docs.cloud.vessl.ai/member/volume/load-data

Upload to Object storage from the CLI, or load Cluster storage from inside a workspace that mounts it.

Containers in workspaces and jobs are ephemeral. To make a dataset, model checkpoint, or large config file available to your training scripts, put it in a [persistent volume](/member/volume/overview) and mount that volume into the workload. This guide walks through the practical ways to get data **into** a volume.

<Danger>
  Do not encode data into the job command itself. Pasting a gzip+base64 blob, a long heredoc, or other large payloads into `--cmd` is rejected by the API: command bodies over **256 KiB**, environment variable values over **8 KiB**, or more than **128 environment variable pairs** return a 4xx error. Use one of the patterns below instead.
</Danger>

## At a glance

The right approach depends on which kind of volume you target.

| Volume kind | How to load data |
| - | - |
| **[Object storage](/member/volume/overview#using-object-storage)** | Upload directly from your machine with `vesslctl volume upload`, or any S3-compatible client via `vesslctl volume token`. |
| **[Cluster storage](/member/volume/overview#using-cluster-storage)** | Mount the volume into a workspace, then bring the data into the mount path from inside that workspace. |

***

## Object storage — upload from your machine

`vesslctl volume upload` is the primary path. Files stream from your machine straight to S3, so transfer size is limited only by your network and storage quota.

<Steps>
  <Step title="Pick or create an Object storage volume">
    ```bash theme={null}
    vesslctl volume list --type object
    ```

    If you need a new volume, see [Create a volume](/member/volume/create) or use the CLI:

    ```bash theme={null}
    vesslctl volume create \
      --name training-data \
      --storage <object-storage-slug> \
      --teams <team-name>
    ```

    `--teams` controls which teams can mount this volume; it is required for Object storage.
  </Step>

  <Step title="Upload local files">
    ```bash theme={null}
    vesslctl volume upload <volume-slug> ./dataset/ \
      --remote-prefix datasets/v1/ \
      --exclude "*.pyc" \
      --exclude "__pycache__"
    ```

    `--dry-run` previews the file list without transferring. `--overwrite` replaces existing remote keys; without it, identical keys are skipped. See [`vesslctl volume upload`](/cli/commands/volume#upload) for the full flag reference.
  </Step>

  <Step title="Verify and mount">
    ```bash theme={null}
    vesslctl volume ls <volume-slug> --prefix datasets/v1/
    ```

    Mount the volume into a [workspace](/member/workspace/create#persistent-volume) or pass it to a job with `--object-volume <volume-slug>:/shared`.
  </Step>
</Steps>

<Tip>
  Need to drive the upload from another tool — `aws s3 cp`, `rclone`, [DVC](https://dvc.org/), or a custom pipeline? Run `vesslctl volume token <volume-slug>` to get temporary S3 credentials and an endpoint URL scoped to just that volume. See [`vesslctl volume token`](/cli/commands/volume#token).
</Tip>

***

## Cluster storage — load through a workspace

`vesslctl volume upload` does **not** support Cluster storage volumes. Instead, mount the Cluster storage volume into a workspace and bring the data into the mount path from inside that workspace.

<Steps>
  <Step title="Create a workspace that mounts the volume">
    Mount the Cluster storage volume at a clear path under [Persistent volume](/member/workspace/create#persistent-volume), for example `/data`:

    ```bash theme={null}
    vesslctl workspace create \
      --name data-loader \
      --cluster <cluster-slug> \
      --resource-spec <spec-slug> \
      --image quay.io/vessl-ai/torch:2.9.1-cuda13.0.1-py3.13-slim \
      --cluster-volume <cluster-volume-slug>:/data
    ```

    Any container image with the tools you need (`curl`, `wget`, `aws`, `huggingface-cli`, `git-lfs`, …) works. To minimize hourly cost while you move data, pick a **CPU-only** spec from `vesslctl resource-spec list`.
  </Step>

  <Step title="Connect to the workspace">
    Wait until the workspace is `running`, then connect over SSH or in JupyterLab. See [Connect to a workspace](/member/workspace/connect).

    Once connected, `cd /data` (or whatever mount path you chose). Anything you write below this path lands in the Cluster storage volume and persists after the workspace is paused or terminated.
  </Step>

  <Step title="Bring the data in (pick a pattern below)">
    Several patterns work. Pick the one that matches where the data lives.
  </Step>

  <Step title="Pause the workspace when you are done">
    Cluster storage data persists past `pause` — you do not need a running workspace to keep the data alive. Pause to stop compute billing:

    ```bash theme={null}
    vesslctl workspace pause <workspace-slug>
    ```

    Resume with `vesslctl workspace start <workspace-slug>` later if you need to add or modify data.
  </Step>
</Steps>

### Pattern A — Pull from the public internet

The simplest and most common case: the data is already at a public (or token-authenticated) URL.

```bash theme={null}
# Inside the workspace shell, with the volume mounted at /data
cd /data

# Plain HTTP(S) downloads
wget https://example.com/datasets/imagenet-subset.tar.gz
tar -xzf imagenet-subset.tar.gz

# Hugging Face datasets / model repos
pip install -U "huggingface_hub[cli]"
huggingface-cli download <org>/<repo> --local-dir ./hf-cache --repo-type dataset

# S3 / GCS / Azure (use the matching CLI)
aws s3 sync s3://my-bucket/datasets/v1/ ./datasets/v1/
```

For very large transfers, `aria2c -x 16` parallelizes HTTP downloads, and `rclone copy` handles cloud-storage providers with built-in retry and verification.

### Pattern B — Push from your laptop over SSH

When the data is only on your laptop and you want to skip the round trip through the public internet, use SSH to copy directly into the mount path.

```bash theme={null}
# scp a single file or directory
scp -i /path/to/<key> -P <port> ./dataset.tar.gz \
  root@<workspace-host>:/data/

# rsync (resumable, deduped, recommended for large trees)
rsync -avh --progress -e "ssh -i /path/to/<key> -p <port>" \
  ./dataset/ root@<workspace-host>:/data/
```

The host, port, and key path come from the workspace **Connect** tab — see [Connect to a workspace](/member/workspace/connect#ssh-key-connection). `rsync` is preferable for anything multi-gigabyte: it resumes after a dropped connection (`--partial`) and only retransmits changed files on a re-run.

### Pattern C — Stage through Object storage

When you want a one-time copy from your laptop into Cluster storage on a different cluster (or from one cluster to another), use Object storage as a portable intermediate. Object storage is reachable from any cluster.

```bash theme={null}
# 1. From your laptop: upload to an Object storage volume
vesslctl volume upload <object-volume-slug> ./dataset/ \
  --remote-prefix v1/

# 2. Create the data-loader workspace mounting BOTH volumes
vesslctl workspace create \
  --name data-loader \
  --cluster <cluster-slug> \
  --resource-spec <spec-slug> \
  --image quay.io/vessl-ai/torch:2.9.1-cuda13.0.1-py3.13-slim \
  --object-volume <object-volume-slug>:/shared \
  --cluster-volume <cluster-volume-slug>:/data

# 3. Inside the workspace: copy from /shared into /data
cp -r /shared/v1/. /data/v1/
```

After the copy completes, the Object storage staging copy is optional to keep — delete it from the volume if it is no longer needed, or keep it as a backup.

### Pattern D — Open a custom HTTP port

Need a browser drag-and-drop, a sync server, or a temporary webhook into the workspace? Open a custom HTTP or TCP port when you create the workspace (see [Workspace ports](/member/workspace/create#ports)) and serve directly from the mount path.

```bash theme={null}
# Quick browser-friendly file upload UI on a custom HTTP port (for example, 8000)
pip install --no-cache-dir uvicorn fastapi python-multipart
# … or use any small upload server such as filebrowser or miniserve --upload-files

# rclone serve: expose /data over HTTP/WebDAV/SFTP for a chosen client
rclone serve http /data --addr :8000  # then point your laptop's rclone at it
```

Use this when neither the CLI upload (Object) nor SSH copy (Pattern B) fits — for example, when a teammate without SSH access needs to drop files in, or when an external service is pushing data to the workspace.

<Warning>
  Custom ports are reachable from anywhere the workspace URL is — treat them like any other public endpoint. Add basic auth, a one-time token, or shut the port down once the load is finished.
</Warning>

***

## Anti-pattern: do not embed data in `--cmd`

A pattern that looks tempting — especially to LLM coding agents — is to gzip+base64 a dataset into a single shell line and pass it via `--cmd`:

```bash theme={null}
# DON'T DO THIS — the API rejects --cmd over 256 KiB,
# and even shorter inline blobs make jobs hard to reproduce and observe.
vesslctl job create \
  --cmd "echo 'H4sIAA...<3 MiB of base64>...' | base64 -d | gunzip > /tmp/data && python eval.py"
```

The API rejects this: `Job.command` is capped at 256 KiB, each environment variable value at 8 KiB, and the total environment variable count at 128. Requests beyond these thresholds return 4xx.

Always upload the data to a volume (this page) and mount it instead.

***

## Next steps

* [Understand storage](/member/volume/overview) — Cluster vs Object storage characteristics and pricing.
* [Create a volume](/member/volume/create) — provision a new Object storage volume from the console.
* [Create a workspace](/member/workspace/create) — attach volumes during workspace creation.
* [`vesslctl volume`](/cli/commands/volume) — full CLI reference for upload, download, token, and management.


# Understand storage
Source: https://docs.cloud.vessl.ai/member/volume/overview

Cluster storage vs Object storage and how to use them.

## VESSL Cloud storage

Workspaces come with Temporary storage that disappears when stopped. To keep your data, use **persistent storage**.

| Storage type | Description | Best for | Mount path |
| - | - | - | - |
| **Cluster storage** | High-availability distributed storage (CephFS/NVMe) shared across workspaces in the same cluster. Data persists even after workspace termination. | Code, virtualenvs (pip/conda), datasets, team collaboration within a cluster | User-configurable |
| **Object storage** | S3-backed POSIX-compatible storage accessible from any cluster in your organization | Datasets, checkpoints, large artifacts to share across clusters | `/shared` (recommended) |
| **Temporary storage** | Default ephemeral storage included in every workspace | Fast scratch space (data is **wiped** when stopped) | Varies |

## Using Cluster storage

Cluster storage provides fast, persistent storage within a cluster. Multiple workspaces on the same cluster can mount the same volume simultaneously.

<div>
  <Frame>
    <img alt="Cluster storage volumes available to a member" />
  </Frame>

  <small>Example: Cluster storage volumes assigned to your team</small>
</div>

### How to get started

1. **Check availability**: Go to **Cluster storage** in the sidebar to see volumes assigned to your team.
2. **Mount to a workspace**: When [creating a workspace](/member/workspace/create), select Cluster storage volumes in the **Storage** step. Choose a mount path (for example, `/root` or `/data`).
3. **Use it**: Access your files at the mount path inside the workspace. Install packages, save checkpoints, and store code — everything persists across workspace restarts and terminations.

<Info>
  Cluster storage volumes can only be created by organization admins. If no Cluster storage is available for your team, contact your admin to set it up. See [Manage storage (admin)](/admin/storage/overview).
</Info>

### Key characteristics

* **Bound to a cluster**: Only workspaces on the same cluster can mount the volume
* **Read-Write-Many (RWX)**: Multiple workspaces can access the same volume simultaneously
* **Data persists**: Data survives workspace stop, pause, and terminate
* **\~150 MB/s throughput**: Fast enough for large dataset loading and model checkpoints
* **Pricing**: \$0.20/GiB/month, billed daily based on actual usage from 2026-07-01. See [Storage pricing](/pricing/storage) for details.

## Using Object storage

Object storage provides S3-backed storage that can be shared across any cluster in your organization.

<div>
  <Frame>
    <img alt="Object storage volumes available to a member" />
  </Frame>

  <small>Example: Object storage volumes</small>
</div>

### How to get started

1. **Create a volume**: Go to **Object storage** in the sidebar and click **Create new volume**. See [Create Object storage volume](/member/volume/create) for details.
2. **Mount to a workspace**: When [creating a workspace](/member/workspace/create), select Object storage volumes in the **Storage** step.
3. **Use it**: Access your files at the mount path (recommended `/shared`). Share datasets, checkpoints, and artifacts across teams and clusters.

<Danger>
  Object storage is slower than Cluster storage and is not suitable as your main workspace path. VESSL Cloud rejects `/root` as an Object storage mount path, so the workspace will fail to create — use `/shared` or another dedicated path instead.
</Danger>

### Key characteristics

* **Cross-cluster access**: Mount from workspaces on any cluster in your organization
* **Read-Write-Many (RWX)**: Multiple workspaces can read and write simultaneously
* **S3-backed**: Durable, scalable storage
* **\~150 MB/s throughput**: Suitable for large dataset sharing
* **Self-service**: Any team member can create Object storage volumes

<Info>
  **Key difference:**

  * **Object storage**: S3-based, accessible from all clusters. Best for shared datasets, checkpoints, and cross-cluster artifacts.
  * **Cluster storage**: CephFS/NVMe-based, bound to one cluster. Best for code, virtualenvs, package installs, and fast persistent storage within the cluster.
</Info>

## Which storage should I use?

| Use case | Recommended |
| - | - |
| Code, virtualenvs, pip/conda packages | **Cluster storage** |
| Large datasets for training within a cluster | **Cluster storage** |
| Share data across different clusters | **Object storage** |
| Long-term backup and archiving | **Object storage** |
| Quick scratch work (disposable) | **Temporary storage** |

## What changed from Workspace volume?

| | Legacy Workspace volume | Cluster storage |
| - | - | - |
| Data on terminate | Lost | **Preserved** |
| Sharing | Single workspace only (RWO) | Multiple workspaces (RWX) |
| Mount path | Fixed to `/root` | **User-configurable** |
| Billing | \$0.0070/hr per 50 GiB | \$0.20/GiB/month |

<Warning>
  **Migration notice:** Cluster storage replaces the legacy **Workspace volume (deprecated)**, which was per-workspace with RWO semantics.
  If you have existing Workspace volume data, contact [support@vessl.ai](mailto:support@vessl.ai) for migration assistance.
</Warning>

## Terminology mapping

| Concept | VESSL Cloud term | Kubernetes (typical) | Notes |
| - | - | - | - |
| Cluster-bound shared | Cluster storage | PV/PVC on CephFS (RWX) | Distributed, multi-workspace within cluster |
| Cross-cluster shared | Object storage | PV/PVC on S3/NFS (RWX) | Network file share, any cluster |
| Ephemeral | Temporary storage | emptyDir | Deleted on stop/terminate |


# Clean up workspaces
Source: https://docs.cloud.vessl.ai/member/workspace/cleanup

Stop or terminate workspaces to control costs.

To avoid unnecessary charges after finishing your work:

<Tip>Take a quick tour of pausing a workspace, terminating it, then using **View Terminated** to review history and **Delete** to permanently remove it.</Tip>

<div>
  <iframe title="Pause and Permanently Delete a Workspace" />
</div>

<div>
  <Frame>
    <img alt="Kebab menu with Pause option selected on a running workspace" />
  </Frame>

  <small>Example: Pause workspace</small>
</div>

1. Navigate to the **Workspaces** tab.
2. Open the kebab menu on a running workspace and confirm **Pause Workspace**.

To permanently remove a workspace:

<div>
  <Frame>
    <img alt="Terminate confirmation dialog asking to retype the workspace name" />
  </Frame>

  <small>Example: Terminate workspace</small>
</div>

1. Click **Terminate**.
2. Type the workspace name and confirm termination.

<Warning>
  Paused workspaces may still incur storage costs (Cluster storage is billed at \$0.20/GiB/month). Terminated workspaces incur no cost.
</Warning>

## Delete from list

To completely remove a terminated workspace from the list:

<div>
  <Frame>
    <img alt="Terminated workspaces list with Delete buttons, revealed by the View Terminated toggle" />
  </Frame>

  <small>Example: Terminated workspaces list</small>
</div>

1. Enable **View Terminated** toggle to see terminated workspaces.
2. Click the **Delete** button on the workspace card.
3. Type the workspace name and confirm deletion.

<Info>
  Terminated workspaces are no longer auto-deleted after 24 hours. Use **Delete** to manually remove them from the list when you no longer need the history.
</Info>


# Connect to a workspace
Source: https://docs.cloud.vessl.ai/member/workspace/connect

Open services in your browser or connect using SSH from your terminal or VS Code.

<Tip>
  **Prefer the terminal?** Run `vesslctl workspace ssh <workspace-slug>` to open the same SSH session straight from your shell. See [`vesslctl workspace ssh`](/cli/commands/workspace#ssh).
</Tip>

## HTTP services

In the workspace detail page, open the **Connect** tab. All HTTP-accessible services—including JupyterLab and any custom ports you opened during workspace creation—are listed here.

* Click the URL to open the service directly in your browser.
* Use the copy button to copy the URL to your clipboard.

## SSH key connection

The **Connect** tab also provides SSH connection details. Two options are available:

* **Connect using SSH**: A one-line command to run directly in your terminal.
* **SSH host setup for VS Code**: An SSH config block to add to `~/.ssh/config` for VS Code Remote-SSH.

<Info>
  SSH keys must be registered in your account settings before connecting. See [SSH keys](/member/settings/ssh-keys) for details.
</Info>

<div>
  <Frame>
    <img alt="Workspace Connect tab showing HTTP services and SSH key connection" />
  </Frame>

  <small>Example: The Connect tab with HTTP services and SSH connection options</small>
</div>

### Connect from terminal

1. Open the **Connect** tab and select the **Connect using SSH** tab.
2. Click the copy icon to copy the SSH command.
3. Replace `/path/to/<key-name>` with the actual path to your private key file (usually in `~/Downloads`).
4. Paste and run the command in your terminal.

### Connect using VS Code Remote-SSH

1. Install the VS Code extension **Remote-SSH**.
2. Open the **Connect** tab and select the **SSH host setup for VS Code** tab.
3. Click the copy icon to copy the SSH config block.
4. Paste the block into your `~/.ssh/config` file.
5. Replace `/path/to/<key-name>` with your downloaded private key path (usually in `~/Downloads`).
6. In VS Code, open the Command Palette and run `Remote-SSH: Connect to Host...`, then select the workspace name.

Example `~/.ssh/config` entry:

```sshconfig theme={null}
Host <workspace-name>
  HostName capella.cloud.vessl.ai
  IdentityFile /path/to/<key-name>
  Port 32154
  User root
```

<div>
  <Frame>
    <img alt="VS Code Remote-SSH add host screen" />
  </Frame>
</div>

<div>
  <Frame>
    <img alt="VS Code Remote-SSH host connection screen" />
  </Frame>
</div>

<Tip>
  If you experience input latency in the remote terminal, enable VS Code's **local echo** feature. It displays your keystrokes immediately before the remote server confirms them. Turn it on in [terminal.integrated.localEchoEnabled](vscode://settings/terminal.integrated.localEchoEnabled). See [Reducing remote input latency](https://code.visualstudio.com/docs/terminal/advanced#_reducing-remote-input-latency-preview) for details.
</Tip>


# Convert a workspace to a Job
Source: https://docs.cloud.vessl.ai/member/workspace/convert-to-job

Reuse a workspace's image, resource spec, and volumes to launch a Job in one click.

When you've prototyped in a workspace and want to run the same setup as a job — longer training or parameter sweeps — **Convert to Job** clones the environment in one click. The original workspace is untouched, so you can keep iterating in it while the job runs in parallel.

## What carries over

The job inherits everything needed to reproduce the workspace runtime, and drops the interactive pieces a job doesn't use:

| Cloned to the job | Dropped |
| - | - |
| Container image | SSH keys |
| Resource spec (GPU, CPU, region) | Custom exposed ports |
| Mounted Object and Cluster volumes (with mount paths) | Init script |
| | The workspace's own root volume |

Jobs run a command to completion and don't need SSH access, custom ports, or a root volume.

## What you provide

* **Command** — the job entrypoint, for example `python train.py --epochs 50`.
* **Environment variables** or secret references (optional) — run-specific settings plus any [secrets](/member/settings/secrets) the script needs.
* Override the **resource spec**, **image**, or **volumes** (optional) before submitting.

## Convert from the GUI

<div>
  <Frame>
    <img alt="Workspace detail page showing the Convert to Job button in the top-right action bar, next to View history" />
  </Frame>

  <small>Example: the Convert to Job action on a workspace detail page</small>
</div>

1. Open the workspace detail page (**Workspaces** → the workspace).
2. Click **Convert to Job** in the top-right action bar.
3. Fill in the **Command** and any env vars or secrets.
4. Override the resource spec, image, or volumes if you need a different runtime for the run.
5. Click **Create job**.

You're redirected to the new job's detail page. The source workspace stays exactly as it was, so you can keep developing in it while the job runs.

## Convert with a coding agent

VESSL Cloud extends beyond the web console to coding agents like Claude Code. The vesslctl skill includes a guide for converting a workspace into a job.

Tell the coding agent which workspace to convert and ask in plain language:

```
Convert this workspace to a job <workspace-slug>
```

It moves the environment over without the manual, multi-step flow. If a runtime setting needs to change, just ask the agent in plain language and follow its guidance.

## Tips

* **Store your data on a Cluster storage or Object storage volume.** The workspace's root volume isn't carried over. Keep datasets, checkpoints, and converted scripts on it, mounted on both the workspace and the job, and the job reads them directly — no data to move.
* **Set a working directory.** Separating the working directory from the command keeps runs consistent without repeating the path each time. The same `.py` can resolve to a different file depending on the working directory, so pinning it helps especially when you run experiments in parallel.

<Info>
  The conversion is a one-shot clone, not a live link. Changes you make to the workspace after conversion don't flow into the running job, and vice versa.
</Info>


# Create a workspace
Source: https://docs.cloud.vessl.ai/member/workspace/create

Select resources, configure your environment, and launch a GPU instance from a single page.

<Tip>
  **Prefer the terminal?** You can create workspaces from the CLI with `vesslctl workspace create`, including SSH keys and custom ports. See [`vesslctl workspace create`](/cli/commands/workspace#create) for the full flag reference.
</Tip>

## Quick demo

Explore the workspace creation flow with the quick demo below.

<div>
  <iframe title="Create a New Compute Workspace with Persistent Storage and SSH Access" />
</div>

## Overview

All workspace settings are configured on a single page. Fill in each section and click **Create** to launch your workspace.

<div>
  <Frame>
    <img alt="Create workspace page showing all configuration sections" />
  </Frame>

  <small>Example: Workspace creation page</small>
</div>

## Workspace name

Enter a name for your workspace. A random name is generated by default.

## Resource spec

Select your hardware specification in three steps: GPU product, region, and GPU count.

### 1. GPU product

Choose the GPU model that fits your workload. Each card shows the GPU name and VRAM capacity (for example, **A100 SXM** 80GB VRAM, **H100 SXM** 80GB VRAM). Select **CPU only** if you don't need a GPU.

### 2. Region

Select the region where your workspace will run. VESSL Cloud automatically assigns the optimal cluster within the selected region.

### 3. GPU count

Choose how many GPUs to allocate. Each card shows:

* **Availability** indicator (High / Low)
* **Hourly cost**
* **vCPU count**, **RAM**, and **Temporary storage** size

<Info>
  Each GPU count card shows an availability indicator:

  * **High availability**: Sufficient resources available — your workspace should start promptly.
  * **Low availability**: Limited resources available — your workspace may wait in queue longer than usual.
</Info>

## Persistent volume

Add a persistent volume to keep data across restarts and share it with your team.

* Select a **Volume** from the dropdown and specify a **Mount Path**.
* Click **Add volume** to attach additional volumes.

<Warning>
  Workspaces include Temporary storage that disappears when stopped. Attach a **persistent volume** to keep your data.
</Warning>

<Info>
  Cluster storage volumes are only available when the GPU region you selected matches the storage's region. If no Cluster storage appears in the dropdown, check that your organization has Cluster storage in the same region.
</Info>

<Info>
  **Recommended path for Cluster storage**:

  * Mount Cluster storage at `/root` (`$HOME`) for code and environments, or use a custom path like `/data`.
</Info>

<Danger>
  Object storage is slower than Cluster storage and not suitable as your main workspace path. Do not mount Object storage at `/root` — use `/shared` or another separate path for datasets and cross-cluster sharing.
</Danger>

### Storage types

| Type | Description | Max per workspace |
| - | - | - |
| Cluster storage | High-availability distributed storage (CephFS/NVMe) shared within the same cluster. Data persists after terminate. | Multiple |
| Object storage | S3-backed POSIX-compatible storage accessible across all clusters | Multiple |

<Info>
  You can attach multiple Cluster storage and Object storage volumes to a single workspace.
</Info>

See also: [Storage list](/member/volume/list) for available storage volumes and usage details.

## Container image

Select a pre-configured official image (like PyTorch, CUDA) or switch to the **Custom** tab to use your own image.

<Note>
  When using a custom image, ensure that **SSH server (SSHD)** and **Python** are installed to enable connectivity and full functionality.
</Note>

## SSH keys

Select an existing SSH key or click **Generate SSH Key** to create a new key pair.

* The private key will be downloaded to your machine, and the public key is saved to your account automatically.

## Advanced settings

Toggle **Advanced settings** to configure ports.

### Ports

Default ports are pre-configured:

* **HTTP 8888** — JupyterLab
* **TCP 22** — SSH

Click **Add port** to expose additional custom ports (HTTP or TCP). Each port needs a unique name within the workspace, and the names `ssh` and `jupyter` are taken by the default ports above.

## Pricing summary and create

The **Pricing summary** panel on the right shows the selected resource spec details (VRAM, vCPU, RAM) and the estimated hourly cost.

<div>
  <Frame>
    <img alt="Pricing summary showing resource details and Create button" />
  </Frame>

  <small>Example: Pricing summary with Create button</small>
</div>

Click **Create** to launch your workspace.

<Note>
  **Credit buffer**: Workspaces will not be terminated until your balance drops below -\$10. This buffer amount will be displayed as a negative balance on your credit badge and deducted from your next top-up.
</Note>


# View workspace details
Source: https://docs.cloud.vessl.ai/member/workspace/details

Compute specs, pricing summary, image, and attached storage.

<div>
  <Frame>
    <img alt="Workspace details page with Compute specs, Pricing summary, Container image, and storage sections" />
  </Frame>

  <small>Example: Workspace details</small>
</div>

<Info>
  The details page shows the following sections:

  * **Compute specs**: Cluster, GPU, CPU, memory, and Temporary storage size
  * **Pricing summary**: Hourly GPU resource cost and storage cost
  * **Container image**: The Docker image running in the workspace
  * **Cluster storage**: Mount path and capacity of Cluster storage volumes
  * **Object storage**: Object storage volumes and their mount paths
</Info>

<Note>
  These details stay visible on paused workspaces too, so you can review the configuration before resuming.
</Note>

## Cost states

| State | Cost |
| - | - |
| Running | GPU + storage |
| Paused | Storage only (GPU = \$0) |
| Terminated | No cost |

## Status & history

Get detailed visibility into your workspace's lifecycle.

<Tip>Use the demo below to see how to open **Event history** in the workspace details page and review the event timeline.</Tip>

<div>
  <iframe title="View the Activity History of a Terminating Workspace" />
</div>

<div>
  <Frame>
    <img alt="Event history panel showing workspace state transitions and errors over time" />
  </Frame>

  <small>Example: Workspace event history</small>
</div>

<Info>
  The status panel shows:

  * **Detailed status**: Specific reason — *Waiting for GPU capacity* when `Queued`, *Downloading image* when `Initializing`
  * **Event history**: Timeline of state transitions, errors (for example, `OOMKilled`, credit exhaustion), and scheduling events
  * **Runtime**: Elapsed time when running, `N/A` when paused, total runtime when terminated
</Info>

## See also

* [Connect](/member/workspace/connect)
* [Pricing](/pricing/gpu-instances)


# View workspaces
Source: https://docs.cloud.vessl.ai/member/workspace/list

Understand columns and lifecycle states on the workspace list.

<Tip>
  **Prefer the terminal?** `vesslctl workspace list` shows the same workspaces along with a SLUG column you can copy straight into other commands. See [`vesslctl workspace list`](/cli/commands/workspace#list).
</Tip>

Go to the **Workspaces** tab in the sidebar to view all your environments at a glance.

<div>
  <Frame>
    <img alt="Workspace list with name, status, cluster, resource spec, runtime, and hourly cost columns" />
  </Frame>

  <small>Example: Workspace list</small>
</div>

<Info>
  The workspace list shows the following columns:

  * **Name**: Workspace name
  * **Status**: current state (see below)
  * **Cluster**: where resources are located
  * **Resource spec**: GPU, CPU, memory, Temporary storage
  * **Runtime**: accumulated running time
  * **Hourly cost**: rate for the selected spec (visible if pricing is enabled)
</Info>

## Statuses

* **Queued**: Waiting for resources. Shows specific reason such as *Waiting for GPU capacity*.
* **Initializing**: Preparing the environment. Shows specific reason such as *Downloading image*.
* **Running**: Actively running. Runtime counter is active.
* **Paused**: Session is suspended. Runtime shows `N/A`.
  * Temporary storage data is cleared and not preserved.
* **Terminating**: Workspace is being deleted.
* **Terminated**: Fully terminated. Shows **Total runtime** for billing reference.
* **Failed**: Stopped due to an error (for example, Out of Memory Killed (OOMKilled), credit exhaustion, Temporary storage exceeded).

## View terminated workspaces

Terminated workspaces are no longer auto-deleted after 24 hours. Use the **View Terminated** toggle at the top of the workspace list to show or hide terminated workspaces.

<div>
  <Frame>
    <img alt="View Terminated toggle that reveals terminated workspaces in the list" />
  </Frame>

  <small>Toggle to show terminated workspaces</small>
</div>

<Tip>Use the demo below to see how to review terminated workspaces with **View Terminated** and permanently remove them with **Delete**.</Tip>

<div>
  <iframe title="Pause and Permanently Delete a Workspace" />
</div>

* View event history and termination reasons for debugging
* Manually delete workspaces when no longer needed
* Keep your active workspace list clean while preserving history


# View logs
Source: https://docs.cloud.vessl.ai/member/workspace/logs

View real-time container logs for debugging and monitoring.

Use the Logs tab to stream container output in real time. This is useful for debugging and monitoring training progress.

<div>
  <Frame>
    <img alt="Logs tab streaming real-time container output" />
  </Frame>

  <small>Example: Workspace logs</small>
</div>


# Monitor metrics
Source: https://docs.cloud.vessl.ai/member/workspace/metrics

Track GPU, VRAM, temperature, CPU, memory, and storage usage for your workspace.

The **Metrics** tab provides timeseries charts for GPU, VRAM, temperature, CPU, memory, and network usage so you can track performance, detect bottlenecks, and identify resource waste.

<Note>
  You can also open the **Metrics** tab while a workspace is paused — the most recent run's charts stay visible without resuming.
</Note>

<div>
  <Frame>
    <img alt="Workspace metrics showing GPU, VRAM, temperature, CPU, memory, and network charts" />
  </Frame>

  <small>Example: Workspace metrics</small>
</div>

## Time range

Use the time range selector at the top of the charts to choose a window:

* **1h** (default), **6h**, **12h**, **1d**, **7d**

All charts update to reflect the selected time range.

## Display settings

Click the display settings control to customize the chart layout:

* **Grid mode** (default): Charts are arranged two per row for a compact overview
* **Expand mode**: Charts are shown one per row for detailed analysis

You can also toggle individual charts on or off. Your display preferences are saved to your browser.

## GPU utilization

Shows GPU compute usage over time as a percentage. Use this chart to check whether your GPU is actively processing workloads.

| Detail | Value |
| - | - |
| Y-axis | 0–100% |
| Interpretation | Below **30%** can indicate over-provisioned resources |

## VRAM usage

Shows GPU video memory consumption over time. High VRAM usage can indicate risk of out-of-memory (OOM) errors.

<div>
  <Frame>
    <img alt="VRAM usage chart showing GPU video memory consumption (GB) over time" />
  </Frame>

  <small>Example: VRAM usage chart</small>
</div>

| Detail | Value |
| - | - |
| Y-axis | GB |
| Interpretation | High usage can slow model loading or increase out-of-memory (OOM) risk |

<Warning>
  If VRAM usage consistently exceeds **95%**, your workload is at risk of OOM errors. Consider scaling up GPU memory via **Pause & Edit**.
</Warning>

## Temperature

Shows GPU temperature over time. Sustained high temperatures may trigger thermal throttling, reducing performance.

<div>
  <Frame>
    <img alt="Temperature chart tracking GPU temperature in degrees Celsius over time" />
  </Frame>

  <small>Example: Temperature chart</small>
</div>

| Detail | Value |
| - | - |
| Y-axis | °C |
| Interpretation | Consistently above **85°C** can indicate thermal throttling |

## CPU and memory

* **CPU Utilization**: Percentage of allocated CPU cores in use.
* **Memory Usage**: System RAM consumed by the workspace.

## Network I/O

Shows data transferred in (Rx) and out (Tx) of the workspace over time.

## Storage

Storage metrics show current usage for volumes attached to the workspace:

* **Temporary storage**: Ephemeral storage included in the workspace. Data is cleared when the workspace stops or terminates
* **Cluster storage**: Persistent volumes mounted from Cluster storage (if attached)
* **Object storage**: S3-backed volumes mounted from Object storage (if attached)

## Under-utilization and high-utilization banners

When you navigate to this page from the [Home dashboard](../dashboard/overview) by clicking an under-utilized or high-utilization workload, a contextual banner appears at the top.

### Under-utilization banner

<div>
  <Frame>
    <img alt="Under-utilization banner recommending Pause & Edit to downscale when GPU utilization stays below 30%" />
  </Frame>

  <small>Example: Under-utilization banner</small>
</div>

* **Condition**: GPU utilization below **30%** (one-hour average)
* **Banner context**: Recommends downscaling via **Pause & Edit** to reduce cost
* **Action**: Links to the Pause & Edit documentation
* **Dismiss**: The banner can be dismissed; it reappears after 24 hours if the condition persists

### High-utilization banner

* **Condition**: GPU utilization above **90%** (one-hour average)
* **Banner context**: Recommends scaling up via **Pause & Edit** when more compute or memory is needed
* **Action**: Links to the Pause & Edit documentation

<Tip>
  **Threshold summary**: Under-utilization triggers below **30%** GPU utilization (one-hour average). High-utilization triggers above **90%**.
</Tip>


# Understand workspaces
Source: https://docs.cloud.vessl.ai/member/workspace/overview

What a workspace is and why it matters for ML development on VESSL Cloud.

<Tip>
  **Workspaces work from the CLI too.** Create, list, SSH into, pause, and terminate workspaces from your terminal with `vesslctl workspace`. See the [CLI cheat sheet](/cli/cheatsheet) for a one-page command reference, or [vesslctl workspace](/cli/commands/workspace) for the full flag reference.
</Tip>

**[Workspace](/guides/get-started/glossary#workspace)** lets you instantly run a containerized environment with [GPU](/guides/get-started/glossary#gpu) and CPU resources for ML development.

In a workspace, you can run code using JupyterLab or connect using SSH.

* Start quickly without complex infrastructure setup
* Choose resources and launch instantly
* Pause to preserve the environment at lower cost, or Terminate to stop billing

<div>
  <Frame>
    <img alt="Workspace tab listing running and paused environments with their resources and cost" />
  </Frame>

  <small>Example: Workspace overview</small>
</div>


# GPU instances
Source: https://docs.cloud.vessl.ai/pricing/gpu-instances

Available GPU instance families and pricing overview.

Below are current hourly prices for on-demand GPUs. Prices may change over time.

| GPU | VRAM | On-demand | Reserved |
| - | - | - | - |
| H100 SXM | 80 GB | \$2.98/hr | Contact sales |
| A100 SXM | 80 GB | \$1.48/hr | Contact sales |
| L40S | 48 GB | \$1.80/hr | Not available |
| H200 SXM | 141 GB | Not available | Contact sales |
| B200 | 192 GB | Not available | Contact sales |
| B300 | 288 GB | Not available | Contact sales |
| GB300 | 288 GB | Not available | Contact sales |

H200, B200, B300, and GB300 are available as reserved capacity only. Reserved rates are quoted by GPU, term, and volume.

* [Talk to sales about reserved capacity](https://vessl.ai/en/talk-to-sales?utm_source=docs\&utm_medium=referral\&utm_campaign=gpu_pricing_en\&utm_content=reserved_cta)

<Note>
  Values are indicative and subject to updates.
</Note>

<Info>
  Last updated: 2026-09-26
</Info>


# Inference pricing
Source: https://docs.cloud.vessl.ai/pricing/inference

Provisioned Throughput pricing: the PTU rate, contract terms, and capacity per PTU.

Below are the current Provisioned Throughput prices, in Provisioned Throughput Units (PTUs). Prices may change over time.

### Provisioned Throughput

| Item | Price |
| - | - |
| **PTU rate** | **\$0.05/PTU/minute**, the same for every model |
| **PTU quantity** | Arranged individually with sales |
| **Contract term** | Arranged individually with sales |
| **Billing cycle** | Monthly |

**Example**: A contract of 8 PTUs costs \$576 per day, and about \$17,520 per month on the 730-hour month the **Estimate total cost** calculator uses.

### Capacity per PTU

One PTU processes up to the following tokens per minute (TPM), by model and token type. These are default values; a contract can set its own capacity per PTU, which takes precedence.

| Model | Input (TPM) | Cached input (TPM) | Output (TPM) |
| - | - | - | - |
| **GLM 5.3 Flash** | 333,333 | 1,666,667 | 100,000 |
| **DeepSeek V4.1 Flash** | 166,667 | 7,142,857 | 41,667 |

<Info>
  Use the **Estimate total cost** calculator on any model page to size a mixed workload and compare the cost with a frontier model. See [Understand PTUs and billing](/inference/ptu).
</Info>

* [Talk to sales to set up Provisioned Throughput](https://vessl.ai/en/talk-to-sales?utm_source=docs\&utm_medium=referral\&utm_campaign=inference_en\&utm_content=pricing_cta).

<Note>
  Values are indicative and subject to updates.
</Note>

<Info>
  Last updated: 2026-09-14
</Info>


# Storage pricing
Source: https://docs.cloud.vessl.ai/pricing/storage

Pricing for Cluster storage and Object storage.

<Note>
  **Storage pricing & policy update — effective 2026-07-01 09:00 UTC.** Object storage moves from free preview to paid usage at \$0.03/GiB/month. Cluster storage keeps the same per-GiB rate but switches from provisioned-capacity billing to actual-usage daily billing. See the [FAQ](#faq) below for details.
</Note>

Below are the prices that apply from 2026-07-01. Prices and policies may change over time.

### Cluster storage

Cluster storage is billed **daily based on actual usage** — the volume of data physically stored, not the provisioned capacity.

| Item | Price |
| - | - |
| Cluster storage | **\$0.20/GiB/month** (\$0.0067/GiB/day, billed daily pay-as-you-go) |

**Example**: If you provision a 100 GiB Cluster storage volume but only store 10 GiB of data, you are billed for 10 GiB — approximately \$2/month.

<Info>
  Cluster storage uses high-availability CephFS/NVMe within a cluster. Data persists even after workspace termination, and volumes can be shared across workspaces in the same cluster.
</Info>

### Object storage

Object storage is billed **daily based on actual usage**.

| Item | Price |
| - | - |
| Object storage | **\$0.03/GiB/month** (\$0.001/GiB/day, billed daily pay-as-you-go) |

**Example**: 100 GiB of stored data costs approximately \$3/month.

<Info>
  Object storage is S3-backed and accessible across clusters in your organization. Use it for datasets, model checkpoints, and cross-cluster sharing.
</Info>

### Legacy pricing

<Warning>
  **Workspace volume** (deprecated): \$0.0070/hr for 50 GiB. Workspace volumes are replaced by Cluster storage.
  Contact [support@vessl.ai](mailto:support@vessl.ai) to migrate existing data.
</Warning>

### Storage and credits

If your credits run out, your storage data is retained for up to **30 days** while access is restricted, and then deleted. Back up important data before your balance reaches zero. See the [Credit exhaustion policy](/admin/billing/credit-exhaustion-policy) for the full lifecycle.

## FAQ

<AccordionGroup>
  <Accordion title="What is changing on 2026-07-01?">
    Two changes ship on the same date.

    1. **Object storage** moves from free preview to paid usage at **\$0.03/GiB/month** (\$0.001/GiB/day).
    2. **Cluster storage** keeps the same **\$0.20/GiB/month** rate, but billing switches from provisioned capacity (monthly) to actual usage (daily, pay-as-you-go).
  </Accordion>

  <Accordion title="When does the new pricing take effect?">
    Both changes apply from **2026-07-01 09:00 UTC**. Usage through 2026-06-30 is billed under the previous policy.
  </Accordion>

  <Accordion title="How much is Object storage?">
    **\$0.03/GiB/month**, billed daily as \$0.001/GiB/day on a pay-as-you-go basis.
  </Accordion>

  <Accordion title="Will data that was free before be billed starting in July?">
    Yes. From 2026-07-01, all Object storage data you keep counts toward your usage. Clean up unneeded data beforehand to keep costs down.
  </Accordion>

  <Accordion title="Does the per-GiB price of Cluster storage change?">
    No. The rate stays at **\$0.20/GiB/month**. What changes is the billing model (provisioned capacity → actual usage) and measurement cadence (monthly → daily).
  </Accordion>

  <Accordion title="If I provision a 100 GiB Cluster storage volume but only store 10 GiB, what gets billed?">
    Only the **10 GiB** of actual data. Under the new policy you no longer need to pre-provision exact capacity — billing follows what you actually store.
  </Accordion>

  <Accordion title="What happens to volumes that were already provisioned before July?">
    From 2026-07-01, all Cluster storage is measured and billed by actual usage automatically. No migration step is required on your side.
  </Accordion>

  <Accordion title="How is usage measured?">
    A daily batch collects the amount of data stored. That day's usage drives that day's charge. The exact batch time is not published, to prevent abuse of the measurement window.
  </Accordion>

  <Accordion title="When does the first bill under the new policy arrive?">
    Charges under the new policy begin on **2026-07-01**. Usage from June is billed under the previous policy.
  </Accordion>

  <Accordion title="Can I estimate my bill before July?">
    Yes. Check your current actual usage in the [**Billing** overview](/admin/billing/overview), then estimate as `Object storage (GiB) × \$0.03 + Cluster storage (GiB) × \$0.20` per month.
  </Accordion>
</AccordionGroup>

<Note>
  All prices are indicative and subject to updates.
</Note>

<Info>
  Last updated: 2026-05-27
</Info>


# Connect over SSH
Source: https://docs.cloud.vessl.ai/vm-clusters/connect-ssh

Connect to each node in your VM cluster over SSH, and troubleshoot common issues.

Each node in your cluster has a dedicated public IP and accepts SSH with the representative public key your account manager registered for the cluster.

## Prerequisites

* An **Active** cluster.
* The private key matching the **representative SSH public key** your account manager registered for the cluster.

## Connect

Find each node's public IP in the cluster's **Node management** tab, then connect:

<div>
  <Frame>
    <img alt="Node management tab listing each node with its public IP and a Copy all SSH config button" />
  </Frame>

  <small>Example: the Node management tab with per-node public IPs and Copy all SSH config</small>
</div>

```bash theme={null}
ssh -i ~/.ssh/<key> ubuntu@<node-ip>
```

You log in as `ubuntu`. To run commands as root, escalate with `sudo` (for example, `sudo -i`).

Each node has its own dedicated public IP — connect to each one separately using the IPs listed in the **Node management** tab.

## Troubleshooting

| Symptom | Cause and fix |
| - | - |
| `Permission denied (publickey)` | You're using a key that doesn't match the one registered for the cluster. Confirm your private key matches the registered public key. |
| Connection timeout | Inbound traffic to port 22 isn't allowed. Add an [inbound firewall rule](/vm-clusters/firewall-rules) with protocol `tcp` and port `22`, and set the source CIDR to include your IP. |


# Plan for data retention
Source: https://docs.cloud.vessl.ai/vm-clusters/data-retention

What happens to your data when a contract expires, and how to back it up.

## Boot disk vs NFS

* **Boot disk** — local to each node. It can be lost if the node is relocated due to a hardware fault, and it's deleted when the contract expires. Don't keep your only copy of important data here.
* **[NFS shared storage](/vm-clusters/nfs-storage)** — shared across all nodes in the cluster. It's also deleted when the contract expires.

## At expiry

<Warning>
  When your contract expires, all VMs are stopped and **all data — boot disk and NFS — is deleted immediately**. There is no grace period and no recovery. Back up anything important before the expiry date.
</Warning>

Data deletion at expiry and advance notice are defined in the [VM Cluster service terms](/legal/vm-cluster).

## Expiry reminders

We email you before expiry so you have time to back up or extend:

* **7 days before** (D-7)
* **3 days before** (D-3)
* **1 day before** (D-1)
* **On the expiry date** (D-0)

All reminders are sent at 00:00 UTC.

## Back up your data

Before expiry, copy anything you need off the cluster — for example with `rsync` to your own machine, or by syncing NFS to object storage such as S3.


# Extend a contract
Source: https://docs.cloud.vessl.ai/vm-clusters/extend-contract

Extend the term of an active VM cluster contract.

To extend or change a contract, [talk to sales](https://vessl.ai/en/talk-to-sales?utm_source=docs\&utm_medium=referral\&utm_campaign=vm_clusters_en\&utm_content=extend_contract) or [contact support](mailto:support@vessl.ai).

Reach out before your contract expires — and back up your data, since [expiry deletes everything immediately](/vm-clusters/data-retention).


# Browse the FAQ
Source: https://docs.cloud.vessl.ai/vm-clusters/faq

Common questions about VM clusters, billing, storage, and operations.

<AccordionGroup>
  <Accordion title="Why VM instead of bare metal?">
    VMs recover quickly from hardware failures by migrating to a new physical host. You still get GPU passthrough performance and can run root-level operations through `sudo`. For bare-metal requirements, [talk to sales](https://vessl.ai/en/talk-to-sales?utm_source=docs\&utm_medium=referral\&utm_campaign=vm_clusters_en\&utm_content=faq_bare_metal).
  </Accordion>

  <Accordion title="Can I pay with my existing VESSL Cloud credits?">
    No. VM clusters are billed separately from VESSL Cloud and can't be paid with VESSL Cloud credits. Your account manager handles billing.
  </Accordion>

  <Accordion title="Do you provide managed Kubernetes or Slurm?">
    Not yet — managed Kubernetes and Slurm are on our roadmap. In the meantime, you can install your own orchestrator (Kubernetes, Slurm, or anything else) on the cluster yourself, since you can run root-level operations through `sudo`.
  </Accordion>

  <Accordion title="How is contract length decided?">
    Contract length is agreed with sales when you request a cluster. [Talk to us](https://vessl.ai/en/talk-to-sales?utm_source=docs\&utm_medium=referral\&utm_campaign=vm_clusters_en\&utm_content=faq_contract_length) for the terms you need.
  </Accordion>

  <Accordion title="Can I change node count or specs mid-contract?">
    No. To change your configuration, [talk to sales](https://vessl.ai/en/talk-to-sales?utm_source=docs\&utm_medium=referral\&utm_campaign=vm_clusters_en\&utm_content=faq_change_config) and we'll scope a new cluster.
  </Accordion>

  <Accordion title="Can I change my payment method mid-contract?">
    No. To change your payment method, talk to your account manager.
  </Accordion>

  <Accordion title="Can I recover data after expiry?">
    No. All data is deleted immediately at expiry, with no grace period. Back up before the expiry date — see [Data retention and expiry](/vm-clusters/data-retention).
  </Accordion>

  <Accordion title="How long does a reboot take?">
    Reboots typically take tens of minutes, and can run past an hour in some cases. See [Reboot a node](/vm-clusters/reboot).
  </Accordion>

  <Accordion title="What if I lose my SSH key?">
    You manage authorized keys directly on each node. Because you have root, you can add a new public key to `~/.ssh/authorized_keys`. If you've lost access to the node entirely, [contact support](mailto:support@vessl.ai).
  </Accordion>

  <Accordion title="Can I change the GPU driver?">
    Yes. You have root access, so you can change drivers and kernel modules.
  </Accordion>

  <Accordion title="Can I run privileged containers (Docker `--privileged`, K8s `securityContext`)?">
    Yes. You have root on the VM itself, so any container runtime you install — Docker, containerd, Kubernetes — can run containers with `--privileged`, custom capabilities, raw device mounts, or anything else that needs host-level access.
  </Accordion>

  <Accordion title="Do you provide InfiniBand?">
    Yes — InfiniBand is provided by default on all nodes for multi-node communication.
  </Accordion>

  <Accordion title="What GPU types and cluster sizes are available?">
    H100 through the latest Blackwell GPUs (H100, H200, B200, B300), in multi-node clusters sized to your workload. [Talk to sales](https://vessl.ai/en/talk-to-sales?utm_source=docs\&utm_medium=referral\&utm_campaign=vm_clusters_en\&utm_content=faq_other_gpus) to scope and provision your cluster. Once it's set up, you can manage it from the VM clusters dashboard.
  </Accordion>

  <Accordion title="Is auto-scaling supported?">
    No. The node count is fixed for the contract term. If you need more capacity, [talk to sales](https://vessl.ai/en/talk-to-sales?utm_source=docs\&utm_medium=referral\&utm_campaign=vm_clusters_en\&utm_content=faq_autoscaling).
  </Accordion>
</AccordionGroup>


# Configure firewall rules
Source: https://docs.cloud.vessl.ai/vm-clusters/firewall-rules

Control inbound access to your VM cluster with firewall rules.

Firewall rules control inbound network access to your cluster. You manage them yourself from the cluster detail page.

<div>
  <Frame>
    <img alt="Cluster detail page with the Firewall rules tab selected, showing rules with protocol, port range, source IP, and description, plus an Edit button" />
  </Frame>

  <small>Example: the Firewall rules tab on the cluster detail page</small>
</div>

## Scope

Rules apply to the **entire cluster** — every node gets the same rules. You can't set rules per node.

## When you can edit

You can edit rules while the cluster is **Active**. Click **Edit** in the **Firewall rules** tab, change rules inline, then click **Save** to apply. While changes propagate, each row shows an **Updating...** indicator; this usually takes a few seconds to a few minutes. The team is notified by email when rules change.

## Rule fields

| Field | Notes |
| - | - |
| **Type** | A preset (SSH, HTTP, HTTPS, Custom TCP, Custom UDP, All traffic) that prefills the protocol and port |
| **Protocol** | Set by the **Type** preset (TCP, UDP, or All) |
| **Port range** | Single port (for example, `8080`) or a range (for example, `8000-9000`) |
| **Source IP** | **IPv4** CIDR — required. Use **My IP** to fill in your current address |
| **Description** | Optional |

Presets are available for common cases: SSH (TCP/22), HTTP (TCP/80), HTTPS (TCP/443), Custom TCP, Custom UDP, and All traffic.

## Default rule

When you first open the rule form, an **SSH** rule (TCP/22 from `0.0.0.0/0`) is prefilled as a starting point. You can keep it, edit it, or remove it before saving — there are no managed rules, and every rule is treated equally.

## Rule policies

* **No duplicates** — a rule with the same protocol, port range, and source as an existing rule is rejected. Change any one of the three and it's allowed.
* **CIDR notation is required** — even a single IP must use `/32` (for example, `10.0.0.1/32`).

## Status banners

A warning banner appears at the top of the **Firewall rules** tab when the current rule set could cause access problems. Each banner shows up automatically while the condition is true and disappears once it's resolved.

| When | Banner message |
| - | - |
| Any rule uses source `0.0.0.0/0` | *Rules with source of 0.0.0.0/0 allow all IP addresses to access your cluster. Consider limiting to specific IP addresses.* |
| No SSH rule (TCP/22) exists | *You do not have an SSH rule. Without one, you cannot access nodes through SSH.* |


# Health checks
Source: https://docs.cloud.vessl.ai/vm-clusters/health-checks

How VESSL Cloud judges each node's health — statuses, levels, and what triggers each color.

Every node in your cluster is health-checked continuously. Each GPU gets its own status, and node-level conditions (memory, disk, kernel modules, InfiniBand, observability) roll up into a single status for the node, refreshed about once a minute.

## Node overview

The cluster detail page shows a **Node overview** strip with every node as a colored cell, so you can read the whole cluster's health at a glance.

## Statuses

| Status | Color | Meaning |
| - | - | - |
| **Healthy** | 🟢 | No active alarms. |
| **Warning** | 🟡 | At least one warning-level alarm. The node is usable but something needs attention. |
| **Critical** | 🔴 | At least one critical alarm. The node may be unusable or producing bad results. |
| **Unknown** | ⚪ | We can't judge the node right now — see [Unknown](#unknown-gray) below. |

A node's status is **worst-wins**: it takes the highest severity across all of its alarms and per-GPU statuses. Having more warnings does not escalate the node to Critical on its own.

## Levels

Health is tracked at two levels — each GPU has its own status, and the node has an overall status that combines node-level checks with the worst per-GPU status.

| Level | Where you see it | What's checked |
| - | - | - |
| **GPU** (per device) | The 8-GPU grid on the node detail page | XID errors, ECC, temperature, throttling |
| **Node** | Node overview cell and the node row dot | Memory, disk, kernel modules, InfiniBand fabric, observability gaps |

## GPU checks

Each GPU has its own status — the worst condition among the checks below. The node picks up the worst GPU's color using worst-wins.

| Code | Condition | Status |
| - | - | - |
| `gpu_high_temp` | GPU temperature ≥ **85°C** (sustained) | 🟡 Warning |
| `gpu_high_temp` | GPU temperature ≥ **95°C** | 🔴 Critical |
| `gpu_memory_high_temp` | HBM (memory) temperature ≥ **85°C** | 🟡 Warning |
| `gpu_memory_high_temp` | HBM temperature ≥ **95°C** | 🔴 Critical |
| `gpu_hw_throttle` | Hardware throttling | 🟡 Warning |
| `gpu_no_process_high_util` | High GPU utilization with no attached process | 🟡 Warning |
| `row_remap_nearing_limit` | HBM row remaps approaching the safety limit | 🟡 Warning |
| `gpu_ecc_dbe` | Uncorrectable (DBE) ECC error | 🔴 Critical |
| `gpu_row_remap_failure` | HBM row remap failure | 🔴 Critical |
| `gpu_remapped_rows_pending` | HBM row remaps pending (reboot required) | 🔴 Critical |
| `gpu_count_mismatch` | Fewer than 8 GPUs detected by the driver | 🔴 Critical |
| `gpu_smi_unhealthy` | GPU reported unhealthy by `nvidia-smi` | 🔴 Critical |
| `gpu_driver_pri_bus_fault` | GPU driver / PCIe bus fault | 🔴 Critical |
| `gpu_recovery_action_required` | GPU recovery action required | 🔴 Critical |

### XID errors

An XID is an error report from the NVIDIA driver. The codes below signal a hardware, driver, or firmware fault serious enough for VESSL to mark the GPU **Critical**. Codes not listed here don't change the GPU's status.

| XID | Code | Meaning | Status |
| - | - | - | - |
| **38** | `gpu_xid38_driver_firmware_mismatch` | Driver / firmware mismatch | 🔴 Critical |
| **48** | `gpu_xid48_dbe_row_remap` | DBE row remap | 🔴 Critical |
| **62** | `gpu_xid62_internal_fw_breakpoint` | Internal firmware breakpoint | 🔴 Critical |
| **64** | `gpu_xid64_ecc_row_remap_failure` | ECC row remap failure | 🔴 Critical |
| **74** | `gpu_xid74_nvlink_error` | NVLink error | 🔴 Critical |
| **79** | `gpu_xid79_fallen_off_bus` | GPU fallen off the bus | 🔴 Critical |
| **95** | `gpu_xid95_uncontained_ecc_reboot` | Uncontained ECC | 🔴 Critical |
| **110** | `gpu_xid110_security_fault` | Security fault | 🔴 Critical |
| **119** | `gpu_xid119_gsp_rpc_timeout` | GSP RPC timeout | 🔴 Critical |
| **120** | `gpu_xid120_gsp_error` | GSP error | 🔴 Critical |
| **121** | `gpu_xid121_c2c_link_error` | C2C link error | 🔴 Critical |
| **123** | `gpu_xid123_spi_pmu_rpc_write_failure` | SPI PMU RPC write failure | 🔴 Critical |
| **136** | `gpu_xid136_link_training_failed` | Link training failed | 🔴 Critical |
| **140** | `gpu_xid140_unrecovered_ecc` | Unrecovered ECC error | 🔴 Critical |
| **143** | `gpu_xid143_gpu_init_failure` | GPU initialization failure | 🔴 Critical |
| **154** | `gpu_xid154_recovery_action_changed` | GPU recovery action changed | 🔴 Critical |
| **167** | `gpu_xid167_pcie_fatal_timeout` | PCIe fatal timeout | 🔴 Critical |
| **169** | `gpu_xid169_sec2_halt` | Micro-controller halt (SEC2) | 🔴 Critical |
| **171** | `gpu_xid171_dram_uncorrectable` | Uncorrectable DRAM error | 🔴 Critical |
| **172** | `gpu_xid172_sram_uncorrectable` | Uncorrectable SRAM error | 🔴 Critical |

These additional codes also mark the GPU **🔴 Critical** (grouped under
`gpu_xid_critical_misc`, shown with the specific XID number): 9, 12, 16, 18,
19, 26, 27, 28, 29, 30, 32, 33, 34, 35, 36, 42, 44, 46, 47, 59, 60, 61, 65,
68, 69, 78.

For the full list of XID codes, see the [NVIDIA XID documentation](https://docs.nvidia.com/deploy/xid-errors/index.html). On the node detail page, each XID alert links to its catalog entry.

## Node checks

These contribute to the node status. They affect the node dot and the Node overview cell — they don't change any individual GPU's status. Hover the node's health indicator on the cluster detail page to see which specific alarm is firing.

### System and kernel

| Code | Condition | Status |
| - | - | - |
| `memory_low` | Low system memory | 🟡 Warning |
| `disk_low` | Low root disk space | 🟡 Warning |
| `peermem_not_loaded` | `peermem` kernel module not loaded | 🔴 Critical |

### InfiniBand

| Code | Condition | Status |
| - | - | - |
| `ib_symbol_errors` | Symbol errors on an InfiniBand HCA (physical-layer corruption) | 🟡 Warning |
| `ib_link_flap` / `ib_storage_link_flap` | Link flap on an InfiniBand HCA | 🟡 Warning |
| `ib_transport_retries_exceeded` | Transport retries exceeded on multiple InfiniBand HCAs | 🟡 Warning |
| `ib_port_down` | One or more InfiniBand ports are down (multi-node paths fail) | 🔴 Critical |

## Observability gaps

When part of a node's health data can't be collected, the node shows **Warning** with one of these labels:

| Label | What it means | Status |
| - | - | - |
| **Node unreachable** | The node isn't responding, so its health can't be checked. | 🟡 Warning, escalating to 🔴 Critical the longer it stays unreachable |
| **GPU metrics unavailable** | GPU metrics aren't being collected, so GPU health can't be checked. | 🟡 Warning |
| **InfiniBand metrics unavailable** | InfiniBand metrics aren't being collected, so link health can't be checked. | 🟡 Warning |

Partial data loss does **not** turn the node Unknown — gray is reserved for the cases below.

## Unknown (gray)

A node is Unknown (⚪) only when its health can't be judged at all. Two cases:

* The node is in **Rebooting** state. We don't judge a node until it's fully running. This is normal during reboot or initial provisioning.
* The node isn't set up for monitoring at all. Uncommon; if a running node stays this way, [contact support](mailto:support@vessl.ai).

In both cases, every cell on the node detail page is gray and the node dot is gray.

## When a node is unhealthy

* **[Reboot the node](/vm-clusters/reboot)** — often clears transient faults.
* **Wait for recovery** — our engineers monitor nodes and recover them manually.
* **[Contact support](mailto:support@vessl.ai)** if the problem persists.

If a node fails due to hardware, our engineers may replace it — replacement is a manual decision, not automatic. There's no fixed maintenance schedule today; if maintenance is needed, we'll notify you in advance.

Health monitoring, node replacement, and maintenance are defined in the [VM Cluster service terms](/legal/vm-cluster). Availability commitments, where they apply, are defined in the [Service Level Agreement (SLA)](/legal/sla).


# Metrics
Source: https://docs.cloud.vessl.ai/vm-clusters/metrics

GPU and system time-series metrics for every node in your cluster.

Each node exposes a per-GPU overview plus time-series charts for GPU, system, network, and InfiniBand metrics. Open a node's detail page from the **Active** cluster → **Node management** tab → click a node.

## GPU overview

Each node lists its 8 GPUs with utilization, VRAM, temperature, power, and a per-GPU health badge. See [Health checks](/vm-clusters/health-checks) for what each badge state means.

<Frame>
  <img alt="Node detail page header and the GPU overview, showing all 8 GPUs with utilization, VRAM, temperature, and power" />
</Frame>

## Time range

Pick a time range from **1h, 6h, 12h, 1d, 7d, or 30d**. For deeper analysis, open the linked Grafana dashboard.

## Metric charts

Metrics are grouped into **6 sections with 25 charts total**.

### Utilization (2 charts)

Track whether GPUs are actively executing tasks and how much memory each one holds.

<Frame>
  <img alt="Utilization section: GPU Utilization and GPU Memory Used time-series charts" />
</Frame>

| Chart | What it shows |
| - | - |
| **GPU Utilization** | Percentage of time the GPU is executing tasks. Low utilization may indicate over-provisioned GPU resources or that upstream vCPUs cannot keep the GPU fed. |
| **GPU Memory Used** | Amount of frame buffer (VRAM) currently in use on each GPU. A sudden drop to **0** indicates a process crash inside the VM; a steady upward trend may signal a memory leak. |

### System (7 charts)

Spot bottlenecks outside the GPU — vCPU saturation, memory pressure, disk, network, or the VM's overall health.

<Frame>
  <img alt="System section (top): CPU Usage, Load Average, System Memory Usage, and Root Disk Usage charts" />
</Frame>

<Frame>
  <img alt="System section (continued): Network RX, Network TX, and Node Uptime charts" />
</Frame>

| Chart | What it shows |
| - | - |
| **CPU Usage** | Percentage of time the VM's vCPUs spend executing tasks. Sustained high values indicate vCPUs are saturated; if GPUs are idle at the same time, vCPUs are likely the bottleneck. |
| **Load Average (5m)** | Average number of processes waiting on vCPUs inside the VM over the last **5 minutes**. Sustained high values may indicate VM overload. |
| **System Memory Usage** | Percentage of the VM's allocated RAM in use. Sustained high values may trigger the OOM (Out of Memory) killer inside the VM, and swap usage causes severe slowdowns. |
| **Root Disk Usage** | Percentage of the VM's root filesystem (`/`) capacity in use. Near capacity may cause write failures for any process needing disk space. |
| **Network RX** | Inbound throughput on the VM's primary ethernet interface. Sustained **0 B/s** during expected activity may indicate an ethernet outage, separate from the InfiniBand fabric. |
| **Network TX** | Outbound throughput on the VM's primary ethernet interface. Carries control-plane traffic such as API calls and logs, separate from the InfiniBand fabric used for high-bandwidth workloads. |
| **Node Uptime** | Tracks node uptime over time. **1** = up (no critical alerts firing), **0** = down (critical alert firing such as XID errors, ECC DBE, or IB link down). Gaps mean the node stopped reporting entirely. |

### Temperature & power (3 charts)

Watch for thermal throttling and power-related instability.

<Frame>
  <img alt="Temperature & power section: GPU temperature, memory temperature, and power usage charts" />
</Frame>

| Chart | What it shows |
| - | - |
| **GPU Temperature** | GPU chip temperature in degrees Celsius. Sustained values approaching the GPU's thermal limit trigger thermal throttling. |
| **Memory Temperature** | HBM (High Bandwidth Memory) temperature in degrees Celsius. Cross-check with GPU temperature to identify the thermal hotspot. |
| **Power Usage** | Current power draw per GPU in watts. Active compute draws close to the GPU's rated TDP; **0 W** typically indicates the VM does not recognize the GPU, and sharp swings may signal unstable load. |

### Memory & clock detail (3 charts)

Identify throttling and HBM activity issues.

<Frame>
  <img alt="Memory & clock detail section: memory utilization, memory clock, and SM clock charts" />
</Frame>

| Chart | What it shows |
| - | - |
| **Memory Utilization** | Percentage of time the GPU's memory engine is active. This measures activity time, not bandwidth (GB/s) — **100%** doesn't necessarily mean max throughput. |
| **Memory Clock** | Current frequency of the GPU's HBM memory clock. Values below the base clock may indicate throttling. Cross-check with **Temperature & power**. |
| **SM Clock** | Current frequency of the SM (Streaming Multiprocessor) clock. Values below the base clock may indicate power or thermal throttling. |

### ECC & errors (4 charts)

Catch GPU hardware faults early — before they take down a training run.

<Frame>
  <img alt="ECC & errors section: ECC SBE/DBE and remapped rows charts" />
</Frame>

| Chart | What it shows |
| - | - |
| **ECC SBE (Correctable)** | Single-bit memory errors corrected by hardware in the last **5 minutes**. Occasional events are normal, but a sharp upward trend may precede uncorrectable errors. |
| **ECC DBE (Uncorrectable)** | Uncorrectable memory errors in the last **5 minutes**. The healthy count is **0**; a single event may corrupt in-flight computation or crash the process using the GPU. |
| **Remapped Rows (Correctable Errors)** | Correctable HBM row remap events in the last **5 minutes**. An upward trend may signal HBM degradation. |
| **Remapped Rows (Uncorrectable Errors)** | Uncorrectable HBM row remap events in the last **5 minutes**. The healthy count is **0**; any occurrence is critical and may require GPU replacement. |

### InfiniBand detail (6 charts)

Monitor the node-to-node fabric used by multi-node distributed training — throughput, errors, and link stability. Each chart is plotted per HCA (Host Channel Adapter).

<Frame>
  <img alt="InfiniBand detail section: per-HCA throughput, receive, and symbol error charts" />
</Frame>

<Frame>
  <img alt="InfiniBand detail section: IB Link Error Recovery and IB Link Downed charts" />
</Frame>

| Chart | What it shows |
| - | - |
| **IB TX Throughput** | Outbound InfiniBand throughput per HCA attached to the VM. Significant imbalance between HCAs may indicate a cable or switch issue; sustained **0 Gbps** may indicate the link is down. |
| **IB RX Throughput** | Inbound InfiniBand throughput per HCA on the VM. Asymmetry against TX may indicate routing issues; per-HCA lines help isolate a faulty port. |
| **IB Receive Errors** | InfiniBand receive errors per HCA in the last **5 minutes**. Sustained values above **0** may indicate cable or port damage, disrupting multi-VM workloads. |
| **IB Symbol Errors** | InfiniBand symbol errors on the VM's HCAs in the last **5 minutes**. May indicate cable aging or optical module issues. |
| **IB Link Error Recovery** | InfiniBand link recovery events on the VM's HCAs in the last **5 minutes**. A rising trend signals link instability and may escalate to **Link Downed**. |
| **IB Link Downed** | InfiniBand link-down events per HCA in the last **5 minutes**. The healthy count is **0**; any occurrence disconnects the VM from the IB fabric. |


# Use NFS storage
Source: https://docs.cloud.vessl.ai/vm-clusters/nfs-storage

Add shared NFS storage to your cluster, where it mounts, and how billing and expiry work.

NFS shared storage is an optional filesystem shared across all nodes in your cluster — useful for datasets, checkpoints, and anything you want available on every node.

## Why use it

A node's boot disk can be lost if the node is rebooted or relocated due to a hardware fault. Keep important data — datasets and checkpoints — on NFS instead.

<Warning>
  **Keep anything you can't afford to lose on NFS.** When a node is replaced after a hardware fault, your VM comes back on new hardware with an empty boot disk. Whatever lived only on the old node, including a training run in progress, is gone and can't be recovered. Write datasets, checkpoints, and results to NFS from the start so a node replacement costs you a restart, not your work.
</Warning>

## Capacity

NFS shared storage is optional. Let us know if you need it when you [request your cluster](/vm-clusters/order), and we'll size it to your workload.

## Mounting

NFS is mounted at `/data` on every node by default. You can re-mount or symlink it elsewhere as you like.

<Warning>
  When your contract expires, both the boot disk and NFS are deleted immediately. There is no grace period and no recovery. Back up anything important before the expiry date — see [Data retention and expiry](/vm-clusters/data-retention).
</Warning>


# Request a VM cluster
Source: https://docs.cloud.vessl.ai/vm-clusters/order

How to request a VM cluster: talk to sales, agree on a configuration, and we provision it for you.

VM clusters are set up with our sales team. Tell us what you need, we scope a configuration with you, and we provision and hand over the cluster.

## How to request

[Talk to sales](https://vessl.ai/en/talk-to-sales?utm_source=docs\&utm_medium=referral\&utm_campaign=vm_clusters_en\&utm_content=order_intro) with a short description of your workload. It helps to share:

* **GPU type**: H100, H200, B200, or B300.
* **Cluster size**: how many nodes you need (each node has 8 GPUs).
* **Contract length**: how long you need the cluster.
* **Storage**: whether you need NFS shared storage, and roughly how much.

We review availability and work out a configuration with you, then put together a plan tailored to your workload.

## What happens next

Once you agree on the configuration:

1. We provision the cluster.
2. When it's ready, you receive SSH connection details and the cluster shows as **Active** in your dashboard. See [Connect over SSH](/vm-clusters/connect-ssh).

## Before you start

VM clusters use your VESSL Cloud account for access and admin. Have these ready:

* **Organization admin** role: a VM cluster is an organization-level resource.
* A **representative SSH public key** for root access. Share it with your account manager, who registers it on the cluster. You connect to each VM with the matching private key.


# Understand VM Clusters
Source: https://docs.cloud.vessl.ai/vm-clusters/overview

Rent 8+ GPUs for multi-node training, with full root access, InfiniBand, and shared storage.

With **VM Clusters**, you rent a dedicated cluster of high-performance GPU nodes, each with 8 GPUs. GPUs from NVIDIA's Hopper to Blackwell generations (H100, H200, B200, B300) are available. [Talk to sales](https://vessl.ai/en/talk-to-sales?utm_source=docs\&utm_medium=referral\&utm_campaign=vm_clusters_en\&utm_content=overview_other_gpus) to scope a cluster for your workload. VESSL Cloud manages the GPU supply and provisioning; you get **full root access** on every node, with no other customers sharing your hardware.

<div>
  <Frame>
    <img alt="VM Clusters page listing clusters with their status, GPU, nodes, and contract dates" />
  </Frame>

  <small>Example: VM Clusters list with multiple lifecycle states</small>
</div>

## Why VM Clusters

* **Multi-node distributed training** — InfiniBand is provisioned by default, giving you high-bandwidth, low-latency RDMA networking between nodes for data- or model-parallel workloads.
* **Full root control** — swap GPU drivers, load custom kernel modules, and configure the OS however you need.
* **Near bare-metal GPU performance** — each VM gets its GPUs directly using GPU passthrough, keeping virtualization overhead minimal.
* **Bring your own stack** — install Slurm, Kubernetes, security agents, or your own deployment scripts. Root access on every node.

## What you get

| | |
| - | - |
| **Form factor** | VM with directly attached GPUs (passthrough), not bare metal |
| **GPU** | 8 per node |
| **Cluster size** | Multi-node, each node with 8 GPUs, [scoped with sales](https://vessl.ai/en/talk-to-sales?utm_source=docs\&utm_medium=referral\&utm_campaign=vm_clusters_en\&utm_content=overview_cluster_size) for your workload |
| **OS image** | Ubuntu 24.04 with CUDA preinstalled |
| **Networking** | InfiniBand between nodes, a dedicated public IP per node |
| **Boot disk** | 2 TiB per node |
| **Storage** | Optional NFS shared storage, 1–200 TiB |
| **Access** | Full root access on every node |
| **Contract length** | Arranged with sales; billed for the full term, including reboots and unhealthy windows |

<Warning>
  **Boot disk data is not durable.** If a node is reprovisioned (for example, after a hardware failure), all data on its boot disk is lost. Keep training data, checkpoints, and any other important files on **NFS shared storage**, which is mounted across every node in the cluster.

  **Data is deleted at contract expiry.** Once a contract ends, all VMs are stopped and all associated data — including boot disks and NFS storage — is permanently deleted. There's no grace period. We send reminder emails before expiry so you can back up or [extend the contract](/vm-clusters/extend-contract) in time.
</Warning>

Contract terms, storage durability, billing, and data retention are defined in the [VM Cluster service terms](/legal/vm-cluster).

## Core features

* **[NFS shared storage](/vm-clusters/nfs-storage)** — a shared filesystem mounted across all nodes in the cluster.
* **[Firewall rules](/vm-clusters/firewall-rules)** — inbound access control for the whole cluster, managed by you.
* **InfiniBand by default** — for node-to-node communication in multi-node training. A single-node cluster doesn't use InfiniBand; that node uses all of its resources exclusively.
* **[Health checks](/vm-clusters/health-checks)** and **[Metrics](/vm-clusters/metrics)** — per-node health verdict with GPU, InfiniBand, and ECC checks, plus time-series charts for GPU and system metrics. Refreshed every minute.
* **[Reboot](/vm-clusters/reboot)** — restart a VM yourself when you need to.

## Workspace vs VM Cluster

If you only need a containerized environment for development or single-node work, a [workspace](/member/workspace/overview) is faster to start and cheaper. Choose a VM cluster when you need kernel or driver control, multi-node training with InfiniBand, or a reserved cluster. See [Workspace vs VM Cluster](/vm-clusters/vs-workspace) for a full comparison.

<Note>
  VM Clusters is an Organization-level resource, managed by **Admin** members.
</Note>

<Card title="Request a VM cluster" icon="server" href="/vm-clusters/order">
  Tell us what you need and we'll scope and provision it.
</Card>


# Reboot a node
Source: https://docs.cloud.vessl.ai/vm-clusters/reboot

When and how to reboot a node, and what happens when you reboot.

You can reboot a node yourself from the cluster detail page — useful for clearing transient GPU faults or applying driver changes.

<div>
  <Frame>
    <img alt="Node detail page header showing the node status, public and internal IP, and a Reboot button" />
  </Frame>

  <small>Example: the Reboot button on a node's detail page</small>
</div>

## What happens when you reboot

* **Cold restart only.** Because GPUs are passed through to the VM, live migration isn't possible — the VM is fully restarted.
* The VM may come back on the **same or a different physical node**.
* Reconnecting over SSH typically takes **tens of minutes**, and can run past an hour in some cases.

<Note>
  Billing continues during a reboot, because a VM cluster is a reserved contract.
</Note>

<Note>
  Keep important data on [NFS shared storage](/vm-clusters/nfs-storage). A node's boot disk can be lost if the node is relocated due to a hardware fault.
</Note>


# Compare with Workspace
Source: https://docs.cloud.vessl.ai/vm-clusters/vs-workspace

When to use a containerized workspace and when to use a dedicated VM cluster.

Both run on VESSL Cloud, but they solve different problems. A **[workspace](/member/workspace/overview)** is a containerized environment that starts in seconds. A **VM cluster** gives you dedicated VM nodes with root access and InfiniBand.

## Comparison

| | Workspace (container) | VM cluster |
| - | - | - |
| **Isolation** | Shared node, containerized | Dedicated nodes, not shared |
| **Privileges** | Container-scoped, no host or kernel access | Full root access on each VM |
| **Container privileges** | No — you're already inside a container | Yes — run any container, including `--privileged`, with full capabilities and device mounts |
| **OS and kernel** | Container image only; shared host kernel | Your OS, kernel modules, and drivers |
| **Multi-node** | Single node | Multi-node |
| **InfiniBand** | — | Default, between nodes |
| **Storage** | Optional Cluster storage or Object storage | 2 TiB boot disk per node (not durable), plus optional NFS shared storage |
| **Billing** | On-demand, per hour | Reserved contract, arranged with sales |

## When to choose a workspace

* A container already covers your workload — you don't need kernel-, driver-, or OS-level control.
* You want to start experimenting immediately for short, exploratory work.
* You prefer no commitment — pay per hour for what you actually use, when capacity happens to be available.

## When to choose a VM cluster

* You need kernel-, driver-, or OS-level control — install custom kernel modules, specific driver versions, Slurm, Kubernetes, your own orchestrator, or host-level security agents.
* You need multi-node distributed training — InfiniBand is provisioned by default for high-bandwidth, low-latency RDMA between your nodes.
* You need capacity locked in at your chosen start date and guaranteed available for the entire contract — so a project plan doesn't depend on "is a GPU free right now?"
* You want dedicated hardware — each VM owns its physical server, with no other customer sharing your GPUs, CPU, memory, or network.

## What about batch jobs?

A **[job](/member/job/overview)** is another containerized option: it runs a script to completion on a single node, non-interactively — submit a fine-tuning or evaluation run and let it finish, with no infrastructure to manage. Like a workspace, it has no root access and no multi-node InfiniBand. Choose a VM cluster when you need multi-node distributed training with InfiniBand, root- or kernel-level control, or a dedicated reserved cluster.

<Note>
  A VM cluster is billed separately from VESSL Cloud and can't be paid with VESSL Cloud credits. Your account manager handles billing.
</Note>


# Acceptable use policy
Source: https://docs.cloud.vessl.ai/legal/acceptable-use

VESSL Cloud acceptable use policy (AUP).

<Info>
  Effective date: August 6, 2026 · Last updated: August 6, 2026
</Info>

This Acceptable Use Policy ("AUP") governs your use of VESSL Cloud and related websites (the "Services") under your agreement with the applicable VESSL contracting entity ("VESSL", "we", or "us"). This AUP forms part of that agreement. By using the Services, you agree to this AUP and are responsible for your users' and end users' compliance with it.

Capitalised terms used here are defined in Section 9 or if not defined herein, in your agreement with VESSL.

## 1. Prohibited content

You must not use the Services to store, generate, host, transmit, or distribute any content that:

* is illegal, or facilitates illegal activity, under any applicable law;
* infringes intellectual-property rights or misappropriates trade secrets;
* is defamatory, harassing, threatening, or obscene;
* constitutes child sexual abuse material (CSAM) or non-consensual intimate imagery — these are strictly prohibited and reported to authorities as required by law;
* contains malware, viruses, or other malicious code; or
* violates the privacy or data-protection rights of others.

## 2. Prohibited activities

You must not:

* **Falsify identity or data** — impersonate any person or entity, or provide false registration, identity, or payment information.
* **Spam** — send unsolicited bulk or commercial messages, or violate anti-spam or marketing laws.
* **Mine without authorisation** — use the Services for cryptocurrency mining except where expressly permitted in writing by VESSL.
* **Conduct network attacks** — perform or facilitate denial-of-service or distributed denial-of-service (DoS/DDoS) attacks, flooding, or operate botnets.
* **Scan or probe** — scan, penetration-test, or probe networks or hosts you do not own or lack permission to test, including third-party systems.
* **Interfere with the platform** — disrupt or degrade the Services or other users' use of them, gain unauthorised access to any system or data, or circumvent usage limits, authentication, or security controls.
* **Reverse engineer** — hack, reverse engineer, decompile, or attempt to derive source code or non-public components of the Services, except to the extent this restriction is prohibited by law.
* **Distribute harmful software** — create, host, or distribute malware, spyware, or adware.
* **Break the law** — use the Services in violation of any applicable law, including export-control, sanctions, and anti-money-laundering laws.

## 3. AI- and compute-specific misuse

Because the Services provide computing infrastructure for AI and other workloads, developing, training, fine-tuning, and deploying AI/ML models and applications is a core, permitted use. These restrictions concern purpose, not model development itself. Accordingly, you must not use the Services to develop, train, deploy, or operate models or applications that:

* generate CSAM, non-consensual intimate imagery, or content that sexualises minors;
* enable targeted harassment, stalking, or incitement to violence;
* conduct unlawful surveillance or biometric identification in violation of applicable law;
* produce malware, exploits, or tools designed primarily to cause harm or to defeat security;
* carry out fraud, phishing, or large-scale deceptive or disinformation campaigns; or
* make automated decisions about individuals in ways prohibited by applicable law.

## 4. Your responsibility

You are responsible for all activity under your account and for your users and end-users. You must secure your credentials, and use only your designated primary system configuration and resources as provided. You must comply with any resource-use limitations communicated by VESSL, including limits applicable during trial or promotional periods. We may limit access to certain network resources (for example, gaming or cryptocurrency-related sites) where we reasonably believe their use during a trial or credit-limited period indicates misuse of the Services or of credits.

## 5. Monitoring and enforcement

5.1 **Investigation.** VESSL may investigate suspected violations of this AUP but assumes no general obligation to monitor Customer Content. An investigation may include review of Usage Data and, only where reasonably necessary for an event-driven abuse, fraud, malware, security, or AUP investigation, limited access to relevant Customer Content in accordance with the DPA. Access must be need-to-know, minimized, and logged. VESSL may create a memory dump or perform similar technical analysis only where technically necessary for an identified incident or investigation; any resulting artifact will be treated, secured, accessed, and deleted as Customer Content under the DPA. This Section does not authorize routine human review or use of Customer Content to train or update a model.

5.2 **Enforcement actions.** If we determine, in our reasonable discretion, that you have violated this AUP, we may take any of the following actions, with or without prior notice depending on the severity and the risk to VESSL, other users, or third parties:

* issue a warning and request that you remediate the violation;
* throttle, restrict, suspend, or disable access to all or part of the Services or your account;
* remove, disable, or quarantine offending content or workloads; and/or
* terminate your account or agreement.

5.3 **Immediate action.** For violations that are illegal, that threaten the security, integrity, or availability of the Services, or that risk harm to others, we may suspend access and remove or disable content **immediately and without prior notice**.

5.4 **Preservation and disclosure.** We may preserve and disclose information and content where we believe in good faith it is necessary to comply with law or valid legal process, to enforce this AUP, to detect or prevent fraud or security issues, or to protect the rights, property, or safety of VESSL, our users, or the public — including reporting illegal content to the relevant authorities.

5.5 **Cooperation and reinstatement.** You must cooperate with VESSL to investigate and remediate violations. We may, at our discretion, reinstate suspended access once a violation has been satisfactorily resolved.

5.6 **Liability.** To the maximum extent permitted by law and subject to Section 11 of the MSA, VESSL is not liable for an enforcement action taken in good faith under this Section. This Section does not limit another right or remedy available to VESSL and does not exclude or limit liability that cannot lawfully be excluded or limited.

## 6. Reporting abuse

To report a suspected violation of this AUP, abusive activity, or illegal content, contact **[trustandsafety@vessl.ai](mailto:trustandsafety@vessl.ai)** or **[privacy@vessl.ai](mailto:privacy@vessl.ai)** with relevant details (URLs/identifiers, description, and your contact information). We review reports and take appropriate action.

## 7. Changes

VESSL may update this AUP from time to time. Updates to this AUP are governed by Section 14.10 of the MSA and, for Self-Service Customers, Section A7 of Annex A.

## 8. Relationship to other terms

This AUP supplements, and does not limit, your agreement with VESSL, our [Privacy Policy](/legal/privacy), and our [Data Processing Agreement](/legal/dpa). In case of conflict regarding acceptable use, this AUP governs.

## 9. Definitions

* **Mining** — using computing resources to validate cryptocurrency transactions or to create or earn cryptocurrency or similar digital assets.
* **Spam** — unsolicited bulk or commercial electronic messages, or content distributed in violation of anti-spam or marketing laws.
* **Illegal Content** — content the creation, possession, storage, or distribution of which violates applicable law.
* **Malicious code** — software intended to damage, disable, or gain unauthorised access to systems or data (e.g., viruses, worms, ransomware, spyware).


# Container Compute service terms
Source: https://docs.cloud.vessl.ai/legal/container-compute

Service-specific terms for the VESSL Cloud Container Compute service.

<Info>
  Effective date: August 18, 2026 · Last updated: August 18, 2026
</Info>

These Container Compute Service Terms ("**Container Compute Terms**") supplement the [Master Services Agreement](/legal/msa) (the "**MSA**") and govern Customer's use of the VESSL container-based compute services, including Workspaces and Jobs (collectively, the "**Container Compute Services**"). In the event of a conflict between these Container Compute Terms and the MSA, these Container Compute Terms will prevail over the MSA to the extent of the conflict, in accordance with the order of precedence set out in MSA Section 2.2.

**Scope note:** These Container Compute Terms govern container-based compute environments (Workspaces and Jobs). Other compute and infrastructure services are governed by their own Service-Specific Terms:

* VM Cluster services (GPU virtual machines with root SSH access): [VM Cluster Service Terms](/legal/vm-cluster)
* Standalone storage services (Cluster Storage and Object Storage): [Storage Service Terms](/legal/storage)

Capitalized terms not defined here have the meanings given in the MSA.

## 1. Description of the Container Compute Services

The Container Compute Services are VESSL's managed AI infrastructure platform for container-based compute, delivering on-demand GPU and CPU Workspaces and Jobs.

VESSL orchestrates, schedules, monitors, and operates the Container Compute Services through its proprietary control plane and management software. The underlying compute capacity may be provisioned on infrastructure operated by VESSL or by an underlying infrastructure provider engaged by VESSL as a Sub-processor. A current list of Sub-processors is available in the [Sub-processor List](/legal/sub-processors).

Customer accesses the Container Compute Services through the VESSL platform (including the console, API, and/or CLI) and not by means of any direct, unmodified access to the underlying infrastructure provider's console or API. The Region(s) in which a given Container Compute Service is provisioned are determined by the Cluster selected by Customer in the VESSL platform.

VESSL offers the following Container Compute Service categories, as further described in the Documentation (see [Understand workspaces](/member/workspace/overview) and [Understand jobs](/member/job/overview)):

**Workspaces**: On-demand GPU or CPU container instances that Customer can launch, connect to, and use persistently through the VESSL platform. Workspaces provide a containerized environment; Customer does not receive root access to the host operating system or kernel.

**Jobs**: Compute jobs that Customer submits for execution on GPU or CPU resources. Jobs run to completion or until terminated by Customer, and do not provide persistent access to the instance.

## 2. Resource Provisioning

### 2.1 On-Demand Resources

Where Customer consumes resources on a pay-as-you-go basis, availability is subject to capacity. VESSL does not guarantee on-demand availability except to the extent expressly committed in the [SLA](/legal/sla).

### 2.2 Region and Data Center

Container Compute Services are provided from the Region(s) determined by the Cluster selected by Customer in the VESSL platform. VESSL may relocate workloads between data centers within the same Region for operational reasons. Migration to alternative infrastructure within the same Region or to a different Region is governed by Section 6.3.

## 3. VESSL's Obligations and Responsibilities

### 3.1 Incorporation by Reference

VESSL's obligations and responsibilities in connection with the Container Compute Services are governed by the following documents:

**Security**: MSA Section 8

**Data Processing and Privacy**: the [DPA](/legal/dpa) and [Privacy Policy](/legal/privacy)

**Security Incident Response**: the procedures set forth in the [DPA](/legal/dpa)

**Warranties and Disclaimers**: MSA Sections 9 and 10

**Limitation of Liability**: MSA Section 11

**Service Levels**: MSA Section 13 and the [SLA](/legal/sla)

### 3.2 Service-Specific Obligations

In addition to and supplementing Section 3.1, VESSL will perform the following obligations specific to the Container Compute Services:

**(a) Control Plane Operations:** VESSL will operate and maintain the control plane for orchestration, scheduling, and monitoring of Workspaces and Jobs.

**(b) Container Isolation:** VESSL will maintain reasonable technical measures to ensure network- and storage-level isolation between each Customer's container workloads.

## 4. Customer Responsibilities

### 4.1 Configuration

Customer is responsible for the configuration of its workloads, including container images, parameters, scaling policies, and security configurations on top of the base images provided by VESSL.

### 4.2 Security

Customer is responsible for (a) the access controls and policies that VESSL exposes within Customer's account on the VESSL Platform, (b) credential management for Customer's Authorized Users, (c) encryption keys (where Customer manages keys), and (d) the security of any software, configurations, or container images Customer deploys through the VESSL Platform.

### 4.3 Backup, Disaster Recovery, and Storage Durability

Customer is solely responsible for backup, snapshot, and disaster recovery of Customer Content. VESSL does not provide a numerical storage-durability commitment for the Container Compute Services. Customer should design its workloads on the assumption that storage media may fail.

### 4.4 Resource Limits

Data stored only on temporary storage may be lost in the event of a resource-limit violation. Data stored on Cluster Storage or Object Storage volumes is not affected. VESSL is not liable for data loss resulting from resource-limit violations. Customer is responsible for designing workloads to operate within allocated resource limits. Resource-limit enforcement behavior is described in the Documentation (see [Resource limits](/guides/platform/resource-limits)).

## 5. Managed Software Stack

VESSL provides a managed software stack for the Container Compute Services, as described in the [Managed software stack](/guides/platform/managed-software-stack) documentation. Third-party components included in the stack are provided under the licenses of the respective vendors. Security patching is described in the Documentation (see [Managed software stack](/guides/platform/managed-software-stack)).

## 6. Maintenance and Replacement

### 6.1 Scheduled Maintenance

VESSL conducts scheduled maintenance as described in the SLA. Customer is responsible for designing workloads to tolerate maintenance windows.

### 6.2 Hardware Replacement

VESSL may replace hardware components based on monitoring data, including detected GPU errors, storage failures, cooling system failures, or planned hardware refresh. Any migration resulting from hardware replacement is governed by Section 6.3; maintenance-related exclusions and notice are governed by the SLA.

### 6.3 Infrastructure and Region Migration

(a) **Same-Region**: If VESSL reasonably determines that continued operation on the existing infrastructure within a Region is not commercially feasible, VESSL may migrate Customer workloads to alternative infrastructure in the same Region with at least 30 days' advance notice (or such shorter period as is reasonably practicable in the circumstances) and migration support.

(b) **Cross-Region**: VESSL will provide Customer with at least 30 days' advance written notice. If Customer does not object in writing within 30 days of receipt of notice, Customer will be deemed to have consented to the migration. If Customer objects, Customer may terminate the affected Services without penalty and receive a refund for any unused prepaid Fees.

(c) **Exceptions**: This Section does not apply where migration is required to address a security incident, regulatory requirement, or Force Majeure Event.

## 7. Storage

### 7.1 Storage Types

VESSL may offer multiple storage tiers for use with the Container Compute Services. Standalone storage services (Cluster Storage and Object Storage volumes managed independently) are governed by the separate [Storage Service Terms](/legal/storage).

### 7.2 Temporary Storage

Each Workspace is allocated temporary local storage for use during the session. Temporary storage is deleted when the Workspace is paused or terminated, and cannot be recovered. Customer must store data requiring persistence on Cluster Storage or Object Storage volumes governed by the [Storage Service Terms](/legal/storage).

### 7.3 Quotas and Limits

Storage quotas and operational limits, where applicable, are displayed in the VESSL console or described in the Documentation (see [Billing overview](/admin/billing/overview)).

### 7.4 Data Retention on Termination

The applicable data-return, recovery/export, retention, and deletion period is determined by the event and transaction path under MSA Section 5.4, Annex A or the applicable private Order Form, the Storage Service Terms, and the DPA, subject to any express service-specific exception. Customer is responsible for transferring needed data within the applicable period.

### 7.5 Customer Container Images

Customer may use custom container images with the Container Compute Services, including images pulled from Customer's Git repositories or external registries (collectively, "**Customer Images**"). Customer retains ownership of Customer Images and is solely responsible for:

* the legality of any third-party software included in Customer Images;
* compliance with the licenses applicable to such software;
* the security configuration and contents of Customer Images, including patching, hardening, and removal of secrets;
* Where Customer Images contain Personal Data, establishing a lawful basis for processing and complying with all applicable data protection laws (including the Personal Information Protection Act of Korea and the EU General Data Protection Regulation); and
* downloading and deleting Customer Images upon termination, in accordance with MSA Section 5.4.

VESSL hosts Customer Images solely as part of the Container Compute Services and assumes no responsibility for their contents, including any Personal Data contained therein.

## 8. Billing and Insufficient Balance

For Self-Service, Container Compute Services are billed on a pay-as-you-go basis under Annex A, using Purchased Credits and Promotional Credits as applicable and the pricing displayed in the VESSL console. For B2B, the billing basis, Fees, payment terms, and any committed-use terms are governed by the applicable private Order Form or invoice.

Charges accrue based on the resources provisioned or consumed, including applicable GPU or CPU type, duration, and storage.

For Self-Service, VESSL may reject creation or start of a Workspace if Customer does not have sufficient Purchased Credits or Promotional Credits. If Customer's available Purchased Credits and Promotional Credits reach zero, running Workspaces will be automatically paused. Pausing immediately and irreversibly deletes temporary storage data. If Customer does not replenish the applicable balance within twenty-four (24) hours after Pause, the affected Workspaces will be automatically terminated.

VESSL may reject a new Job submission, or suspend or terminate a running Job, if Customer does not have sufficient Purchased Credits or Promotional Credits or another authorized payment method to cover the applicable charges.

If the Purchased Credits and Promotional Credits available for Self-Service Storage Services are exhausted and no other authorized payment method covers those Services, VESSL may restrict access to affected Cluster Storage and Object Storage. VESSL will retain the affected persistent storage for a fixed period of thirty (30) days and will provide notice before deletion. The thirty-day period begins when the applicable balances first become exhausted and remain insufficient to cover the Storage Services. Replenishment or authorization of another payment method before deletion cures the depletion condition and restores access subject to ordinary technical processing time. If Customer later exhausts the applicable payment coverage again, a new thirty-day period begins. After the full thirty-day period, VESSL may permanently delete the affected storage and associated Customer Content.

## 9. Acceptable Use

The [Acceptable Use Policy](/legal/acceptable-use) (AUP) applies in full to all use of the Container Compute Services.

## 10. Service Levels

The public [SLA](/legal/sla) applies automatically to eligible paid Self-Service Container Compute Services and measures availability separately for each running Workload. For a B2B Customer, the public SLA applies by default, except to the extent an applicable Custom SLA Addendum or Order Form expressly provides otherwise. Service Credits are Customer's sole monetary remedy for a failure to meet an applicable SLA metric, subject to the exceptions and no-double-recovery rule in the SLA and MSA Section 13.

## 11. Modifications

VESSL may update these Container Compute Terms only in accordance with MSA Section 14.10.

***

VESSL AI, Inc. — [legal@vessl.ai](mailto:legal@vessl.ai)


# Cookie policy
Source: https://docs.cloud.vessl.ai/legal/cookie

How VESSL AI uses cookies and similar technologies.

<Info>
  Effective date: August 6, 2026 · Last updated: August 6, 2026
</Info>

This Cookie Policy explains how VESSL AI KOREA Inc. and VESSL AI, Inc. ("**VESSL**", "we", "us") use cookies and similar technologies on the VESSL websites and the VESSL Cloud service (together, the "**Services**"). It should be read together with our [Privacy Policy](/legal/privacy), which explains how we process personal data more generally.

## 1. What are cookies?

Cookies are small text files that a website places on your device when you visit. We also use related technologies such as **pixels**, **tags**, **software development kits (SDKs)**, and **local/session storage**. In this policy we refer to all of these as "cookies".

Cookies may be **first-party** (set by VESSL) or **third-party** (set by a provider we use, such as an analytics or marketing partner). They may be **session** cookies (deleted when you close your browser) or **persistent** cookies (which remain for a set period or until you delete them).

## 2. Categories of cookies we use

We group cookies into the four categories below. The cookies and similar technologies actually in use, including their provider, category, purpose, domain or host, and duration, are identified in our [Cookie List](/legal/cookie-list) and in the cookie preference tool made available on the applicable website.

| Category | What it does | Consent |
| - | - | - |
| **Strictly necessary** | Required for the Services to work — authentication and the sign-in flow, session continuity, security (CSRF protection, bot mitigation), payment fraud prevention, in-app support, and load balancing. The Services cannot function properly without these. | Not required (set on all visits) |
| **Functional** | Remember your choices and preferences (e.g., last-used organization/team) to provide enhanced features. | Consent-based |
| **Performance** | Help us understand how the Services are used so we can measure and improve performance (e.g., Google Analytics, Amplitude, documentation-site analytics). | Consent-based |
| **Targeting** | Used to measure campaign effectiveness, including through campaign, referral, or click identifiers, and, where applicable, to deliver and attribute advertising. | Consent-based |

Where applicable law requires consent, VESSL does not set functional, performance, or targeting cookies until you have given consent through the applicable cookie banner or preference tool. Strictly necessary cookies may be used without consent where permitted because they are essential to provide, secure, or operate a service you have requested.

## 3. Legal basis

Where consent is required by applicable law — including the EU ePrivacy rules, the UK privacy and electronic communications rules, and, in the Republic of Korea, the Personal Information Protection Act (PIPA) and applicable guidance of the Personal Information Protection Commission (PIPC) on online customized (behavioral) advertising — we rely on consent for non-essential cookies and similar technologies. We use strictly necessary technologies as permitted by applicable law to provide, secure, and operate the Services. Personal data collected through these technologies is processed on the legal bases described in our Privacy Policy.

## 4. Managing your cookies

* **Cookie banner / preference centre.** Where VESSL uses non-essential cookies and consent or another choice is required by applicable law, you can accept or reject them through the banner or preference centre on the applicable website. You can later change or withdraw your choice at any time through the "Manage cookies" control on that website.
* **Global Privacy Control.** Where your browser or extension sends a recognized GPC signal, we treat it as a withdrawal of consent for non-essential cookies on that browser or device: the Functional, Performance, and Targeting categories stay off, and any earlier consent recorded for that browser is treated as withdrawn. If you afterwards turn a category on yourself, your explicit choice applies.
* **Browser settings.** Most browsers (Chrome, Edge, Safari, Firefox, Samsung Internet, Opera) let you block or delete cookies through their settings. Note that blocking all cookies may prevent parts of the Services — particularly authenticated areas of VESSL Cloud — from working.
* **Provider opt-outs.** Some third-party providers offer their own opt-outs, for example Google Analytics: [https://tools.google.com/dlpage/gaoptout](https://tools.google.com/dlpage/gaoptout). Each provider's own cookie documentation and opt-out, where one exists, is linked in the [Cookie List](/legal/cookie-list).

Withdrawing consent does not affect the lawfulness of processing carried out before withdrawal.

## 5. California and Delaware Residents

If you are a resident of California or Delaware, this section provides additional information required under the California Consumer Privacy Act ("CCPA") and the Delaware Personal Data Privacy Act.

* **Online tracking.** Through the Performance and Targeting cookies described in Section 2, third-party providers may collect personal information about your online activities over time and across different websites and online services operated by us and by other companies ("cross-context behavioral advertising"). The Functional cookies we use are set by VESSL on a single site and are not used for this purpose.
* **Sale or sharing of personal information.** We do not sell personal information for money. To the extent that VESSL's use of Targeting technologies constitutes a "sale," "sharing," or targeted-advertising processing under the CCPA or another applicable privacy law, you may opt out through the "Manage cookies" control or a recognized Global Privacy Control signal, both described in Section 4. See our Privacy Policy for further information about applicable privacy rights.
* **Interest-based advertising.** Where we engage in interest-based advertising through the Digital Advertising Alliance ("DAA") participants, you may opt out via the DAA's consumer choice page: **[https://optout.aboutads.info/](https://optout.aboutads.info/)**.

## 6. Changes to this policy

We may update this Cookie Policy from time to time. Material changes will be announced on our website, and the "last updated" date above will be revised.

## 7. Contact

Questions about this Cookie Policy or our use of cookies: **[privacy@vessl.ai](mailto:privacy@vessl.ai)**.


# Cookie list
Source: https://docs.cloud.vessl.ai/legal/cookie-list

Individual cookies and similar technologies used across VESSL websites and VESSL Cloud.

<Info>
  Effective date: August 6, 2026 · Last updated: August 6, 2026
</Info>

This page identifies the individual cookies and similar technologies used on the VESSL websites and the VESSL Cloud service. It is the Cookie List referred to in our [Cookie Policy](/legal/cookie), which defines the categories used below. Providers that process personal data on VESSL's behalf are listed in the [Sub-processor list](/legal/sub-processors).

**Scope.** `vessl.ai` (including `vessl.ai/blog`), `cloud.vessl.ai`, and `docs.cloud.vessl.ai`.

**Consent.** Only the strictly necessary technologies are used without your consent. Everything in the Functional, Performance, and Targeting categories is set only after you accept that category in our cookie banner or cookie settings, and stops being written when you withdraw that consent. See Section 8.

**Sharing across sites.** Most cookies below are set on the parent domain `.vessl.ai`, so the same cookie is readable on all three sites and a single consent choice applies to all of them. Cookies whose host is shown without a leading dot are scoped to that one site.

## 1. Strictly necessary

| Cookie | Set by | Host | Purpose | Duration |
| - | - | - | - | - |
| `vessl_cookie_consent` | VESSL (first party) | `.vessl.ai` | Stores your cookie choices — which categories you accepted, when, and the version of the notice you saw — so that we can honour them and not ask again on every page or site | 6 months |
| `cloud_access_token` | VESSL (first party) | `.vessl.ai` | Authenticated access token for VESSL Cloud | 24 hours |
| `cloud_refresh_token` | VESSL (first party) | `.vessl.ai` | Re-issues the access token so your session continues | 7 days |
| `g_state` | Google | `cloud.vessl.ai` | Records that you dismissed the Google sign-in prompt, so it is not shown again for a period. Set by Google Identity Services, which VESSL uses for Google sign-in | 180 days |
| `__stripe_mid` | Stripe | `.cloud.vessl.ai` | Fraud prevention: identifies the device across payment attempts. Set when a payment form loads in VESSL Cloud | 1 year |
| `__stripe_sid` | Stripe | `.cloud.vessl.ai` | Fraud prevention: identifies the current payment session while a payment form is open | 30 minutes |

Signing in with Google also causes Google to set its own account and security cookies on `accounts.google.com` and other Google domains. Those cookies are set by Google as an independent controller of your Google account, not by VESSL, and are governed by the [Google Privacy Policy](https://policies.google.com/privacy).

The in-app support chat (Pylon) is also treated as strictly necessary: it is a support channel you have asked us to provide when signed in. It sets no cookie; its browser-storage keys are listed in Section 6.

## 2. Functional

| Cookie | Set by | Host | Purpose | Duration |
| - | - | - | - | - |
| `cloud_last_org_v1` | VESSL (first party) | `cloud.vessl.ai` | Remembers the organization you last used, so you land in it on your next visit | 1 year |
| `cloud_last_team_v1` | VESSL (first party) | `cloud.vessl.ai` | Remembers the team you last used within an organization | 1 year |

## 3. Performance

| Cookie | Set by | Host | Purpose | Duration |
| - | - | - | - | - |
| `_ga` | Google Analytics | `.vessl.ai` | Distinguishes unique visitors across all three sites | Up to 400 days |
| `_ga_8LSM3LEDEX` | Google Analytics | `.vessl.ai` | Holds analytics session state for `vessl.ai` and `cloud.vessl.ai` | Up to 400 days |
| `_ga_N7NDLW2PZK` | Google Analytics | `.vessl.ai` | Holds analytics session state for `docs.cloud.vessl.ai` | Up to 400 days |
| `AMP_be333f40b6` | Amplitude | `.vessl.ai` | Product-usage analytics device and session identifier for `vessl.ai` | 1 year |
| `AMP_19a4a4040f` | Amplitude | `.vessl.ai` | Product-usage analytics device and session identifier for `cloud.vessl.ai` | 1 year |
| `AMP_8ae1e9c618` | Amplitude | `.vessl.ai` | Product-usage analytics device and session identifier for `docs.cloud.vessl.ai` | 1 year |

## 4. Targeting

| Cookie | Set by | Host | Purpose | Duration |
| - | - | - | - | - |
| `__hstc` | HubSpot | `.vessl.ai` | Main HubSpot visitor-tracking cookie: domain, first visit, last visit, and session count | 6 months |
| `hubspotutk` | HubSpot | `.vessl.ai` | Visitor identifier that links form submissions to a HubSpot contact | 6 months |
| `__hssc` | HubSpot | `.vessl.ai` | Tracks the current session and page views within it | 30 minutes |
| `__hssrc` | HubSpot | `.vessl.ai` | Detects whether the browser was restarted, to decide whether to start a new session | Session |
| `_gcl_au` | Google Ads | `.vessl.ai` | Conversion linker: attributes ad clicks to conversions | 90 days |
| `_gcl_aw` | Google Ads | `.vessl.ai` | Stores the Google Ads click identifier when you arrive from a Google ad, so a later sign-up can be attributed to it | 90 days |
| `_gcl_gs` | Google Ads | `.vessl.ai` | Stores the Google Ads click session identifier that accompanies `_gcl_aw` | 90 days |
| `AMP_MKTG_19a4a4040f` | Amplitude | `.vessl.ai` | Stores the campaign or referrer that brought you to `cloud.vessl.ai`, for attribution | 1 year |
| `AMP_MKTG_8ae1e9c618` | Amplitude | `.vessl.ai` | Stores the campaign or referrer that brought you to `docs.cloud.vessl.ai`, for attribution | 1 year |
| `vessl-utm-params` | VESSL (first party) | `cloud.vessl.ai` | Campaign parameters captured from the URL, held until sign-up so the sign-up can be attributed, then deleted | 30 days |
| `vessl-ref` | VESSL (first party) | `cloud.vessl.ai` | Carries the referral parameter into the browser; moved to session storage for the current tab and then deleted | Session |

## 5. Cookies set on providers' own domains

The technologies below run on VESSL sites but write their cookies to the provider's own domain, so they are not visible under `vessl.ai`. They follow the same consent categories as the sections above.

| Cookie | Set by | Host | Category | Purpose | Duration |
| - | - | - | - | - | - |
| `ajs_anonymous_id` | Arcade | `demo.arcade.software` | Performance | Anonymous visitor identifier for the interactive product demos embedded in the documentation | 1 year |
| `bcookie` | LinkedIn | `.linkedin.com` | Targeting | Browser identifier used by the LinkedIn Insight Tag | 1 year |
| `bscookie` | LinkedIn | `.www.linkedin.com` | Targeting | Secure browser identifier used for authenticated LinkedIn actions | 1 year |
| `lidc` | LinkedIn | `.linkedin.com` | Targeting | Routes requests to the right LinkedIn data centre | 24 hours |
| `li_sugr` | LinkedIn | `.linkedin.com` | Targeting | Probabilistic browser identifier used for audience matching | 90 days |
| `UserMatchHistory` | LinkedIn | `.linkedin.com` | Targeting | Synchronizes the LinkedIn Ads identifier | 30 days |
| `AnalyticsSyncHistory` | LinkedIn | `.linkedin.com` | Targeting | Records when the visitor was synchronized with LinkedIn's analytics service | 30 days |
| `GCL_AW_P` | Google Ads | `.doubleclick.net`, `.google.com`, `.googleadservices.com` | Targeting | Stores the ad click identifier on Google's own domains when you arrive from a Google ad, so a later conversion can be matched to it | 90 days |
| `test_cookie` | Google (DoubleClick) | `.doubleclick.net` | Targeting | Checks whether the browser accepts cookies before ad tags are served | 15 minutes |
| `__cf_bm` | HubSpot, LinkedIn | `.hubspot.com`, `.hs-scripts.com`, `.hs-analytics.net`, `.hs-banner.com`, `.hsforms.com`, `.hsforms.net`, `.linkedin.com` | Strictly necessary | Bot management for those providers' own script and form endpoints. Set by Cloudflare on their behalf, not by VESSL — see Section 7 | 30 minutes |

## 6. Local and session storage

The Cookie Policy also covers browser storage. The keys below are written to `localStorage` or `sessionStorage`; they are not transmitted with HTTP requests and are removed when you clear site data. They follow the same consent categories as the cookies above. The first-party interface-state keys below are implementation details and their names may change between releases.

| Key | Storage | Set by | Category | Purpose |
| - | - | - | - | - |
| `vessl:*`, `signout-time` | `localStorage` | VESSL | Strictly necessary | Interface state such as dismissed banners and the last page you were on, and notifying other open tabs that you have signed out |
| `pylon-preferred-locale`, `pylon-theme` | `localStorage` | Pylon | Strictly necessary | Language and appearance preference for the in-app support chat |
| `pusherTransportTLS` | `localStorage` | Pylon | Strictly necessary | Remembers which real-time connection method worked, so the support chat reconnects faster |
| `mintlify_anonymous_id`, `mintlify_session_id` | `localStorage`, `sessionStorage` | Mintlify | Performance | Documentation-site visitor and session identifiers |
| `AMP_unsent_*`, `AMP_remote_config_*`, `AMP_URL_INFO` | `localStorage`, `sessionStorage` | Amplitude | Performance | Queue of analytics events not yet sent, SDK configuration, and landing-page URL |
| `_gcl_ls` | `localStorage` | Google Ads | Targeting | Conversion-linker data, used where cookies are unavailable |
| `li_adsId` | `localStorage` | LinkedIn | Targeting | Advertising identifier used by the LinkedIn Insight Tag |
| `vessl-ref` | `sessionStorage` | VESSL | Targeting | Referral parameter for the current tab, moved here from the `vessl-ref` cookie |

## 7. Notes on providers

**Cloudflare. No Cloudflare cookie is set on any `vessl.ai` domain. The `__cf_bm` cookies in Section 5 are set on HubSpot's and LinkedIn's own domains by those providers' bot protection. Our hosting providers serve some of our sites through Cloudflare’s network, which sets no cookie on our domains.**

**Pylon.** The in-app support chat loads only for signed-in users of VESSL Cloud. It sets no cookie; it writes the browser-storage keys listed in Section 6 and holds the chat conversation inside its own widget on `widget.usepylon.com`.

**Arcade.** Some documentation pages embed an interactive product demo provided by Arcade. The demo runs from `demo.arcade.software` and sets its own anonymous visitor identifier there; it loads only on the pages that contain a demo.

**Stripe.** The two `__stripe_*` cookies in Section 1 are set on `cloud.vessl.ai` by Stripe's payment library when a payment form loads, and are used for fraud prevention. Where a payment is completed on Stripe's own hosted checkout pages, any further cookies are set by Stripe on Stripe's domains and are governed by the [Stripe Privacy Policy](https://stripe.com/privacy).

### 7.1 Provider cookie documentation

Each provider publishes its own description of the cookies it sets, and some offer their own opt-out. Those pages are maintained by the provider, not by VESSL.

| Provider | Documentation |
| - | - |
| Google (Analytics, Ads, DoubleClick) | [Advertising cookies](https://business.safety.google/adscookies/) · [How Google uses cookies](https://policies.google.com/technologies/cookies) · [Analytics opt-out](https://tools.google.com/dlpage/gaoptout) |
| HubSpot | [Cookies HubSpot sets in a visitor's browser](https://knowledge.hubspot.com/privacy-and-consent/what-cookies-does-hubspot-set-in-a-visitor-s-browser) |
| LinkedIn | [LinkedIn cookie table](https://www.linkedin.com/legal/l/cookie-table) |
| Amplitude | [Privacy](https://amplitude.com/privacy) |
| Arcade | [Privacy](https://www.arcade.software/privacy) |
| Stripe | [Cookie policy](https://stripe.com/cookies-policy/legal) |
| Pylon | [Privacy](https://www.usepylon.com/privacy) |
| Mintlify | [Privacy](https://www.mintlify.com/legal/privacy) |
| Cloudflare | [Cloudflare cookies](https://developers.cloudflare.com/fundamentals/reference/policies-compliances/cloudflare-cookies/) |

## 8. Managing your choices

* **Cookie banner.** On your first visit you can choose **Accept all**, **Essential only**, or **Settings**. Nothing outside Section 1 is set until you choose.
* **Cookie settings.** The **Settings** view lets you accept or reject Functional, Performance, and Targeting individually. Strictly necessary technologies cannot be switched off.
* **Manage cookies.** You can reopen the settings at any time from the **Manage cookies** link on each site, and withdraw a consent you gave earlier. When you withdraw consent we stop setting cookies in that category and delete the ones we can reach from the browser.
* **Re-asking.** Your choices are remembered for 6 months, after which we ask again. We also ask again if we materially change the categories or this notice.
* **Global Privacy Control.** If your browser sends a recognized GPC signal, we treat it as an opt-out and leave the optional categories off unless you turn them on yourself.
* **Browser settings and provider opt-outs.** See [Cookie Policy, Section 4](/legal/cookie#4-managing-your-cookies).

## 9. Change log

| Date | Change |
| - | - |
| 2026-08-06 | Initial publication. |

***

Questions about this list: **[privacy@vessl.ai](mailto:privacy@vessl.ai)**.


# Data processing agreement
Source: https://docs.cloud.vessl.ai/legal/dpa

VESSL Cloud data processing agreement (DPA).

<Info>
  Effective date: August 6, 2026 · Last updated: August 6, 2026
</Info>

This Data Processing Agreement ("DPA") forms part of the Master Services Agreement (the "Agreement") between Customer ("Customer") and the VESSL entity that is the contracting party under the Agreement ("VESSL"). Under this DPA, Customer acts as a controller or processor, as applicable, and VESSL acts as a processor or sub-processor, as applicable. If Customer registers for or uses the Services without executing an Order Form, VESSL AI, Inc., a Delaware corporation ("VESSL US"), is the contracting party. If Customer executes an Order Form, the VESSL entity identified in that Order Form is the contracting party. Capitalised terms not defined here have the meaning given in the Agreement. Where there is a conflict, this DPA prevails over the Agreement with respect to the processing of Customer Personal Data; the Standard Contractual Clauses set out at Annex 2 prevail over the body of this DPA for transfers they cover.

## 1. Definitions

* **Applicable Data Protection Laws** — all laws applicable to the processing of personal data under the Agreement, including Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 ("**GDPR**"), the GDPR as incorporated into UK national law and supplemented by the UK Data Protection Act 2018 ("**UK GDPR**"), the Republic of Korea *Personal Information Protection Act* ("**PIPA**"), the California Consumer Privacy Act and California Privacy Rights Act ("**CCPA/CPRA**").
* **Customer Personal Data** — personal data contained in Customer Content or in Outputs, in each case to the extent processed by VESSL on the Customer's behalf in providing the Services. For the avoidance of doubt, personal data appearing in Outputs that VESSL processes is treated as Customer Personal Data for the purposes of this DPA, even where the underlying defined term "Customer Content" in the Agreement does not, on its own, include Outputs.
* **controller, data subject, personal data, personal data breach, processing, processor** — as defined in the GDPR (or, where the GDPR does not apply, the equivalent terms under Applicable Data Protection Laws).
* **Service Provider, Business, Sale/Sell, Share, Sensitive Personal Information** — as defined under the CCPA/CPRA where applicable.
* **Sub-processors** — means the sub-processors engaged by VESSL to process Customer Personal Data in connection with the Services, as listed in the [Sub-processor List](/legal/sub-processors).

Other capitalised terms have the meaning given in the Agreement.

## 2. Roles and scope

2.1 **VESSL's role.** As part of providing the Services, VESSL processes Customer Personal Data as a processor where Customer is a controller and as a sub-processor where Customer is a processor on behalf of another controller. VESSL will process Customer Personal Data only to provide, operate, support, and secure the Services and only on Customer's documented instructions. The Agreement, this DPA, the applicable Service-Specific Terms, and a support request or other instruction submitted by an authorized Customer representative constitute documented instructions only within their express scope. A support request does not authorize access to or alteration of Customer Personal Data beyond the purpose, systems, data types, permitted actions, and duration recorded for that request.

2.2 The subject matter, duration, nature, and purpose of the processing, the types of personal data, and the categories of data subjects are described in Annex 1.

2.3 **Customer responsibilities.** Customer warrants that it has a lawful basis and all necessary notices, consents, rights, and authority for the processing it instructs VESSL to perform, and that its instructions comply with Applicable Data Protection Laws. If Customer acts as a processor, Customer also warrants that the relevant controller has authorized Customer to appoint VESSL and the Sub-processors and to give the documented instructions reflected in this DPA. Customer is responsible for the accuracy and legality of Customer Content and for ensuring that a person who submits a support instruction or authorizes access to, or alteration of, Customer Personal Data has authority to do so on Customer's behalf.

2.4 **Notices to Customer.** If VESSL believes an instruction infringes Applicable Data Protection Laws, VESSL will inform the Customer (without obligation to provide legal advice) and may suspend processing of the affected Customer Personal Data without liability, to the extent reasonably necessary to avoid VESSL's own non-compliance. VESSL will, to the extent legally permitted, inform Customer if VESSL receives a legally binding request for disclosure of Customer Personal Data by a law enforcement authority.

## 3. Customer Content — restrictions on use and limited access

3.1 **Restrictions on use for VESSL's own purposes.** VESSL will not access, read, use, analyse, mine, disclose, or otherwise process Customer Content for VESSL's own purposes. VESSL will process Customer Content solely to provide, operate, support, and secure the Services on Customer's documented instructions. VESSL will not use Customer Content, Inputs, or Outputs to train, fine-tune, or update any machine learning or artificial-intelligence model, whether internal or externally available, unless Customer affirmatively opts in in writing. Applying an existing automated security, malware, fraud, or AUP-enforcement tool does not authorize training or updating that tool or another model with Customer Content.

3.2 **Limited access.** VESSL may access Customer Content only to the minimum extent necessary and only where: (a) automated processing or limited operational access is required to provide or operate the Services in accordance with Customer's documented instructions; (b) an authorized Customer representative requests or authorizes support or troubleshooting, provided that access to substantive Customer Content remains within the purpose and data scope recorded in the support request; (c) access is required by applicable law or valid legal process, subject to Section 2.4 where applicable; or (d) access is reasonably necessary to detect, investigate, prevent, or respond to abuse, fraud, malware, a security incident, or a suspected AUP violation.

3.3 **Data-changing and destructive support actions.** Except where Section 3.2(c) or the emergency exception below applies, VESSL will not delete, move, overwrite, modify, restore, reorganize, or execute a command reasonably expected to alter Customer Content in connection with support unless an authorized Customer account owner, administrator, or designated support contact gives action-specific authorization after VESSL describes the intended action and reasonably foreseeable data impact. A general request to "fix," "resolve," or "clean up" an issue is not by itself authorization to delete or materially alter Customer Content. Where practicable, VESSL will allow Customer to perform the remediation.

If action is reasonably necessary to prevent or contain imminent material harm to the Services, other customers, or data, VESSL may take the least intrusive action reasonably available without prior Customer authorization. VESSL will require internal escalation where practicable, record the reason, scope, actor, time, and action, and notify Customer afterward unless legally prohibited or notice would materially impair the response. VESSL will prefer suspension or isolation over deletion where it adequately contains the risk.

3.4 **No routine human monitoring.** VESSL will not monitor or review the substantive content of Customer Content on a routine human basis. Human access under Sections 3.2 and 3.3 must be exceptional or Customer-directed, limited to personnel with a need to know, protected by confidentiality obligations, minimized to the approved purpose, time-limited where practicable, and linked to an access and action log.

3.5 **Diagnostic artifacts.** VESSL may create a memory dump, diagnostic bundle, screenshot, or exported copy containing Customer Content only where technically necessary for an identified support case, incident, or investigation and permitted under Sections 3.2 or 3.3. VESSL will treat each artifact as Customer Content and Customer Personal Data, restrict and log access, store it securely, and delete it promptly after the documented purpose is complete unless applicable law requires preservation.

## 4. Confidentiality

VESSL will ensure that personnel authorised to process Customer Personal Data are bound by confidentiality obligations (contractual or statutory). Access to Customer Personal Data is limited to personnel who need it to provide the Services.

## 5. Security

VESSL will implement and maintain an information security program incorporating physical, technical and organisational measures commensurate with the nature and risks of processing the Customer Personal Data including protection against unauthorised or unlawful processing of Customer Personal Data and against accidental loss, destruction and damage. Such physical, technical and organisational measures will at a minimum include those described in Annex 3. VESSL may update these measures from time to time, provided the overall level of security is not materially reduced.

## 6. Sub-processors

6.1 The Customer hereby provides general authorisation for VESSL to engage the Sub-processors listed in the **Sub-processor List** (Annex 4) (as amended from time to time) to process Customer Personal Data in connection with the Services.

6.2 VESSL will impose data-protection obligations on each Sub-processor that are no less protective than those in this DPA. VESSL remains liable for its Sub-processors' acts and omissions to the same extent VESSL would be liable if performing the services of each Sub-processor directly under the terms of this DPA.

6.3 **Notice and objection.** VESSL may add or replace a Sub-processor by giving Customer at least thirty (30) days' prior written notice. Customer may object by written notice to [privacy@vessl.ai](mailto:privacy@vessl.ai) within fifteen (15) days after VESSL's notice, but only on reasonable and documented grounds relating to the protection of Customer Personal Data. VESSL will provide information reasonably necessary to evaluate the objection, and the parties will work in good faith to resolve it. If VESSL cannot reasonably avoid using the proposed Sub-processor for the affected Service or provide a commercially reasonable alternative without material burden or cost, either party may terminate only the affected Service before the proposed Sub-processor begins processing Customer Personal Data. On such termination, VESSL will refund any unused pre-paid Fees specifically paid for the terminated affected Service. Purchased Credits remaining in Customer's account remain subject to Annex A and are not refundable except as required by applicable law. Customer's failure to object within the fifteen-day period constitutes acceptance of the proposed change.

## 7. Data subject requests

VESSL will, to the extent legally permitted, inform Customer if VESSL receives a request to exercise data subject rights pursuant to Applicable Data Protection Laws ("**Data Subject Request**") in respect of any Customer Personal Data. Taking into account the nature of the processing, VESSL will provide reasonable assistance to the Customer, at Customer's cost, by appropriate technical and organisational measures, insofar as possible, to respond to Data Subject Requests. If VESSL receives a request directly from a data subject regarding Customer Personal Data, it will not respond on the merits but will, where permitted, redirect the data subject to the Customer and notify the Customer without undue delay.

## 8. Personal Data Breach

VESSL will notify the Customer without undue delay after becoming aware of a personal data breach affecting Customer Personal Data. VESSL will provide reasonable assistance to Customer, at Customer's cost, to help Customer comply with its obligations under Applicable Data Protection Laws in respect of such personal data breach.

## 9. Assistance to Customer

VESSL will (i) where legally required, and at Customer's cost, provide reasonable assistance to Customer as necessary for Customer to meet its obligations under Applicable Data Protection Laws including, where appropriate, the preparation of data protection impact assessments or similar assessments with respect to VESSL's processing of Customer Personal Data, and (ii) on Customer's reasonable written request, and at Customer's cost, provide the information reasonably necessary for Customer to conduct a Transfer Impact Assessment under EDPB Recommendations 01/2020 (or equivalent), provided that such information will be VESSL's Confidential Information.

## 10. International transfers

10.1 **Region-based processing.** For Self-Service, VESSL processes Customer Personal Data in the region or regions selected by Customer through the VESSL console or the applicable Services configuration. For B2B, VESSL processes Customer Personal Data in the region or regions selected in the applicable Order Form or the applicable Services configuration. Backup, disaster-recovery, support-engineer access, billing, and operational metadata may be processed in other regions as set out in the Documentation or the applicable Order Form. VESSL may transfer Customer Personal Data outside the selected region or regions as necessary to (a) provide the Services as instructed by Customer, (b) provide global support functions and operational continuity, (c) comply with applicable law, or (d) respond to a security incident.

10.2 **EEA.** Where processing involves transfers of Customer Personal Data subject to the GDPR to a country without an adequacy decision, the SCCs are incorporated by reference and apply with the elections in Annex 2: Module Two applies where Customer is a controller, and Module Three applies where Customer is a processor. For transfers from any other jurisdiction with transfer restrictions not otherwise addressed in this Section 10, the parties cooperate in good faith as set out in Section 10.5.

10.3 **UK.** Where processing involves transfers of Customer Personal Data subject to the UK GDPR to a country without an adequacy decision, the UK Addendum to the SCCs, incorporated herein at Schedule 1, applies.

10.4 **Republic of Korea.** Where processing involves overseas transfers from the Republic of Korea, VESSL will provide the information required under **PIPA Article 28-8** and assist the Customer in obtaining consent or otherwise relying on a lawful ground for the transfer. VESSL maintains internal procedures sufficient to fulfil this Section 10.4 and provides the Customer with reasonable documentation of those procedures on written request.

10.5 **Other jurisdictions.** For other jurisdictions imposing transfer restrictions, the parties will cooperate in good faith to implement appropriate safeguards.

## 11. Audit

VESSL will, upon Customer's reasonable request, provide to Customer third-party audit reports and certifications relating to VESSL's compliance with this DPA. If, after reviewing such reports and/or certifications, the Customer reasonably requests a further audit, the parties will discuss in good faith the scope, timing, and conditions of any audit. Any audit agreed under this DPA must be: (i) conducted no more than once per year (except where a competent supervisory authority requires), (ii) with at least 60 days' prior written notice (or shorter where an authority directly requires), (iii) during normal business hours, (iv) conducted in a manner that is minimally disruptive to VESSL's operations, (v) subject to an appropriate confidentiality agreement between the parties, and (vi) at Customer's sole cost and expense.

## 12. Return and deletion

12.1 **Return or deletion.** Subject to Sections 12.2 and 12.3, on termination or expiry of the Agreement, VESSL will return or delete Customer Personal Data in accordance with Customer's documented choice or the lifecycle selected by Customer under the applicable Annex or Order Form, unless applicable law requires retention.

12.2 **Recovery/export period.** For a voluntary Self-Service account termination, ordinary account, credential, workload, and console access ends immediately. For fourteen (14) days after termination, Customer may request controlled account recovery or export of eligible Customer Content through the process stated in Annex A and the Support Policy. VESSL is not required to restore billable workloads or ordinary account access solely to provide an export. A B2B Customer may receive a different period expressly stated in its private Order Form, including up to ninety (90) days.

12.3 **Deletion and limited retention.** At the end of the applicable period, VESSL will delete or de-identify Customer Personal Data from active systems, except that: (a) data belonging to an organization with another authorized member is not deleted solely because one user withdraws; (b) temporary or ephemeral data may be deleted earlier under an applicable Service-Specific Term; (c) separately managed storage remains subject to its expressly stated lifecycle; and (d) limited data in backups, security or audit records, transaction records, or a legal hold may be retained only for so long as required by applicable law or a documented retention schedule made available to Customer. Data retained under clause (d) remains protected under this DPA, is unavailable for ordinary use, and will be deleted or de-identified when the applicable requirement or schedule expires.

## 13. CCPA / CPRA and US state-law commitments

13.1 **CCPA/CPRA.** Where the Customer is a "**Business**" (or a service provider acting for a Business) under the CCPA/CPRA, VESSL acts as a "**Service Provider**" for Customer Personal Data and will comply with the following additional provisions:

* No sale, share, or unauthorised use. VESSL will not "Sell" or "Share" Customer Personal Data, and will not retain, use, or disclose it for any purpose other than the business purposes in the Agreement and this DPA, or outside the direct business relationship with Customer. VESSL will not combine it with personal information from other sources except as permitted under CCPA §1798.140(ag)(1)(D).
* Same level of protection. VESSL will provide the same level of privacy protection as the CCPA/CPRA requires of a Business.
* Notice on inability to comply. VESSL will notify the Customer if it determines it can no longer meet its CCPA/CPRA obligations; the Customer may then take reasonable steps to stop and remediate unauthorised use, including suspending the relevant processing of Customer Personal Data.
* Sub-processors. VESSL will flow down commitments substantially similar to this Section to any Sub-processor.

13.2 **Other US states.** Where a comparable comprehensive US state privacy law applies, VESSL acts in its equivalent processor capacity under that law as mutually agreed by the parties, and will be subject to the other provisions of this DPA.

## 14. General

14.1 Each party's liability under this DPA is subject to the limitations and exclusions of liability in the Agreement.

14.2 This DPA is governed by the governing law and forum specified in Section 14.1 of the Agreement, except that the SCCs are governed by the law and subject to the forum they specify.

14.3 If any provision is held invalid, the remainder continues in effect.

14.4 Subject to Section 6.3, VESSL may update this DPA from time to time in accordance with Section 14.10 of the Agreement.

## 15. Term and termination

This DPA is effective from execution of the Agreement ("**Effective Date**") and remains in effect for as long as VESSL processes Customer Personal Data. Obligations relating to confidentiality and return/deletion survive termination.

## Annex 1 — Details of processing

### A. List of parties

**Data exporter (Customer — controller or processor, as applicable):** for Self-Service, the individual or organization identified as Customer under the Agreement and in VESSL's account and console records, with the contact details associated with that account; for B2B, the entity identified as Customer in the applicable Order Form, with its contact details, contact role, and signature, if any, as set out in that Order Form.

**Data importer (VESSL — processor or sub-processor, as applicable): The identity of the data importer depends on which VESSL entity is party to the Agreement. (a) If the contracting entity is VESSL Korea, the data importer is VESSL Korea. (b) If the contracting entity is VESSL US, the data importer is VESSL US.**

| Field | Detail |
| - | - |
| Entity | VESSL AI KOREA Inc. (주식회사 베슬에이아이코리아) or VESSL AI, Inc. |
| Address | 13F, 7 Teheran-ro 5-gil, Gangnam-gu, Seoul, Republic of Korea, 06134 or 535 Mission Street, Ste 1550, San Francisco, CA 94105 |
| **Contact (operations)** | [privacy@vessl.ai](mailto:privacy@vessl.ai) |
| **Contact (Privacy Officer)** | Jihwan Chun, [privacy@vessl.ai](mailto:privacy@vessl.ai) |
| **UK & EEA Representative (GDPR Art 27)** | EU: European Data Protection Office (EDPO), Avenue Huart Hamoir 71, 1030 Brussels, Belgium. UK: EDPO UK Ltd, Unit 33, Waterside, Schooner Court, 44-48 Wharf Road, London, N1 7UX, United Kingdom. See [Privacy Policy](/legal/privacy) §10 |
| **Activities relevant to the transfer** | Provision of the Services as described below |
| **Role** | Processor or sub-processor, as applicable. |

### B. Description of processing

| Item | Detail |
| - | - |
| **Subject matter** | Provision of the VESSL Cloud service (GPU/CPU compute, storage, and inference) |
| **Duration & retention** | For the term of the Agreement plus the deletion timelines in Section 12 of this DPA |
| **Nature & purpose** | Hosting, storing, transmitting, computing, and otherwise processing Customer Content to operate workloads and provide the Services; operating the platform, monitoring performance, ensuring security and integrity, and providing support |
| **Frequency** | Continuous, for the duration of the subscription term |
| **Categories of data subjects** | As determined by the Customer (e.g., the Customer's employees, contractors, authorised users, customers, prospects, end users, and other individuals whose data is in Customer Content) |
| **Categories of personal data** | As determined by the Customer and contained in Customer Content or Outputs — e.g., identifiers (name, email, account/device ID, IP), contact information, authentication and access logs, and application content submitted by the Customer |
| **Special-category and other restricted data** | Customer must not submit the categories of Restricted Data prohibited by MSA Section 3.8 unless VESSL expressly agrees in writing. If VESSL agrees, the parties will document any additional safeguards required for that processing. |

### C. Competent supervisory authority

The supervisory authority determined under Clause 13 of the SCCs based on the data exporter's circumstances.

## Annex 2 — Standard Contractual Clauses

The EU SCCs (Decision (EU) 2021/914) are incorporated as follows:

* **Module selection:** Module Two (controller-to-processor) where Customer is a controller; Module Three (processor-to-processor) where Customer is a processor.
* **Clause 7 (docking):** applies.
* **Clause 9 (sub-processors):** Option 2 (general written authorisation); minimum notice period 30 days (Section 6.3).
* **Clause 11 (redress):** the optional independent-dispute-resolution body does not apply.
* **Clause 13 (competent supervisory authority)**: the competent supervisory authority is determined in accordance with Clause 13 and Annex 1, Part C.
* **Clause 17 (governing law) & 18 (forum):** the law and courts of **Ireland**.
* **Annex I.A/B/C, II, III of the SCCs:** completed by reference to Annex 1, Annex 3, and the Sub-processor List of this DPA.

## Annex 3 — Technical and organisational measures

VESSL maintains the following measures, which VESSL may update provided the level of security is not materially reduced:

* **Information security program** — documented policies and procedures aligned with industry standards (e.g., ISO/IEC 27001, SOC 2 criteria).
* **Access control & key management** — role-based, least-privilege access; SSO with mandatory multi-factor authentication for personnel; periodic access reviews and prompt revocation on role change; dedicated key-management services (HSM-backed where supported) with documented rotation, separation of duties, and least-privilege key access.
* **Encryption** — encryption in transit (TLS 1.3 by default; TLS 1.2 for legacy clients pending deprecation) and at rest (AES-256 or equivalent); passwords stored as one-way hashes; user secrets encrypted.
* **Network & endpoint security** — network segmentation, firewalls, intrusion detection/prevention, and DDoS protection at VESSL-controlled edge layers (additional protections at the underlying infrastructure layer depend on the relevant sub-processor's certifications); hardened images, patch management, and endpoint protection on personnel devices; automatic masking of sensitive fields (passwords, tokens, keys, secrets) in logs.
* **Logging, monitoring & log retention** — centralised logging, anomaly detection, SIEM, and security operations; security/audit logs retained for a period appropriate to risk (typically 12 months for security/audit logs and 90 days for operational telemetry), with integrity controls against unauthorised modification or deletion.
* **Vulnerability management & audit** — periodic vulnerability scanning, penetration testing, secure SDLC, dependency management; periodic third-party audits (e.g., SOC 2 Type II, ISO/IEC 27001/27017/27018/27701) and an internal audit program.
* **Personnel security** — background checks (where permitted), confidentiality obligations, and periodic security and privacy training.
* **Physical security** — Services provisioned on data centres operated by sub-processors with industry-recognised certifications (e.g., ISO 27001, SOC 2), each onboarded under VESSL's vendor-risk management program; controlled office access.
* **Incident response** — documented incident-response plan, on-call rotation, post-incident review, and breach-notification procedures (Section 8).
* **Business continuity & disaster recovery** — backup, restoration, and failover procedures; multi-availability-zone backups.
* **Data segregation** — logical separation of Customer Personal Data between tenants.
* **Data minimisation** — practices designed to limit processing to what is necessary to provide the Services and honour Customer instructions.
* **Secure disposal** — media sanitisation per industry standards (e.g., NIST SP 800-88) before reuse or disposal, and secure destruction of decommissioned media managed by VESSL or its sub-processors.
* **Support and diagnostic access** — named support roles; individual non-shared administrator accounts; strong authentication; least-privilege and, where practicable, just-in-time or time-limited elevation; ticket-linked Customer authorization; access and action logging; separate confirmation for destructive actions; secure handling and prompt deletion of diagnostic artifacts; periodic access review; and training for Support and Engineering personnel.

## Annex 4 — Sub-processors

The current list of sub-processors is maintained at the [Sub-processor List](/legal/sub-processors) and forms part of this DPA.

**SCHEDULE 1 — UK ADDENDUM TO SCCS**

## Part 1: Tables

### Table 1: Parties

| **Start date** | The Effective Date | |
| - | - | - |
| **The Parties** | **Exporter (who sends the Restricted Transfer)** | **Importer (who receives the Restricted Transfer)** |
| **Parties' details** | Full legal name: for Self-Service, the individual or organization identified as Customer under the Agreement and in VESSL's account and console records; for B2B, the Customer's full legal name stated in the applicable Order Form. Trading name (if different): as stated in the applicable account and console records or Order Form. Main address: as stated in the applicable account and console records or Order Form. Official registration number (if any): as stated in the applicable account and console records or Order Form. | Full legal name: VESSL AI KOREA Inc. or VESSL AI, Inc. (as applicable). Main address: VESSL AI KOREA Inc.: 13F, 7 Teheran-ro 5-gil, Gangnam-gu, Seoul, Republic of Korea, 06134. VESSL AI, Inc.: 535 Mission Street, Ste 1550, San Francisco, CA 94105. Official registration number: VESSL AI KOREA Inc.: 110111-7470761. VESSL AI, Inc.: 6123225. |
| **Key Contact** | Full name (optional), job title, and contact email: as stated in the applicable account and console records for Self-Service or in the applicable Order Form for B2B. | Full name: Jihwan Chun. Job title: Chief Privacy Officer. Contact email: [privacy@vessl.ai](mailto:privacy@vessl.ai). |
| **Signature (if required for the purposes of Section 2)** | N/A | N/A |

### Table 2: Selected SCCs, Modules and Selected Clauses

**Addendum EU SCCs**

* ☐ The version of the Approved EU SCCs which this Addendum is appended to, detailed below, including the Appendix Information:

Date:

Reference (if any):

Other identifier (if any):

Or

* ☒ the Approved EU SCCs, including the Appendix Information and with only the following modules, clauses or optional provisions of the Approved EU SCCs brought into effect for the purposes of this Addendum:

| Module | Module in operation | Clause 7 (Docking Clause) | Clause 11 (Option) | Clause 9a (Prior Authorisation or General Authorisation) | Clause 9a (Time period) | Is personal data received from the Importer combined with personal data collected by the Exporter? |
| - | - | - | - | - | - | - |
| 1 | | | | | | |
| 2 | Yes | Applies | The optional independent-dispute-resolution body does not apply | General authorisation applies | Minimum notice period of 30 days applies | |
| 3 | Yes | Applies | The optional independent-dispute-resolution body does not apply | General authorisation applies | Minimum notice period of 30 days applies | |
| 4 | | | | | | |

### Table 3: Appendix Information

"**Appendix Information**" means the information which must be provided for the selected modules as set out in the Appendix of the Approved EU SCCs (other than the Parties), and which for this Addendum is set out in:

* Annex 1A: List of Parties: See Annex 1, Part A of this DPA
* Annex 1B: Description of Transfer: See Annex 1, Part B of this DPA
* Annex II: Technical and organisational measures including technical and organisational measures to ensure the security of the data: See Annex 3 of this DPA
* Annex III: List of Sub processors (Modules 2 and 3 only): See Annex 4 of this DPA

### Table 4: Ending this Addendum when the Approved Addendum Changes

**Ending this Addendum when the Approved Addendum changes**

Which Parties may end this Addendum as set out in Section 19:

* ☒ Importer
* ☐ Exporter
* ☐ neither Party

**Part 2: Mandatory Clauses**

Part 2: Mandatory Clauses of the Approved Addendum, being the template Addendum B.1.0 issued by the ICO and laid before Parliament in accordance with s119A of the Data Protection Act 2018 on 2 February 2022, as it is revised under Section 18 of those Mandatory Clauses.


# Inference service terms
Source: https://docs.cloud.vessl.ai/legal/inference

Service-specific terms for the VESSL Cloud Inference service.

<Info>
  Effective date: September 15, 2026 · Last updated: September 7, 2026
</Info>

These Inference Service Terms ("Inference Terms") supplement the [Master Services Agreement](/legal/msa) (the "MSA") and govern Customer's use of any managed model-serving capability that VESSL makes available under the Documentation or an applicable Order Form (collectively, the "Inference Services"). A reference in these Inference Terms to a model, endpoint type, capacity model, interface, or feature does not constitute a commitment that it is or will be available. In the event of a conflict between these Inference Terms and the MSA, the order of precedence is the order set out in MSA Section 2.2.

Capitalized terms not defined here have the meanings given in the MSA.

## 1. Description of the Inference Services

To the extent made available, the Inference Services enable Customer to submit Inputs to an AI Model through a VESSL-managed endpoint and receive Outputs. The available endpoint type, capacity model, interfaces, AI Models, Regions, rate limits, quotas, and other features are only those identified in the then-current Documentation, VESSL console, or applicable Order Form. Customer accesses the Inference Services only through the interfaces VESSL makes available and not through direct, unmodified access to an underlying infrastructure provider's console, APIs, or credentials.

### 1.1 Definitions

In addition to the terms defined in the MSA, the following terms apply to these Inference Terms:

**"AI Model"** means a computational machine-learning model that, when executed against an Input, generates an Output.

**"Hosted Model"** means an AI Model that VESSL expressly identifies in the Documentation or applicable Order Form as selected, integrated, and operated by VESSL.

**"Input"** means prompts, instructions, code, data, or other content provided by Customer (or its Authorized Users or End Users) for processing by an AI Model.

**"Output"** has the meaning given in the MSA and includes the response returned by the AI Model in respect of an Input.

**"Model License"** means any third-party or open-source license terms applicable to an AI Model that VESSL makes available, as identified in the Documentation or applicable Order Form.

## 2. Models and Licenses

### 2.1 Third-Party Models

Where VESSL makes a third-party or open-source AI Model available, that model is subject to its applicable Model License. Customer is responsible for reviewing and complying with that Model License and for determining whether the model is suitable for Customer's intended use. VESSL does not represent or warrant that a Model License permits Customer's intended use.

### 2.2 No Training of Models

VESSL will not use Customer Content, Inputs, or Outputs to train, fine-tune, or update any AI Model, internal classifier, content-moderation model, security model, or other machine-learning or artificial-intelligence model unless Customer affirmatively opts in in writing. VESSL may apply existing automated security, abuse-detection, fraud-prevention, and content-filtering tools as permitted by the MSA and DPA, but may not use the Customer Content, Inputs, or Outputs processed by those tools to train or update a model without that written opt-in.

### 2.3 Beta and Preview Services

Inference Services, AI Models, endpoints, or features that VESSL designates as "Beta," "Preview," "Experimental," or similar are subject to MSA Section 2.3, are excluded from the SLA, may be modified or withdrawn at any time, and may produce less stable Outputs. Customer may use them for production workloads at Customer's discretion and risk, but must not use them for a prohibited High-Risk Use under MSA Section 14.19. An applicable Order Form may impose a narrower restriction.

## 3. Inputs and Outputs

### 3.1 Customer Inputs

Customer is solely responsible for the Inputs it submits to the Inference Services and for ensuring that such Inputs comply with this Agreement, the AUP, applicable Model Licenses, and applicable law. Customer represents that it has all rights and consents necessary to submit the Inputs.

### 3.2 Outputs

As between VESSL and Customer, Customer owns the Outputs generated by the Inference Services from Customer's Inputs, subject to the rights of model providers under the applicable Model License (including any restrictions on commercial use or distribution of Outputs). Customer acknowledges that Outputs are produced by machine learning models and assumes responsibility for evaluating Outputs for fitness for use in accordance with Section 3.3.

### 3.3 Probabilistic Nature of Outputs

Customer acknowledges that machine learning models produce probabilistic Outputs that may be inaccurate, incomplete, biased, or otherwise unsuitable for a given purpose. Outputs may include "hallucinations," fabricated facts, or content that resembles but does not actually originate from training data. Customer will (a) evaluate Outputs for fitness for purpose before relying on or distributing them, and (b) implement human review and other controls appropriate to Customer's use case, including in any high-risk or regulated context.

### 3.4 No Use as Sole Basis for High-Stakes Decisions

Customer will not use Outputs as the sole basis for decisions in domains with significant legal or similarly significant effects on individuals (including credit, employment, housing, healthcare, education, criminal justice, immigration, and benefits eligibility) without meaningful human oversight, transparency to affected individuals, and compliance with applicable law (including the EU AI Act).

## 4. AI Content Restrictions

The MSA and AUP apply in full to Customer's use of the Inference Services. Customer must not use the Inference Services in a manner prohibited by MSA Section 3.1 or AUP Sections 1 through 3, including to generate child sexual abuse material, non-consensual intimate imagery, content that materially uplifts CBRN weapons, malware or exploits, fraudulent or deceptive content, or content used for unlawful automated decision-making.

VESSL may apply existing automated content filters to Inputs and Outputs where reasonably necessary to enforce these restrictions, protect the Services, or comply with applicable law. Applying a filter does not authorize VESSL to use Customer Content to train or update that filter or another model. Any human access to filtered Inputs or Outputs is governed by the DPA and Support Policy. Customer remains responsible for ensuring that its Inputs and use of Outputs comply with the AUP and the applicable Model License.

## 5. Data Handling

### 5.1 Logging and Retention

By default, the Inference Services operate on a Zero Data Retention basis: VESSL does not persist Inputs or Outputs beyond what is necessary to process the request and return the Output to Customer, and does not use Inputs or Outputs to train, fine-tune, or update any model (consistent with Section 2.2). VESSL processes only operational metadata that does not contain the content of Inputs or Outputs — such as token counts, request counts, timestamps, status codes, and model identifiers — for billing, rate-limiting, security, abuse prevention, and capacity planning, and retains such metadata in accordance with the DPA.

### 5.2 Optional Content Logging and Limited Exceptions

Notwithstanding Section 5.1, VESSL may retain Inputs and Outputs only in the following cases: (a) where Customer expressly opts in — through the VESSL console or the applicable Order Form — to content logging for debugging or quality purposes, in which case VESSL retains Inputs and Outputs for the period selected by Customer (thirty (30) days by default and no more than sixty (60) days), after which VESSL deletes the Inputs and Outputs from active production systems; and (b) to the minimum extent, and for the shortest time, necessary to detect, prevent, or respond to abuse, fraud, or security incidents, or to comply with law or valid legal process. Any residual copies permitted in backups, security or audit records, or under a legal hold are governed by DPA Section 12.3. Any such retention remains subject to MSA Section 6.2 (which prohibits use of Customer Content, Inputs, or Outputs to train, fine-tune, or update any machine learning or artificial-intelligence model, whether internal or externally available, absent Customer's affirmative written opt-in) and the DPA.

### 5.3 Personal Data

Customer must not submit Restricted Data identified in MSA Section 3.8 unless VESSL expressly agrees in writing. For other Personal Data, Customer is responsible for compliance with Applicable Data Protection Laws.

### 5.4 Confidentiality of Inputs and Outputs

Customer's Inputs are Customer Content. Inputs and Outputs will be treated as Customer's Confidential Information under the MSA and, to the extent they contain Personal Data processed by VESSL on Customer's behalf, as Customer Personal Data under the DPA. VESSL will not use Inputs or Outputs to train, fine-tune, or update any model without Customer's affirmative written opt-in. VESSL personnel and Sub-processors may access Inputs or Outputs only to the minimum extent permitted under the DPA for operation, Customer-authorized support, security, abuse prevention, valid legal process, or an approved emergency response, and only under applicable confidentiality, access-control, minimization, and logging requirements.

## 6. Rate Limits and Quotas

The Inference Services are subject to rate limits and to context-length, token, request-size, and concurrency limits as set out in the Documentation or Order Form. VESSL may modify these limits as necessary to protect the integrity, security, and availability of the Inference Services, with reasonable notice where practicable.

## 7. Billing for Inference

For Self-Service, if VESSL makes a Self-Service Inference Service available, billing is governed by Annex A using the rates and billing units displayed in the VESSL console or Documentation. For B2B, the applicable billing basis and Fees are stated in the Order Form. Customer is not charged for a request that fails in the circumstances described in Section 6.3(a) of the SLA. VESSL's applicable usage and billing records are authoritative except in the case of manifest error.

## 8. Service Levels

The Inference Services are Covered Services under the public SLA only to the extent, and from the date, that VESSL expressly designates them as such in the then-current public SLA. Where so designated, the availability commitment, the measurement method, and the exclusions applicable to the Inference Services are those stated in that SLA, and the remedy for on-demand use is the one stated there. Service Credits are not issued for on-demand use of an Inference Service. Any other service-level commitment — including any throughput, capacity, latency, or token generation rate commitment — and any Service Credit or other remedy for it, applies only if expressly stated in the then-current public SLA, an applicable private SLA, a Custom SLA Addendum, or an Order Form. Beta, Preview, Early Access, and other pre-general-availability Inference Services remain excluded from the SLA under MSA Section 2.3.

## 9. No Indemnification for Outputs

Except as expressly set out in MSA Section 12.1, VESSL does not indemnify Customer against claims arising from the content or Customer's use of Outputs, including Outputs of a third-party AI Model. Any rights or remedies provided by a third-party model provider are governed by the applicable Model License or agreement with that provider.

## 10. Model Lifecycle and Deprecation

### 10.1 Model Availability

VESSL may add, update, or withdraw an AI Model made available through the Inference Services. The Documentation identifies the AI Models then available and, where VESSL supports version pinning for a model, the model versions Customer may pin.

### 10.2 Deprecation Notice

For a Hosted Model that VESSL has made generally available, VESSL will give Customer at least fourteen (14) days' notice before that model ceases to be available through the Inference Services. Notice is given through the Documentation, the VESSL console, or by email to the address on file for Customer. Where VESSL's usage data indicates that a model is in broad production use, VESSL will use commercially reasonable efforts to provide a longer notice period.

### 10.3 Beta, Preview and Experimental Models

An AI Model, endpoint, or feature designated as Beta, Preview, Experimental, or otherwise pre-general-availability may be modified or withdrawn at any time without notice, consistent with Section 2.3.

### 10.4 Immediate Withdrawal

Notwithstanding Section 10.2, VESSL may suspend or withdraw an AI Model immediately and without the notice period in Section 10.2 where (a) the applicable Model License terminates, expires, or is modified so that it no longer permits VESSL to make the model available, (b) continued availability would create a security, safety, or abuse risk, or (c) withdrawal is required by applicable law or regulation, by a governmental or judicial order, or in response to a claim that the model or its outputs infringe or misappropriate a third-party right. VESSL will notify Customer as promptly as reasonably practicable in each such case and will identify a replacement model where one is available.

### 10.5 Effect

Withdrawal of an AI Model in accordance with this Section 10 is not a failure to provide the Inference Services and does not give rise to a Service Credit under the SLA. Customer is responsible for migrating to a replacement model before the stated end date. A request submitted to a withdrawn model after that date may return an error.

## 11. Modifications

VESSL may modify these Inference Terms from time to time, subject to MSA Section 14.10.

***

VESSL AI, Inc. — [legal@vessl.ai](mailto:legal@vessl.ai)


# Privacy policy
Source: https://docs.cloud.vessl.ai/legal/privacy

How VESSL AI collects, uses, shares, and protects personal data.

<Info>
  Effective date: August 6, 2026 · Last updated: August 6, 2026
</Info>

VESSL AI KOREA Inc. and VESSL AI, Inc.("**VESSL**", "**we**", "**us**") are committed to protecting your personal data. This Privacy Policy explains what personal data we collect, how and why we use it, who we share it with, how long we keep it, and the rights you have.

**Korean residents:** a separate Korean-language privacy notice ([개인정보 처리방침](/ko/legal/privacy)) applies to you under the Republic of Korea *Personal Information Protection Act*. Where both apply, the rights in each are cumulative.

## Scope

This policy covers personal data we process as a **controller** through:

* our websites ([https://vessl.ai](https://vessl.ai), [https://docs.cloud.vessl.ai](https://docs.cloud.vessl.ai));
* the **VESSL Cloud** service ([https://cloud.vessl.ai](https://cloud.vessl.ai)); and
* our communications and support channels,

(together, the "Services") and our sales, business development, and marketing activities.

**Customer content.** Any personal data included in data, code, models, and files that customers upload to or generate within VESSL Cloud ("**Customer Content**") are processed by VESSL as a **processor** on the customer's behalf, under our [Data Processing Agreement](/legal/dpa) — not under this policy. We do not use Customer Content for our own purposes.

## Who is responsible (controller)

The controller of your personal data depends on the processing:

* **VESSL AI KOREA Inc.** (주식회사 베슬에이아이코리아), based in Seoul, Republic of Korea, is the controller for any processing of personal data where VESSL AI KOREA Inc. is the contracting entity.
* **VESSL AI, Inc.**, based in the United States, is the controller for any processing of personal data where VESSL AI, Inc. is the contracting entity.

Where this policy refers to "VESSL," "we," or "us," it means the entity acting as controller for the relevant processing. Contact details for both are at the end of this policy.

## 1. Personal data we collect

| Categories of Information | Personal Data |
| - | - |
| **Account registration information** | Email, username, hashed password, age-eligibility confirmation, terms-acceptance, sign-up IP and user-agent |
| **Third-party authentication information** | Google OAuth identifier, email, profile name (if you use social login) |
| **Billing & payments information** | Billing contact name/email, company, country, address, VAT/business-registration number, card issuer and last 4 digits, Stripe customer ID, payment amount/currency/time. We typically do not receive or store full card numbers or CVC — these go directly from your browser to Stripe. |
| **Business contacts & sales information** | Name, company, role, business email, phone (collected at events, via enquiry forms, or from public business channels). Where collected indirectly, we provide notice as required by law. |
| **Support & communications information** | Your name, email, message content, attachments (in-app chat, email, support tickets), and any other information you provide us. |
| **Events & webinar registration information** | Registration details and attendance |
| **Technical information (automatically collected)** | IP address, device/browser data, access logs (URL, method, status, time), error reports, usage metrics, and cookie/SDK identifiers |

We collect only what we need to provide and secure the Services. We do **not** seek to collect special-category data (e.g., health, biometrics, political opinions). Please do not submit such data in free-text fields.

Where you access the Services through our command-line interface (CLI) or software development kits (SDKs), we also collect limited diagnostic and usage telemetry — such as the command invoked, CLI/SDK and runtime versions, operating-system type, and error or crash reports — to maintain, secure, and improve those tools. You can limit this collection as described in our CLI documentation.

## 2. Why we use your data, and our legal bases

We may use each of the categories of information that we collect for the business purposes described in the table below.

Where such concept is recognized under applicable privacy laws, we process personal data based on the following legal bases:

| Purpose | Categories of Information | Legal Basis |
| - | - | - |
| Create and manage your account; authenticate you | Account registration information and third-party authentication information | **Performance of a contract** |
| Provide, operate, and support VESSL Cloud | Account registration information, support & communications information, and technical information | **Performance of a contract** |
| Process payments, billing, and tax | Billing & payments information | **Contract** and **Legal obligation** (tax/commercial-records law) |
| Secure the Services; prevent fraud and abuse; maintain logs | Technical information | **Legitimate interests** (security of our service) and **Legal obligation** |
| Respond to enquiries and provide support | Support & communications information | **Legitimate interests** (to support our customers) |
| Send marketing emails, newsletters, and campaign content; sales outreach and B2B lead management | Business contacts & sales information | **Consent** (where required) and **Legitimate interests** (to promote our Services to businesses) |
| Product analytics and service improvement | Support & communications information and technical information | **Consent** (where required by law – e.g., for non-essential cookies/SDKs) /**Legitimate interests** (to improve our Services) |
| Comply with legal requests and defend legal claims | Any of the above, as relevant | **Legal obligation** / **Legitimate interests** (to defend our legal interests) |

Where we rely on **legitimate interests**, we have balanced those interests against your rights; you may object at any time (see "Your rights"). Where we rely on **consent**, you may withdraw it at any time without affecting prior processing.

## 3. Marketing and your choices

We send marketing communications in accordance with applicable law including with your consent where it is required by law. To opt out of email marketing communications, please click on the unsubscribe link or follow the directions within the email marketing communications you have received from us. You also can opt out via your account settings or by emailing [privacy@vessl.ai](mailto:privacy@vessl.ai). Transactional and service messages (e.g., security, billing, service announcements) are not marketing and are sent as part of the Service.

## 4. Who we share your data with

We may share the categories of personal data listed above with the following entities:

* **Group company.** We may share personal data between group entities (VESSL AI KOREA Inc. and VESSL AI, Inc.) for service delivery, customer support, product improvement, compliance, and internal reporting.
* **Sub-processors / service providers.** We use the vendors listed in our [Sub-processor List](/legal/sub-processors) (e.g., AWS for hosting, Stripe for payments, SendGrid/Resend for email, HubSpot for CRM, Sentry/Datadog for monitoring). They act on our instructions under data-protection contracts.
* **Advertising & analytics partners.** Subject to your cookie consent, we use third-party providers — **Google** (Google Analytics and Google Ads / DoubleClick), **LinkedIn** (Insight Tag), **Amplitude** (product-usage analytics), **HubSpot** (website visitor tracking and campaign measurement), **Mintlify** (documentation-site analytics), and **Arcade** (interactive product demos in the documentation) — for website analytics, advertising, and campaign measurement. These providers are listed in our [Sub-processor List](/legal/sub-processors).
* **Payment processing.** Card payments are handled by **Stripe**, contracted through VESSL AI, Inc.
* **Legal and safety.** We may disclose data to comply with law, respond to lawful requests by public authorities, enforce our terms, or protect rights, property, and safety.
* **Corporate transactions.** In a merger, acquisition, asset sale, or other substantial corporate transaction, data may be transferred.

## 5. International data transfers

VESSL AI KOREA Inc. is based in the Republic of Korea, and VESSL AI, Inc. is based in the United States. The primary hosting region for account and operational data is **AWS Seoul (Republic of Korea)**, but many of our sub-processors are based in the US.

When we transfer personal data originating from the EEA or the UK to a country without an adequacy decision, we rely on the European Commission's **Standard Contractual Clauses (SCCs) and the UK Addendum to the SCCs**, with supplementary measures where appropriate. You can request a copy of the relevant safeguards by emailing **[privacy@vessl.ai](mailto:privacy@vessl.ai)**.

## 6. How long we keep your data

We keep personal data only as long as necessary for the purposes above, then delete or anonymise it:

* **Account data** — for the life of the account. Following a voluntary account-deletion request, ordinary access ends immediately and, unless the account holder gives an action-specific instruction for earlier irreversible deletion, account data may be retained for up to fourteen (14) days solely to permit controlled account recovery. It is then deleted or anonymised unless a longer period is required by law. Customer Content processed on a customer's behalf remains governed by the DPA rather than this Policy.
* **Billing, tax, and transaction records** — for the periods required by applicable commercial and tax law.
* **Security/access logs** — for the period required to operate and secure the Services and to meet legal obligations.
* **Marketing data** — until you withdraw consent or object.

## 7. Your rights

Subject to applicable laws, you may have the right to:

* **access** your personal data and obtain a copy;
* **rectify** inaccurate or incomplete data;
* **erase** your data ("right to be forgotten");
* **restrict** processing;
* **data portability** — receive your data in a portable format;
* **object** to processing based on legitimate interests, and to direct marketing at any time; and
* **withdraw consent** at any time where processing is based on consent.

We do not process your personal data to make decisions based solely on automated processing that produces legal or similarly significant effects.

To request to exercise any right, email **[privacy@vessl.ai](mailto:privacy@vessl.ai)** or use your account settings. We respond within the period required by law. We may need to verify your identity.

You also have the right to lodge a complaint with a data-protection supervisory authority. For example, EEA data subjects may complain to the supervisory authority of their country of residence or work. Korean residents may contact the **Personal Information Protection Commission (PIPC)** / KISA (privacy.kisa.or.kr).

## 8. Cookies

We use cookies and similar technologies as described in our [Cookie Policy](/legal/cookie). Every cookie and browser-storage key we use is identified individually — with its provider, category, host, purpose, and duration — in our [Cookie List](/legal/cookie-list). You can manage non-essential cookies through our cookie banner. Analytics, advertising, and other non-essential cookies are set only with your consent. A small number of strictly necessary cookies are used without consent as permitted by applicable law, including some set by providers on our behalf for sign-in and payment fraud prevention.

## 9. Security

We maintain technical, organisational, and physical safeguards appropriate to the risk — including encryption in transit (TLS), hashing of passwords, encryption of secrets, access controls with multi-factor authentication, logging, and storage with certified cloud providers (e.g., ISO 27001 / SOC 2). No method of transmission or storage is perfectly secure, but we work to protect your data and to notify you and regulators of breaches as required by law.

## 10. Region-specific provisions

**California (CCPA).** If you are a California resident, you have rights to know, access, correct, and delete your personal information, and not to be retaliated against for exercising any of these privacy rights. You or your authorized agent may exercise these rights as described in Section 7, and we do not discriminate against you for exercising them. **We do not sell personal information for money.** To the extent our use of Targeting cookies constitutes "sharing" or targeted-advertising processing under California or other applicable law, you may opt out at any time through the "Manage cookies" control or a recognized Global Privacy Control signal. See our [Cookie Policy](/legal/cookie) Section 5. We do not collect or share sensitive information except in ways permitted under the CCPA. To exercise these rights, email [privacy@vessl.ai](mailto:privacy@vessl.ai).

**General Data Protection Regulation (GDPR) – European Representative**

Pursuant to Article 27 of the General Data Protection Regulation (GDPR), VESSL AI Korea Inc. and VESSL AI Inc. has appointed European Data Protection Office (EDPO) as its GDPR Representative in the EU. You can contact EDPO regarding matters pertaining to the GDPR:

* by using EDPO's online request form: [https://edpo.com/gdpr-data-request](https://edpo.com/gdpr-data-request)
* by writing to EDPO at Avenue Huart Hamoir 71, 1030 Brussels, Belgium

**UK General Data Protection Regulation (GDPR) – UK Representative**

Pursuant to Article 27 of the UK GDPR, VESSL AI Korea Inc. and VESSL AI Inc. has appointed EDPO UK Ltd as its UK GDPR representative in the UK. You may contact EDPO UK regarding matters relating to the UK GDPR and/or complaints under section 164A of the Data Protection Act 2018 (DPA 2018) as amended by the Data Use and Access Act 2025 (DUAA).

* by using EDPO's online request and complaint form: [https://edpo.com/uk-gdpr-data-request/](https://edpo.com/uk-gdpr-data-request/)
* by writing to EDPO UK at Unit 33, Waterside, Schooner Court, 44-48 Wharf Road, London, N1 7UX, United Kingdom

## 11. Children

The Services are intended for businesses and professional users and are **not directed to children under 16**. We do not knowingly collect or sell personal data from children. If you believe a child has provided us data, contact [privacy@vessl.ai](mailto:privacy@vessl.ai) and we will delete it.

## 12. Changes to this policy

We may update this policy from time to time. Material changes will be announced on our website and the "last updated" date will be revised.

## 13. Contact us

| **Controller** | VESSL AI KOREA Inc. (주식회사 베슬에이아이코리아) | VESSL AI, Inc. (United States) |
| - | - | - |
| **Address** | 13F, 7 Teheran-ro 5-gil, Gangnam-gu, Seoul, Republic of Korea, 06134 | 535 Mission Street, Ste 1550, San Francisco, CA 94105 |
| **Privacy contact** | [privacy@vessl.ai](mailto:privacy@vessl.ai) | [privacy@vessl.ai](mailto:privacy@vessl.ai) |


# Service-specific Terms
Source: https://docs.cloud.vessl.ai/legal/service-terms

Additional terms that apply to individual VESSL Cloud services.

Service-specific Terms supplement the Master Services Agreement and apply to particular VESSL Cloud services. In the event of a conflict, the order of precedence set out in the Master Services Agreement governs.

<CardGroup>
  <Card title="Container Compute Service Terms" href="/legal/container-compute" />

  <Card title="VM Cluster Service Terms" href="/legal/vm-cluster" />

  <Card title="Storage Service Terms" href="/legal/storage" />

  <Card title="Inference Service Terms" href="/legal/inference" />
</CardGroup>


# Service level agreement
Source: https://docs.cloud.vessl.ai/legal/sla

VESSL Cloud service level agreement (SLA).

<Info>
  Effective date: October 5, 2026 · Last updated: September 28, 2026
</Info>

This Service Level Agreement ("SLA") describes the standard availability commitments VESSL makes for eligible paid Self-Service use of the Covered Services. This SLA forms part of the Master Services Agreement. It applies automatically to an eligible paid Self-Service Customer. A B2B Customer is governed by this standard SLA (including Section 4), except to the extent a Custom SLA Addendum, or Order Form applicable to that transaction expressly provides otherwise. Capitalized terms not defined here have the meanings given in the Master Services Agreement.

This SLA does not apply to (i) Beta, Preview, Early Access, or other pre-general-availability Services or features (whether or not separately labeled), (ii) Services provided free of charge or under promotional credits, or (iii) periods during which Customer is in material breach of the Agreement (including the AUP) or has unpaid undisputed Fees more than thirty (30) days past due.

## 1. Definitions

**"Billing Month"** means a calendar month during the Subscription Term.

**"Cluster Storage Volume"** means a customer-visible persistent storage volume created through the VESSL Platform, bound to a specific Cluster, and mountable by one or more Workspaces or Jobs in that Cluster.

**"Downtime"** means a period during which a Covered Service is Unavailable under Section 3, 4 (Managed GPU Node), or 5 (Storage).

**"Downtime Minutes"** means, for an affected unit of a Covered Service in a Billing Month, the aggregate number of minutes during which a unit is Unavailable under the applicable Section of this SLA, excluding any period that constitutes Excluded Time. Partial minutes will be counted proportionately based on VESSL's applicable monitoring records, and overlapping periods of Unavailability will not be counted more than once. Any proration expressly permitted under this SLA will apply.

**"Eligible Request"** means a request that Customer submits to a Model Endpoint within the scope of Section 6.1 and that (a) is properly formed and authenticated; (b) is within Customer's quotas, rate limits, and the documented context, token, request-size, and concurrency limits for that Model Endpoint; (c) does not specify a client-side deadline shorter than the then-current server-side default; and (d) where it is a retry, conforms to the back-off requirement in Section 6.2.

**"Excluded Time"** means the aggregate number of minutes excluded under Section 7. Partial minutes will be counted proportionately.

**"Failed Request"** means an Eligible Request that returns an HTTP 5xx status code, that receives no response within the applicable server-side timeout, or that, being a streaming request, is terminated by VESSL before its terminal event is delivered. A response described in Section 6.4 is not a Failed Request. An Eligible Request that is not a Failed Request succeeds.

**"Model Endpoint"** means a distinct combination of (a) a model identifier made available through an Inference Service and (b) the Region in which it is served, as invoked by Customer through the applicable API.

**"Monthly Fee"** means: (a) for Self-Service, the monetary Fees or paid value of Purchased Credits actually charged for the affected unit in the applicable Billing Month; and (b) for B2B, the amount calculated under the applicable private transaction document. Promotional or complimentary value is excluded.

**"Monthly Uptime Percentage"** means, for a given affected unit of a Covered Service in a Billing Month: 100% × (Total Minutes − Downtime Minutes − Excluded Time) / (Total Minutes − Excluded Time).

**"Service Credit"** means the non-cash remedy calculated and issued under this SLA. A Service Credit is not a Purchased Credit or Promotional Credit.

**"Total Minutes"** means the total number of minutes in a Billing Month.

**"Unavailable"** has the meaning stated for the applicable Covered Service in Sections 3.1, 4.1 and 5.1.

## 2. Covered Services

This SLA applies to the following Services ("**Covered Services**"):

| Covered Service | Section | SLO target |
| - | - | - |
| Container Compute — Workspace and Batch Job availability | 3 | 99.0% per running Workload, per Billing Month |
| Compute Cloud — managed GPU node availability | 4 | 99.0% per node, per Billing Month |
| Storage — Cluster Storage availability | 5 | 99.5% per affected Cluster Storage Volume, per Billing Month |
| Inference Services — Model Endpoint availability (on-demand use) | 6 | 99.0% of Eligible Requests succeed, per Model Endpoint, per Billing Month |

For B2B Customers, managed GPU nodes provisioned under an Order Form — whether delivered as bare-metal or virtual machine (VM) nodes — are Covered Services under Section 4 of this SLA by default, unless the applicable Order Form or Custom SLA Addendum expressly provides otherwise. Higher availability commitments (e.g., for multi-Region or multi-AZ deployments) may be agreed in a Custom SLA Addendum. Service-specific commitments may be modified or supplemented in an Order Form or Custom SLA Addendum.

## 3. Compute Cloud SLA — Workspace and Batch Job availability

### 3.1 Workspace and Batch Job Unavailability

A running Workspace or Batch Job provisioned through the VESSL Platform (each, a "**Workload**") is **Unavailable** when, due to a cause attributable to VESSL, the Workload cannot run, including any of the following:

* the running container fails its health checks;
* the GPU or other compute resource allocated to the Workload becomes unusable and cannot be restored by routine recovery operations (such as reboot or reset); or
* a failure of the VESSL Platform or its control plane prevents the Workload from running.

Container Compute availability is measured at the level of the affected Workload, using VESSL's platform health and availability monitoring. A Workload is treated as available or Unavailable as a whole; there is no partial-resource proration.

Unavailability of Cluster Storage that prevents a Workload from running is addressed under Section 5 and not under this Section 3.

### 3.2 Provisioning Capacity Indicator (Advisory)

The VESSL Platform may display, for a given resource specification, a real-time capacity indicator (for example, "High," "Low," or "Unavailable") reflecting whether new Workspaces or Batch Jobs of that specification can currently be scheduled on available capacity. This indicator is **advisory only**: it reflects point-in-time scheduling capacity, may change without notice, and is designed to fail open (so that only a confirmed absence of schedulable capacity blocks a new Workload's creation). The availability of on-demand capacity to provision new Workloads is **not** a service-level commitment under this SLA (consistent with the Container Compute Service Terms), and the capacity indicator does not give rise to Service Credits. The Service Credits under this Section 3 apply only to the Unavailability of running Workloads as defined in Section 3.1.

### 3.3 Container Compute Service Credits

| Monthly Uptime Percentage (per Workload) | Service Credit (% of affected Workload Monthly Fee) |
| - | - |
| \< 99.0% and ≥ 97.0% | 10% |
| \< 97.0% and ≥ 95.0% | 15% |
| \< 95.0% | 30% (cap) |

The Service Credit for any individual Workload in a Billing Month will not exceed 30% of that Workload's Monthly Fee. Aggregate Service Credit caps across all Covered Services are set out in Section 8.3.

### 3.4 Maintenance and Replacements

Scheduled maintenance, emergency maintenance, planned hardware replacement, and emergency hardware replacement are excluded from Downtime to the extent the maintenance or replacement is reasonably necessary for the operation, security, or integrity of the Services and is conducted in accordance with this Section 3.4.

(a) **Notice.** VESSL will provide at least seven (7) calendar days' advance notice of scheduled maintenance that is expected to interrupt the Services (via the VESSL console, by email, or in the Documentation). For emergency maintenance or emergency hardware replacement, VESSL will provide as much advance notice as is reasonably practicable and may proceed without prior notice where necessary to protect the security, integrity, or availability of the Services.

(b) **Excludable maintenance cap.** Downtime arising from maintenance and replacement under this Section 3.4 is excluded from Downtime calculations only up to a total of eight (8) hours in any Billing Month. Any such Downtime in excess of eight (8) hours in a Billing Month is not excluded and counts as Downtime.

Notice timing, frequency limits, and detailed procedures applicable to each category are described in the Documentation. For Customers with bare-metal GPU deployments, more specific maintenance and replacement commitments may be set out in a Custom SLA Addendum. Maintenance or replacement that materially exceeds the documented procedures, or the eight (8)-hour monthly allowance in Section 3.4(b), is not excluded from Downtime.

## 4. Compute Cloud SLA — managed GPU node availability (B2B only)

### 4.1 Managed GPU Node Unavailability

A managed GPU node provisioned through VESSL's control plane, APIs, and management software, whether provisioned as a bare-metal node or a virtual machine (VM) node, is **Unavailable** when, due to a cause attributable to VESSL, Customer cannot reach or use the node for its contracted workload, including any of the following:

* The node is unreachable from VESSL's control plane or its on-node agent is unresponsive;
* One or more contracted GPUs cannot be recovered by routine operations (reboot, GPU reset, driver reload);
* The pre-installed OS or VESSL-managed software stack (e.g., NVIDIA drivers, OFED, HPC-X) prevents normal node or GPU operation.

**Measurement.** VESSL probes each node at intervals of no greater than sixty (60) seconds. Unavailability runs from the first of three (3) or more consecutive failed probes until the next successful probe.

Where some but not all GPUs on a node are Unavailable while the remainder of the node remains operational, Downtime for that node may be calculated on a prorated basis equal to the fraction of GPUs Unavailable (for example, 2 of 8 GPUs Unavailable corresponds to 25% Downtime applied to that node's Monthly Fee). VESSL may, at its discretion or where set out in a Custom SLA Addendum, treat such partial failure as full-node Unavailability where operational considerations make per-GPU proration impractical.

Unavailability of shared storage that prevents node use is addressed under Section 5 and not under this Section 4.

### 4.2 Managed GPU Node Service Credits

| Monthly Uptime Percentage (per node) | Maximum Service Credit (% of affected node Monthly Fee) |
| - | - |
| \< 99.0% and ≥ 95.0% | 10% |
| \< 95.0% and ≥ 90.0% | 15% |
| \< 90.0% | 30% |

Service Credits shall only be issued upon a valid claim submitted by Customer in accordance with Section 8 and shall not be applied automatically.

### 4.3 Maintenance and Replacements

Scheduled maintenance, emergency maintenance, planned hardware replacement, and emergency hardware replacement are excluded from Downtime to the extent (a) VESSL provides reasonable advance notice where practicable, and (b) the maintenance or replacement is reasonably necessary for the operation, security, or integrity of the Services. The necessity and scope of any maintenance or replacement shall be determined solely by VESSL, and such determination shall be deemed reasonable.

For scheduled maintenance, VESSL will provide at least seventy-two (72) hours' prior written notice via [support@vessl.ai](mailto:support@vessl.ai). For emergency maintenance, VESSL will provide as much advance notice as is reasonably practicable and will notify Customer via [support@vessl.ai](mailto:support@vessl.ai) within twenty-four (24) hours following completion.

For Customers with bare-metal GPU deployments, more specific maintenance and replacement commitments may be set out in a Custom SLA Addendum. Maintenance or replacement that materially exceeds the documented procedures is not excluded from Downtime.

## 5. Storage SLA

### 5.1 Cluster Storage Unavailability

Cluster Storage availability is measured separately for each affected Cluster Storage Volume. A Cluster Storage Volume is Unavailable when, due to a cause attributable to VESSL, read, write, or file-listing operations on the mounted Volume fail continuously for five (5) minutes or more.

### 5.2 Cluster Storage Service Credits

| Monthly Uptime Percentage (per affected Cluster Storage Volume) | Service Credit (% of affected Cluster Storage Volume Monthly Fee) |
| - | - |
| \< 99.5% and ≥ 95.0% | 10% |
| \< 95.0% and ≥ 90.0% | 15% |
| \< 90.0% | 30% (cap) |

The Service Credit for an individual affected Cluster Storage Volume in a Billing Month will not exceed thirty percent (30%) of that Volume's Monthly Fee. Aggregate Service Credit caps across all Covered Services are set out in Section 8.3.

### 5.3 Object Storage (Not Covered)

Object Storage is **not** a Covered Service under this SLA. VESSL does not provide an availability commitment for Object Storage, and no Service Credits are available in respect of Object Storage. VESSL operates Object Storage using commercially reasonable measures as described in the Storage Service Terms and the Documentation; VESSL's liability for Customer Content stored in Object Storage that is lost, corrupted, or rendered inaccessible is governed by Section 11 (Limitation of Liability) of the MSA.

## 6. Inference Services SLA

### 6.1 Scope

This Section 6 applies to Customer's **on-demand use** of the Inference Services through a Model Endpoint. Inference Service availability is measured by Monthly Availability of requests (Section 6.2) rather than by Monthly Uptime Percentage.

Where Customer reserves inference capacity under a Custom SLA Addendum — Provisioned Throughput ("PT Addendum"), the Service Credits and throughput commitments for that capacity are governed by the PT Addendum. The measurement framework, definitions, and exclusions in this Section 6 remain the baseline for all Inference Services, including reserved capacity.

This Section 6 does not apply to (a) an Inference Service, model, or model version designated as Beta, Preview, or Early Access; (b) an endpoint serving a model, adapter, container image, or serving configuration supplied or modified by Customer; (c) Batch or asynchronous inference; or (d) an endpoint Customer has configured to scale to zero replicas, unless an Order Form or Custom SLA Addendum states otherwise.

### 6.2 Model Endpoint Availability

Monthly Availability, for a Model Endpoint in a Billing Month, is the **percentage of the Eligible Requests submitted to that Model Endpoint in that Billing Month that succeed (that is, that are not Failed Requests)**. It is measured server-side at the boundary of the VESSL inference gateway, using VESSL's request records. As stated in Section 2, VESSL commits that Monthly Availability for a Model Endpoint will be at least 99.0% in each Billing Month.

Two categories of Eligible Requests are left out of that calculation. First, Eligible Requests submitted in a five (5) minute period, measured in UTC, in which Customer submitted fewer than three hundred (300) Eligible Requests to that Model Endpoint. Second, Eligible Requests submitted during Excluded Time.

When a request fails, Customer must wait before retrying: at least one (1) second after the first failure, doubling for each consecutive failure up to thirty-two (32) seconds. A repeated identical request that does not follow this is not an Eligible Request.

VESSL does not commit to the availability of on-demand capacity to serve any particular request volume. **Guaranteed throughput is available only under a Custom SLA Addendum for provisioned throughput capacity.**

### 6.3 Remedies for Failed Requests

(a) **No charge for failed requests.** Customer is not charged for a Failed Request. Where such a charge is applied, VESSL will reverse it on request or at the next billing reconciliation.

(b) **Sole remedy for on-demand use.** The Inference Services are billed on usage, so Customer's Fees fall as its requests fail. Section 6.3(a) is accordingly Customer's sole remedy under this SLA for a failure to meet the SLO in Section 2. Service Credits are not issued for on-demand use of an Inference Service, and Section 8 does not apply to that use.

(c) **Reserved capacity.** Where Customer reserves inference capacity under an Order Form, Customer pays for it whether or not it is used. The availability commitment, service levels, and Service Credits for that capacity are those in the applicable Custom SLA Addendum, and nothing in Section 6.3(a) or 6.3(b) limits them.

### 6.4 Responses That Are Not Failures

None of the following is a Failed Request, and none gives rise to any remedy under Section 6.3:

* a response with an HTTP 4xx status code, including 400, 401, 403, 404, 409, 413, 422, and 424;
* a response with an HTTP 429 status code, or any other throttling, rate limiting, queuing, admission delay, or reduced throughput arising from quotas, rate limits, or the absence of available capacity, or from Customer reaching or exceeding any capacity reserved for Customer under an Order Form;
* a refusal, filtered response, or truncated response generated by a content-safety, moderation, or guardrail component, whether operated by VESSL or by the model provider;
* an error resulting from Customer setting a client-side deadline or timeout shorter than the then-current server-side default for the Model Endpoint;
* a stream terminated by Customer, by Customer's client library, or by a Customer-side or intermediary timeout, or a request cancelled by Customer;
* an output that is incomplete, inaccurate, non-deterministic, or otherwise unsatisfactory in content or quality; and
* an error arising from Customer's continued use of a model or model version after the end of its published deprecation or end-of-life period.

### 6.5 No Latency or Throughput Commitment

This Section 6 commits to availability only. VESSL makes no commitment as to time to first token, time per output token, token generation rate, throughput, queueing, or cold-start time. Such a commitment arises only where expressly agreed in a Custom SLA Addendum or an Order Form.

### 6.6 Model Availability and Deprecation

The set of models made available through an Inference Service may change. Adding, modifying, deprecating, or removing a model or model version in accordance with Section 10 (Model Lifecycle and Deprecation) of the Inference Service Terms does not count against Monthly Availability and gives rise to no remedy under this Section 6.

## 7. Excluded Time

The following time is excluded from Downtime calculations and from the denominator of Monthly Uptime Percentage calculations to the extent applicable:

* Force majeure events, including natural disasters, war, pandemic, governmental action, and similar events beyond VESSL's reasonable control.
* Failures of public internet, carrier networks, internet backbone providers, upstream transit providers, or networks used by Customer to access the Services (including failures on the Customer side of the connection). Where connectivity is procured by Customer directly or arranged by VESSL on Customer's behalf with a third-party carrier, the relevant carrier's terms of service govern, and any resulting loss of external connectivity is excluded from Downtime.
* Denial-of-service attacks, hacking, or malware not caused by VESSL's negligence.
* Customer acts or omissions, including misconfiguration, unauthorized changes, application errors, security incidents within Customer's control, exceeding documented quotas, rate limits, or other technical limitations, and use outside the documented scope.
* Scheduled maintenance, emergency maintenance, planned replacement, and emergency replacement to the extent within the conditions of Section 3.4 and Section 4.3.
* Suspensions, throttling, or limitations imposed pursuant to MSA Section 3.4 (including for breach of the Agreement, the AUP, or past-due undisputed Fees).

For an Inference Service, the following time is also excluded, to the extent applicable:

* Any period during which VESSL performed a deployment, model load, model version rollout, scale-out, or configuration change to the affected Model Endpoint at Customer's request or in accordance with Customer's configuration;
* Any period during which the affected Model Endpoint is serving a model, model version, adapter, container image, or serving configuration supplied or modified by Customer, or is operating outside the configuration documented for that Model Endpoint; and
* Any failure of a third-party model provider, model repository, or upstream model API on which the affected Model Endpoint depends, where the failure is not attributable to the VESSL Platform.

## 8. Service Credit Claims

### 8.1 How to Claim

To claim Service Credits, Customer must submit a request to [support@vessl.ai](mailto:support@vessl.ai) no later than thirty (30) calendar days after the end of the Billing Month in which the Downtime occurred. A claim not submitted by that deadline is waived to the extent permitted by applicable law. Each claim must include (i) the affected Service and time periods, (ii) supporting logs or monitoring data, and (iii) the requested Service Credit.

### 8.2 Validation and Application

VESSL will determine Monthly Uptime Percentage and validate each claim in good faith using its monitoring, service, billing, configuration, and other available records. VESSL may also consider supporting evidence submitted by Customer. For Self-Service, an approved Service Credit will be posted to Customer's account. For B2B, an approved Service Credit will be applied to the next invoice or, if no invoice remains, to a renewal or an equivalent extension of the affected Subscription Term as permitted by the applicable private transaction document.

### 8.3 Cap

A Service Credit for an individual affected unit will not exceed thirty percent (30%) of that unit's Monthly Fee. Aggregate Service Credits across all affected Covered Services in a Billing Month will not exceed one hundred percent (100%) of the Monthly Fees for those affected Covered Services in that Billing Month.

### 8.4 Form of Service Credits

Service Credits are non-transferable, are not redeemable for cash, and are not Purchased Credits. A Self-Service Service Credit expires twelve (12) months after issuance or when Customer's account terminates, whichever occurs first, except to the extent mandatory law requires otherwise. B2B validity and application are governed by the applicable private transaction document.

## 9. Sole Monetary Remedy; No Double Recovery

Except for the fee adjustment under Section 6.3(a), Service Credits are Customer's sole monetary remedy for a failure to meet an SLA metric. This Section 9 does not limit: (a) Customer's right to terminate for an uncured material breach under Section 5.2 of the MSA; (b) liability arising from VESSL's willful misconduct or gross negligence to the extent it cannot lawfully be limited; or (c) a right that cannot lawfully be excluded. Customer may not recover both a Service Credit and another monetary remedy for the same loss or event. This SLA does not constitute a warranty or guarantee of uninterrupted or error-free service and does not extend or enhance any warranty stated in the MSA.

## 10. Updates

Updates to this SLA are governed by MSA Section 14.10.

***

VESSL AI, Inc. — [support@vessl.ai](mailto:support@vessl.ai)


# Storage service terms
Source: https://docs.cloud.vessl.ai/legal/storage

Service-specific terms for VESSL Cloud Cluster storage and Object storage.

<Info>
  Effective date: August 18, 2026 · Last updated: August 18, 2026
</Info>

These Storage Service Terms ("**Storage Terms**") supplement the [Master Services Agreement](/legal/msa) (the "**MSA**") and govern Customer's use of the VESSL standalone storage services, including Cluster Storage and Object Storage (collectively, the "**Storage Services**"). In the event of a conflict between these Storage Terms and the MSA, these Storage Terms will prevail over the MSA to the extent of the conflict, in accordance with the order of precedence set out in MSA Section 2.2.

**Scope note:** These Storage Terms apply to standalone storage volumes that Customer creates and manages independently through the VESSL platform. Storage resources that are provisioned as an integral component of another Service (e.g., block storage attached to Container Compute Workspaces, NFS Storage within VM Clusters, or temporary local storage allocated during a Workspace session) are governed by the Service-Specific Terms for that Service, not by these Storage Terms.

Capitalized terms not defined here have the meanings given in the MSA.

## 1. Description of the Storage Services

The Storage Services are VESSL's managed data-storage services, enabling Customer to create, manage, and access persistent storage volumes through the VESSL platform (including the console, API, and/or CLI). The Storage Services currently comprise the following storage types:

**Cluster Storage**: High-availability shared storage provisioned within a specific Cluster. Data persists independently of Workspace and Batch Job lifecycle.

**Object Storage**: Shared storage that is not bound to a specific Cluster. Data persists independently of Workspace and Batch Job lifecycle.

VESSL may introduce additional storage types or tiers from time to time, as described in the Documentation (see [Understand storage](/member/volume/overview)). Temporary local storage (e.g., NVMe scratch space allocated during a Workspace session) is not part of the Storage Services; it is ephemeral and is deleted when the Workspace is paused or terminated.

## 2. Definitions

In addition to the terms defined in the MSA, the following terms apply to these Storage Terms:

**"Cluster Storage"** means the VESSL storage service that provides persistent, shared storage within a Cluster.

**"Cluster Storage Volume"** means a customer-visible persistent storage volume created through the VESSL platform, bound to a specific Cluster, and mountable by one or more Workspaces or Jobs in that Cluster.

**"Object Storage"** means shared storage volumes that are accessible across Clusters and teams within an Organization, independent of any specific Cluster.

**"Volume"** means a persistent storage unit created by Customer that can be mounted to Workspaces or Batch Jobs to store and access data.

## 3. Provisioning and Access

### 3.1 Volume Creation

Customer may create Volumes through the VESSL platform. Volume creation is subject to the quotas, limits, and permissions described in the Documentation (see [Create a volume](/admin/storage/create-volume)).

### 3.2 Access Control

Customer is responsible for configuring access permissions for each Volume, including team assignments and Workspace attachments. VESSL provides role-based access controls as described in the Documentation (see [Manage volume data](/member/volume/detail)). Customer is solely responsible for the accuracy and appropriateness of its access-control configuration.

### 3.3 Data Upload and Management

Customer may upload, download, browse, and manage files within Volumes as described in the Documentation (see [Load data into a volume](/member/volume/load-data)). Operations that exceed documented quotas, rate limits, or file-size limits may be throttled or rejected.

### 3.4 Workspace and Job Attachment

Volumes may be attached to Workspaces and Batch Jobs as described in the Documentation (see [Create a workspace](/member/workspace/create)). The attachment does not transfer ownership of the Volume or its contents. When a Workspace is terminated, the attached Volume and its data persist unless Customer explicitly deletes the Volume.

### 3.5 Cluster Binding

Cluster Storage volumes are bound to the Cluster in which they are created. Object Storage volumes are not bound to any specific Cluster and may be accessed from any Cluster within the Organization.

## 4. Storage Characteristics

### 4.1 Performance

Storage performance may vary depending on workload patterns, concurrent access, and underlying infrastructure. VESSL does not guarantee specific throughput, IOPS, or latency levels for the Storage Services.

### 4.2 Durability and Data Protection

VESSL uses commercially reasonable measures to protect data stored in the Storage Services against loss. However, VESSL does not provide a numerical storage-durability commitment. Customer should maintain independent copies of all critical data.

### 4.3 Availability

The public SLA applies only to eligible Cluster Storage and measures availability separately for each affected Cluster Storage Volume. Object Storage is not a Covered Service under the public SLA.

### 4.4 Persistence

Data stored in both Cluster Storage and Object Storage persists independently of Workspace and Batch Job lifecycle. This is distinct from temporary local storage, which is ephemeral and deleted when the Workspace is paused or terminated.

## 5. Quotas and Limits

Storage capacity selections, technical limits, and operational limits, where applicable, are displayed in the VESSL console or described in the Documentation (see [Storage pricing](/pricing/storage)). The applicable billing basis is governed by Section 8 and Annex A or the applicable private Order Form.

## 6. Customer Responsibilities

This Section sets out Customer-side responsibilities specific to the Storage Services. VESSL's obligations are governed by the [MSA](/legal/msa), the [Data Processing Agreement](/legal/dpa) (DPA), the [Privacy Policy](/legal/privacy), and the [SLA](/legal/sla).

### 6.1 Content

Customer is solely responsible for (a) the legality, accuracy, and quality of all content stored in the Storage Services, (b) obtaining all rights and consents necessary to store and process such content, (c) compliance with applicable data-protection laws, and (d) ensuring that stored content does not violate the Acceptable Use Policy (AUP) or applicable law.

### 6.2 Backup

Customer is responsible for maintaining backup copies of data stored in the Storage Services that Customer considers critical. The Storage Services do not include an automated, self-service, or guaranteed backup or restore service. VESSL may, in its discretion and subject to technical feasibility, provide limited manual assistance in response to a support request, but such assistance does not transfer Customer's backup responsibility or create a recovery, restoration-time, or data-integrity commitment. VESSL's liability for data loss is governed by Section 11 (Limitation of Liability) of the MSA.

### 6.3 Access Management

Customer is responsible for properly configuring access permissions for Volumes and for managing which Authorized Users and workloads can access Customer's data. Unauthorized access resulting from Customer's misconfiguration is Customer's responsibility.

### 6.4 Data Hygiene

Customer is responsible for managing the lifecycle of its Volumes, including deleting Volumes that are no longer needed.

## 7. Data Retention and Deletion

### 7.1 During the Subscription Term

Customer data remains in the Storage Services for so long as the applicable Volume exists and Customer's account is active. Customer may delete individual files or entire Volumes at any time through the VESSL platform. Deletion of a Volume is permanent and irreversible. Customer should download any needed data before deleting a Volume.

### 7.2 Lifecycle Events

(a) **Voluntary Self-Service Account Termination.** Ordinary account access ends immediately. Eligible Customer Content is available only through the controlled fourteen (14)-day recovery or export process described in Annex A and the DPA. After that period, VESSL may delete the remaining Customer Content in accordance with the DPA.

(b) **Self-Service Payment Depletion.** If the Purchased Credits and Promotional Credits available for the Storage Services are exhausted and no other authorized payment method covers those Services, VESSL may restrict access to affected Cluster Storage and Object Storage. VESSL will retain the affected persistent storage for a fixed period of thirty (30) days and will provide notice before deletion. The thirty-day period begins when the applicable balances first become exhausted and remain insufficient to cover the Storage Services. Replenishment or authorization of another payment method before deletion cures the depletion condition and restores access subject to ordinary technical processing time. If Customer later exhausts the applicable payment coverage again, a new thirty-day period begins. After the full thirty-day period, VESSL may permanently delete the affected storage and associated Customer Content.

(c) **B2B Termination.** The data-return or deletion period stated in the applicable private Order Form controls and may be up to ninety (90) days if expressly stated. If the Order Form does not state a period, MSA Section 5.4 and the DPA control.

(d) **Backups and Required Retention.** DPA Section 12 governs backups, legal holds, residual records, and deletion from systems where immediate deletion is not technically feasible.

### 7.3 Cluster Decommission

If the Cluster underlying a Cluster Storage Volume is decommissioned, VESSL will provide reasonable advance notice and, where practicable, assist Customer in migrating data to an alternative Cluster or to Object Storage. VESSL's obligation in such circumstances is limited to providing commercially reasonable migration support during the notice period.

## 8. Billing

For Self-Service, Storage Services are billed under Annex A using the rates, billing cycles, calculation methods, and any outbound data-transfer charges displayed in the VESSL console. VESSL will provide at least seven (7) days' advance notice before an increase to a published Self-Service Storage Services usage rate takes effect. The increase applies prospectively and does not alter Fees accrued before its effective date. For B2B, the applicable private Order Form or invoice governs rates, committed Fees, billing cycles, and data-transfer charges during its term.

## 9. Preview Features

VESSL may introduce new features or capabilities within the Storage Services and designate them as "Preview," "Beta," or similar in the Documentation or VESSL platform. Such designated features are subject to MSA Section 2.3 (Beta Services), may be modified, re-priced, or discontinued, and are excluded from the SLA. This designation applies only to features expressly labeled as such, and not to the underlying Storage Service types (Cluster Storage, Object Storage) as a whole.

## 10. Acceptable Use

The [Acceptable Use Policy](/legal/acceptable-use) applies in full to all use of the Storage Services.

## 11. Service Levels

The public [SLA](/legal/sla) applies automatically to eligible paid Self-Service Cluster Storage and measures availability separately for each affected Cluster Storage Volume. Object Storage is not a Covered Service under the public SLA. For a B2B Customer, the public SLA applies by default, except to the extent an applicable Custom SLA Addendum or Order Form expressly provides otherwise. Service Credits are Customer's sole monetary remedy for a failure to meet an applicable SLA metric, subject to the exceptions and no-double-recovery rule in the SLA and MSA Section 13.

## 12. Modifications

VESSL may update these Storage Terms only in accordance with MSA Section 14.10.

***

VESSL AI, Inc. — [legal@vessl.ai](mailto:legal@vessl.ai)


# Sub-processor list
Source: https://docs.cloud.vessl.ai/legal/sub-processors

VESSL Cloud sub-processors engaged in processing customer personal data.

<Info>
  Effective date: August 6, 2026 · Last updated: August 6, 2026
</Info>

This page has two distinct parts. Section 1 lists the Sub-processors that VESSL AI KOREA Inc. or VESSL AI, Inc., as applicable ("VESSL"), engages to process Customer Personal Data on behalf of Customers under the Data Processing Agreement ("DPA"). Section 1 forms part of the DPA and is subject to DPA Section 6. Section 2 identifies service providers and third-party technologies that VESSL uses when processing personal data as a controller under the Privacy Policy. Section 2 does not form part of the DPA, and changes to Section 2 are not subject to DPA Section 6. Capitalised terms not defined here have the meaning given in the DPA.

## 1. Third-party sub-processors

| Sub-processor | Purpose of processing | Entity location | Hosting location | Privacy / sub-processor documentation |
| - | - | - | - | - |
| **Amazon Web Services, Inc.** | Core cloud infrastructure (databases, object storage, message queues) storing account, billing, operational-metadata, and log data | United States | Republic of Korea (Seoul) as primary region; other AWS regions for backup, recovery, and disaster response | [Privacy](https://aws.amazon.com/privacy/) · [Sub-processors](https://aws.amazon.com/compliance/sub-processors/) |
| **Stripe, Inc.** | Payment-card processing, billing, and fraud prevention | United States | United States | [Privacy](https://stripe.com/privacy) · [Service providers](https://stripe.com/legal/service-providers) |
| **Twilio Inc.** (SendGrid) | Transactional email delivery (sign-up verification, password reset, billing, alerts) | United States | United States | [Privacy](https://www.twilio.com/en-us/legal/privacy) · [Sub-processors](https://www.twilio.com/en-us/legal/sub-processors) |
| **Plus Five Five, Inc.** (dba Resend) | Service-announcement (non-marketing) email delivery; storage of recipient email addresses | United States | United States | [Privacy](https://resend.com/legal/privacy-policy) · [Sub-processors](https://resend.com/legal/subprocessors) |
| **Functional Software, Inc.** (Sentry) | Application error and exception monitoring | United States | United States | [Privacy](https://sentry.io/privacy/) · [Sub-processors](https://sentry.io/legal/subprocessors/) |
| **Datadog, Inc.** | Application logs, metrics, and traces; operational monitoring | United States | United States | [Privacy](https://www.datadoghq.com/legal/privacy/) · [Sub-processors](https://www.datadoghq.com/legal/subprocessors/) |
| **HubSpot, Inc.** | CRM contact storage, sales/onboarding enquiry handling, and marketing-email automation (to consenting recipients) | United States | United States | [Privacy](https://legal.hubspot.com/privacy-policy) · [Sub-processors](https://legal.hubspot.com/sub-processors-page) |
| **Amplitude, Inc.** | Product-usage analytics (consent-based) | United States | United States | [Privacy](https://amplitude.com/privacy) · [Sub-processors](https://amplitude.com/subprocessor-list) |
| **Google LLC** | Google Tag Manager (tag management), Google OAuth (social login), Google Analytics, and Google Ads / DoubleClick (advertising and remarketing) | United States | United States | [Privacy](https://policies.google.com/privacy) · [Sub-processors](https://cloud.google.com/terms/subprocessors) |
| **LinkedIn Corporation** (Microsoft) | Marketing — LinkedIn Insight Tag: ad conversion measurement and audience targeting | United States | United States | [Privacy](https://www.linkedin.com/legal/privacy-policy) |
| **Slack Technologies, LLC** (Salesforce) | Internal operational alerts to VESSL teams (webhooks) | United States | United States | [Privacy](https://slack.com/trust/privacy/privacy-policy) · [Sub-processors](https://slack.com/intl/en-gb/slack-subprocessors) |
| **Pylon Labs, Inc.** | In-app chat and customer support | United States | United States | [Privacy](https://www.usepylon.com/privacy) · [Sub-processors](https://usepylon.com/subprocessors) |
| **Vercel Inc.** | Hosting of the marketing website (vessl.ai) and edge logs | United States | United States and global edge network | [Privacy](https://vercel.com/legal/privacy-policy) · [Documentation](https://vercel.com/legal/dpa#subprocessing) |
| **Mintlify, Inc.** | Hosting and analytics for the documentation site (docs.cloud.vessl.ai) | United States | United States | [Privacy](https://www.mintlify.com/legal/privacy) · [Terms](https://www.mintlify.com/legal/third-party-provider-terms) |
| **Arcade Software, Inc.** | Interactive product demos embedded in the documentation site (consent-based) | United States | United States | [Privacy](https://www.arcade.software/privacy) |
| **The Ghost Foundation** (Ghost Pro) | Blog content management and hosting | Singapore | Netherlands | [Privacy](https://ghost.org/privacy/) · [Documentation](https://ghost.org/dpa/) |

## 2. Compute infrastructure (customer-selected)

The following providers run Customer Content and workloads on infrastructure that the Customer selects (by region or cluster), and therefore process Customer Personal Data contained in those workloads as sub-processors. Which provider applies depends on the compute region/cluster the Customer chooses.

| Sub-processor | Purpose of processing | Entity location | Hosting location | Privacy documentation |
| - | - | - | - | - |
| **Amazon Web Services, Inc.** | GPU/CPU compute for customer workloads | United States | Global | [Privacy](https://aws.amazon.com/privacy/) |
| **Nebius Inc.** | GPU/CPU compute for customer workloads | United States | Global | [Privacy](https://docs.nebius.com/legal/privacy) · [Documentation](https://docs.nebius.com/legal/dpa-inc) · [Sub-processors](https://docs.nebius.com/legal/sub-processors) |
| **Samsung SDS Co., Ltd.** | GPU/CPU compute for customer workloads | Republic of Korea | Republic of Korea | [Privacy](https://cloud.samsungsds.com/serviceportal/policy/privacy.html) |
| **NHN Cloud Corp.** | GPU/CPU compute for customer workloads | Republic of Korea | Republic of Korea, United Kingdom | [Privacy](https://www.nhncloud.com/kr/terms/privacy-policy) |
| **NAVER Cloud Corp.** | GPU/CPU compute for customer workloads | Republic of Korea | Republic of Korea | [Privacy](https://privacy.navercloudcorp.com/en/PrivacyPolicy/ncs) |
| **SK Telecom Co., Ltd.** | GPU/CPU compute for customer workloads | Republic of Korea | Republic of Korea | [Privacy](https://privacy.sktelecom.com/view.do?ctg=policy\&name=policy) |

## 3. Change log

| Effective date | Change |
| - | - |
| 2026-08-06 | Initial publication of the VESSL sub-processor list. |

***

Questions about this list: [privacy@vessl.ai](mailto:privacy@vessl.ai).


# Support policy
Source: https://docs.cloud.vessl.ai/legal/support-policy

VESSL Cloud customer support scope, channels, and response targets.

<Info>
  Effective date: August 6, 2026 · Last updated: August 6, 2026
</Info>

This Support Policy governs VESSL's standard support procedures under Section 2.6 of the Master Services Agreement located at [https://docs.cloud.vessl.ai/legal/msa](/legal/msa). It does not independently modify Fees, liability, Intellectual Property Rights, data-use rights, termination rights, retention periods, or other legal or commercial terms. The response and update targets in this Policy are operational targets rather than Service Level commitments, and Service Credits under the SLA do not apply to deviations from them unless a private Order Form, Premium Support agreement, or Custom SLA Addendum expressly states otherwise.

Capitalized terms not defined here have the meanings given in the Master Services Agreement.

## 1. Support Channels

Customers may submit support requests through the following channels:

| Channel | Use |
| - | - |
| **[support@vessl.ai](mailto:support@vessl.ai)** | Email — all severities, 24/7 ingestion |
| **VESSL console — Support tab** | Self-serve ticketing |
| **status.vessl.ai** | Status page; subscribe for incident notifications. The status page is the authoritative source for VESSL-published incident updates and scheduled-maintenance notices. |
| **Dedicated channel** *(Enterprise)* | Slack Connect or other channel as set out in the Order Form |

Support channels accept submissions twenty-four (24) hours a day, seven (7) days a week. "Business Hours" means 09:00–18:00 Korea Standard Time, Monday through Friday, excluding public holidays in the Republic of Korea.

Severity is initially set by Customer and may be adjusted by VESSL based on the actual impact described.

## 2. Severity Levels

| Severity | Definition |
| - | - |
| **Sev-1 (Critical)** | Full cluster outage; complete API outage; confirmed data integrity issue affecting production workloads |
| **Sev-2 (Major)** | Concurrent node failures affecting at least ten percent (10%) of the total number of nodes contracted by Customer; significant performance degradation; elevated error rates on production endpoints; production workload functionally impaired but partially operational |
| **Sev-3 (Minor)** | Minor component issue with available workaround; non-production-impacting performance variation |
| **Service Request** | Configuration changes, access requests, information requests, or other non-incident requests |

## 3. Target Response Times

VESSL aims to provide initial response and ongoing status updates as follows:

| Severity | Target initial response | Target status update cadence |
| - | - | - |
| Sev-1 | 2 hours | Every 2 hours until resolution |
| Sev-2 | 4 hours | Every 8 hours until resolution |
| Sev-3 | 8 business hours | Every 24 business hours until resolution |
| Service Request | 24 business hours | — |

"Initial response" means the time from Customer's submission of a support request through a designated channel until VESSL acknowledges receipt and assigns an engineer. Auto-acknowledgments do not qualify as initial response.

These are operational targets and not Service Level commitments; Service Credits under the SLA do not apply to deviations from these targets. Enterprise Customers may obtain contractually committed response targets through a separately executed Premium Support agreement or Custom SLA Addendum.

## 4. Service Hours

| Severity | Coverage |
| - | - |
| Sev-1, Sev-2 | Best-efforts 24×7, including weekends and holidays |
| Sev-3, Service Requests | Business Hours |

A private Order Form or Premium Support agreement may provide different support hours.

Enterprise Customers may receive enhanced coverage (including named Technical Account Manager support and accelerated response targets) as set out in their Order Form or a separately executed Premium Support agreement.

## 5. Incident Summary and Root Cause Analysis (RCA)

For Sev-1 incidents, and for Sev-2 incidents where VESSL reasonably determines that an RCA is warranted, VESSL aims to provide a preliminary incident summary within five (5) business days after incident resolution and will use commercially reasonable efforts to provide any final Root Cause Analysis ("RCA") within sixty (60) days after incident resolution. These are operational targets and not Service Level commitments.

A final RCA, where provided, may describe:

* the cause of the incident, to the extent identified;
* the scope and timeline of impact;
* remediation actions taken; and
* preventive measures planned, where applicable.

Information that is confidential, security-sensitive, or a trade secret may be omitted from an incident summary or RCA at VESSL's discretion.

## 6. Escalation

If Customer is dissatisfied with the response to a Sev-1 or Sev-2 incident, Customer may request escalation by replying to the existing support ticket or contacting [support@vessl.ai](mailto:support@vessl.ai) and identifying the request as an escalation. Enterprise Customers may have additional escalation paths set out in their Order Form, including escalation to a named Technical Account Manager or to executive sponsors.

## 7. Customer Cooperation

Effective support depends on Customer cooperation. Customer is expected to:

* provide a clear description of the symptoms and impact;
* provide reasonable diagnostic information (logs, request IDs, timestamps, affected resources, environment context);
* be available for follow-up questions during incident resolution;
* implement reasonable mitigations within Customer's control; and
* accurately classify severity at submission and update VESSL if impact materially changes.

## 8. Customer Authorization and Data Access

8.1 **Authorized requesters.** For an individual Self-Service Customer, the verified account holder may authorize support access and actions. For an organization, an account owner or administrator may authorize access and actions unless the Customer has designated another support contact with the relevant authority. VESSL may verify the requester's identity, account role, and authority before acting.

8.2 **Operational diagnostics.** VESSL may access resource state, health, utilization, Service configuration, platform events, process status, and technical logs under the Agreement and DPA to the minimum extent reasonably necessary to provide requested support, operate the Services, or protect security and availability. Such access must be need-to-know, minimized, time-limited where practicable, and logged.

Process names, command lines, stack traces, and logs are not automatically operational data. If they expose credentials, payloads, file contents, prompts, personal data, or other substantive Customer Content, Section 8.3 applies.

8.3 **Substantive Customer Content.** Before personnel view substantive Customer Content, VESSL must obtain case-specific authorization through the support ticket or another documented Customer instruction. The authorization must identify the support purpose and reasonably expected systems and data scope.

8.4 **Data-changing or destructive work.** Before VESSL deletes, moves, overwrites, repairs, reorganizes, restores, or otherwise changes Customer Content, or executes a command reasonably expected to do so, VESSL must obtain action-specific authorization from an authorized requester after describing the intended action and reasonably foreseeable data impact. A general request to "fix" an issue is not sufficient authorization to delete or materially alter Customer Content. VESSL will prefer Customer-performed remediation where practical.

8.5 **Emergency and security response.** Where prior authorization is impracticable and action is reasonably necessary to prevent or contain imminent material harm, comply with valid legal process, or conduct an event-driven AUP/security investigation, VESSL may take the least intrusive action reasonably available. VESSL will escalate internally where practicable, record the reason, scope, actor, time, and action, and notify Customer afterward unless legally prohibited or notice would materially impair the response. Suspension or isolation is preferred over deletion where it adequately contains the risk.

8.6 **Diagnostic artifacts.** Memory dumps, diagnostic bundles, screenshots, and exported files that contain Customer Content are protected as Customer Content. VESSL will create them only when technically necessary for an authorized case, restrict and log access, store them securely, and delete them promptly after the documented purpose is complete unless applicable law requires preservation.

## 9. Out of Scope

This Support Policy does not cover:

* Customer's own software, applications, or models;
* Third-party software not provided by VESSL;
* Customer-side networking, devices, or infrastructure;
* Beta, Preview, Early Access, or other pre-general-availability Services or features (which receive support on a best-efforts basis only);
* Custom development, integrations, or professional services (which are subject to separate agreements).

## 10. Updates

VESSL may update this Support Policy only in accordance with MSA Section 14.10. The "Last updated" date above reflects the latest version.

***

VESSL AI, Inc. — [support@vessl.ai](mailto:support@vessl.ai)


# VM Cluster service terms
Source: https://docs.cloud.vessl.ai/legal/vm-cluster

Service-specific terms for the VESSL Cloud VM Cluster service.

<Info>
  Effective date: October 5, 2026 · Last updated: September 28, 2026
</Info>

These VM Cluster Service Terms ("**VM Cluster Terms**") supplement the [Master Services Agreement](/legal/msa) (the "**MSA**") and govern Customer's use of the VESSL VM Cluster services (the "**VM Cluster Services**"). In the event of a conflict between these VM Cluster Terms and the MSA, these VM Cluster Terms will prevail over the MSA to the extent of the conflict, in accordance with the order of precedence set out in MSA Section 2.2.

Capitalized terms not defined here have the meanings given in the MSA.

## 1. Description of the VM Cluster Services

The VM Cluster Services are VESSL's managed GPU virtual-machine platform, providing Customer with dedicated GPU-accelerated virtual machine clusters with root-level SSH access, high-speed interconnect networking, and optional shared file-system storage. Each VM Cluster consists of one or more Nodes provisioned on infrastructure operated by VESSL or by an underlying infrastructure provider engaged by VESSL as a Sub-processor. VM Cluster Services are available exclusively to B2B Customers under an applicable Order.

Customer accesses the VM Cluster Services through the VESSL platform (including the console, API, and/or CLI) and connects to individual Nodes via SSH using Customer-registered SSH keys. Customer does not have direct, unmodified access to the underlying infrastructure provider's console, API, or credentials.

The VM Cluster Services are distinct from the Container Compute Services (Workspaces and Batch Jobs) described in the Container Compute Service Terms. The VM Cluster Services provide full virtual-machine-level access with GPU passthrough, whereas the Container Compute Services provide container-based compute environments. The two are governed by separate Service-Specific Terms.

## 2. Definitions

In addition to the terms defined in the MSA, the following terms apply to these VM Cluster Terms:

**"Boot Disk"** means the local disk attached to a Node. Boot Disk storage is local to the physical server hosting the Node and is not replicated or backed up by VESSL.

**"Contract Duration"** means the period stated in the applicable private Order Form during which the VM Cluster is active.

**"Extension"** means a request by Customer to extend the Contract Duration of an existing VM Cluster beyond its original end date, subject to approval by VESSL.

**"Firewall Rules"** means the inbound network access-control rules that Customer configures at the VM Cluster level through the VESSL platform.

**"Health Status"** means the operational status of a Node as determined by VESSL's monitoring agents. Current Health Status classifications are described at [Health checks](/vm-clusters/health-checks).

**"NFS Storage"** means the optional Network File System shared storage that is mounted across all Nodes in a VM Cluster and is available for Customer's use during the Contract Duration.

**"Node"** means a single VM within a VM Cluster, mapped one-to-one to a dedicated physical server. GPUs are not shared with other customers.

**"Order"** means a private Order Form or other written transaction document accepted by VESSL that identifies the VM Cluster configuration and incorporates these VM Cluster Terms.

**"VM Cluster"** means a group of one or more Nodes provisioned as a unit under a single Order, together with any associated NFS Storage and networking resources.

## 3. Service Status

The VM Cluster Services are generally available Services. The warranties, disclaimers, limitations of liability, and indemnification provisions of the MSA apply in accordance with their terms. Service levels are governed by Section 15 of these VM Cluster Terms.

## 4. Ordering and Provisioning

### 4.1 Sales-Assisted Request and Order Form

Customer may request a VM Cluster configuration through VESSL's sales or support channel. VESSL may accept, decline, or propose changes to the request based on capacity, technical feasibility, credit review, and other reasonable commercial or operational considerations. A request does not guarantee GPU availability or create a binding commitment. A binding commitment arises only when the applicable private Order Form or other written transaction document is accepted by VESSL and Customer in accordance with its terms and any stated payment or security prerequisite is satisfied.

### 4.2 Configuration

The GPU model, number of Nodes, NFS Storage capacity, Region, Contract Duration, Fees, and other configuration details are stated in the applicable Order.

### 4.3 Provisioning

After the applicable Order becomes effective and its stated prerequisites are satisfied, VESSL will use commercially reasonable efforts to provision the VM Cluster. Provisioning timelines are estimates and are not guaranteed unless the applicable Order expressly states otherwise. VESSL will notify Customer when the VM Cluster is active and SSH access is available.

## 5. Contract Terms

### 5.1 Duration

The Contract Duration and any renewal or extension rights are stated in the applicable private Order Form. No minimum or maximum Contract Duration is created by the public Documentation.

### 5.2 Commencement and Expiration

The Contract Duration commences when VESSL marks the VM Cluster as active. The VM Cluster expires automatically at the end of the Contract Duration. There is no automatic renewal.

### 5.3 Extension

Customer may request an Extension of the Contract Duration while the VM Cluster is in provisioning or active status. Extensions are subject to:

(a) VESSL's approval, which may consider capacity commitments to other customers;

(b) re-pricing at the then-applicable rate (VESSL is not obligated to maintain the original pricing); and

(c) Customer's completion of payment for the Extension period.

An approved Extension extends the existing VM Cluster; it does not create a new Order. Node specifications and NFS Storage capacity cannot be changed through an Extension; changes to specifications require a new Order.

### 5.4 Cancellation

Cancellation, committed Fees, and refunds are governed by the applicable Order and the MSA. Unless the applicable Order states otherwise, Customer may not cancel after provisioning has commenced, and Fees are non-refundable except as required by applicable law or where VESSL terminates the affected VM Cluster Services due to VESSL's uncured material breach.

### 5.5 No Specification Changes

Customer may not change the GPU model, number of Nodes, NFS Storage capacity, or other hardware specifications of a VM Cluster during the Contract Duration. If Customer requires different specifications, Customer must submit a new Order.

## 6. Hardware and Access

### 6.1 GPU Configuration

Each Node is a dedicated virtual machine with GPU passthrough, mapped one-to-one to a physical server. GPUs are not shared with other customers. The GPU model, GPU count per Node, and other hardware specifications are as set out in the Order.

### 6.2 Root Access

Customer receives root-level SSH access to each Node. Customer may install software, modify the operating system and kernel, install or replace GPU drivers, load kernel modules, and otherwise exercise full administrative control over the Node's operating environment.

**Customer assumes full responsibility for any consequences arising from the exercise of root access**, including system instability, data loss, security vulnerabilities, driver incompatibility, and workload failures caused by Customer's modifications. Modifications that interfere with VESSL's monitoring agents or platform-managed components are subject to Section 9.4. Issues caused by Customer's modifications to the base operating system, drivers, or kernel are not treated as service incidents and are excluded from the applicable service-level measurement under the SLA or any other service-level provision applicable to the affected Order.

### 6.3 InfiniBand

Nodes in a multi-Node VM Cluster include InfiniBand networking for high-bandwidth inter-node communication. VESSL provides logical tenant isolation on the InfiniBand fabric so that customers cannot access or control each other's resources. Due to the shared physical nature of the InfiniBand infrastructure, complete physical-layer isolation is not provided. VESSL does not guarantee specific bandwidth, latency, or topology characteristics. A single-Node VM Cluster does not use InfiniBand for inter-node communication. Additional current technical information is described at [Understand VM Clusters](/vm-clusters/overview).

### 6.4 Base Image

VESSL provisions each Node with a base operating-system image as described in the Documentation (see [Understand VM Clusters](/vm-clusters/overview)). Customer may modify or replace the base image at Customer's own risk, subject to Section 6.2. Third-party software components included in the base image are subject to their respective licenses.

## 7. Storage

### 7.1 Boot Disk

Each Node includes a Boot Disk for local storage. The Boot Disk is local to the physical server hosting the Node and is not replicated, snapshotted, or backed up by VESSL. The Boot Disk capacity is determined by the underlying hardware and is not configurable by Customer.

**Boot Disk data may be permanently lost in the event of hardware failure, node replacement, auto-recovery, or reboot to a different physical server.** Customer must store all important data, including training checkpoints, model weights, datasets, and configuration files, on NFS Storage or an off-platform backup system. VESSL is not responsible for any data stored solely on a Boot Disk.

### 7.2 NFS Storage

Customer may optionally include NFS Storage in the Order. NFS Storage is a shared file system mounted on all Nodes in the VM Cluster, providing persistent shared storage for training data, checkpoints, and other artifacts.

(a) **Capacity**: The NFS Storage capacity, availability, and Fees are stated in the applicable Order.

(b) **Persistence**: NFS Storage data is preserved across individual node reboots and node replacements within the same VM Cluster. NFS Storage data is deleted upon expiration of the Contract Duration in accordance with Section 12.

(c) **Access**: NFS Storage is accessible only from Nodes within the associated VM Cluster. Cross-cluster NFS access is not supported.

### 7.3 NFS Capacity Management

VESSL monitors NFS usage and may notify Customer if usage approaches or exceeds the selected capacity. If Customer exceeds the selected capacity, VESSL may contact Customer to arrange additional capacity at additional cost.

### 7.4 Storage Durability

VESSL does not provide a numerical storage-durability commitment for Boot Disks or NFS Storage. Customer should design workloads on the assumption that storage media may fail.

## 8. Networking

### 8.1 Public IP

Each Node is assigned a public IP address for SSH access and outbound connectivity. Customer does not acquire ownership of any IP address assigned by VESSL. VESSL may reassign IP addresses upon contract termination, node replacement, or for operational reasons.

### 8.2 Firewall Rules

Customer is responsible for configuring and maintaining Firewall Rules to control inbound network access to the VM Cluster. Customer manages Firewall Rules directly through the VESSL platform at the VM Cluster level. VESSL does not provide managed firewall rules, intrusion-detection services, or default deny-all policies unless otherwise stated in the Documentation (see [Configure firewall rules](/vm-clusters/firewall-rules)).

**Customer is solely responsible for the security of the Firewall Rules configuration**, including any unauthorized access that results from misconfigured or overly permissive rules.

### 8.3 Egress Traffic

Inbound and outbound data-transfer treatment, including any included usage and charges, is governed by the applicable Order.

### 8.4 Network Performance

VESSL does not guarantee specific network throughput, latency, or packet-loss characteristics for Ethernet connectivity. InfiniBand performance is subject to the conditions in Section 6.3.

## 9. Customer Responsibilities

This Section sets out Customer-side responsibilities specific to the VM Cluster Services. VESSL's obligations are governed by the [MSA](/legal/msa), the [Data Processing Agreement](/legal/dpa) (DPA), the [Privacy Policy](/legal/privacy), and the [SLA](/legal/sla).

### 9.1 Configuration and Operations

Customer is responsible for all aspects of the workloads running on the VM Cluster, including operating-system configuration, software installation, GPU driver management, kernel modifications, security hardening, container orchestration, and application deployment. VESSL provides the base infrastructure and platform; Customer operates the workload layer.

### 9.2 Security

Customer is responsible for:

(a) the security of all software, configurations, and data on the Nodes, including any software installed or modifications made under root access;

(b) the configuration and management of Firewall Rules (Section 8.2);

(c) SSH key management and access control for Authorized Users;

(d) timely application of security patches to Customer-installed software;

(e) monitoring for and responding to unauthorized access, malware, or other security incidents within Customer's Nodes; and

(f) compliance with the Acceptable Use Policy (AUP).

### 9.3 Backup and Data Protection

Customer is solely responsible for backing up all Customer Content, including data stored on Boot Disks and NFS Storage. VESSL does not perform backups of Customer Content on VM Clusters. Customer should maintain independent, off-platform copies of all critical data. Boot Disk data is at particular risk of loss (see Section 7.1).

### 9.4 Monitoring Agent Integrity

VESSL deploys monitoring agents on each Node for health monitoring and platform operations. Customer must not disable, remove, or materially reconfigure VESSL-installed monitoring agents without VESSL's prior written approval. If Customer interferes with monitoring agents, VESSL may limit the scope of support provided for the affected Nodes. If the SLA or another service-level provision applies to the affected Nodes, VESSL may also calculate the applicable service-level measurement from the time Customer reports the incident rather than from the time VESSL's monitoring would otherwise have detected it.

## 10. Billing and Payment

### 10.1 Configuration and Fees

The applicable Order governs the VM Cluster configuration, GPU Node charges, NFS Storage charges, data-transfer charges, committed Fees, and other applicable rates.

### 10.2 Payment

The applicable Order or invoice governs the due date, payment method, currency, taxes, and other payment terms.

### 10.3 Credits Exclusion

Purchased Credits and Promotional Credits may not be applied to VM Cluster Services unless VESSL expressly agrees otherwise in writing. Service Credits issued for a Node covered under Section 4 of the [SLA](/legal/sla) are applied in accordance with the SLA and the applicable Order.

### 10.4 Extensions

An Extension requires VESSL's written approval. The applicable rate and payment terms are determined when the Extension is approved and may differ from the original Order.

### 10.5 Refunds

Fees paid for VM Cluster Services are non-refundable after provisioning has commenced, except as required by applicable law, as expressly stated in the applicable Order, or where VESSL terminates the affected VM Cluster Services due to VESSL's uncured material breach, in which case Customer is entitled to a pro-rated refund of the unused allocable prepaid Fees.

## 11. Health Monitoring and Recovery

VESSL monitors Node Health Status and, in the event of a detected node failure, will attempt to reboot the affected Node. **The Node may be restarted on a different physical server, and Boot Disk data may be lost** (see Section 7.1). VESSL does not guarantee any specific recovery time except as expressly agreed in the applicable Order or SLA. Support and escalation are governed by the Support Policy and any applicable support commitments under the Order.

Current Health Status visibility, Customer-initiated reboot behavior, and metrics display are described at [Health checks](/vm-clusters/health-checks), [Reboot a node](/vm-clusters/reboot), and [Metrics](/vm-clusters/metrics). Those pages do not create a contractual metrics-retention period, response time, recovery time, or escalation commitment.

## 12. Data Retention on Expiration

### 12.1 No Grace Period

Upon expiration of the Contract Duration, VESSL will immediately:

(a) terminate all Nodes in the VM Cluster;

(b) reclaim the underlying hardware resources; and

(c) permanently delete all Customer Content on Boot Disks and NFS Storage associated with the VM Cluster.

**There is no grace period for data retrieval after expiration.** Customer must download or back up all Customer Content before the Contract Duration expires.

### 12.2 Advance Notice

VESSL will send email notifications to Customer's registered email address in advance of the expiration date to remind Customer to back up all data; the current reminder schedule is described at [Plan for data retention](/vm-clusters/data-retention). Failure to send or receive such notifications does not extend the Contract Duration or create an obligation for VESSL to preserve data.

### 12.3 Customer Responsibility

Customer is solely responsible for downloading or backing up all Customer Content before the expiration of the Contract Duration. VESSL has no obligation to retain, return, or make available any Customer Content after expiration. VESSL's deletion of Customer Content upon expiration is not a breach of this Agreement.

### 12.4 Cancelled or Declined Orders

If an Order is cancelled before provisioning or declined by VESSL, no Customer Content will have been stored on the VM Cluster, and no data-retention obligations arise.

## 13. Maintenance and Replacement

### 13.1 Scheduled Maintenance

VESSL may perform scheduled maintenance on the infrastructure underlying the VM Cluster Services. Maintenance notice requirements and the treatment of maintenance in availability calculations are governed by the applicable SLA and Order.

### 13.2 Node Replacement

VESSL may replace a Node's underlying physical hardware. Node replacement may result in the loss of Boot Disk data. VESSL will use commercially reasonable efforts to coordinate replacements to minimize disruption. NFS Storage data is preserved across node replacements. Replacement is based on VESSL's reasonable operational determination, including observed hardware failure or degraded Health Status; current health-check information is available at [https://docs.cloud.vessl.ai/vm-clusters/health-checks](/vm-clusters/health-checks).

### 13.3 Infrastructure Migration

If VESSL reasonably determines that continued operation on the existing infrastructure is not commercially or technically feasible, VESSL may migrate the VM Cluster to alternative infrastructure in the same Region with reasonable advance notice and migration support.

For Cross-Region migrations, VESSL will provide Customer with at least 30 days' advance written notice. If Customer does not object in writing within 30 days of receipt of notice, Customer will be deemed to have consented to the migration. If Customer objects, Customer may terminate the affected VM Cluster Order without penalty and receive a pro-rated refund of pre-paid Fees allocable to the unused portion of that Order's Contract Duration.

This Section does not apply where migration is required to address a security incident, regulatory requirement, or Force Majeure Event.

## 14. Acceptable Use

The [Acceptable Use Policy](/legal/acceptable-use) (AUP) applies in full to all use of the VM Cluster Services. Without limiting the AUP, the grant of root access under Section 6.2 does not authorize Customer to access, probe, or interfere with:

(a) infrastructure, networks, or systems outside Customer's VM Cluster, including the hypervisor layer and management networks; or

(b) other tenants' data, workloads, network segments, or environments.

## 15. Service Levels

Nodes provisioned under an Order are Covered Services under Section 4 of the public [SLA](/legal/sla) by default, unless the applicable Order or Custom SLA Addendum expressly provides otherwise. A private SLA or other service-level provision applies to the extent expressly incorporated into the applicable Order. Service Credits under an applicable SLA are Customer's sole monetary remedy for a failure to meet its metrics, subject to the exceptions and no-double-recovery rule in that SLA and MSA Section 13.

## 16. Modifications

VESSL may update these VM Cluster Terms only in accordance with MSA Section 14.10.

***

VESSL AI, Inc. — [legal@vessl.ai](mailto:legal@vessl.ai)