Skip to content

codespaces

Subscribe to all “codespaces” posts via RSS or follow GitHub Changelog on Twitter to stay updated on everything we ship.

~ cd github-changelog
~/github-changelog|main git log main
showing all changes successfully

Today, we’re announcing that the ability to prebuild codespaces is entering public beta. Prebuilding a codespace enables fast environment creation times, regardless of the size or complexity of your repositories. A prebuilt codespace will serve as a ‘ready-to-go’ template where your source code, editor extensions, project dependencies, commands, and configurations have already been downloaded, installed, and applied so that you don’t have to wait for these tasks to finish each time you create a new codespace.

As a part of this release we’ve made improvements to the set-up process for prebuilds, as well as added support for GitHub-managed Actions workflows that will automatically prebuild a codespace for any configured repository’s branch and region(s). Additionally, since prebuild configurations are built on GitHub Actions virtual machines, repository admins will have access to a rich set of logs to help with efficient debugging in case failures occur.

Prebuilt codespaces are available in beta for all GitHub Enterprise Cloud and Team organizations. Repository admins can head over to their repository’s settings page and create prebuild configurations under the Codespaces tab. Once set up, you can take advantage of fast codespace creation by selecting machine types with the ‘prebuild ready’ tag.

Check out the prebuilds documentation to help you get started!

See more

We've gotten a lot of feedback from users that it's hard to differentiate multiple codespaces in the same repo, especially if they're on the same branch. To make it a little easier to tell codespaces apart, we've started automatically creating "friendly" (and fun) names for your codespaces.

codespace_friendly_names

If you don't like our names, we're also working on the ability for users to re-name their codespaces.

For more information on Codespaces, see "GitHub Codespaces overview".

See more

Currently, Codespaces users in organizations in Team and Enterprise Cloud plans can use any machine type, from 2-core to 16-core (or even 32-core). We've heard from many organization administrators that they want the ability to restrict which machine sizes repositories in their organization should have access to as a means of cost control, and have implemented a new Codespaces policy feature to allow admins this level of control.

Organization admins can now visit their organization's settings page and create Codespaces policies to restrict which machine types repositories in their organization can use. For instance, an admin can restrict certain repositories to only access 2-core and 4-core machines, while granting other, more compute intensive repositories, access to 16-core machines.

In the future, the Codespaces policy feature will be expanded to include additional constraints, including setting a maximum idle timeout, restricting which port forwarding settings are allowed, and more. We'd love your feedback on other constraints you're interested in.

For more information, see "Restricting access to machine types".

See more

Codespaces have been constrained to specific users or all members of an organization, which, while great for day-to-day software development, didn't allow everyone in an organization to participate. That's why we're so happy to announce that as of today, you can invite outside collaborators to access Codespaces.

Outside collaborators expand Codespaces to use cases like interviewing, training, and teaching, where you can easily add outside collaborators to specific repositories within your organization (or in certain cases, giving each collaborator their own repository). Start by granting "All members and outside collaborators" access to Codespaces, then inviting collaborators to repositories you want them to use Codespaces in.

For more information, see "Enabling Codespaces for your organization."

See more

By default Codespaces time out after 30 minutes of inactivity. We’ve heard from many users that they have a desire to extend this up to an entire workday. You can now set a default idle timeout for your codespaces from five minutes to four hours, as well as override the idle timeout for an individual codespace using the gh CLI.

For more information, see “Setting your timeout period for Codespaces”.

See more

Dotfiles are a common way to specify custom, user-specific behavior for applications (like Vim or Emacs) and shells on your codespaces. If enabled, dotfiles stored in a user's public dotfiles repository would be used for this configuration. With this change, any user owned repo, including private repos, can be used to install dotfiles into your codespaces.

For more information, see "Dotfiles".

See more

GitHub Codespaces allows teams and organizations to spin-up developer environments directly from a browser or through Visual Studio Code, without the hassle of setting up a brand new environment tailored to a specific repository.

We've been hard at work since our general availability announcement in August making Codespaces the best way for you to develop software, which is why we're so happy to announce several new features at GitHub Universe 2021.

We know that many developers use the gh CLI to speed up or fully automate daily tasks, and we've received dozens of requests to add Codespaces support to the CLI. As of today, the gh codespace (or gh cs for those saving keystrokes) command now allows developers to manage their codespaces from the GitHub CLI. In addition to codespace creation, listing, and starting/stopping, users can forward ports, set port visibility, SSH into their codespaces, and copy files to/from their codespaces.

# Create a new codespace via the CLI
gh codespace create --repo monalisa/octocat --branch main

We're especially excited about ssh access, as it allows developers who prefer to use editors like vim and emacs to more easily develop in Codespaces. Just gh cs ssh into your codespace and launch your editor of choice; we'll set up the environment and grab all your dotfiles so you're ready to develop in seconds.

# SSH into the codespace created above
gh codespace ssh -c monalisa-monalisa-octocat-1337h4x0r

Complimenting the CLI, we are also launching an API in beta. The API provides control plane operations around a user's codespaces including creating, starting/stopping, listing available machine types, and setting user secrets. These APIs will allow developers to build Codespaces integrations into their favorite editors and tools, as well as allow for additional automation around Codespaces.

# Stop a running codespace via the API
curl https://api.github.com/user/codespaces/monalisa-monalisa-octocat-1337h4x0r/stop \
  -H "Authorization: token <Personal Access Token>" \
  -X POST

We also know that security and privacy are critical, and we've gotten a lot of feedback on providing additional visibility options for forwarded ports beyond public and private. Today we're launching a third option: org visible ports, which are accessible to any user in the organization the codespace has been created in. This is great for securely collaborating with your teammates on new and exciting features in your codespaces.

# Make port 80 visible to all users in an org
gh codespace ports visibility 80:org -c monalisa-monalisa-octocat-1337h4x0r

Continuing with security improvements, we have also heard from developers having difficulty launching codespaces from devcontainers stored in private container registries. To make this easier, we are offering streamlined access to containers stored in the GitHub Container Registry; you no longer have to provide a Personal Access Token (PAT).

Speaking of devcontainers, we know that there's a wide gap between using a predefined devcontainer and building a custom devcontainer. To help make that transition a little easier, we're launching the ability to extend devcontainers with features, which include shells, package managers, programming languages, and other common tools. For example, adding Terraform to a supported base image is as easy as adding the following to your devcontainer.json.

"features": {
  "terraform": "latest"
}

If you have any feedback about these features, or Codespaces in general, we'd love to hear from you!

Learn more about all our newly released features:

See more

Today, Codespaces is rolling out progressively for organizations on Team and Enterprise Cloud plans. Organization owners can enable Codespaces in organization settings.

Codespaces can be used for free through September 10th, 2021 (PST) for enabled organizations in Team and Enterprise Cloud plans, after which billing begins.

For users in individual plans, we’re extending the existing Codespaces beta. For those in the beta, access will remain and we’ll share updates on what’s coming in the near future.

Read more on our Codespaces page and in docs.

See more

We recently launched new and improved content for Codespaces. We heard from our beta testers that they wanted more task-focused documentation, more information on the benefits of Codespaces, and more specific examples on how to use it. We've restructured the content to make it easier for you to discover and added the following sections:

See more