Kubernetes on RemoteGPU

RemoteGPU gives you a managed Kubernetes environment that you can use from the console, from kubectl, or from both at the same time.

This part of the product is designed for teams that are comfortable managing Kubernetes resources.

Kubernetes use cases

Kubernetes is for teams that need to run and operate their own container workloads in a namespace.

Typical use cases include:

• running containers with deployments, jobs, or cronjobs
• managing resources with kubectl, manifests, or CI-driven apply flows
• combining application runtime, batch execution, persistent storage, and HTTP routing

For guided Comfy workspaces, use Application. For direct model requests without managing Kubernetes resources, use Inference API.

Choose a workflow

Use the console when you want guided setup, quick inspection, logs, and status views without writing every resource manifest by hand.

Use kubectl when your team manages Kubernetes resources from manifests, CI, or local tooling.

Many teams use both: start in the console for namespace access and quick inspection, then use kubectl for manifest-driven changes.

Both paths operate on the same namespace resources. Services and ingresses created with kubectl appear in the console, and console-created resources are visible through Kubernetes APIs in the namespace.

The basic model

Resource	What it is	Typical next step
Namespace	Your workspace and isolation boundary	Create workloads inside it
Deployment	The application runtime you want to run	Add a Service for reachable workloads
Job	One-off batch work that runs to completion	Inspect pods, events, and logs, or replace it with a new job run
Service	The stable internal network target for traffic inside the cluster	Add an Ingress for public HTTP access
CronJob	Scheduled batch work that creates jobs on a schedule	Inspect the jobs it creates and tune schedule or retention settings
Ingress	The public HTTP entrypoint for a service	Share the generated host with callers
PersistentVolumeClaim	Persistent storage for workload data	Mount it into a deployment, job, or cronjob

Common paths:

• Long-running private app: Namespace -> Deployment -> Service
• Long-running public HTTP app: Namespace -> Deployment -> Service -> Ingress
• One-off batch work: Namespace -> Job
• Scheduled batch work: Namespace -> CronJob
• Persistent workload data: Namespace -> PersistentVolumeClaim -> workload mount

Quick start

Start here for the shortest path through the product:

1. Open Kubernetes / Deployments in the console.
2. Create a namespace or use your existing default namespace.
3. Create a Kubernetes exec API key in Settings / API Keys.
4. Download the namespace kubeconfig from the console.
5. Create a deployment, job, or cronjob with the workflow that fits your team.
6. Add persistent storage for workloads that need data to survive pod restarts.
7. Create a service for long-running application traffic.
8. Add an ingress for public HTTP access to a service-backed app.

You can start from Kubernetes / Deployments in the console, then move between the Deployments, Services, and Ingresses views without leaving the Kubernetes section.

Before you begin

Before you start, make sure you have:

• a signed-in console session to create namespaces and download kubeconfig
• a Kubernetes exec API key when you plan to use kubectl
• a namespace, because supported resources are namespace-scoped
• a ClusterIP service before creating public HTTP ingress routing

Work with Kubernetes

The console is organized around five resource views:

• Deployments
• Jobs
• Services
• CronJobs
• Ingresses

Use the console when you want a guided setup, live status, logs, and namespace inspection without writing manifests for every change.

For help choosing the right key, read API keys.

Example:

export REMOTEGPU_API_KEY=rgpu_your_scoped_api_key
kubectl --kubeconfig ./kubeconfig-team-ml.yaml get pods

The downloaded kubeconfig refreshes short-lived namespace credentials, so the API key needs to stay available in the shell or CI environment that runs kubectl.

Supported resources

Resource	Console	kubectl	Notes
Deployment	Supported	Supported	Primary app workflow in the console
Service	Supported	Supported	Console creates standard ClusterIP services
Ingress	Supported	Supported	Public HTTP routing follows the RemoteGPU ingress profile
Job	Supported for console creation and inspection	Supported	Use kubectl for advanced job fields
CronJob	Supported for console creation and inspection	Supported	Use kubectl for advanced scheduling and job template fields
ConfigMap	Not surfaced as a dedicated console workflow	Supported	Standard namespace resource for manifest-driven teams
PersistentVolumeClaim	Not surfaced as a dedicated console workflow	Supported	Use storage-standard for supported persistent storage
Pod, logs, events	Supported for inspection	Supported	The console can help with day-2 visibility

Ingress is part of the supported Kubernetes model on RemoteGPU, with a defined platform profile described in Ingresses.

Important limits

Area	Expectation
Service type	Use ClusterIP
Direct public service exposure	NodePort and externalIPs are not supported
Ingress hostnames	Must match the namespace-scoped pattern <prefix>--<namespace-token>.apps.remotegpu.ai
Ingress TLS	Managed apps.remotegpu.ai hosts use the platform wildcard certificate; do not configure per-ingress TLS
Ingress behavior	Service-backed HTTP routing is supported; unsupported annotation patterns and unsupported backend shapes may be rejected
Persistent storage	Use storage-standard with one of the supported fixed sizes
kubectl access	Requires a RemoteGPU API key with Kubernetes exec access

Read next

• Read Deployments to run or update an application.
• Read Services to expose a deployment inside the cluster.
• Read Ingresses to publish a service with HTTP routing.
• Read Storage to create persistent volumes for workloads.
• Read Jobs for one-off batch work.
• Read CronJobs for scheduled batch work.