Back to GitHub Support Contact GitHub

GitHub for Business - page 5

GitHub Enterprise 11.10.320 Release

We’ve been working hard over the last few months, and are happy to announce the latest release of GitHub Enterprise. It includes some exciting new Enterprise-specific features, as well as a set of features integrated from

Repository Next

GitHub Enterprise now includes a new UI for interacting with your repositories that’s been available on for a while. It’s designed to focus on your content and tries to get out of the way and let you get your day-to-day work done.

repository next

Improved LDAP Integration

GitHub Enterprise now supports LDAP group authentication. This means that you can specify your Domain Base and then restrict who can login using groups rather than OUs. You can add as many groups as you like. In fact, you can even set an admin group where members are automatically given Site Admin permissions on the installation.

You can also view all LDAP users who should have access and create them if they haven’t already tried logging in:

Two-factor Authentication

Last week we added two-factor authentication to With today’s release, this feature is now available in GitHub Enterprise, including full support for TOTP in applications like Google Authenticator (available for iOS and Android phones).

two factor authentication

CSV Rendering

CSV rendering is now available so you can view these files in an easy to read format. Try searching them too!

csv rendering


If your installation has been languishing without avatars for a while now, good news! Identicons are shipping with this release of Enterprise, so prepare yourself for a much more colorful experience.


Mobile Views

Need to view a Pull Request linked to from a notification while away from your desk? Not a problem! GitHub Enterprise now supports mobile views.

mobile views

Collectd Monitoring

We’ve added collectd to the appliance so you can send graph data to an external server and better monitor server health and performance. This data is also included in Support Bundles so we can better help diagnose server-side problems.

File Size Limits has had file size limits for a while now. This release includes soft limits for files over 50MB. Unlike, no pushes will be rejected right now.

remote: warning: Large files detected.
remote: warning: File big_file is 55.00 MB; this is larger than GitHub Enterprise's recommended maximum file size of 50 MB

New Gist

The new version of Gist has been available on for a while now. Starting with this release we’re including the updated Gist in Enterprise!

new gist

Along with a variety of general improvements and adjustments, this new release also includes the following features from

Existing customers can download this update from the Enterprise website. If you want to give GitHub Enterprise a try, you can request a free trial from

We hope you enjoy these features as much as we do. Don’t forget that there is more information available about GitHub Enterprise at You can also see the full release notes here.

GitHub Enterprise 11.10.310 Release

We’re excited to announce the latest release of GitHub Enterprise. Along with a variety of general improvements and adjustments, this new release brings the following features from

In addition, we’re also including several new Enterprise specific features:

64-bit Appliance Image

We’ve been working for some time on 64-bit support and some customers have had early access to these images for quite a while now. We’re happy to announce that all new OVA image downloads starting with this release will be 64-bit. GHPs for 32-bit systems will still be available for the foreseeable future to give people running on older appliances the opportunity to migrate at their leisure. You can get more information about how to migrate from a 32-bit appliance to a 64-bit appliance here.

New Management Console Interface

The Management Console interface has remained largely unchanged since we launched GitHub Enterprise nearly a year and a half ago. It worked fairly well, but definitely looked dated and had some problems rendering in Firefox and Internet Explorer. This design refresh was geared largely toward making it work more consistently across browsers, so users who had difficulties using it in browsers other than Chrome should have a better experience now!


GitHub OAuth Authentication

We’ve added a new authentication method. You can now hook your Enterprise installation up to via OAuth for authentication. You do this by setting up a new OAuth application that belongs to your organization on and then use its client id and secret. After hooking that up, users who are members of your organization will be able to login automatically via the standard OAuth approval process. All their public user information on will be pulled in along with their email addresses and SSH public keys.


Improved Upgrade Process

Perhaps the most common upgrade problem that’s encountered involved a timeout being reached during the initial GHP unpacking step. This started happening as the GHP grew in size. To solve this issue, we’ve moved the GHP unpacking stage into a background job, so the request will no longer timeout, which should improve the upgrade experience dramatically going forward. However, due to how the upgrade process works, you won’t see the benefit for this until your next upgrade after 11.10.310. We’ve also made some improvements that will help prevent cases where successful upgrades were detected as failures.

Better Reporting

In previous releases, it wasn’t really possible to get full reports about all repositories, users, or organizations in an installation via the Admin Tools dashboard. Now you can get CSV reports with all of this information easily via the new Reports section.


