5 min read

One Command Center for Every Environment

Skyportal
Featured
One Command Center for Every Environment

One Command Center for Every Environment

Infrastructure rarely lives in one neat box. A production AI stack can span GPU servers, application hosts, staging environments, and multiple Kubernetes clusters—often while an incident is already unfolding. The latest SkyPortal CLI and Python SDK updates bring those systems into one automation-friendly command center.

SkyPortal now gives platform engineers, DevOps teams, SREs, MLOps engineers, and AI infrastructure teams a consistent way to scope an investigation across multiple hosts, connect Kubernetes clusters, automate agent chats, and keep human approval in the loop for sensitive changes.

The result is a faster path from "something changed" to "we know where, why, and what to do next."

What is new in the SkyPortal CLI and Python SDK?

This release expands the open-source SkyPortal developer experience in four important ways:

  • Multi-host infrastructure scope for comparing and operating across selected servers
  • Kubernetes cluster lifecycle commands for connecting, listing, and disconnecting clusters
  • Namespace-aware Kubernetes automation using explicit allowlists
  • Concurrent command execution across scoped SSH hosts and Kubernetes targets, with consolidated approvals when needed

It also preserves the automation features teams expect from a modern infrastructure CLI: stable JSON output, API-key authentication, resumable agent chats, polling, approvals, cancellations, observability data, and backwards-compatible single-server workflows.

Connect Kubernetes without leaving the terminal

You can now connect a Kubernetes cluster directly through the skyportalai CLI:

skyportalai kubernetes connect production \
  --kubeconfig ~/.kube/config \
  --environment Production

skyportalai kubernetes list

Once connected, the cluster receives a normal SkyPortal infrastructure ID. That means Kubernetes can participate in the same agent chat workflow as the rest of your infrastructure:

skyportalai chat send \
  --server 17 \
  --namespace 17=default \
  --wait \
  "Restart the api deployment and verify the rollout"

When the cluster is no longer needed, disconnect it and remove the stored credential:

skyportalai kubernetes disconnect 17

The lifecycle API never returns kubeconfig credential material. The CLI sends the kubeconfig only to the authenticated SkyPortal API, where the existing validation and encrypted-storage path handles it. Local input is bounded by a 1 MiB safety limit, empty or invalid files fail early, and non-interactive JSON mode requires an explicit --yes before disconnecting a cluster.

One AI infrastructure chat, multiple hosts

Multi-host support turns a SkyPortal agent chat into an explicit infrastructure workspace. Repeat --server to create the allowlist, choose the default target with --active-server, and attach namespace scope to Kubernetes targets:

skyportalai chat send \
  --server 12 \
  --server 18 \
  --active-server 12 \
  --namespace 18=default \
  --namespace 18=vllm \
  --wait \
  "Compare GPU health and deployment status on all selected hosts"

The first selected server is the default when a prompt is ambiguous. SkyPortal broadcasts only when the request explicitly targets the selected hosts. This gives operators a clear, predictable boundary: the selected server IDs are an allowlist, not a suggestion.

Need to change scope between turns? Update the existing chat without starting the investigation over:

skyportalai chat select-servers 123 \
  --server 12 \
  --server 18 \
  --active-server 12 \
  --namespace 18=default \
  --namespace 18=vllm

skyportalai chat send \
  --chat-id 123 \
  --wait \
  "Compare the rollout with the GPU regression we found earlier"

Use --clear-scope when you want to remove all selected infrastructure explicitly. For cluster-wide access, __all__ is available, but narrow namespace allowlists remain the safer default for Kubernetes operations.

Automate the same workflow with the SkyPortal Python SDK

The public Python SDK exposes the same multi-host model. You can establish the entire scope atomically before the first agent turn begins:

from skyportalai import Skyportal

with Skyportal(api_key="sk-...") as client:
    chat = client.chat.create_chat(
        "Compare GPU health across the selected environments",
        server_ids=[12, 18],
        active_server_id=12,
        selected_namespaces={18: ["default", "vllm"]},
    )
    result = chat.wait(on_approval=lambda approval: True)
    print(result.status)

Kubernetes lifecycle operations are available from the same client:

from pathlib import Path

from skyportalai import Skyportal

with Skyportal(api_key="sk-...") as client:
    cluster = client.kubernetes.connect(
        "production",
        Path.home().joinpath(".kube/config").read_text(),
        environment="Production",
    )
    print(cluster.id, cluster.connection_verified)

Existing integrations do not have to migrate immediately. The singular server_id=12 form remains supported, while server_ids, active_server_id, active_host_id, and selected_namespaces unlock the richer execution model.

Concurrent SSH and Kubernetes operations—with guardrails

Under the hood, SkyPortal can execute a concurrent batch across in-scope SSH servers and Kubernetes clusters. Each command item has an explicit target kind and, for Kubernetes, an optional namespace. The execution layer keeps those worlds separated:

  • kubectl and helm commands run only against Kubernetes targets
  • SSH commands cannot be silently routed to a Kubernetes cluster
  • Kubernetes batch items target one cluster at a time, while multiple batch items can still run concurrently
  • Out-of-scope server IDs are rejected before dispatch
  • Output is aggregated per command so partial failures remain visible

When a batch contains sensitive or mutating operations, SkyPortal requests one consolidated approval that lists the exact command-target pairs. Approval markers are one-time and scoped to those specific actions. This keeps infrastructure automation fast without turning speed into blanket authorization.

Built for CI/CD, incident response, and platform engineering

The skyportalai command supports stable JSON output for scripts, runbooks, and CI/CD pipelines:

skyportalai --json chat messages 123
skyportalai --json kubernetes list

Set SKYPORTAL_API_KEY for authentication and SKYPORTAL_BASE_URL for a self-hosted deployment. The CLI can wait for a workflow to settle, poll with a configurable interval, return pending approvals, approve or reject an action, cancel active work, and retrieve messages with a sequence cursor.

That makes the same SkyPortal workflow useful in several places:

  • Kubernetes troubleshooting during a deployment or production incident
  • GPU infrastructure monitoring across training and inference hosts
  • MLOps automation for model-serving environments such as vLLM
  • DevOps and SRE runbooks that need readable output and machine-readable JSON
  • Multi-cloud infrastructure management across heterogeneous compute
  • Platform engineering workflows that preserve namespace and server boundaries
  • AI operations and observability that connect symptoms to recent changes

Prefer an interactive terminal? That got multi-host support too

The conversational SkyPortal terminal now accepts more than one server in /server:

/servers
/server 12 18
/status
compare GPU utilization and recent deployments across both hosts

The first ID becomes the active default while all selected IDs define the available execution scope. You can still use /new, /resume, and the familiar persistent chat flow when moving from diagnosis to remediation.

Get started

SkyPortal is an open-source AI infrastructure engineer for Kubernetes, GPU systems, deployments, observability, and production operations. To try the latest CLI and Python SDK:

git clone https://github.com/SkyportalAi/skyportalai.git
cd skyportalai
./run.sh

Then run /login, use /servers to discover your infrastructure, and select one or more targets with /server.

With multi-host context, Kubernetes-native execution, namespace allowlists, concurrent command batches, approval gates, and programmable Python APIs, SkyPortal gives infrastructure teams a single operational interface without flattening the safety boundaries that matter.

Your infrastructure can span environments. Your command center should too.