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 releasing capabilities that will enable developers and organizations to efficiently manage and confidently scale with Codespaces.

Retention setting for all individuals

To enable auto-cleanup of unused codespaces, inactive codespaces will now be automatically deleted if they have been unused after a period of 30 days. The retention period applies to all individual users on GitHub.com that are using Codespaces and can be adjusted to a maximum value of 30 days. With that, developers no longer need to remember to manually clean up old instances of dev environments that may be unintentionally generating additional costs. The retention counter for inactive codespaces can be reset by connecting to the instance. Additionally, developers will be notified via email and in-product messaging to help them stay informed about the auto-deletion.

Retention policy for organization administrators

Organization admins will also be able to set an organization-level retention constraint for their organization’s codespaces. The organization retention policy will override the individual default retention setting for organization-owned codespaces. With this, admins no longer need to remind individual teams to clean up stale codespaces thus minimizing wasteful resources and saving money for their organization.

We are also introducing support for organization level APIs and CLI commands in public beta so that admins can programmatically manage their organization-owned codespaces at scale. With this beta, organization admins can use the following REST API and CLI commands:

API

  • List all codespaces within your organization.
  • Get information on a specific codespace within your organization.
  • Stop, or delete codespaces within your organization.

CLI

  • List all codespaces within your organization.
  • Stop codespaces within your organization.
  • Delete codespaces within your organization.

Additionally, developers can also manage their own codespaces via APIs listed in our documentation that are generally available. With these APIs, you can perform CRUD (Create, Read, Update, and Delete) operations, view available machine types, and manage user-level and repository-level secrets for your codespaces seamlessly.

Get Started

The default 30 day retention setting will be applied to all new codespaces going forward across GitHub Free, Team and Enterprise Cloud plans. The max retention policy constraint is generally available and organization APIs are in beta for GitHub Team and Enterprise Cloud plans.
Here are links to our documentation to get started:

If you have any feedback to help improve this experience, be sure to post it on our discussions forum.

See more

Today, we’re announcing that the ability to prebuild codespaces is entering general availability. A prebuilt codespace serves 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 new codespaces are available on-demand without any wait period. This helps significantly speed up codespace creations–especially for complex or large codebases.

With general availability, we’ve introduced a ‘prebuild in progress’ label in cases where a prebuild template creation is in progress to enable developers stay informed for when a given branch and machine type is ready for a fast codespace creation experience. Administrators now have more control on how often prebuild configurations are updated to manage Actions usage. They can also configure retention settings on prebuild templates to manage underlying storage costs. Additionally, with failure notifications, repository administrators can specify a set of individuals or teams to be informed via email in case a prebuild-associated workflow fails to help with efficient monitoring. Administrators can also temporarily pause a prebuild workflow run while fixing an underlying issue.

With general availability, organizations will be billed for Actions minutes required to run prebuild associated workflows and storage of templates associated with each prebuild configuration for a given repository and region. As an administrator, you can download the usage report for your organization to get a detailed view of prebuild associated Actions and storage costs for your organization-owned repositories.

Prebuilt codespaces are generally available 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 get started!

See more

When you work in a codespace, the environment you are working in is created using a development container, hosted on a virtual machine. If you don’t define a configuration in your repository, GitHub creates a codespace using a default Linux image. This Linux image includes common languages and runtimes such as Python, Node.js, JavaScript, TypeScript etc. to help you get started with an environment that you can further customize or use as is based on your team’s needs.

‘Zero-configuration’ getting started experience for machine learning users

With this update, we’ve released a new version of the default image that enables a seamless getting started experience for machine learning scenarios:

  • The default image now has Jupyter pre-installed by default so that you can immediately run jupyter notebook or jupyter lab from the terminal to get started with your data science project.
  • The default image also has the following commonly used machine learning specific Python libraries pre-installed by default:
    • For numeric computing: numpy, pandas, scipy
    • For data visualizations: matplotlib, seaborn
    • For model building: scikit-learn, tensorflow, keras, torch
    • For data fetching: requests
  • Lastly, you can include any additional project-dependent Python packages in the requirements.txt file, and those will be automatically installed at a user scope when you create your codespace.

Additional updates

  • Alongside these improvements, the default image has been updated with the following tools to optimize for speed and costs associated with default codespaces. We’ve also updated the major version of the image to 2 since the removal of these toolsets introduces breaking changes. While some of the tools are not included by default anymore, you can always add these by creating your own devcontainer configuration.
    Tools added:
    • Node 14
    • Node 16
    • Python 3.9
    • Python 3.10
    • Conda 4.12
    • Java 11
    • Maven 3.8
    • Ruby 3.0
    • Ruby 3.1
    • PHP 8.0
    • PHP 8.1
    • PHP Composer 2.3
    • Hugo 0.96
    Tools removed:
    • Node 12
    • Python 3.8
    • Conda 4.8
    • .NET 5.0
    • Ruby 2.7
    • PHP 7.2
    • PHP 7.3
    • PHP Composer 2.0
    • Hugo 0.90
    • Maven 3.6
    • PowerShell
    • Az CLI
    • Rust
  • Lastly, as a part of this update, for tools that have LTS support (e.g. node, python), the default image will include the latest two LTS releases going forward.

To learn more, check out the latest Codespaces default image configuration.

See more

