Max number of codespaces during beta

Codespaces Beta
#1

I have been using Codespaces beta for about a week and apart from a few minor issues I found and posted in different topics in this community, it really works great.

I even went as far as removing all local clones of the main repos I work on to force myself to work on them with Codespaces only, to test drive remote only development during normal working days.

The only real bottleneck I have with this workflow during the beta is the number fo available codespaces, which are limited to 2. This means that I have to scrap a codespace every now and then to spin up another codespace to make a quick commit, scrap it again and spin up yet another codespace to work around the 2 codespaces limit.

Are there any plans to increase the max number of codespaces during beta, even if it is a paid option? Or limit the number of running codespaces to 2 but allow keeping around a few more codespaces to avoid having to rebuild the same codespaces over and over?

#2

To maximize the 2-codespaces limit, once you made a new change and you’re ready to merge it, you should dispose the codespace immediately. I don’t think GitHub currently allows expansion of the limit.

1 Like
#3

Thanks for the feedback.
Currently, there is no way to increase the limit of codespaces during the beta but we’re taking your ideas to think on.

In the meantime, I encourage you to follow @sr229’s suggestion. Out of curiosity, is there a reason you want to keep your codespace around instead of disposing it after you complete a task?

1 Like
#4

My workflow is already as @sr229 suggested, i.e. I dispose of a codespace when a issue is merged and I know that I need a codespace slot for another project. The only reason why I would like to keep more codespaces around is to avoid the few minutes wait to spin up a new codespaces when switching between projects with the 2 slot limit.

1 Like
#5

Makes sense!

Thanks for the feedback. We’ll keep this in mind as we continue work on Codespaces!

#6

count of 2

Removed my duplicate post and coming over here to add additional feedback.

I’d like to propose that the number of codespaces be increased, even if the number of ACTIVE codespaces be limited to 2.

Even the free tier of stuff like GitPod doesn’t restrict the reaction of the codespaces to 2.
A inactive asleep codespace should allow more flexibility.

possible other option

One of my coworkers instead using the “clone repo inside container” and reuses the same codespace (using visual studio codespaces) to have the equivalent of a multi repo codespace to work.

The ability to create a codespace not tied to one repo might be a possibility or let me know if the option would instead be to create a “base workspace” repo (i’ve done one like this: https://github.com/sheldonhull/codespace-powershell/) and then clone repos inside of it and use it for all the relevant work?

why the count is limiting

If you use Codespace-Linux with all tools included to make a dev environment simple to work with, dotnet, python, go etc… then this image can take a while. Locally, I see the containers taking up almost 10GB. If the bootstrapping of a new container took < 1 min then I’d not worry about the count, but with it taking 5-10 mins and waiting on refresh it’s just too intrusive to the development workflow when jumping between repos.

1 Like