Deployments

A Kubernetes Deployment runs and updates a replicated application workload in a namespace. Use deployments on RemoteGPU for long-running containers such as web apps, workers, and services.

Choose a workflow

Use the console when you want guided setup, quick edits, and a UI view of the deployment status.

Use kubectl when your team manages deployments from manifests or CI. Include the RemoteGPU runtime SKU label in the pod template so the workload can be scheduled with the right plan.

What a deployment controls

A deployment brings together the main runtime settings for an application:

• the container image to run
• the replica count that should stay running
• the RemoteGPU plan used for scheduling and defaults
• the container port that later services may target
• optional probes and environment settings for health and configuration

A deployment does not make your application reachable by itself. To send traffic to it, create a service. To make that service public, create an ingress.

Before you create a deployment

Before you create the deployment:

• choose the namespace where the workload should run
• decide whether the workload needs internal traffic, public traffic, or no network exposure
• decide whether the workload needs persistent data through a PersistentVolumeClaim
• pick a plan that matches the workload's CPU, memory, and GPU needs

Create a deployment

From the console:

1. Open Kubernetes / Deployments
2. Select a namespace
3. Click Create deployment
4. Fill in the deployment form

Console field	What it means
Deployment name	Kubernetes deployment name in the selected namespace
Image	The container image to run
Replica count	How many pods the deployment should keep running; use 0 to stop compute while keeping the deployment
Plan	The RemoteGPU SKU for scheduling and defaults
Container port	The application port that later services may target

The container port is only a hint for the runtime and later service creation. It does not create a public URL.

Choosing a plan

The plan you pick in the console maps to a RemoteGPU SKU.

The console plan picker handles the SKU for console-created deployments.

With kubectl, add the runtime SKU label to the deployment pod template:

metadata:
  labels:
    remotegpu.ai/runtime-sku: gpu-h100-1x

Missing or conflicting runtime SKU labels prevent the deployment from being accepted.

Console and kubectl operate on the same deployment

The console and kubectl both operate on the live Kubernetes deployment:

• deployments created in the console appear in kubectl
• deployments applied with kubectl appear in the console
• updates and scale changes made in either place are reflected in the other view

Scaling a deployment to 0 is supported from both the console and kubectl. Services and ingresses can remain configured, but they will not have backing pods until you scale the deployment back above 0.

Troubleshooting

Symptom	What to check
kubectl apply is rejected	Confirm the pod template includes one RemoteGPU runtime SKU label such as remotegpu.ai/runtime-sku: cpu-shared-8g
Pods stay pending	Check the selected plan, namespace quota, and pod events with kubectl describe pod
The console shows a deployment but traffic does not reach it	Confirm the deployment has ready pods, then create or inspect the matching service
A public URL has no backend	Confirm the deployment is scaled above 0 and the service selector matches the deployment pod labels
Image startup fails	Inspect pod logs and events from the console or with kubectl logs and kubectl describe pod

Read next

• Read Services to expose the deployment inside the cluster.
• Read Ingresses to publish a service with HTTP routing.
• Read Storage to attach persistent storage.