Big news for computer science (CS) teachers. GitHub verified teachers using GitHub Classroom get access to GitHub’s groundbreaking, browser-based IDE, Codespaces. It’s a seismic shift for CS education, breaking down barriers in a fundamentally new way. Whether you’re a teacher frustrated with the complexities of managing local machine-based developer environments, tired of troubleshooting your students’ tools rather than focusing on their code, or looking to reduce technical and cost barriers for your CS Classroom, Codespaces addresses so many of the pain points in CS education with one elegant solution – integration in GitHub Classroom.

You can enable Codespaces in GitHub Classroom and then choose it as the preferred editor when creating assignments.

image

These changes will gradually roll out over the next week. For more information on how to use this new experience, check out our documentation and blog. Your feedback is welcome at our Education Community Forum.

See more

Currently, codespaces are automatically stopped after 30 minutes of inactivity to avoid wasteful resources when they're not being used. Additionally, a default idle timeout can be set for a codespace of up to four hours.

We heard from many organization admins that they want to restrict idle timeouts for organization-owned codespaces as a measure of cost control. With this feature, we've added the ability for administrators to set a maximum idle timeout that applies to organization-owned codespaces. For instance, if the maximum idle timeout constraint is set to 15 minutes, then all organization-owned codespaces will be automatically stopped after 15 minutes of inactivity regardless of the default timeout set by individual developers.
image

We will continue adding additional policy constraints based on feedback, some of which include setting maximum retention periods, setting allowed container images, and more. We'd love your feedback on additional policies that will help your scenarios on Codespaces discussions.

For more information, see Restricting idle timeouts for organization-owned codespaces

See more

Codespaces now has improvements that will streamline your experience when working with multi-repository and monorepo projects.

To enable teams to develop applications that span across multiple repositories (e.g. common in microservice architectures), we have added the ability for users to configure which permissions their codespace should have on creation. This means that users will no longer have to set up a personal access token inside of their codespace to clone or create pull requests for multiple repositories.

Additionally, if you're a part of a larger organization and have many teams working in a single repository (e.g. monorepo), Codespaces now supports multiple devcontainer.json files inside of your .devcontainer directory, as long as they follow the pattern of .devcontainer/${DIR}/devcontainer.json.

Lastly, to provide more flexibility during codespace creation, there's a new advanced create flow for Codespaces that allows you to select various options, such as branch, geographic region, machine type, and a specific dev container file while creating your codespace. If you want to skip the advanced creation flow, you can always go for the one-click create by selecting Create codespace on <branch name> to create a codespace with the default configuration.

With these updates, repositories can be setup with multiple devcontainers, each with permission sets, setup scripts, and a codespace configuration specific for certain sub-teams or developer roles (e.g. front-end, back-end). Then, developers can select the ideal devcontainer, machine type, and geographic region for their task during the codespace creation with the advanced flow, as needed.

Here are some helpful links to get you started!

See more

Repository administrators can now configure how often/when prebuild configurations for a given branch should be updated. Prebuilds enable developers to startup Codespaces in seconds – regardless of repository size or complexity – by building your development environment beforehand. Previously, prebuild configurations were updated on every push made to a prebuild-enabled branch. During public beta, we heard from many repo admins requiring more control on how often their configurations should be updated based on their team’s processes as well costs associated with running Actions workflows to keep configurations up to date.

With this feature, admins can now make more nuanced trade-offs between environment “freshness” and Actions usage. For example, an admin working in a large organization may decide to update their prebuild configuration every hour rather than on every push to get the most economy and efficiency out of their Actions usage. While creating or updating prebuilds for a given repo and branch, repository admins can choose from three triggers to initiate a refresh:

  • Every push (default): With this setting, prebuild configurations are updated on every push made to the given branch. This ensures that new Codespaces always contain the latest configuration, including any recently added or updated dependencies.
  • On configuration change: With this setting, prebuild configurations are updated only when configuration files (ex. devcontainer) change. This ensures that developers always have access to a Codespace based on the latest configuration without having to run Actions workflows on every push made to the repo.
  • Scheduled: With this setting, you can have your prebuild configurations update on a custom schedule only, regardless of any pushes made to the branch or updates made to associated configuration files. This can further reduce consumption of Actions minutes and give admins even more control on how often configurations should be updated.

image

For more information, see Configuring prebuilds for your repository

See more

Currently, forwarded ports within codespaces can be set to private in which case they can be accessed only by the owner of the codespace, be shared with members of the organization or be set to public at which point anyone the URL is shared with can view the port. We heard from many organization admins that they want to disable public ports for organization-owned codespaces with the goal of ensuring that company assets can only be shared and accessed by members of the organization for security purposes.

With this feature, we have added the ability for organization admins to add port visibility constraints that enable them to control which visibility settings are available within organization-owned codespaces. For instance, admins will be able to disable the 'public' visibility port setting for desired repositories within their organization and enable developers to continue sharing ports only with members of their organization. This would be done to help preventing codespaces users from accidentally exposing company owned assets to unauthorized individuals.
port visibility policy constraint image

We will continue adding additional policy constraints based on feedback, some of which include setting a maximum idle timeout, setting maximum retention periods, setting allowed container images, and more. We'd love your feedback on additional policies that will help your scenarios.

For more information, see Restricting the visibility of forwarded ports

See more

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