GitHub is no longer admitting new users or organizations to the limited beta for GPU-powered Codespaces due to limited capacity for this virtual machine type. Existing beta participants will be able to continue using these machine types, however no new users on the current waitlist will be granted access. For any updates on features we’re working on and what stage they’re in, please follow the GitHub public roadmap.
What would you do with twice the memory on your computer? How about 30% better CPU performance?
Over the past six weeks we’ve upgraded underlying infrastructure for Codespaces, migrating from Intel to AMD based CPUs, which boast improved specs.
As of today, 4-core and higher Codespaces now include twice the RAM, and 30% better CPU performance, at no additional cost to you. You now get snappier performance and more room for your processes to stretch out without having to lift a finger. We’ll be rolling out the same upgrade for the 2-core Codespaces in a matter of days.
If you’re using an 8-core machine because you need the RAM, now you can save cost by backing that down to a 4-core machine so you get twice the bang for the buck. Same goes for scaling down from 4 to 2 cores, and so on. Because free usage of GitHub Codespaces is calculated by cores per hour, using a smaller machine will also give you more free coding hours.
Now your GitHub Codespaces cloud dev environment builds, tests, and shares your running application faster than ever, at the same price.
Note: this release does not affect the machines used in the generation of Codespaces prebuilds.
Give ‘em a spin! https://github.com/codespaces
GitHub Codespaces has introduced new access and ownership settings, providing organizations more granular control over which members and outside collaborators are able to create codespaces on organization-owned private and internal repositories.
Owners of organizations on the Team or Enterprise plan can now select which of their organization's members or collaborators are allowed to use GitHub Codespaces on organization-owned private and internal repositories. In order to use GitHub Codespaces, an organization member or collaborator will need explicit access to GitHub Codespaces and either write or fork permissions on the repository.
Any members or collaborators not explicitly granted access will not be allowed to use GitHub Codespaces within the organization's private or internal repositories. Those members or collaborators may still use codespaces on public repositories owned by the organization, like any other GitHub user.
Additionally, organization administrators can select whether member or collaborator codespaces fall under organization or user ownership. Codespaces ownership dictates who pays for a codespace, which policies are applied, and where audit logs from codespace usage are sent. For organization owned codespaces, the organization pays for the codespace, organization policies apply, and the logs are sent to the organization. For an organization to own any codespaces, the organization administrator will need to set a spending limit in order to enable GitHub Codespaces within their organization. Enterprise Managed Users are not able to create user owned codespaces because their usage must be paid for by the enterprise.
Starting in August, Codespaces will be updating web client port forwarding to improve security, reliability, and performance for users. As part of this update, the URL for forwarded ports will change from https://*.preview.app.github.dev to https://*.app.github.dev.
To prepare for this change, replace any hardcoded references to preview.app.github.dev in your code with the GITHUB_CODESPACES_PORT_FORWARDING_DOMAIN environment variable by July 31 to avoid any disruptions. The environment variable value will be updated from preview.app.github.dev to app.github.dev when the migration completes. Learn more about environments variables here.
Organization administrators can now specify the maximum number of organization-billed codespaces that any member of the organization, or collaborator, can create.
By default, without this new policy, if organization members or collaborators are permitted to create codespaces that are billable to your organization, they can create multiple such codespaces. The number of codespaces someone can create is governed by a limit to the total number of codespaces that they can create across all repositories they can access. This limit is set by GitHub. With this new policy you can now control the maximum number of organization owned codespaces someone can create.
When this policy is applied to an organization, members or collaborators who meet or exceed this limit will be unable to create new codespaces that are billed to the organization. In order to create a new organization-billed codespace, they must first delete existing codespaces owned by the organization to get below the specified limit. The maximum codespaces policy does not impact user-billed codespaces, or codespaces created on repositories that are not owned by the organization. The policy must be applied across the entire organization, and cannot target specific repositories.
This policy, especially when combined with the existing retention period and idle timeout policies, provides organization administrators new ways to control cost within their organization, while encouraging best practices around cleaning up codespaces that are no longer in use.
To get started, review the documentation for how to apply a maximum codespaces per user policy within your organization.
GitHub Codespaces plans to begin rolling out improved access controls for organizations on June 27th, 2023. These changes will provide organizations additional control over which of their organization’s members or outside collaborators are allowed to use GitHub Codespaces on private and internal repositories. This change will not affect public repository usage.
Today, any user with read access to an org-owned private or internal repository can create a codespace from that repository. The organization may elect not to pay for this Codespace usage, but currently there is no way to block the usage entirely. Starting June 27th, GitHub Codespaces will begin introducing additional Access, Billing, and Ownership settings to more granularly control this behavior. With these new settings, organization admins can decide who within the organization is allowed to create codespaces from private and internal organization-owned repositories, and who owns those created Codespaces:
Some codespace usage may be impacted by this change. Organization owners will receive an email if anyone in their organization has a codespace that will be deleted because it was created from a private or internal repository by an org member or collaborator who will not have the appropriate permissions after this change.
This change will impact organizations that have configured their organization’s billing settings to either “Selected members” or “All members”. If your organization has specified one of those options, members or outside collaborators who are not specified in the list of selected users will lose access to GitHub Codespaces created from impacted internal or private repositories.
Administrators will receive a separate email if anyone in their organization has a codespace that matches these criteria.
Organization administrators should review the list of specific users who are currently allowed to bill codespaces usage to their organization to ensure all members who should have access, continue to have access. This can be done by adding them to the existing billing setting before your organization migrates to the new access setting.
Adding new users to this list will automatically transfer codespace ownership to the organization for any existing, personally owned codespaces created by these users on organization owned repositories. Once this happens, these codespaces will no longer be impacted by this change. Before doing this, ensure your spending limit is properly configured.
Users with impacted codespaces should either push any unsaved changes from these codespaces, or export their changes to a new branch. This will ensure that no code is lost as part of this change.
Codespaces impacted by this change will become inaccessible when the updates are released, and will be permanently deleted 7 days after that.
Today, any organization member or outside collaborator with read access to a repository can create a codespace on that repository. While the organization may elect not to pay for this usage, the member or outside collaborator can still pay for their own usage.
This release will introduce two control mechanisms for access and ownership.
Access will control which users are allowed to create codespaces on private and internal repositories within your organization. There will be four options:
Ownership and Billing controls who pays for codespace usage, who receives the audit log events from codespace usage, and whose policies are applied to the codespaces. There will be two options:
Please contact support if you have any issues.
In the coming week, GitHub will upgrade the host operating system for the virtual machines that build and run the dev containers in GitHub Codespaces from Ubuntu 18.04 to Ubuntu 22.04. Ubuntu 18.04 will reach its end of standard support on May 31, 2023, so we are upgrading in order to maintain the highest quality of support and security for all development environments. Most users will not be impacted by this update.
The host virtual machine is responsible for building and running the dev container configured in the devcontainer.json. When a developer connects to a codespace, they connect directly to the dev container, whose operating system is defined by the devcontainer.json configuration. This maintenance upgrade will not impact the development container configuration or prebuilds, and will not require any package updates within the development environment itself.
We recommend decoupling your dev container configuration from the host operating system. If your dev container depends on a specific host operating system version or Linux kernel version, this upgrade will impact you. For example, if you are installing specific kernel headers from the host into your dev container, you should change your configuration to install the generic linux headers, as this package will properly update independent of the host operating system kernel version.
If you see any issues that you believe are related to this change, please reach out to GitHub Support.
Helpful Links:
Visual Studio Code enables users to Sync Settings between VS Code environments. Codespaces exposes this capability as a way to personalize your experience. Prior to this release, Settings Sync for the VS Code web client was one-way by default, and two-way sync had to be enabled manually for each codespace.
With today's release, you can now choose whether to enable Settings Sync. Settings Sync is off by default. If you enable Settings Sync, the sync is two-way for repositories you trust, and one-way for untrusted repositories. Codespaces will also remember your choice.
The quickest way to enable Settings Sync is to start a codespace using the VS Code for the Web client, then choose 'Turn on Settings Sync…'
You will then be prompted for permission to enable Settings Sync for the repository. If you authorize, the Settings Sync setting on your GitHub profile will be enabled, and the repository will be added to a list of trusted repositories so that future codespaces on that repository will automatically have Settings Sync enabled in VS Code for the Web.
You can manage your Settings Sync and GPG verification settings from your GitHub Codespaces Settings page at
https://github.com/settings/codespaces.
On the Codespaces settings page you can manage which repositories you trust for GPG verification and Settings Sync.
Settings Sync and GPG verification now share a single set of trusted repositories. You can enable or disable GPG verification and Settings Sync independently. If you have Settings Sync enabled and you open a codespace from a repository that is not in your list of trusted repositories, the Settings Sync will be read only – your settings will be pulled from the Settings Sync server and applied to your codespace, but no settings changes will be written back. If you open a codespace for a repository you do trust, your settings will be synced both to and from the server.
If you have enabled GPG verification for all repositories, we advise you to restrict the repositories to a trusted list when you first enable Settings Sync.
If you choose to enable Settings Sync for all repositories we will keep that setting for GPG verification as well, but we recommend restricting both Settings Sync and GPG verification to trusted repositories to improve your security posture.
Codespaces has a number of new features to get you coding fast, from anywhere on the web, with a single click. Let's jump right in!
You can now add recommended secrets to a project when creating a Codespace!
Recommending secrets will ensure developers won't miss any API keys when creating a Codespace from your repo. You can specify any secrets you need to run your project in a Dev Container. If a developer already has a secret stored in their user secrets, Codespaces recommends they add the secret to their repository. Developers can worry less about setup and jump right into development!
Do you want to share your project for others to try out? You can generate a share link to share in a tweet, add to your website, or send to a friend.
Want developers to pick up on the last Codespace they had when they clicked your share link? You can set your share links to drop developers into the same Codespace every time by selecting "Quick start."
You can select a specific Dev Container for the share link to create a codespace from! Codespaces detects the repo and branch from your repository, limiting your setup.
We've even made it easier to embed the share link into a nice "Codespaces" badge with HTML and Markdown. Nifty!
If your users have never created a codespace from your share link, they are recommended to create a codespace. If users already have a codespace from your share link, they are be prompted to resume their codespace.
You can now name your Dev Containers! By defining the property name in your devcontainer.json, you can set the name that will appear under the Dev Container selection on the Codespaces creation page. Even if you don't define the name property in your devcontainer.json, Codespaces will still infer a more useful name from your Dev Container file path.
Do you want to collaborate on a repository, PR, or Branch? You can jump right back into your Codespace with the ',' key. No need to go to github.com/codespaces, or go to your Code<> drop-down to jump into development. Just one button and you're back to developing!
Check out the docs:
Want to leave feedback? Make a post on our discussions page
Thank you!
The GitHub Codespaces plugin for the JetBrains Gateway now supports Rider as a remote IDE. .NET developers can now leverage the standardization and power of GitHub Codespaces with JetBrains Rider's singular code indexing, navigation, and debugging capabilities.
GitHub Codespaces support for Rider enables multiple solution file scenarios. If there is only one solution file in a given codespace, the GitHub Codespaces plugin will automatically select that solution file. If there are multiple, the plugin will prompt the user to select which solution file they intend to use to open their project. Repositories without solution files are still compatible with Rider, however some features will be limited when no solution file is selected.
To get started with Rider, follow the documentation for installing GitHub Codespaces into the JetBrains Gateway. Once installed, users can connect to any of their existing codespaces with Rider as their selected IDE.
We are extremely excited to deliver our top requested feature since the beta announcement of JetBrains support in GitHub Codespaces.
Additional Resources:
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!
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!
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.
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.
The beta supports connectivity to a codespace, private port forwarding, and a fully featured code editing experience in the following IDEs:
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:
>=2.18.0)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.
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.
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:
You can also set JupyterLab as your preferred editor, enabling single click access to codespaces via JupyterLab:
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!
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:
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.
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!
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.
openFilesYou 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!
postAttachCommandpostAttachCommand 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.
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!
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.
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.
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.
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.
We hope this will make configuring your repositories for Codespaces significantly easier.
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.
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.
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.
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