Admin SDK and dashboard

The HUB's Admin API drives accounts, users, regions, storages, volumes, and access keys. Reach it with the Admin SDK or over REST.

Authentication

Backends sign requests with the admin key. appserv verifies each signature against PROVIDER_VERIFICATION_KEY. Only backends hold the admin key. It never reaches a browser.

mountOS uses two key pairs here. The admin key (MOUNTOS_SDK_SIGNING_KEY, which appserv verifies against PROVIDER_VERIFICATION_KEY) authorizes Admin API calls. The dashboard session pair (DASHBOARD_SIGNING_KEY and DASHBOARD_VERIFICATION_KEY) backs the opaque token that the dashboard browser holds.

mountOS carries user-level authorization separately. A dedicated DASHBOARD_USER_HMAC_KEY signs it. Only the dashboard backend and appserv share that key. DASHBOARD_USER_HMAC_KEY is a distinct secret from the public PROVIDER_VERIFICATION_KEY. The two authorization scopes stay separate.

SDK

The SDK is open source. One API spec generates its TypeScript, Go, and Rust packages. All three expose the same resource groups:

• Accounts and users
• Regions and metadata clusters
• Storages and volumes, with forks and API keys
• Audit logs
• Nodes and client sessions
• Alerts
• License
• Vault
• Discovery
• The dashboard

mountOS versions the packages together with the API. The npm package also ships a SKILL.md with version-matched guidance for AI agents. The admin SDK repository has the source and reference.

npm i @mountos-io/admin-sdk

import { createServerClient } from '@mountos-io/admin-sdk'

const client = createServerClient({
  baseUrl: 'https://hub.example.com',
  privateKey: process.env.MOUNTOS_SDK_SIGNING_KEY!,
})

const { id } = await client.accounts.create({ name: 'mountOS' })

go get github.com/mountos-io/mountos-admin-sdk/go

import sdk "github.com/mountos-io/mountos-admin-sdk/go"

client, err := sdk.NewClient(sdk.Config{
  BaseURL:    "https://hub.example.com",
  PrivateKey: os.Getenv("MOUNTOS_SDK_SIGNING_KEY"),
})

acct, err := client.Accounts.Create(ctx, &sdk.CreateAccountRequest{Name: "mountOS"})

cargo add mountos-admin-sdk

use mountos_admin_sdk::{Client, Config, CreateAccountRequest};

let client = Client::new(Config {
    base_url: "https://hub.example.com".into(),
    private_key: std::env::var("MOUNTOS_SDK_SIGNING_KEY").unwrap(),
    ..Default::default()
})?;

let created = client.accounts.create(&CreateAccountRequest {
    name: "mountOS".into(),
    description: None,
    icon_url: None,
    provider_info: None,
}).await?;

REST

appserv serves the API under /api/v1 on the HUB domain. Each request carries a bearer token in the Authorization header. The token is a JWT. The admin key signs it. The SDKs mint it automatically. For direct REST calls, api.md in the SDK repository documents every route and the token claims.

curl https://hub.example.com/api/v1/accounts/list \
  -H "Authorization: Bearer $JWT"

Other languages

The API spec, api.yaml, generates the three packages above. Use it to generate a client in any other language. Or contact support@mountos.io.

Dashboard

The admin dashboard is an optional UI over the same Admin API. Anything it does is also an SDK or REST call.

It runs as a browser frontend with a small backend gateway. The gateway holds the admin key and signs requests. The browser holds only a short-lived opaque session token. The dashboard is open source. It is published as mountos-admin-client.

A native companion, mountos-desktop(opens in new tab), is the open-source macOS menu bar and Windows system tray client. It drives the same mountos CLI to mount volumes, manage profiles, and run bulk upload, download, and HLS sink jobs. Each job keeps the CLI's own retry, resume, and status tracking. You can fork it to customize.