# How LinkedIn Cut Build Times from 30 Minutes to 10 Seconds
*LinkedIn’s RDev lets engineers code in the cloud with pre-built containers, cutting setup from 30 mins to 10 secs while keeping CI consistent.*
By [Rohit Lakhotia](https://scaleengineer.com/authors/rohit-lakhotia)
Published: 2025-11-03
Canonical: https://scaleengineer.com/blog/how-linkedin-cut-build-times-from-30-minutes-to-10-seconds
---
Imagine you open your laptop, start coding, and everything compiles in seconds\! No waiting for builds, no complex setup, no dependency conflicts\. Feels like developing on your local machine but powered by the cloud\.

That’s exactly what LinkedIn’s Developer Productivity and Happiness team achieved\. They built a **remote development platform \(RDev\)** that cut setup time from **30 minutes to just 10 seconds** and made builds dramatically faster, consistent, and more reliable across their massive engineering ecosystem\.

Let’s discover **how they did it**, the **problems they solved**, and the **technology** that makes it all work in this blog today\.

## What was the Problem?

LinkedIn’s engineering environment is huge, thousands of developers, and products built using **Java, Python, C/C\+\+, Go, JavaScript, iOS, and Android**\.

Each of these technologies has unique setup requirements\. So, every time a developer started a new project \(or joined a team\), they had to:

- Install and configure dependencies
- Set up environment variables
- Resolve version mismatches
- Sync local builds with CI pipelines

This process often took **10–30 minutes or more**, and sometimes hours for new developers\.

Then came remote work during the pandemic and things got even trickier\. Developers were working on laptops with:

- Fewer CPU cores
- Limited memory and disk space
- Slower I/O
- And occasional **thermal throttling**

Running large local builds became painful\. Background processes, network delays, and inconsistent setups made development unpredictable\. CI \(Continuous Integration\) builds often behaved differently than local ones causing debugging nightmares\.

LinkedIn needed a **consistent, fast, and scalable** way for developers to build and run code independent of their local hardware\.

## What was LinkedIn’s vision?

To solve this, LinkedIn launched **Remote Development \(RDev\)**, a system that lets developers **build and run code inside powerful cloud containers**, while coding through their usual IDEs \(like VS Code\)\.

The goal:

“Provide every developer with a remotely accessible, reliable, and predictable development environment, fast to set up and consistent with CI\.”

Each **RDev** is essentially a **container** pre\-configured with all the necessary tools, dependencies, and packages for a specific product\.

These containers run on LinkedIn’s **private cloud**, on hardware optimized for build performance with low latency to internal services like repositories and package registries\.

You can think of it as, “Your code runs in the cloud, but your experience feels completely local\.”

## What were the Speed Gains?

The impact was massive\!\!

RDevs reduced:

- **Setup time** from 10\-30 minutes → **10 seconds**
- **Build times** for large applications significantly, thanks to cloud compute resources
- **Inconsistencies** between local and CI environments

## Predicting Developer Needs with Pre\-Built RDevs

Instead of creating containers on\-demand \(which takes time\), LinkedIn predicts what developers will need based on **usage patterns**\.

For example:

- Which repositories or products are being worked on the most
- Which frameworks or build types are commonly used
- When build demand peaks

Using this insight, LinkedIn **pre\-builds RDev containers** in advance\.

Each pre\-built RDev already has:

- The source code checked out
- All dependencies installed
- The product built and running

So when a developer requests an environment, they get a **ready\-to\-code instance** instantly, no setup, no waiting\.

This difference is clearly visible in performance metrics \(as shown in the below figure\):

![](https://media.beehiiv.com/cdn-cgi/image/fit=scale-down,format=auto,onerror=redirect,quality=80/uploads/asset/file/ba69c87a-1fc1-4727-a220-ec49784a9204/image.png?t=1760348085)

[Source: LinkedIn official blog](https://www.linkedin.com/blog/engineering/cloud-computing/building-in-the-cloud-with-remote-development)

Local setups took minutes, while pre\-built RDevs launched in seconds\.

## How they ensured consistency everywhere?

One of the smartest parts of LinkedIn’s architecture is how they **unified development and CI builds**\.

Normally, developers build locally, and CI builds happen separately in pipelines\. This creates two potential sources of error, local environment differences and mismatched dependencies\.

LinkedIn solved this by **running both CI and RDev builds in the same container image**\.

This means:

- The same image that powers RDev is used for CI builds
- CI jobs execute inside containers identical to RDev
- No more “works on my machine” problems

To achieve this, they modified their CI pipeline so that the **build step runs inside a container** created from the same RDev image\.

It’s similar to how **GitHub Actions** supports builds using:

```
runs-on: ubuntu-latest
container: your-custom-image
```

This approach ensures **reproducibility, consistency, and reliability** across local, remote, and CI environments\.

## Core Architecture of LinkedIn’s Remote Development Ecosystem

The architecture has several major components working together:

![](https://media.beehiiv.com/cdn-cgi/image/fit=scale-down,format=auto,onerror=redirect,quality=80/uploads/asset/file/7f1a4e96-b0f9-4d04-bdeb-440e0641e9f0/Mermaid_Chart_-_Create_complex__visual_diagrams_with_text.-2025-10-13-101833.png?t=1760350738)

### 1\. Base Image Infrastructure

At the foundation lies LinkedIn’s **Base Image Infrastructure**, which integrates container image builds directly into their CI pipeline\.

It allows developers to:

- Create and publish **custom container images** to LinkedIn’s internal registry
- Use **template images** for common stacks like Python, Java, or JavaScript
- Automatically rebuild images when dependencies \(RPMs\) change

A service called the **Image Dependency Updater** keeps all RDev images fresh, rebuilding them whenever base dependencies or RPMs are updated\.

This ensures every developer always works with **up\-to\-date, secure, and consistent environments**\.

### 2\. RDev Configuration

Each LinkedIn product repository contains a \.devcontainer/devcontainer\.json file, following **VS Code’s container configuration format**\.

This JSON file specifies:

- The base image name
- Environment variables
- Ports to expose
- Additional setup instructions

It’s a **declarative blueprint** describing exactly how the containerized environment should look and behave\.

### 3\. RDev CLI

Developers interact with RDev through a **Python\-based CLI tool**, distributed across all machines\.

The CLI supports commands to:

- Create and connect to an RDev
- Open it via CLI or IDE \(using SSH\)
- Manage active environments

With just one command, a developer can spin up a cloud\-based workspace and start coding immediately\.

### 4\. RDev Server

The **RDev Server** is a **[Rest\.li](https://rest.li/)****\-based Python service** that acts as a broker between the CLI and Kubernetes\.

It:

- Forwards requests from CLI to the Kubernetes operator
- Fetches results and metadata \(developer preferences, dotfiles, etc\.\)
- Maintains the mapping between developers and their RDev environments

Think of it as the **control plane** of the entire system\.

### 5\. RDev Operator \(Kubernetes Extension\)

This is where the real magic happens\.

LinkedIn extended Kubernetes using the **Operator Pattern** to manage custom resources specifically for RDev\.

They defined two **Custom Resource Definitions \(CRDs\)**:

1. **Rdev** represents a single, stateful remote dev instance
2. **RdevPool** maintains a pool of pre\-built RDevs using Kubernetes Clonesets

The **RDev Operator**, built using the **Kubebuilder SDK**, continuously ensures that the current state of the system matches the desired state automatically creating, updating, or deleting RDevs as needed\.

## Inside an RDev Pod

Each **RDev** runs as a **Kubernetes Pod** consisting of three key containers and a few mounted volumes\.

### Containers:

1. **rdev\-init\-workspace**: An init container that prepares the workspace, sets up developer preferences, and ensures all tools are ready\.
2. **rdev\-sshd**: The core container where development happens\. It runs the sshd service and is created from the image defined in devcontainer\.json\. Contains all tools, SDKs, and build systems required for that product\.
3. **rdev\-sidecar**: Handles additional tasks like installing dotfiles and running the **Startup Probe** \(used to check if the build is complete and the environment is ready\)\.

### Volumes:

1. **Home Volume**: Stores the developer’s home directory, including code, dotfiles, and configs\. Persisted using **Persistent Volume Claims \(PVC\)**, ensuring that data isn’t lost if the Pod moves or restarts\.
2. **RDev Info Volume**: Stores metadata such as host and port details, using Kubernetes Downward API annotations\.

The Pod is also connected to a **Kubernetes Service** \(via NodePort\) to expose ports outside the cluster, enabling remote SSH or IDE access\.

## How RDevPool Keeps Things Ready

To make environments instantly available, LinkedIn maintains a **pool of pre\-built RDev Pods** via the **RDevPool CRD**\.

Here’s how it works:

1. The RDevPool controller keeps track of a defined number of replicas\.
2. When a developer requests an environment, it assigns them a **fully built, ready RDev Pod**\.
3. The assigned Pod is removed from the pool\.
4. The controller automatically spins up a **new Pod** to replace it, maintaining the desired pool size\.

### Build Readiness Check

Once an RDev Pod is created:

- The **PostStart hook** triggers a build command inside the rdev\-sshd container\.
- The **Startup Probe** \(running in the rdev\-sidecar\) monitors the build’s status\.

It marks the Pod as **“ready”** only after confirming the build completed successfully, either by:

- Detecting a specific “build complete” file, or
- Fetching a success URL via curl\.

This ensures developers only get assigned fully functional environments\.

## Why it Matters

This system achieves several big wins:

1. **Blazing\-Fast Setup: **No manual setup\. Developers instantly get a ready\-to\-code environment, often within **10 seconds**\.
2. **Consistent Across Dev and CI:**The same container image powers both local dev and CI, guaranteeing that “if it works locally, it’ll work in CI\.”
3. **Predictable and Reliable: **Builds happen on cloud hardware with predictable performance, no overheating laptops or random slowdowns\.
4. **Seamless Developer Experience:**Thanks to SSH integration, developers use their **favorite IDEs \(like VS Code\)** and feel like they’re coding locally even though everything’s running in the cloud\.
5. **Auto\-Updated Environments: **Base image infrastructure and dependency tracking ensure developers always use the latest, secure, and compatible versions of all packages\.

## What’s LinkedIn is planning next?

LinkedIn’s team believes **remote development will become a core part of modern software engineering**, especially in distributed organizations\.

They’re now exploring:

- **Automatic reproduction of failed CI builds**, so developers can debug issues in the exact same environment where the failure happened\.
- **RDev per Pull Request**, where each PR automatically spins up a dedicated environment for reviewers to visualize and test changes directly\.

The vision is to make remote development not just a productivity boost but a fundamental part of how engineers **build, test, and collaborate**\.

## TL;DR

| Component | Function |
| --- | --- |
| **RDev Containers** | Pre\-configured cloud dev environments for each product |
| **Base Image Infrastructure** | Builds and updates container images automatically |
| **RDev CLI** | Command\-line interface to manage RDevs |
| **RDev Server** | REST service bridging CLI and Kubernetes |
| **RDev Operator** | Custom Kubernetes controller for RDev lifecycle |
| **RDevPool** | Maintains ready\-to\-assign pre\-built environments |
| **Persistent Volumes \(PVCs\)** | Preserve developer data across sessions |
| **SSH \+ IDE Integration** | Enables seamless local\-like experience |
| **CI Integration** | Runs builds in identical containers for consistency |

Official blog from LinkedIn: [Building in the cloud with remote development](https://www.linkedin.com/blog/engineering/cloud-computing/building-in-the-cloud-with-remote-development)

By now, you must have had a clear idea of,** How LinkedIn Cut Build Times from 30 Minutes to 10 Seconds? **In a nutshell, LinkedIn built a **Remote Development \(RDev\)** system that lets developers code in the cloud using pre\-built, containerized environments\. It drastically cut setup time from **30 minutes to 10 seconds**, ensuring faster, consistent builds across local and CI systems\.

**Congratulations\! You've just advanced another step in your tech journey\. Keep progressing\!**