Gitpod and Github Codespaces are both Visual Studio Code based online code editors, with attached Linux dev environment servers, for running terminal tasks; in simple terms, both are cloud-based code editors, and are free* to use.

Note: Github Codespaces is only free for personal use during its beta period, which might change in the future, for Github Teams and Organizations there is a pay-as-you-go pricing setup. To get access to personal Github Codespaces you will need to sign up for the beta.

If you have trouble signing up for Codespaces as a team or organisation the process is to email codespaces@github.com

This article details my personal experiences with Gitpod and Github Codespaces, these are my opinions and not definitive facts, your experiences may differ from mine.

Why online IDEs?

I have more experience with Gitpod, as it's been around for quite a bit longer than Github Codespaces, however, my experience with online code editors and IDEs is longer than that.

My first experience with an online code editor was Cloud9 in 2016 (this was before Cloud9 was bought by Amazon and became AWS Cloud9). At the time Cloud9 was a free service and was readily available for personal use, I loved the convenience of the service, so much so, that I fully switched from programming locally to programming online for a short period. All good things come to an end, by December 2019, Cloud9 announced that they were shutting down their standalone service, and instead, Cloud9 would be offered as part of AWS, so, just before I lost access to Cloud9, I started searching for alternatives, ranging from Eclipse Che, Red Hat CodeReady Workspaces, Codeanywhere to StackBlitz, out of all the alternatives the most competent of them was Gitpod.

The online vscode revolution

The main reason I searched for alternatives was that at that point in time I was attempting to use a Chromebook for all my work. When I found Gitpod I liked the general user experience it was similar to vscode but had some extra additions that made more sense in an online environment, such as the ability to open small previews of websites while developing, etc... Plus, online editors were the only way to code on a Chromebook (this has now changed. Chrome OS now supports Linux as a subsystem), so, 🤷‍♂️.

Gitpod vs. Codespaces

Gitpod themselves already made an article about their benefits over Github Codespaces, you can find it here gitpod.io/gitpod-vs-github-codespaces. I will give a brief overview of the differences between the two, note where they overstate their differences and benefits, explain how to make the most of the each service, and then give my personal take on both services.

The first point Gitpod makes is that it's "Ready in a flash"

Gitpod removes long init and build times by continuously pre-building workspaces for your project. Thereby it allows you to start coding or debugging immediately, from any context, at any time.

This is technically correct, at least to a certain point. Gitpod's actual building process takes slightly longer than that of Github Codespaces or at the very least it feels that way, I haven't, nor do I plan to give any exact empirical performance data, as both services are constantly changing things, in fact, the week before I wrote this article, Github introduced github.dev.

For your information: github.dev is an online vscode based web editor, the difference between this and Github Codespaces, is that Codespaces comes with a terminal, and this doesn't

In the defense of Gitpod, it can prebuild a workspace unlike Github Codespaces, so you can start coding immediately, without having to wait for the long build process to finish.

Another point that Gitpod makes is that it has "3x more power",

By leveraging cloud technologies like containers and Kubernetes, Gitpod achieves best-in-class resource efficiency with scalable workspaces running on shared high-powered cloud servers.

This is probably the iffiest points they make, since I can't verify their server configs, nor can I verify that the plans they used for testing, end up being cheaper in actual use, especially, since Github has only released the pricing scheme for Github Teams and Enterprise, and not personal use.

Note: After a discussion with @GeoffreyHuntley from @gitpod I have confirmed that “[they] currently provision machines with 64gb of memory and 16vCPUs and workspaces timeshare the resources in a burstable manner. There are upper limitations to resource consumption on a per workspace basis”. Gitpod is working on sharing more information on their server side config in the coming months.

As of August 30, 2021, Gitpod has 8 plans*, 2 of which are self-hosted options. They are,

For Github Codespaces, the pricing* is,

*Both services have more details included in their pricing scheme, I recommend going through those for detailed and up-to-date information.

