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

GitHub Codespaces with included free usage is now rolling out to all GitHub Free and Pro accounts. Over the coming days you'll see a new option under the green "Code" button (where you are used to getting the info you need to clone a repository) that enables you to spin up and manage cloud based development environments that free you from the pain and hassle of setting up and maintaining local configurations. Until now, only Teams and Enterprise managed GitHub Organization members had access to Codespaces.

With this update, GitHub will provide each Free plan account 120 core hours, or 60 hours of run time for a 2 core codespace, plus 15 GB of storage to use each month. Pro accounts get 180 core hours and 20 GB storage per month. You can see how much included usage is remaining for your account during the current billing period on your billing page. If you use up all of your included usage, it is easy to set up a spending limit and keep working. For more details see "About billing for GitHub Codespaces."

We hope that everyone will take Codespaces for a spin, and come join us in the community discussion space to tell us your story!

See more

This changelog only applies if you participated in the beta program for Codespaces for Individuals.

Today marks the start of the rollout of Codespaces for Free and Pro accounts, and thus the end of the beta for Individuals. Unfortunately, this also ends unlimited free use of Codespaces.

The good news is that this marks the beginning of much broader collaboration with more people who can now take advantage of included free compute and storage. All Free and Pro GitHub accounts receive a generous amount of free included usage each month.

Note that the default spending limit for GitHub Codespaces is $0. So even if you already have a payment method configured with GitHub, you will not automatically be billed unless you change your spending limit.

The rollout will take place over several days, so these changes will affect you in the coming days. For more details see “About billing for GitHub Codespaces.”

For those who participated, a heartfelt THANK YOU for all the feedback that has been instrumental to our getting to this milestone.
We hope that you’ll continue to enjoy Codespaces, and come join us in the community discussion space to tell us your story!

See more

GitHub now supports the use of GitHub Codespaces with JetBrains IDEs via the JetBrains Gateway. After downloading the JetBrains Gateway and installing the GitHub Codespaces plugin, users will be able to connect to their codespaces with the JetBrains IDE of their choice.

jb-gateway

Once connected, users can leverage the full power of JetBrains' IDEs in the cloud: fast, accurate code completion; integrated run and debug configurations; and unparalleled code navigation tools. Rather than needing to install each IDE on a developer machine, using GitHub Codespaces with JetBrains IDEs enables the use of any JetBrains IDEs in the cloud.

jetbrains-image

The beta supports connectivity to a codespace, private port forwarding, and a fully featured code editing experience in the following IDEs:

  • IntelliJ IDEA
  • PyCharm
  • WebStorm
  • GoLand
  • RubyMine
  • PHPStorm

Additional IDE support, codespace management tools (e.g. creation, deletion, changing the machine type), and better support for Development Container creation will be added as the beta progresses.

In order to connect to a codespace via the JetBrains Gateway, users will need the following:

Check out the documentation to learn more and get started.
For feedback or questions, create an issue in this repository and we will get back to you.

See more

GitHub is excited to announce support for using GitHub Codespaces with JupyterLab. JupyterLab is the next-generation user interface for Project Jupyter offering all the familiar building blocks of the classic Jupyter Notebook (notebook, terminal, text editor, file browser, rich outputs, etc.) in a flexible and powerful user interface.

JupyterLab in a Codespace

Using GitHub Codespaces with JupyterLab combines the delightful notebook editing, data exploration, and narrative building experiences of JupyterLab with the power, standardization, and simplicity of a codespace.

You can open any codespace in JupyterLab via the repository page or the GitHub CLI:

open in JupyterLab examples

You can also set JupyterLab as your preferred editor, enabling single click access to codespaces via JupyterLab:

set JupyterLab as default editor

JupyterLab support is even more powerful when combined with GPU-powered codespaces. Though GPU access is not yet generally available, you can request early access here.

Click here to learn more about GitHub Codespaces support for Machine Learning and AI, or jump straight into our template repository and try it out!

See more

We recently released organization-level API support that enables administrators to programmatically manage their organization-owned codespaces at scale. Today we're announcing that these APIs are generally available.

With organization APIs providing a wide range of management operations, organizations can seamlessly integrate GitHub Codespaces into their existing workflows to automate and manage their development processes at scale.

Organization-level APIs are generally available to GitHub Team and Enterprise Cloud plans. Here is a link to our documentation to get started:

See more

Codespace Templates

