From Laptop Noise to Cloud Instances

For years, Slack engineers developing the webapp ran local microcosms of the application to test their changes. That workflow came with a heavy tax: installing and maintaining local dependencies, running resource-intensive software, and writing custom scripts that had to work across different operating systems. The Developer Productivity team heard this pain loud and clear through surveys and metrics, and set out to eliminate it by moving the entire development experience—code intelligence, type-checking, and builds—to remote environments. Engineers would no longer need to maintain code or dependencies locally; they could spin up a fresh, isolated environment on demand, ready in minutes.

The Local Workflow's Growing Pains

Slack’s backend runs on Hack, built atop HHVM. The codebase has grown significantly, and a fresh clone now takes nearly 30 minutes. Running HHVM became resource-intensive enough to make engineers’ laptops sound like power generators while degrading the performance of other applications. Although no single development environment was mandated, most webapp engineers used VSCode with a broad set of extensions supporting Hack’s syntax highlighting, formatters, and linters. Over the years, Slack engineers devised multiple strategies to improve this experience, but the setup remained brittle.

The first iterations ran HHVM directly on macOS, which brought familiar headaches: Homebrew breaking installs, upgrade failures, and playing catch-up whenever a new HHVM version shipped—a frequent occurrence. The next iteration moved all HHVM dependencies into local Docker containers, easing version sync but adding a new layer of custom scripts and services to build images. While this smoothed out inconsistencies, it introduced new dependencies such as Docker, HHVM build image maintenance, and automation glue. The high traffic in internal Docker self-help channels signaled that more work was needed.

Designing Remote Development Environments

In early 2021, a new team within the Developer Productivity org took on the explicit goal of improving the consistency and speed of code writing. User interviews, engineer feedback, and existing infrastructure all pointed to a need to evolve past local setup overhead. The webapp accounts for 60% of code changes across Slack’s engineering organization, making it the prime target.

The proposed solution went through several iterations and broad feedback sessions before a prototype landed in Slack’s internal CLI tooling—the natural home for developer workflows. A single command was added to launch the remote experience:

slack remote-dev -b <branch_name>

This command creates a new branch, reserves a development environment, attaches the branch to it, installs required dependencies, and opens a local VSCode instance with the right settings and extensions preconfigured. The result is a fresh instance ready for work in under 90 seconds, without cloning the webapp repository locally.

How the Fleet Stays Fast

A pool of development environments is always available for reservation via AWS Auto Scaling Groups (ASG). These environments periodically sync against master, pulling down new commits and dependencies to minimize setup time on request. When an engineer reserves an environment, periodic jobs are disabled and the instance detaches from the ASG, which provisions a replacement to maintain the pool size. This mechanism saves roughly 12 minutes of bootstrap time on every reservation.

Running slack remote-dev -b <branch_name> reserves an environment with the engineer’s branch checked out. The setup then configures the instance for VSCode’s Remote SSH extension, including installing the matching vscode-server and applying standardized settings.json and launch.json files. The result is a local-quality development experience with full IntelliSense, code navigation, and debugging out of the box.

Recognizing that editor and terminal configuration are deeply personal, the team enabled substantial customization. Engineers can sync custom extensions, scripts, bash profiles, aliases, git config, and VSCode settings from a local ~/.remote-dev-home directory. This flexibility also supports editors like Vim or Emacs, while git operations behave as they would locally.

Environments are short-lived by design. Detaching from an environment automatically terminates the underlying instance, and any environment whose associated branch gets merged is detached and terminated automatically. That keeps the fleet lean and cost-effective, running only as many instances as needed at any moment.

The Payoff: Speed, Scale, and Simplicity

Remote development environments standardized requirements across all webapp engineers and removed a large chunk of setup overhead. Engineers gained the ability to work on multiple branches in parallel—a difficult proposition with local development—by requesting a fresh, isolated environment per branch. Context switching costs dropped, and collaboration improved since multiple engineers can work on the same reserved environment.

Scaling machine specs also became trivial. Remote environments initially ran on C5.2xlarge instances (8 core, 16 GB RAM), which handled Slack’s backend services. When frontend build support and other tools were added, performance dipped. The fix was a single configuration change upgrading environments to C5.4xlarge (16 core, 32 GB RAM)—a change that would have previously required a costly, time-consuming laptop rollout. Though this doubled environment costs, the engineering efficiency gains justified the expense.

New hires, in particular, saw dramatic improvements. The setup time for webapp development dropped from about an hour to mere minutes. Common tasks also got faster—running unit tests, debugging, installing dependencies, and frontend builds all saw gains. The following metrics compare frontend build durations between remote and local environments:

Adoption and Reception

A minimal remote development workflow shipped in August 2021, onboarding a few regular webapp engineers who helped surface bugs and edge cases.

The following months were spent smoothing the experience based on beta feedback. During beta, 30% of webapp engineers had fully switched to remote development. General availability followed in October 2021; by the end of January 2022, over 90% of engineers had adopted the new workflow. A survey a few weeks after general release drew overwhelmingly positive responses, and feedback from the wider audience drove continuous improvements.

Changing a years-old workflow is a hard sell, but the advantages made the case compelling. Word of mouth from the beta testers spread quickly, and the majority of the team switched of their own accord. Engineers around the organization praised the change:

“It’s a game changer! We’re going from checkers to chess here folks.”

“I think remote dev is a dramatically better experience. It allows working on multiple branches at once and frees up tons of resources on our laptops.”

“I’m a huge fan – this work has greatly improved my productivity and my quiet laptop fans really thank you.”

“This is one of the very few projects I remember us doing that so directly impacted the productivity of product development with almost no trade offs.”

“I can do webapp development on battery power for, like, 2-3 hours straight before my laptop dies thanks to your work. Thank you so much!!!”

An efficient, reliable, and scalable development workflow is essential for a fast-paced company like Slack. The Dev Infrastructure team continues to refine the development experience by leveraging cloud resources, building toward an even more seamless future for all engineers.