Note: You have to pay for your Codespaces storage for the time while said workspace exists, this includes while you are not actively using the workspace. Gitpod to my knowledge doesn't require paying for storage.

Sources: Gitpod, GitHub Codespaces.

In the final point Gitpod makes, they list some of the benefits they offer in a table-like format, I will be blatantly honest, they are leaving out quite a lot of details, so, I will answer in kind but in a more detailed manner.

Workspace Setup

Both Gitpod and Github Codespaces have config files based on Docker that configures your whole env. On Gitpod their config system uses a .gitpod.yml file which stores your workspace config info and a .gitpod.Dockerfile file which sets up a docker image that you can use to run your workspace. By default, Gitpod uses a standard docker image as the foundation for workspaces, the standard image has most of the default tools and programs devs require, plus you can also build on top of it to add small additions to it.

The .gitpod.yml files store basic configuration information, ranging from open ports to post-install scripts. Your basic .gitpod.yml files look like this:

# Commands to start on workspace startup
tasks:
  - init: yarn install
    command: yarn build
# Ports to expose on workspace startup
ports:
  - port: 8000
    onOpen: open-preview

For most of the projects I use Gitpod for, I set up a .gitpod.yml file like this

# .gitpod.yml
image:
  file: .gitpod.Dockerfile

# List the ports you want to expose and what to do when they are served. See https://www.gitpod.io/docs/43_config_ports/
ports:
  - port: 3000
    onOpen: open-preview
  - port: 3001
    onOpen: ignore

github:
  prebuilds:
    # enable for the master/default branch (defaults to true)
    master: true
    # enable for all branches in this repo (defaults to false)
    branches: true
    # enable for pull requests coming from this repo (defaults to true)
    pullRequests: true
    # enable for pull requests coming from forks (defaults to false)
    pullRequestsFromForks: true
    # add a "Review in Gitpod" button as a comment to pull requests (defaults to true)
    addComment: true
    # add a "Review in Gitpod" button to pull requests (defaults to false)
    addBadge: false
    # add a label once the prebuild is ready to pull requests (defaults to false)
    addLabel: prebuilt-in-gitpod

# List the start up tasks. You can start them in parallel in multiple terminals. See https://www.gitpod.io/docs/44_config_start_tasks/
tasks:
  - init: >
      npm install -g pnpm &&
      pnpm install -g ultra-runner &&
      pnpm install
    command: >
      npm install -g pnpm &&
      pnpm install -g ultra-runner &&
      pnpm build

The Gitpod prebuilds section sets up a prebuild for each branch, and pull request, and leaves a comment with a link to the prebuild, check out the docs for Gitpod prebuilds to learn more.

However, where things get interesting is in the tasks section. The init task is run once on workspace startup, and the command task is run on workspace startup, and then on every workspace restart.

The real problem is that the init task even though it runs on startup, doesn't store the environmental variable of nor does it link globally installed packages, and from what I can tell this comes from the fact that every terminal environment is based on the Gitpod docker image that is supplied. If no docker image is specified in the gitpod.yml file then the standard "workspace-full" image is used instead. I recommend reading through Gitpod's docs on the matter.

Note: From what I have been told by @GeoffreyHuntley from @gitpod “[It’s] recommend [that] you build your own docker image and install any software you need as part of building your docker image once your project complexity merits it. In addition to this [they] are also making changes to implement full-workspace backups which will snapshot the entire environment removing this friction”.

The .gitpod.Dockerfile, is the file that directly gives you admin access, and enables you to install/do anything you want to your workspace. From my experience, you most likely won't need to change anything here, except for, maybe VNC purposes, and even then, the docs are very clear.

# .gitpod.Dockerfile
FROM gitpod/workspace-full:latest

# Install custom tools, runtime, etc. using apt-get
# For example, the command below would install "bastet" - a command-line tetris clone:
#
# RUN sudo apt-get -q update && 
#     sudo apt-get install -yq bastet && 
#     sudo rm -rf /var/lib/apt/lists/*
#
# More information: https://www.gitpod.io/docs/config-docker/

