GitHub Codespaces: Move Your Development Environment to the Cloud

Photo by Daniel Julio on Unsplash

A guide to setting up a development environment in seconds without hitting OS or hardware limits.

Hi, I’m Kerem. I am a newly graduated computer engineer, and in my first article, I will talk about GitHub Codespaces — a tool I wish I had discovered as a student.

I remember struggling for hours to install a compiler for the first assignment of my programming class in my freshman year (C was taught in my initial major, Electrical and Electronics Engineering), restarting my computer dozens of times. Finding the right version for my machine, the correct compiler for my operating system, and properly setting the environment variables turned the joy of learning into an absolute ordeal.

What is GitHub Codespaces?

Codespaces is basically a cloud-based development environment service introduced by GitHub to practically solve the notorious “It works on my machine, why doesn’t it work on yours?” problem.

In more technical terms, it allows you to access an isolated Linux machine in seconds that contains all the dependencies, tools, and system configurations your project needs.

How Would It Have Saved Me From the Installation Nightmare?

If I had been using Codespaces back then, it wouldn’t have mattered whether I had Windows or Ubuntu installed on my computer, or how powerful my hardware was. It would have been enough to simply click that green “Code” button on GitHub and start a Codespace. Seconds later, an environment 100% ready for coding, with the compiler version already set and environment variables defined, would be waiting for me. No restarting, no conflicting libraries.

GitHub Codespace Initialization

Farewell to Operating System Wars and Heavy Hardware

Today, when you join a software project, the first day is usually spent setting up the environment. You don’t want to clutter your main machine; you set up virtual machines, deal with Docker configurations, and consume your system resources in the process.

Codespaces changes this entirely. Your development environment no longer has to live inside your computer. You can access your project from any device with a web browser (even a smartphone) and start coding instantly using the resources of cloud servers running in the background.

The Source of the Magic:devcontainer.json

Behind this “instantly ready to code” experience lies a very simple yet powerful engineering concept: Infrastructure as Code. Codespaces looks at the .devcontainer folder located in the root directory of your project. The devcontainer.json file inside this folder acts as the constitution of your environment.

This file tells the cloud server exactly what to do: Which operating system image will be used? Which extensions will be installed automatically when the editor opens? Which ports will be exposed?

Get Kerem Kundak’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Here is an exampledevcontainer.json file:

{
  "name": "Data Engineering Environment",
  "image": "mcr.microsoft.com/devcontainers/python:3.10",
  "customizations": {
    "vscode": {
      "extensions": [
        "ms-python.python",
        "ms-azuretools.vscode-docker"
      ]
    }
  },
  "forwardPorts": [5432, 8080]
}

When you add this configuration to your project, the moment a new team member opens the project in Codespaces, a Linux machine with Python 3.10 installed boots up in the background. Necessary extensions are installed automatically, and database ports (e.g., 5432 for PostgreSQL) are made ready for external access. All the developer has to do is start writing code. Questions like “I wonder which version of Python I have installed?” or “Did I install the Docker extension?” completely disappear.

Connecting to Codespaces with VS Code in the Browser

Terminal output showing devcontainer.json in action

Of course, we are not limited to just the browser. You can also connect to your Codespaces using the VS Code installed on your local computer.

Option to open in VS Code desktop

After clicking this option, you can close the browser tab and continue with your local VS Code.

Local Network Connection: Port Forwarding

When I started using Codespaces, the feature that impressed me the most technically was Port Forwarding.

Normally, when you run an application on a remote cloud server (AWS, GCP, or a standard VPS), accessing it from your own computer is cumbersome. You need to find the server’s external IP address and open a port in the firewall.

In Codespaces, this process is completely automatic. We don’t need massive architectures to see this. Let’s imagine we open the terminal inside Codespaces and write this simple command that starts Python’s built-in web server:

$ python -m http.server 8000

This command starts a simple server listening on port 8000 in that isolated Linux machine in the cloud. The moment you press Enter, Codespaces notices this. A new record drops into the PORTS tab in the bottom panel, and Codespaces forwards this port 8000 in the cloud directly to your own computer through a secure tunnel in the background.

Now, the only thing you need to do is open the browser on your own computer and type localhost:8000 into the address bar. When you press Enter, your project files in the cloud instantly appear before you.

Your application is running on GitHub servers hundreds of kilometers away from you, utilizing high hardware power, but you are testing it via “localhost” as if it were running on your own computer. This is the greatest comfort Codespaces offers to a developer.

Conclusion: The Environment is Ready, Now It’s Time to Build

Traditional environment setup processes are one of the biggest obstacles that delay us from moving on to the “problem solving” and “writing code” phases, which are our actual work. With GitHub Codespaces, we have completely eliminated this obstacle. We now have an isolated development environment that boots up in seconds and runs with the comfort of localhost, independent of our hardware and operating system.

Since the “It worked on my machine” era is closed, we can now start building our actual architectures on top of this clean and flexible infrastructure.

This article was just the first step of a series I will write on overcoming bottlenecks in modern development processes and building more efficient systems. In upcoming articles, we will continue to focus on how to manage different tools within this isolated environment we prepared and how to automate our processes.

Thank you for taking the time to read, see you in the next articles of the series!