Suspending Dormant Users in Bulk

The idea of a dormant user check was updated to work more closely to what a GitHub Enterprise admin would expect by removing some checks that made a lot of sense for, but not so much in a dedicated installation. It’s not uncommon to want to see what users are dormant so you know who you want to suspend to free up seats, so in addition to being able to get a report about who’s dormant, you can browse dormant users and perform a bulk suspension of all dormant users if you want now.

Improved Search Tooling

We’ve added a new Indexing section to the Admin Tools dashboard that allows for additional management of search functionality. You can now disable code searching or code search indexing, initiate code search backfill or issue search index repair jobs. You can also see the status of the ElasticSearch cluster on your appliance.


We hope you enjoy these features as much as we do. Don’t forget that there is more information available about GitHub Enterprise at The latest release can always be downloaded from here.

Today's Email Incident

Earlier today a routine system email was incorrectly sent to many of our GitHub Enterprise customers. In these errant emails, customer email addresses were included in the To: field, making them visible to anyone who received the message.

We are very sorry about this. We have determined what caused this incident and contacted all affected customers directly.


The incident occured in the Rails application we use to manage trials and customer contact information for GitHub Enterprise, not the product itself. No GitHub Enterprise installations were affected, and no license keys or any other data were exposed. was not affected.

As part of a routine daily process, the system notifies the members of any organization whose license is about to expire about the upcoming need for renewal. The app builds an email message including the addresses of all of the active accounts tied to the given organization, putting them in the To: field to enhance deliverability. This morning, the email included a great many more addresses than expected.

Technical details

Yesterday the Rails core team released four security patches (CVE-2013-1854, CVE-2013-1855, CVE-2013-1856, CVE-2013-1857). We immediately reviewed the patches and updated our Rails applications to stay current. Unfortunately one of these security patches included a change that caused certain SQL queries to behave unexpectedly.

Here’s an example of this change in behavior:

class Organization < ActiveRecord::Base
  has_many :teams

  attr_accessible :name, :has_octocats

  scope :has_octocats_scope, lambda { where(:has_octocats => true) }

  def self.has_octocats_class_method
    where(:has_octocats => true)

