Skip to content

From Docker Image to 1-Click App: Enabling Self-Service for Custom Apps

In the Developer Pods series (part-1, part-2 and part-3), we made a simple point: most users do not want infrastructure. They want outcomes.

They do not want tickets. They do not want YAML. They do not want to think about pods, namespaces, ingress, or DNS. They want a working environment or application, available quickly, through a clean self-service experience. That was the core theme behind Developer Pods: Kubernetes is a powerful engine, but it should not be the user interface.

The next step is just as important: letting end users deploy applications packaged as Docker containers into shared, multi-tenant Kubernetes clusters with a true 1-click experience.

Rafay’s 3rd Party App Marketplace is designed for exactly this. It allows providers to curate and publish containerized apps from Docker Hub, third-party vendors, or open-source communities, package them with defaults, user overrides, and policies, and expose them as a secure, governed self-service experience for users across multiple tenants.

Docker App

The Next Logical Step after Developer Pods

Developer Pods showed what happens when platform teams expose the right abstraction.

Instead of handing users raw infrastructure, platform teams publish a curated experience. In the Developer Pods model, that meant a familiar UI, guided choices, and an environment ready in about 30 seconds. The key insight was that the experience feels simple because the platform team has already done the hard work of packaging infrastructure into a consumable product.

That same platform pattern applies to applications packaged as Docker containers.

Instead of asking users to understand Kubernetes objects or manually assemble deployment components, platform teams can publish an application blueprint that users consume through a guided form. The user focuses on the app they want to run. The platform handles everything else.

What 1-click Actually Means

“1-click” does not mean there is no complexity. It means the complexity has been intentionally moved out of the user workflow and into the platform design.

That is the real lesson from the Developer Pods series. Great self-service is not accidental. It is designed. Platform teams define the allowed inputs, choose the defaults, package the right images, apply governance, and create a workflow that is fast for users without becoming chaotic for operators.

A Docker image by itself is not yet a self-service product. It becomes one when the platform team wraps it with the right defaults, controls, policies, and deployment logic.

Example App - Grafana

From the user’s perspective, the workflow is straightforward. They provide a name, select a workspace, specify the container image and port, choose CPU and memory, optionally define commands, arguments, and environment variables, and, if needed, request storage by specifying size and mount path.

Important

The user is thinking about the application, not the infrastructure. They are not writing Kubernetes manifests. They are not creating services or ingress rules. They are simply providing the application-level parameters required to launch what they need.

That maps directly to the Developer Pods philosophy: no YAML, no cluster access, no unnecessary infrastructure exposure. Just a guided form centered on the thing the user actually wants.

Let's look at the Grafana app on DockerHub as an example. The typical Docker command a developer would use is shown below. 

docker run -d -p 3000:3000 --name=grafana grafana/grafana-enterprise

Step 1: Launch Docker App SKU

In the user's self service portal, select the "App from DockerHub" card

Docker App SKU

In the "Container Configuration" section, update the following to reflect our Docker command

  • Container Image - grafana
  • Container Port - 3000

We will skip the storage configuration since we do not require it for this simple Grafana app example.

Grafana Configuration

Click on Deploy. This will initiate the deployment of the Grafana app on the provider's environment. The user will see an in-progress notification

Grafana Pending

Step 2: Access Grafana App

Deployment of the Dockerized Grafana App will take ~30-60 seconds. Once successfully deployed, the user will be presented with instructions on how to access the Grafana App.

Click on the URL will take the user to the Grafana console. Enter the provided, default credentials for first time access. You will be prompted to set a new password.

Grafana Access

Under the Covers

Platform engineers will be curious what exactly happens under the covers. The Rafay Platform takes the user provided input for the Grafana Docker App and automatically generates the required k8s manifests. Let's see what this looks like in our host Kubernetes cluster.

Pod and Deployment

The Rafay platform has autogenerated and deployed k8s pod and a backing deployment.

k8s Pod

Service

The Rafay platform has also autogenerated and deployed a service for Grafana

k8s Pod

Ingress

The Rafay platform has autogenerated and deployed a k8s Ingress and programmed DNS so that user gets a 1-click experience.

k8s Pod

That is what 1-click self-service should look like. Not raw infrastructure. Not manual deployment tickets. Not Kubernetes as a user experience. Just a governed, productized path from application intent to running software.

Closing Thoughts

Developer Pods showed how to make GPU-backed development environments feel instant. The 3rd Party App Marketplace extends that same philosophy to application delivery.

Take a Docker image. Wrap it with defaults, policies, controlled overrides, and tenant-aware deployment logic. Publish it as a self-service offering. Let the user launch it through a clean, simple workflow.