A Self-Service GPU Experience That Feels Instant | Rafay

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

March 22, 2026

Mohan Atreya
Chief Product Officer

In Part 1, 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:

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

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:

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:

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:

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:

If each of those steps requires infrastructure mediation, the platform becomes a bottleneck. Developer Pods changes that dynamic. The self-service model gives users:

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:

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