API keys

Use API keys when you need RemoteGPU access outside the signed-in console.

The two main use cases are:

• calling the Inference API
• using kubectl with RemoteGPU Kubernetes namespaces

If you only work in the console UI, you usually do not need an API key.

Before you create a key

Choose the narrowest key that matches the workflow:

• Console-only users usually do not need an API key.
• Text or Image API callers should create an Inference key.
• kubectl or CI workflows for RemoteGPU Kubernetes namespaces should create a Kubernetes exec key.
• Combined automation should use separate keys when practical. Use an All key only when one workflow genuinely needs both surfaces.

Create an API key in the console

From the console:

1. Open Settings / API Keys
2. Click Create API key
3. Enter a name
4. Choose the scope you need
5. Optionally set an expiration
6. Save the key value somewhere secure

The full key is only shown when it is created. After that, the console only shows the key prefix.

Choose the right scope

Scope	Use it for	Typical caller	Notes
Inference	Text and image inference requests	Application server, script, backend job	Sends the key as a Bearer token
Kubernetes exec	kubectl against a RemoteGPU namespace	Local shell, CI, platform operator	Can be scoped to selected namespaces or all namespaces in the account
All	Combined automation	Admin automation	Use only when one workflow genuinely needs both surfaces

Common key workflows

Use an Inference key when your application needs to call the Text or Image API.

Typical flow:

1. Create a key with the Inference scope.
2. Store it in your application secret manager or runtime environment.
3. Send it in the Authorization: Bearer <api-key> header.

Inference requests send the key in the Authorization header as a Bearer token.

curl -X POST "https://api.remotegpu.ai/v1/inference/image" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{
    "prompt": "YOUR_PROMPT",
    "model": "black-forest-labs/FLUX.1-dev"
  }'

Continue with Text or Image for the full request flow.

Operational guidance

Practice	Why it matters
Use separate keys for separate systems	Limits blast radius when one system changes or leaks
Prefer Inference over All when possible	Keeps application clients away from Kubernetes access
Prefer namespace-scoped Kubernetes exec keys	Reduces accidental cross-namespace access
Set expirations for temporary automation	Makes cleanup predictable
Revoke leaked or unused keys immediately	Removes stale credentials from circulation

Common outcomes

Status code	Meaning
401	The key is missing, invalid, revoked, or expired
403	The key is valid but does not allow the requested product flow
400	The scope payload or expiration is invalid while creating or editing a key

Troubleshooting

Symptom	What to check
Inference API returns 401	Confirm the request sends Authorization: Bearer <api-key>, the full key value was saved at creation time, and the key has not expired or been revoked
Inference API returns 403	Confirm the key scope includes Inference; use a separate Inference key when the caller only needs model access
kubectl cannot refresh credentials	Confirm REMOTEGPU_API_KEY is exported in the shell or CI environment that runs kubectl
kubectl can authenticate but cannot access the namespace	Confirm the key is scoped to the namespace in the downloaded kubeconfig, or create a namespace-scoped key for that namespace
One automation needs both API and kubectl access	Use an All key only when the workflow cannot be split across separate Inference and Kubernetes exec keys

Read next

• Read Text or Image to use an inference key.
• Read Kubernetes overview to use a Kubernetes exec key with kubectl.