Kubernetes

Mount Thor provides a Kubernetes interface for managing bare-metal Macs and macOS virtual machines at scale. This interface runs in parallel with the mthr CLI: use Kubernetes resources for declarative or large-scale management, or use mthr as a convenient command-line workflow. Your compute resources appear in your tenant namespace as Kubernetes objects, so you can manage them with ordinary kubectl commands:

virtualmachines — your macOS virtual machines.
baremetalmachines — your allocated bare-metal Macs.

Both are custom resources in the compute.mountthor.com API group. List and inspect them the same way you would any Kubernetes object — for example kubectl get virtualmachines or kubectl get baremetalmachines — subject to your role’s permissions. Before provisioning compute, set up your billing information and top up your prepaid balance in the Mount Thor portal.

Generate a kubeconfig

mthr login
mthr kubeconfig --out ~/.kube/mount-thor

A valid session is required to mint the credential. Omit --out to be prompted for a path; the default is ~/.kube/mount-thor. Use --out - to write the kubeconfig to stdout.

Use it

Point kubectl at the generated file:

export KUBECONFIG=~/.kube/mount-thor
kubectl get virtualmachines

Or pass it per command with kubectl --kubeconfig ~/.kube/mount-thor. The kubeconfig’s default namespace is your tenant’s namespace (mthr-<tenant>), so bare commands target the right place without -n.

Provision a bare-metal Mac

Create my-mac.yaml:

apiVersion: compute.mountthor.com/v1alpha1
kind: BareMetalMachine
metadata:
  name: my-mac
spec:
  class: m4-24g
  image: macos-26

Apply the request and watch until the machine is ready:

kubectl apply -f my-mac.yaml
kubectl get baremetalmachine my-mac --watch

When it is ready, connect with the CLI:

mthr bm ssh my-mac

You can also use mthr bm desktop my-mac for desktop access. The CLI opens the connection locally and keeps the access session active while the command runs. Delete the resource to release the Mac:

kubectl delete baremetalmachine my-mac

Provision a virtual machine

A VM created with Kubernetes needs an SSH public key for access. Create a dedicated key pair for this VM, or use an existing key pair:

ssh-keygen -t ed25519 -f ./my-vm-key -N ""

Create my-vm.yaml. Replace SSH_PUBLIC_KEY with the contents of ./my-vm-key.pub. The public key is safe to include in the manifest; never include the private key.

apiVersion: compute.mountthor.com/v1alpha1
kind: VirtualMachine
metadata:
  name: my-vm
spec:
  class: m4-24g
  image: macos-26
  sshAuthorizedKeys:
  - publicKey: SSH_PUBLIC_KEY

Apply the request and watch until the VM is running:

kubectl apply -f my-vm.yaml
kubectl get virtualmachine my-vm --watch

Connect to the VM using the matching private key:

mthr vm ssh my-vm --identity-file ./my-vm-key

You can also use mthr vm desktop my-vm for desktop access. See Virtual machines for the VM preview and connection details. Delete the resource when finished:

kubectl delete virtualmachine my-vm

The mthr vm create workflow manages an SSH key automatically. When provisioning through Kubernetes, you provide the public key explicitly so the matching private key can remain under your control.

Staying signed in

The kubeconfig file does not expire. It embeds an exec credential plugin that refreshes your access automatically in the background, so kubectl keeps working without regenerating the file.

Binary path

By default the embedded exec plugin invokes mthr by name, so mthr must be on your $PATH for kubectl to work. For installs where it is not, bake an explicit path into the kubeconfig:

mthr kubeconfig --out ~/.kube/mount-thor --exec-command /opt/mthr/bin/mthr

You can also set the path with the MOUNTTHOR_KUBECONFIG_EXEC_COMMAND environment variable.

Credentials and revocation

No secret is stored in the kubeconfig file. The exec plugin supplies a short-lived client certificate to kubectl on demand. Revoke the Kubernetes access session and clear the cached credential with:

mthr logout

Permissions

Generating a kubeconfig and authenticating does not by itself grant permissions inside the cluster. What you can do is governed by your assigned role. If kubectl returns Forbidden, that is an authorization matter for your role, not a problem with the kubeconfig. For the CLI workflow, see Bare metal or Virtual machines.

Compute

Platform

API Reference

Generate a kubeconfig

Use it

Provision a bare-metal Mac

Provision a virtual machine

Staying signed in

Binary path

Credentials and revocation

Permissions

​Generate a kubeconfig

​Use it

​Provision a bare-metal Mac

​Provision a virtual machine

​Staying signed in

​Binary path

​Credentials and revocation

​Permissions

Generate a kubeconfig

Use it

Provision a bare-metal Mac

Provision a virtual machine

Staying signed in

Binary path

Credentials and revocation

Permissions