> ## Documentation Index
> Fetch the complete documentation index at: https://docs.nuphos.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Linode (Akamai)

> Connect a Linode / Akamai Cloud account to manage instances and LKE clusters.

Nuphos authenticates to Linode — **Akamai Cloud** — with a **personal access
token**, which lets the agent work with your Linodes and managed Kubernetes
(LKE) clusters.

## Connect

### Create a personal access token

In the Linode Cloud Manager, create a **personal access token** (Account → API
Tokens) with read/write access to at least:

* **Linodes**
* **Kubernetes (LKE)**

The token is shown once — copy it.

### Connect in Nuphos

In **Connectors → Connect → Linode**, enter:

| Field                     | Notes                                     |
| ------------------------- | ----------------------------------------- |
| **Label**                 | A friendly name, e.g. "My Linode account" |
| **Personal Access Token** | The token you created                     |

Nuphos verifies the token before saving; an invalid or revoked token is rejected.
The token is stored encrypted.

## In the Nuphos app

* **[Kubernetes clusters](/infrastructure/clusters)** — your LKE clusters appear
  alongside EKS and GKE. Nuphos pulls the kubeconfig for you, so you can browse
  workloads, open pod terminals, and stream logs without any manual setup.
* **[Compute & access](/infrastructure/compute)** — your Linode instances show
  up with status and details next to the rest of your fleet.

## What the agent can do for you

The agent can list your Linodes and LKE clusters and operate the clusters with
the same Kubernetes tooling it uses everywhere else. Ask it things like:

* *"Why is the `worker` deployment on LKE stuck pending?"* — it reads events,
  node status, and config to find the cause.
* *"Which of my Linodes is running out of disk?"* — it inspects the fleet and
  reports back.

## Permissions & authorization

Two boundaries govern what happens through this connector:

* **Hard boundary — who can use it.** Only team **Administrators** can bind or
  remove the token, and they can restrict it to specific members with a
  [member allow-list](/security/access-control). Within a session the agent only
  holds credentials you explicitly selected, re-checked on every request.
* **Soft boundary — what the agent may do with it.** Reads run freely, but
  changes go through [plan approvals](/security/approvals), and at the command
  level [Auto-authorization](/security/auto-mode) keeps read-only commands
  flowing while anything destructive pauses for a human.

The outer limit is the token's own scopes — grant it only the services (and
read/write levels) you want the agent to reach, and Linode enforces the rest.

## Good to know

* Linode tokens can carry an **expiry date** — a reasonable extra safety net;
  just remember to rotate the binding before it lapses.
* To keep environments separate, create one token per purpose and connect them
  as separate bindings, each with its own allow-list.