Dev Environments in the Cloud: An Experiment with Gitpod

August 22, 2022

Some people are arguing that the local dev environment is soon going to be a thing of the past. The main idea behind such claims is that the cloud is so powerful and gives you so much advantage in terms of reproducibility that overpowered developer machines are not necessary anymore (or even a drawback).

With this post, I don't want to join the discussions or speculations about the future of localhost but instead take a test drive with one popular option for Cloud Development Environments: Gitpod.

Background and Expectations

Most of my coding work as a Cloud Automation Engineer (CAE) happens with the following stack:

As a CAE, I know the pain of setting up a local development environment when joining a new project and downloading a repository for the first time. I have even worked hard in multiple teams to reduce the "time to first working code change" for different backend and frontend applications.

With this background, I wanted to see how quickly and easily I could set up a working dev environment in Gitpod for a sample project of mine. This project consists of a simple Rust web server. It also has some Node.js dependencies for semantic releases.

Apart from testing the speed for setting up a generic dev environment, I was also interested in seeing how fast I could adapt this setup for my special needs, especially with NeoVim and my dotfiles.

First Excitement

As the documentation points out, setting up a Gitpod Workspace is as easy as opening the URL{url-of-your-repository}. In fact, you can start a Gitpod Workspace just like I did by opening this URL:

Screenshot of the GitPod Workspace of my repository after a few tweaks

This is what impressed me the most right away:

  1. After less than a minute, I had a working VS Code inside the browser.
  2. Gitpod automatically recognized that this was both a Rust and a Node.js project:
    • It created a .gitpod.yml right away and instructed it to install all the dependencies and run the Rust build in watch mode (which I didn't even know existed before!).
  3. Gitpod automatically detected that my application was running something on port 8080 and immediately offered to do something with it:
    • Gitpod offers to either open a preview inside your browser VS Code, open a preview in a new browser tab or even expose the port publically.
    • While this last option may be a security nightmare for some, I think it's a very cheap way of implementing preview environments!
  4. The default dev environment comes packed with goodies, e.g. pyenv, homebrew, and docker preinstalled. (To check out everything it has to offer, take a look at the gitpod/workspace-full Docker image.)
  5. Not only did I get a VS Code in the browser, but I also had the option to log into that same cloud dev environment via SSH.
    • (At the time when I tried this out, only completely public access (without password or private key restrictions) was possible. In the meantime, public key upload has been implemented.)
    • As NeoVim is my IDE of choice, this is essential for getting a working personal dev environment.
  6. When closing the browser tab, it did tear down my environment:
    • When I went back to the Gitpod Workspaces overview and selected "Open", the Workspace was completely fresh again without any of my previous changes ✅.
  7. But changing my VS Code theme was directly persisted:
    • When I restarted the Workspace or created a new one in a different repo, the theme was kept - without me installing or setting up any extra VS Code plugins! Very comfortable 👍
  8. SSHing into my Gitpod Workspace was straightforward and felt very native as if I were navigating on my local machine (kudos to Warp!).


I wanted to directly commit the automatically created .gitpod.yml but this proved difficult because the Gitpod app did not have enough permissions on my GitHub repository. Thankfully, that was straightforward enough - I think I solved it in under 10 minutes.

Including my dotfiles proved a bit more difficult though:

Final Custom Workflow

My final custom workflow for working with NeoVim in a GitPod Workspace now looks like this:

  1. Create a feature branch in the repo.
  2. Start a Workspace in Gitpod.
  3. Wait around 3 minutes (= Workspace image pull + dotfiles install script)
  4. Copy the ssh login command and execute it.
  5. Open NeoVim once to install all plugins.
  6. Open NeoVim again.
  7. 🚀 Start coding!

Future Improvements

My Verdict and Recommendations

About the author: Josia Scheytt

Loves automating, especially to help fellow engineers. Passionate about Kubernetes, databases, and living the DevOps life in unsiloed teams.

Join us