On the other hand, setting up a workspace for Github Codespaces is hands-on. Picking a default container is easy enough*, you just follow the docs on VS Code, the real problem is that the setup for Github Codespaces is very overwhelming.

For Codespaces you need to create a .devcontainer.json file and store it in the .devcontainer/ folder. The .devcontainer.json file is a json file that contains the information needed to set up your workspace. The .devcontainer.json file looks like this:

// For format details, see https://aka.ms/devcontainer.json. For config options, see the README at:
// https://github.com/microsoft/vscode-dev-containers/tree/v0.162.0/containers/typescript-node
{
  "name": "Node.js & TypeScript",
  "build": {
    "dockerfile": "Dockerfile",
    // Update 'VARIANT' to pick a Node version: 10, 12, 14
    "args": {
      "VARIANT": "16"
    }
  },

  // Set *default* container specific settings.json values on container create.
  "settings": {
    "npm.packageManager": "pnpm"
  },

  // Add the IDs of extensions you want to be installed when the container is created.
  "extensions": [
    "bierner.jsdoc-markdown-highlighting",
    "yzhang.markdown-all-in-one",
    "shd101wyy.markdown-preview-enhanced",
    "visualstudioexptteam.vscodeintellicode"
  ],

  // Use 'forwardPorts' to make a list of ports inside the container available locally.
  "forwardPorts": [3000],

  // Use 'postCreateCommand' to run commands after the container is created.
  "postCreateCommand": "pnpm install",

  // Comment out connect as root instead. More info: https://aka.ms/vscode-remote/containers/non-root.
  "remoteUser": "node"
}

You also need to create a Dockerfile stored inside the .devcontainer/ folder. The Dockerfile contains docker info, so any configs, you require for your workspace can be set here, like this:

# See here for image contents: https://github.com/microsoft/vscode-dev-containers/tree/v0.187.0/containers/typescript-node/.devcontainer/base.Dockerfile

# [Choice] Node.js version: 16, 14, 12
ARG VARIANT="16-buster"
FROM mcr.microsoft.com/vscode/devcontainers/typescript-node:0-${VARIANT}

# [Optional] Uncomment this section to install additional OS packages.
# RUN apt-get update && export DEBIAN_FRONTEND=noninteractive \
#     && apt-get -y install --no-install-recommends <your-package-list-here>

# [Optional] Uncomment if you want to install an additional version of node using nvm
# ARG EXTRA_NODE_VERSION=10
# RUN su node -c "source /usr/local/share/nvm/nvm.sh && nvm install ${EXTRA_NODE_VERSION}"

# [Optional] Uncomment if you want to install more global node packages
# RUN su node -c "npm install -g <your-package-list -here>"

RUN su node -c "npm install -g pnpm"

This example is based on one of my Github projects okikio/native, it's a good starting point for setting up a workspace for your own project.

_Note: The major thing that can throw you off with the Github Codespaces config is that you can't install local packages (I'm talking about node_modules) inside the docker config. Of course, this could be my lack of experience with Docker, but thus far I've been unable to get it to work properly._

For your information: The Gitpod team is planning to add support for the Github Codespaces devcontainer.json format, so, in the future, you might be able to easily switch between both Github Codespaces and Gitpod without breaking a sweat.

Collaboration

I personally haven't collaborated with anyone on Gitpod or Github Codespaces, but each service does offer a way to collaborate with others. For one, Gitpod allows you to share both running workspaces and snapshots (copies of workspaces) with others, and for the other, Github Codespaces allows you to use Live Share to collaborate on the same project.

I feel Live Share is a better collaboration tool, sure with Gitpod you can share workspaces with others, but with Codespaces you can both be working on the same project, without skipping a beat, and technically it would be very similar to sharing workspaces with other devs, so...I'll leave the final judgment of this to you.

Documentation