GitHub Codespaces with included free usage is now rolling out to all GitHub Free and Pro accounts. We've added experiences to quickly start new projects in a codespace using many of the frameworks you know and love. These templates are a prebuilt development environment all boxed up to work with one click, without the need to configure your development environment.
Screen Shot 2022-11-08 at 3 55 55 PM

Codespace templates come with a pre-configured devcontainer. Using a forwarded port you can see your running web application. The configuration of the devcontainer enables the necessary files to be open by default, run the services necessary, and preview the output of the application in your web editor.

Do you want to start developing in Codespaces, but you're unsure what framework to start with? Use the Blank Template to jump right into a brand new codespace! We've also included a set of starter templates for you on the Codespaces index page. You can even make your own your template for developers to use by creating your own repository template! By creating your own codespace template from a repo template, you can create a one-click, prebuilt development environment for others to use your projects.

We hope you take Codespace Templates out for a spin, and join us in the community discussion space to share your templates and collaborate with us!

See more

a photo of a devcontainer.json with openFiles, postAttachCommand, and onAutoForward defined

A development container allows you to create a full-featured development environment to use in your codespace. Codespaces use the devcontainer.json file to define the environment you will be working in within your codespace. We've added new features to devcontainers.json to help you customize the initial experience when you open a codespace.

Define the initial layout of your codespace with openFiles

You can use openFiles to define what files are open by default. If you specify multiple files, the files will open up in order from left to right. The first file defined will be the focused file. openFiles is specific to the Codespaces customization, and is only enabled in the Codespaces web editor for now. Use openFiles to improve your default development environment and ensure that you're setting contributors up for success!

Run scripts after your client connects to your codespace with postAttachCommand

postAttachCommand enables you to run scripts in the terminal after your client connects to the codespace. This change enables you to define multiple postAttachCommand definitions and they will run on separate terminals. This enables you to start your server and watch for changing files after launch from your devcontainer.json.

Combine these features into a full initial codespace experience

These changes to postAttachCommand, combined with the existing openPreview option in the onAutoForward property, enable you to create codespaces with a default layout that ensures a great Codespaces launch experience for users of your repository.

Read more about postAttachCommand, onAutoForward, openFiles, and openPreview on our docs pages!

See more

Adding a configuration for Codespaces involves adding a Development Container to a repository and editing it to meet your needs. Previously, a dev container configuration could either be written manually or created with a VS Code extension. We have now added the ability to create or edit a configuration directly from the Code drop down on a GitHub repository page.

Code dropdown showing the new Codespaces configuration option

Whether you use this mechanism, or you already have a dev container in your repository, you can now edit that configuration within GitHub using the new configuration editor. To open the editor from the code view in a repository, click the pencil icon while viewing a devcontainer.json file.

screenshot of view of devcontainer.json file

You are now editing the devcontainer.json file in place in the browser. The dev container needs to conform to the Development Container specification. The editor makes using dev container Features easy. Dev container Features provide reusable configurations for Codespaces created from the repository. Browse available features from right side of the dev container editor.

screenshot of editor and marketplace

To use a dev container feature, copy the snippet of json and place it in the features object of your devcontainer.json file. Once you have the features you want, commit those changes to the repository by clicking the "Start commit" button.

screenshot of the start commit button function

We hope this will make configuring your repositories for Codespaces significantly easier.

See more

When you are building out a configuration for Codespaces using a dev container, the default behavior is now to do an incremental rebuild. The existing rebuild functionality is still available and has been renamed to ‘Full rebuild’.

Incremental rebuild is much faster because it builds on top of your existing docker cache, reusing common images and layers between rebuilds. This is readily apparent when adding configurations to the default container for Codespaces which is quite large.

When using VS Code, you access these commands from the command palette.

Rebuild commands in the command palette in Visual Studio Code!

The rebuild behavior prior to this change was full rebuild, which is slower but guarantees correctness because it removes all images from the virtual machine before re-pulling even unchanged images. You may occasionally want to do this after many iterations of rebuilding your configuration, and want to free up disk space or ensure your configuration is not dependent on layers that won’t be present during a clean creation of a codespace from the configuration.

See more

With an organizational level policy to restrict container images, organization administrators can now control which base container images are used while creating organization-owned codespaces. This enables administrators to ensure that only verified container images are being used to create organization-owned codespaces.
allowed image policy screenshot