class Team < ActiveRecord::Base
  belongs_to :organization
  attr_accessible :name

  def self.using_octocats_scope
    where(:organization_id =>

  def self.using_octocats_class_method
    where(:organization_id =>

> github = Organization.create(:name => "GitHub", :has_octocats => true)
> acme   = Organization.create(:name => "Acme",   :has_octocats => false)
> github.teams.create(:name => "Supportocats")
> acme.teams.create(:name => "Roadrunners")
#=> 1
#=> 2

So, an Organization owns a number of Team records. We’ve defined a couple of methods to help us scope queries for teams to only those organizations that have octocats. Ideally, both of these methods will scope to the same thing: only Team records with an organization_id of 1, the GitHub Organization. And prior to this latest Rails release, they did.

But the latest release of Rails introduced a subtle change to this behavior. Let’s try to make some queries based on the Organization’s teams:

> teams = github.teams
  Team Load (0.4ms)  SELECT `teams`.* FROM `teams` WHERE `teams`.`organization_id` = 1
> teams.length       # => 1
>   # => "Supportocats"

Great. Here we’ve asked for the GitHub organization’s teams, and we’ve gotten the correct one, “Supportocats”, back. All is good so far. Now let’s use one of our scopes, just to be extra specific:

> teams = github.teams.using_octocats_class_method
  Team Load (0.4ms)  SELECT `teams`.* FROM `teams` WHERE `teams`.`organization_id` = 1 AND `teams`.`organization_id` IN (1)
> teams.length       # => 1
>   # => "Supportocats"

The results are the same, but the query is different. By going through an extra scope, we’ve added an additional SQL predicate, one that says the returned Team records must belong to an Organization that has octocats. Since the GitHub team has them, the result is the same.

Let’s try our scope that is restricted to octocat-having teams on the Acme org:

> teams = acme.teams.using_octocats_class_method
  Team Load (0.4ms)  SELECT `teams`.* FROM `teams` WHERE `teams`.`organization_id` = 2 AND `teams`.`organization_id` IN (1)
> teams.length   # => 0

Here we see a different result, as expected, and a similar query, again asking for all of the Acme organization’s teams that also belong to an Organization that has octocats. The Acme Organization has none, so no teams are returned.

But now we come to an unexpected difference. In the last couple of examples, we were using an Arel scope on Organization that was defined as a normal class method. But if we change to using the scope defined with ActiveRecord’s scope method, we get unexpected and potentially dangerous results:

> teams = acme.teams.using_octocats_scope
  Team Load (0.4ms)  SELECT `teams`.* FROM `teams` WHERE `teams`.`organization_id` IN (1)
> teams.length       # => 1
>   # => "Supportocats"

Now the Acme organization is returning the GitHub organization’s teams! This is obviously bad behavior. What’s happening? In this case, when using the scope method to define an Arel scope on Organization, the where clause of the scope is overriding the condition imposed by the Organization#teams association. The part of the WHERE clause meant to restrict the query to Team records related to the Acme organization was dropped.

We’ve narrowed down this change in behavior to this commit. We have fixed this issue on our affected applications and are working with the Rails core team to determine if this change was intentional as well as what action other users should take.

What we’re doing about it

We’re reviewing every piece of GitHub code that touches email so we can keep this from happening in the future. We’re focusing on more stringent automated tests, sanity checks on email recipients, and even more careful review when we upgrade an external dependency like Rails.

GitHub Enterprise 11.10.300 Release

We’re excited to announce the latest release of GitHub Enterprise. We’re shipping this version with Issue Attachments, Contributions, and much more. Along with a variety of general improvements and adjustments, this new release brings the following features from

In addition, we’re also including several new Enterprise specific features:

Repository Archives

This has been a frequently requested feature since we launched GitHub Enterprise, and we’re happy to announce that it’s now available! Each repository will have a link to download a zip archive of the master branch, along with the ability to download tarball or zip archives of the repository for any tags that have been set. This functionality is backed by the same Nodeload service that serves these files for You can get more background information about Nodeload here and here.

Screen 20Shot 202013-01-29 20at 202 40 01 20PM

Support for Multiple Admin SSH Keys

You can now add more than one SSH authorized key for the admin user on the installation. It will automatically detect any existing keys that are installed as well.

Screen 20Shot 202013-01-29 20at 202 21 57 20PM

Management Console API

A new API for managing GitHub Enterprise settings and maintenances has been added. This new API allows you to update configuration settings, add admin SSH authorized keys, upgrade, and enable or disable maintenance mode. You can find full documentation for the API here. This API has actually existed since the 11.10.280 release, so anyone on 11.10.280 or higher should be able to take advantage of the API. This will be especially useful when you need to upgrade an Enterprise appliance on a remote network, so you don’t have to upload new GHPs over slow connections.

Updated Admin Tools Dashboard

The Admin Tools dashboard has had a major overhaul! It now has a look and feel that better matches the rest of the site.

Screen 20Shot 202013-01-29 20at 202 05 54 20PM

Faster Configuration Runs

Prior to 11.10.300, making any settings changes would cause a full configuration run. The config run would take around 10 minutes to complete, even for minor changes. Now only the initial configuration run and upgrades take the full amount of time. If you’re only making a settings change, runs can take 30 seconds or less now!

Deleted Repository Restoration

When a repository is deleted, it’s now banished to purgatory. Repositories in purgatory wait in limbo for a month before being fully deleted. While in purgatory, any admin can restore the repository with the push of a single button – including all issues, pull requests, and any associated comments. Purgatory is accessible from the Admin Tools view of any user on a GitHub Enterprise installation.

Screen 20Shot 202013-01-29 20at 202 16 23 20PM

Search Indexing API

With the addition of improvements to the search that shipped in this release, a new API is now available to queue up repositories and users for indexing. You can use this API to integrate into whatever other tools you use at your company. Documentation for this API is available here.

We hope you enjoy these features as much as we do. Don’t forget that there is more information available about GitHub Enterprise at You can also see the full release notes here.


  • Dec 05, 2012
  • mdo mdo
  • Github-for-business

Today, we’re launching a completely redesigned homepage for GitHub Enterprise, the private, installable version of GitHub running on your servers. Beyond the visual changes, we’ve tightened up the copy to better communicate what Enterprise is and how it works. Current Enterprise users will see a redesigned dashboard and more when they sign in.

Check out the new GitHub Enterprise, still the best way to build and ship software on your servers.



Discover new ways to build better

Try Marketplace apps free for 14 days

Learn more