# Developer Pods: A Self-Service GPU Experience That Feels Instant

March 22, 2026

**Mohan Atreya**  
Chief Product Officer

In [**Part 1**,](/content/ai-and-cloud-native-blog/instant-developer-pods-rethinking-gpu-access-for-ai-teams/index.html) we discussed the core problem: most organizations still deliver GPU access through the wrong abstraction. Developers do not want tickets, YAML, and long wait times. They want a working environment with the right tools and GPU access, available when they need it.

In this post, let’s look at the other half of the story: the **end-user experience**. Specifically, what does self-service actually look like for a developer or data scientist using Rafay Developer Pods?

The answer is simple: **a familiar UI, a few guided choices, and a running environment they can SSH into in about 30 seconds**.

#### Self-Service Means the User Does Not Need to Understand the Infrastructure

This is perhaps the most important design choice. The user is not being asked to:
- Request capacity through a ticket  
- Understand Kubernetes objects  
- Pick from dozens of low-level infrastructure settings  
- Wait for an operator to provision a VM

Instead, they are presented with a clean, curated workflow built around the thing they actually want:

**“Give me a ready-to-use development environment with the right amount of compute.”**

### Step 1: Fill in a Simple, Familiar Form

The end user logs into Rafay's Self Service Portal. Once they select **Developer Pods**, the user is taken to a straightforward configuration form. They are asked to provide the following:

#### Metadata
- A **name** for the developer pod  
- The target **workspace**

### SSH Access

For most developers, the first expectation after requesting an environment is straightforward:

**“How do I get into it?”**

Developer Pods supports this directly through SSH configuration. In the example below, the user can choose whether to auto-generate an SSH key or provide their own public key.

#### Specify Resources

The next step in the workflow allows the user to specify the compute resources for their Developer Pod. In this example, the user can configure:
- **CPU**  
- **Memory**  
- **GPU Count**  
- **Node Type**

This is where the platform team gives users controlled flexibility. They are not exposed to the entire infrastructure inventory. Instead, they get a curated set of supported choices. That means:
- Users can choose what they need  
- Platform teams maintain governance  
- Expensive GPU capacity is consumed more efficiently

#### Select a Ready-to-Use Image

This is where the experience becomes especially powerful for AI and ML teams. Rather than starting from a blank machine and manually installing everything, users can choose from prebuilt images such as:
- Ubuntu 22.04  
- Ubuntu 24.04  
- PyTorch 2.1 with CUDA 11.8  
- PyTorch 2.2 with CUDA 12.1  
- PyTorch 2.4 with CUDA 12.4  
- PyTorch 2.7 with CUDA 12.8

### Step 2: Launch and Connect

Once the user submits the request, the developer pod is created (approx 30 seconds).

Then comes the moment that matters most. They connect to the environment and start working. In the example below, the pod is reachable over SSH and the user lands directly in an Ubuntu environment.

### Why This Experience Matters

It is easy to underestimate how much velocity is lost in the gap between “I want to try something” and “I finally have an environment." For AI teams, that gap is especially expensive. Experiments are iterative by nature. A developer may want to:
- Test a new model version  
- Validate a dependency change  
- Compare framework versions  
- Run a short-lived fine-tuning task  
- Check GPU behavior with a different image

If each of those steps requires infrastructure mediation, the platform becomes a bottleneck. Developer Pods changes that dynamic. The self-service model gives users:
- fast access to environments  
- familiar workflows  
- curated choices instead of raw infrastructure  
- direct access to compute when they need it

At the same time, platform and operations teams still retain the things they care about: Governance, Standardization, Multi-tenancy, Efficient cluster utilization, Controlled exposure of GPU resources.

### The Bigger Shift: Kubernetes Without Kubernetes

One of the most interesting things about this workflow is what the user **does not** see. Specifically, they do not see:
- Kubernetes YAML  
- Kubectl  
- pods, deployments, ingress, load balancers etc  
- node pools  
- namespaces  
- schedulers  
- resource quotas  
- cluster topology

And that is exactly the point. All of that power is still there. Kubernetes is still doing the heavy lifting. But the user experience has been redesigned around outcomes, not infrastructure primitives.

**This is the real promise of platform engineering for AI infrastructure. Developer Pods is one example of what that looks like in practice.**

### Want a deeper dive in the Rafay Platform?

**Tags:**  
[KubeCon](https://pr@rafay.co/the-kubernetes-current-tag/kubecon)