Laravel-GitHub: a GitHub API bridge for Laravel applications

A Laravel shell around the PHP GitHub API library

The README states the lineage plainly. Laravel GitHub was created by, and is maintained by, Graham Campbell, and it is a PHP GitHub API bridge for Laravel, where the PHP GitHub API refers to the KnpLabs php-github-api library. Underneath the Laravel conventions sits a general purpose PHP client for the GitHub REST API.

That is the honest description of what this package is, and it is more useful than a marketing one. The bridge does not implement GitHub endpoints of its own. What it does is take a library that knows nothing about Laravel and give it the parts a Laravel developer expects: a service provider that sets up the container bindings, a facade for static-style calls, a published configuration file, and a manager that can hold more than one set of credentials.

The manager comes from a separate package the author also maintains, Laravel Manager, and the README is explicit that the interface and the abstract class behind it are part of that package. That is a useful structural fact, because it means the pattern of multiple named connections and a default connection is not a one-off design here but a reusable piece of the author's Laravel toolkit.

The audience is an application that needs GitHub as a dependency: a deployment tool that opens a pull request, a bot that reacts to issues, a dashboard that lists repository activity. The homepage for the project is gjcampbell.co.uk.

Composer, a service provider and an optional facade alias

Installation is a Composer require of the latest version line:

$ composer require "graham-campbell/github:^13.1"

The version constraint in that command is worth noticing, because the README states that this version requires PHP 8.1-8.5 and supports Laravel 10-13. The package is versioned to track a major, and the branch layout follows the same convention, with the default branch of this repository being 13.1 rather than master.

After installation, if you are not using automatic package discovery, you need to register the `GrahamCampbell\GitHub\GitHubServiceProvider` service provider in your `config/app.php`. The provider is described as containing no public methods of interest, its whole job being to set up the container bindings.

The facade alias is optional. If you want it, you add:

        'GitHub' => GrahamCampbell\GitHub\Facades\GitHub::class,

to the aliases in the same config file. Skipping it costs you nothing structural, since the container binding is what actually matters, and the facade is a convenience layer over that binding.

Publishing the config gives you three options

The package needs connection configuration, and the way you get it is the standard Laravel vendor publish step:

$ php artisan vendor:publish

That creates a `config/github.php` file in your application which you can modify. The documentation also tells you to check for changes to the original config file in the package between releases, which is the practical warning that a published config file drifts out of step with the package version you later upgrade to.

The file has three options, and the shape of them is the design.

The `default` option names which connection is used for all work by default, and its default value is `main`. The `connections` option is where each connection is set up, and the documentation notes you may add as many connections as you like, which is also what the manager class is for. The five supported authentication methods are `application`, `jwt`, `none`, `private` and `token`.

The third option is `cache`, where each cache configuration is set up. Only the `illuminate` driver is provided out of the box, and example configuration is included. The narrowness of that last point is worth noticing: HTTP caching for the GitHub API is on by default through Illuminate's cache, and adding a different backend means supplying it yourself.

The manager resolves the client, the facade is a shortcut

The Usage section names the pieces, and the distinctions between them are the API you actually code against.

GitHubManager is described as the class of most interest. It is bound to the IoC container as `github` and can be accessed using the `Facades\GitHub` facade. It implements the `ManagerInterface` by extending `AbstractManager`, both of which come from the Laravel Manager package, and the documentation suggests reading that package's docs for how to use the manager class. One guarantee is stated: the connection class returned will always be an instance of `Github\Client`.

That last point is the one to hold on to. Whatever connection you configure and whatever authentication method you select, what you get back is the client object from the underlying library, with the configured credentials applied. The bridge does not wrap the client's methods, so the API surface you call is the php-github-api API, not a Laravel-flavoured variant of it.

The facade is the second piece. It dynamically passes static method calls to the `github` object in the container, which by default is the `GitHubManager` class. So the facade and the manager are two doors to the same room, and the difference is only in how you reach it.

Support is versioned in a matrix of GitHub API and Laravel

The README carries a compatibility matrix with one axis for the GitHub API version and one for the Laravel version, and it is the most informative table in the documentation.

Reading it, the older GitHub API versions support older Laravel versions: the 7.8 row marks support up to Laravel 5.8, the 8.9 row up to Laravel 7, the 9.8 row up to Laravel 8, the 10.6 row up to Laravel 9, the 11.0 row up to Laravel 9, the 12.8 row up to Laravel 11, and the 13.1 row supports Laravel 10 through 13.

Two things follow from that table. The bridge is versioned against the GitHub API release it targets, not only against Laravel, so a project that needs a particular GitHub API version has to pick the matching row. And the current line, GitHub API 13.1, is the one that works with the Laravel versions people are on now, which is consistent with the stated requirement of Laravel 10-13 and PHP 8.1-8.5.

That the package supports four consecutive Laravel majors is worth noting as well. It means a team upgrading Laravel within that range can take the new package release without a rewrite, and it also means the package's own release history is likely to keep moving as each Laravel version lands.

MIT licensed, released in step with each Laravel generation

The licence is MIT, with the LICENSE file at the repository root and a licence badge in the README. It is a permissive licence with the usual notice and copyright retention requirement, and nothing in the documentation asks for anything beyond that.

On maintenance, the repository is not archived and the last push was on 2026-05-08. The recent releases track the versioning closely: v13.1.1 tagged on 2026-05-08, v13.1.0 on 2026-05-06 and v13.0.0 on 2025-03-03. So the 13.1 line was published in May 2026 after a fourteen month gap from 13.0, and the patch release followed two days later.

The repository also carries the housekeeping files a package like this usually has: a CHANGELOG.md, a `config/` directory, a `src/` directory, a `tests/` directory, a composer.json and a phpunit.xml.dist. The `.github` directory holds the code of conduct and the contribution guidelines, and the README points to a security policy page on GitHub.

The project is also marked with the hacktoberfest topic, which is a small signal about where contributions came from during a period when that event drove a lot of first-time contributions to open source packages, and a reason to read the contribution guidelines before opening a pull request.

Editorial conclusion

Laravel-GitHub fits a Laravel application that needs to talk to GitHub and wants the connection settings in a config file, the client resolved from the container, and the option of several credentials side by side. It is the wrong choice if you want the GitHub API without Laravel conventions, since the underlying PHP library does that job on its own. Verify first that your PHP version is between 8.1 and 8.5 and your Laravel version between 10 and 13, that the authentication method you need is one of the five the config supports, and that the published config file is reviewed after each upgrade, since the documentation warns that it changes between releases.

Frequently asked questions

Official sources

1. GrahamCampbell/Laravel-GitHub on GitHub
2. License: MIT
3. Project website
4. README
5. Releases