Github Codespaces has highly detailed documentation, but it's very content dense and a tad bit overwhelming. Gitpod's documentation on the other hand is simpler and more focused on the basics and includes docs and short screencasts. It's a great way to get started with a cloud based dev environment. Github Codespaces basically assumes you're already very experienced, while Gitpod assumes you're new to the world of online dev environments and slowly builds on top.

VNC

Gitpod and Github Codespaces both have VNC support. From my experiences, both are about equal in terms of how VNC works, however, Gitpod is easier to set up with VNC.

Virtual Network Computing (VNC) is a graphical desktop-sharing system that uses the Remote Frame Buffer protocol (RFB) to remotely control another computer. It transmits the keyboard and mouse input from one computer to another, relaying the graphical-screen updates, over a network. Read more on Wikipedia

A little while back I tried experimenting to see if I could set up Webkit (Safari's browser engine) on my Windows laptop...I failed, I couldn't figure out how to build the Webkit source code on Windows (it was painfully difficult), so, I tried the next best thing, the "cloud", it too failed, but interestingly enough, for a vastly different reason.

For this experiment, I used Github Codespaces (for a previous experiment I had already tried using Gitpod with VNC, so, I thought I would try Github Codespaces this time). I was able to get VNC functional but couldn't set up Webkit, since, Docker has problems with some of the libraries that Webkit uses. I tried for a good ~16 hours before I gave up. I eventually found another alternative, Playwright.

Playwright is an end-to-end framework for testing web apps on multiple browsers, it's a great tool for testing web apps.

While trying out Playwright, I found it would only work on Windows (this was because of Webkit & Docker's library issue).

Let's get back to the original topic, VNC. In my experiments, I found setting up VNC on Github Codespaces difficult and the build process for said workspace long, I actually timed it, the build process for Github Codespaces with VNC was ~6 minutes, while, on Gitpod it was much faster (I can't remember exactly how long it took, but what I do remember is that it was less than 5 minutes), also, Gitpod's documentation is much easier to digest and just get started with.

For VNC on Gitpod check out gitpod.io/blog/native-ui-with-vnc.

For VNC on Github Codespaces check out github.com/microsoft/vscode-dev-containers/blob/main/script-library/docs/desktop-lite.md.

Annoyances

In Gitpod workspaces every terminal is built from the Gitpod docker image given or if non can be found the Gitpod standard image "workspace-full", in theory, this sounds awesome, however, from my experience, it ends up being a huge pain to work around. For example, I have found that if you, use nvm (node version manager) to install a new version of node, let's say v16 to replace the Gitpod standard images node, v14, every new terminal you create will use the version of node set up in the standard image, this seems like a very minor issue, but it can cause a bunch of issues and just make you very annoyed over time, plus it just slows down your development velocity. As stated in workspace-setup section, this issue can be mitigated by building your own docker image or by typing into your .gitpod.yml file,

tasks:
  # Replace version with version you want installed
  - init: >
      nvm install v16 &&
      'nvm alias default v16' >> /home/gitpod/.bashrc
      nvm list

See more on Stackoverflow

The Internet Problem

By using Gitpod and Github Codespaces, you become reliant on the internet, and if you don't have access to the internet, you can't use either service. For most devs, this isn't really a problem, since, in most cases, they need access to the internet to commit changes to Github, Bitbucket, etc...

For cases where you don't have access to the internet, let's say your ISP messed up somewhere and you lose access for a couple days (I am speaking from personal experience here), then you become unable to do any programming at all.

For those who are worried about internet connections the best thing you can do is, to make sure you always have a local copy with all the tools and dependencies already installed, so, you can at least make some progress when you lose access.

For small instances where you lose connection for maybe a minute or two, Github Codespaces and Gitpod keep local copies of all open files, and merge them into the online copy when the connection is re-established, so, no worries there.

Warning: One thing you should pay attention to is, if you lose internet access for a long time while using Gitpod, you have to pin your workspace in their dashboard, otherwise you may lose your workspace after 14 days, and have to start over. This doesn't really apply to Github Codespaces, since you must actively delete a workspace, Codespaces will shut down a workspace, but it won't delete it for you. If you can't find a workspace, and the last time said workspace was used was less than 14 days, you will have click the View All Workspaces button

Miscellaneous

A minor difference between Gitpod and Github Codespaces is that Github Codespaces supports using your locally installed version of VS Code to continue development using the VS Code you know and love, as well as forwarding remote ports to localhost ports and much more, all together Github Codespaces allows devs to develop in an environment very similar to local developments except with less resource use (as most of the processing is happening on the remote server), and slightly greater dependence on the internet, read through Github's docs to learn more.

Gitpod supports something similar, if you install the Gitpod app as a PWA (from what I know, only Edge allows you to forcefully install websites as apps), you can then forward the remote ports on the server to your computer's localhost ports, read more about this on Gitpod's docs.

For your information: Gitpod is working on support for local VS Code, so, by the time you are reading this article it might already be live.

I don't know how important this is to devs, but Github Codespaces automatically syncs settings between VS Code and itself. To use this feature with Gitpod, you need to do some setup with your VS Code installation, read through the issue opened by Gitpod to learn more.

When to use Github Codespaces?

Github Codespaces is an easy to use and reliable VS Code service, its integration with Github is quite convenient and is hard to properly quantify, its extension support is top tier, its a coding experience that is hard to pass on, especially for devs who already use Github's other services. Github Codespaces is great for devs who need high-resource workspaces and are ok without self-hosting on other platforms.

Github Codespaces is good, but it's not the perfect solution for everyone. Github's billing model is a bit strenuous, as workspace storage is not free, so, if you want to use Github Codespaces professionally, you might end up paying quite a bit unintentionally, plus, depending on how many hours you use each Github Codespace, your monthly bill can be a rather painful pill to swallow.

When to use Gitpod?

Gitpod is an easy-to-use and very reliable VS Code service, and its open-source design allows you to get involved, maybe even fix issues as they arise. Gitpod is great for open-source projects, for those that want a reliable and consistent monthly pricing scheme, for devs looking for non-proprietary VS Code workspaces, or devs that want to use Bitbucket, Gitlab, etc.. and/or to use a self-hosted option on AWS, GCP, etc... Really Gitpod is great for the same reasons as Github Codespaces, it’s just that Gitpod has a little less Github integration which makes Github Codespaces a nicer experience to use with Github.

Conclusion

Both services are amazing, as they bring a consistent and reliable VS Code experience to devs via the web. However, they are not the perfect solution for everyone, as they each have their ups and downs.

I have stated my personal experience with both services, and I would recommend using the one that you feel is best for you. Personally, I switch between both services rather often, however, I prefer Github Codespaces. I find it to be the best option for me as it syncs my settings, supports local VS Code, and has great integration with Github and VS Code extensions (I am even able to use Github Copilot in Github Codespaces).

Note: I actually used Github Codespaces together with Github Copilot to write this article. Trust me when I say it's an excellent writing companion, it's almost like the Gmail autocomplete, but better, since it also recognizes code syntax, and can apply them rather effectively.

An alternative to Github Copilot is Tabnine. I haven’t actually used it, but I feel it’s worth mentioning as an alternative, since it works on Gitpod.

For a more neutral and objective comparison between both services, I suggest reading through Nader Dabit's article on FreeCodeCamp comparing the two.

---

Update Sept. 09, 2021: Add missing selfhost and opensource Gitpod plans; get quotes from @GeoffreyHuntley from @gitpod concerning server config; add Tabnine as an alternative to Github Copilot; add possible Docker or .gitpod.yml fix to Gitpod’s terminal node version issue; fix spelling and grammar issues

---

The idea for this article came from a tweet by Nik Molnar @nikmd23 and Stephan Meijer @meijer_s.

Photo by Okiki Ojo, you can find the image on Dropbox.

Also, published on Hackernoon and dev.to