Organization admins can specify which images and/or image sources are allowed to be used while creating organization-owned codespaces. If the image specified in the dev container configuration does not match one of the allowed images, then subsequent codespace creation will fail asking you to update the image in your configuration. The base image policy does not apply to the default image, or the image that's used to recover a codespace if an error is introduced into a dev container configuration which prevents the container from being rebuilt.

For this release, the image policy will be applied at codespace creation and will not be applied when you rebuild a container. Support for the rebuild scenario is coming soon. We'd love your feedback on this policy and any additional policies that will help your scenarios on Codespaces discussions.

For more information, see Restricting base images for organization-owned codespaces

See more

Preview Changes in Your Web Editor

Have you ever launched an application in your codespace only for the running application to get lost in a sea of browser tabs? Today we're announcing the ability to preview your running application directly in your web editor.

Update your Preview URL

Supporting this feature required a change to the URL of previewed applications from -.githubpreview.dev to -.preview.app.github.dev. This is potentially a breaking change. If you rely on a .githubpreview.dev preview url in any project you will need to update your code to reflect the new URL format.

Alternatively, the environment variable GITHUB_CODESPACES_PORT_FORWARDING_DOMAIN gives you access to the domain that your application will forward to. This will enable you to code in this variable anywhere you have hard-coded the preview URL.

See more

Today, we're releasing updates that will optimize prebuilding codespaces for your repositories. With these updates, as long as there is an active prebuild for a given repository, branch, and devcontainer combination, you will be able to spin up prebuilt codespaces for it, even if the latest prebuild workflow for that branch might be failing. This ensures fast codespace creation most of the times regardless of any breaking changes that may be adversely affecting the latest prebuild update.

Repository admins will have the option to disable this optimization if needed by going to their prebuild configuration page under advanced options.
screenshot to disable prebuild optimization

For more information, see Configuring prebuilds for your repository.

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

See more

We recently released a set of organization-level APIs (in beta) to enable administrators to programmatically manage their organization-owned codespaces at scale. Today we're releasing support for additional organization-level APIs based on the feedback that you shared with us. With this release, we've added support for the following REST API commands:

  • Manage organization-level codespaces secrets
    • List organization secrets
    • Get an organization public key
    • Get an organization secret
    • Create or update an organization secret
    • Delete an organization secret
    • List selected repositories for an organization secret
    • Set selected repositories for an organization secret
    • Add selected repository to an organization secret
    • Remove selected repository from an organization secret
  • Manage access control for organization-owned codespaces
    • Enable Codespaces for all members of the organization
    • Enable Codespaces for select members of the organization
    • Enable Codespaces for all members and outside collaborators of the organization
    • Disable Codespaces for the organization

Organization-level 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

With this update, organization admins can manage billing settings for codespaces that are created for organization controlled repositories. Admins can choose to opt-in to the organization covering the bill for GitHub Codespaces, enable Codespaces access only for select members of the organization, allow for all organization members, or also include outside collaborators. See the screenshot below, and documentation for Enabling GitHub Codespaces for your organization for more details.

Organization Settings Billing UI

Note: The functionality of this interface remains the same. The label was updated to "Billing" where it used to be labeled "User permissions" to increase clarity. There are no changes required to your settings as a result of this update.

Any GitHub user who can clone a repository and has access to Codespaces will be able to create a codespace for it. To manage who can clone a repository in your Organization see Managing teams and people with access to your repository.

See more

In April 2022, we released improvements to help streamline your Codespaces experience when working with multi-repository and monorepo projects. Today we're announcing support for prebuilding these project types as well to enable you take advantage of fast creation times across any project configuration.

Prebuilding codespaces for multi-repository projects

For multi-repository projects, or projects that need additional dev time resources (ex. packages), repository administrators can now specify required permissions in the dev container configuration for a prebuild-enabled branch. The prebuild configuration UI will then guide the administrator to authorize those permissions during the creation of the prebuild. This means that users no longer have to set up and manage repository level personal access tokens for prebuild-enabled multi-repository projects.
Authorize permissions for prebuilds!

Prebuilding codespaces for monorepo projects

For monorepo projects, repository administrators can choose a specific dev container configuration from within their repository to be prebuilt while configuring the prebuild. This enables sub-teams working on specific parts of a monorepo to have a prebuild that is optimized for their scenario and requirements.
Select a specific dev container to prebuild

Get started

Here are some helpful links to get you 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 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