Exploring GitPod Configuration and Workflow

In my previous post I explored GitPod and I have kinda settled on it as my default Development environment. The last couple of changes in my GitHub repos were all from GitPod workspaces.

The more I use the service the more I like it. My plan is to eventually transition all my development to this service, which provides a VSCode IDE (or InteliJ) in a web browser. I have also used it now a couple of times on my iPad. I created a shortcut on the home screen which also allows the workspace to then run in full screen mode, so it feels just like a real IDE and not a web page.

One of my best best discoveries this far is how powerful the workspace configuration is.

Anyway, allow me to share some of my discoveries and explain how my current development workflow works. Perhaps you can find some useful tips or perhaps a more experiences GitPod user can show me a better way.


Setting up your development environment

By accident I discovered recently when I opened a project with a requirements.txt file, that GitPod automatically recognized the file as the file Python uses to define dependencies. So, GitPod automatically executed the command pip install -r requirements.txt which installs all the dependencies.

Incidentally, this was for this blog which I now edit only in GitPod.

But, since this is a repeatable task that is required for all workspaces that I may create in the future for this repository, GitPod also created a file called .gitpod.yml with the following content:

# This configuration file was automatically generated by Gitpod.
# Please adjust to your needs (see https://www.gitpod.io/docs/config-gitpod-file)
# and commit this file to your remote git repository to share the goodness with others.

  - init: pip install -r requirements.txt

As you can see from the comment, the full details on how this file works is available from the GitPod documentation site.

This was great... but I also needed the AWS CLI in order to upload site changes to AWS S3. So I modified the file and the final version now looks like this:

  - name: Python Requirements
    init: pip install -r requirements.txt
  - name: AWS CLI
    init: cd ~/ && curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip" && unzip awscliv2.zip && sudo ./aws/install && cd $OLDPWD

Therefore, each time a new workspace is created that does not yet have these development dependencies installed, it will now run these commands.

Therefore, it will not matter how many workspaces you end up using, by having your development dependencies defined as code, GitPod will ensure that these are installed as and when required for new workspaces.

Environment Variables

For security reasons, AWS credentials must never ever be stored in your Git repository - even if it's private. I have seen what could happen if you accidentally commit credentials to GitHub and it's not pretty!

At the same time, I am still contemplating how I want to do this in GitPod, but fow now I settled on manually defining my GitPod Environment variables for AWS credentials.

However, there are some environment variables that I do want to set on every workspace. One such variable is for a command I want to run to clear all AWS environment variables from time to time - perhaps because I want to switch to another set of credentials but mostly as I don't like sensitive information like this floating around in cyberspace too long.

GitPod allows you to define environment variables with scope, as you may be able to see from the screenshot below:

environment variables

Now, whenever I start a workspace, and depending on the scope and the actual workspace, the environment variables will be exposed based on this configuration.

While you are in a workspace, you can see all the exposed variables by running the command gp env. It is similar to just the normal env command available through BASH or ZSH, but displays only the GitPod related environment variables.

In this particular example, when I run just env I see the following, since I already exported my AWS credentials:

GITPOD_TASKS=[{"name":"Python Requirements","init":"pip install -r requirements.txt"},{"name":"AWS CLI","init":"cd ~/ && curl \"https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip\" -o \"awscliv2.zip\" && unzip awscliv2.zip && sudo ./aws/install && cd $OLDPWD"}]

To unset my AWS credentials, I run the following command: eval $UNSET_AWS

Security Warning: Using eval can be dangerous, so please familiarize yourself with the full consequences. On stackoverflow I found a very interesting thread discussing the potential issues.

After running the command, the critical variables are no longer available in the terminal session I use. Keep in mind also where you use the environment variables - as in which terminal sessions.


Dealing with files not yet in your repository

I am still still learning, so I will probably optimize as I go. However, one of the challenges I run into while creating this blog was how to take a screenshot and then use it in my project.

Normally, on a PC, the screenshot can be saved directly in the directory of your project. In this case, since GitPod runs in a browser, it is oblivious to your local filesystem.

I solved this problem using AWS S3 buckets as a shared BLOB store.

Therefore, whenever I need to get files, like screenshots, into my project I will upload them to AWS S3 and then within GitPod, download then into the appropriate directory - all using the AWS CLI.

On iPad, you can use the official AWS Console APP to view files to S3. However, I found that a much better tool to manage all your cloud files from a single app is Stratospherix FileBrowser which works really great.

Therefore, my screenshot steps, are as follows:

Dealing with AWS credentials

As mentioned, I don't yet trust storing my AWS credentials in a cloud service. What I use is a password manager (anyone you prefer should do), to store all my credentials. For the purpose of my workflow, I use my password manager's notes section to define all the credentials exports for a specific IAM user.

Tip: You should really have IAM users with groups/roles defined specific to a specific task. It creates a little overhead, but it does allow you to limit any potential widespread fallout should any one of these sets of credentials be compromised. A malicious person will only be able to do what the user permissions allow then to do, so by giving only the permissions for very specific tasks to each IAM user is a great way to limit what is known as the blast radius.

Therefore, in a single terminal session, I will use the following steps:


I am really liking GitPod more and more as I use it everyday. I really think this is the future. The possibilities that it enables really appeal to me, especially since I am moving more and more of my work to be purely in the cloud. I hope to one day have devices like an iPad that has the minimum of data stored on it, and I rely mostly on cloud applications to get work done. All my data is primarily in the cloud and it no longer matter if a device becomes obsolete - just replace it, install the apps you need and you are ready to go.

What I really enjoy about GitPod in this context is that all my development environments are separated and I can deal with the dependencies and other nuances of each project in a consistent way with teh tools that GitPod provide.

I feel I have only scratched the surface, and perhaps I will share some more in the future. There is a lot I still need to discover - for example working with Docker images in GitPod. However, I can see myself transitioning off laptops and computers to a cloud only environment where an iPad would be more than sufficient for daily work. With that said, I am also looking forward to the additions coming in iPadOS 16 like Stage Manager while using an external monitor in full screen mode. This work environment is much more powerful than almost anything you can reasonably buy in terms of traditional laptops and PC's.

Let me know if you are also excited about this future!


vscode, ide, gitpod