GitHub Backend

lorry was designed with Gitlab as a backend in mind. As such, it is not compiled with GitHub support by default; to use GitHub as your mirroring host, you should compile with the github feature flag set. The GitHub backend has some differences in behaviour to the default Gitlab backend, due to GitHub not behaving the same way as Gitlab and thus being unable to support the same operations.

The first of these is that GitHub does not support arbitrary namespacing. This makes the prefix field somewhat dangeous. If you wish to mirror into the lorry user account’s personal namespace, the prefix field should be set to the lorry user account’s username. If you wish to mirror into an Organisation’s namespace prefix should be set to the name of the organisation to mirror into.

Also, GitHub scans commits for leaked secret tokens. This means that repositories containing what looks like a secret token will be rejected, stopping mirroring. If this occurs, you should disable secret scanning on the lorry user account and in the repository you are mirroring into.

Deployment as a GitHub App

Instead of operating as bot user, lorry can instead operate as a GitHub App. This means that the usual username and private-token fields are no longer respected. Instead your should supply the app field in your downstream configuration, which takes the form of:

app = { app-id = 2662472, private-key-file = "../lorry-testing-app-tbsliver.2026-01-20.private-key.pem" }

Where the app-id field is the App ID shown in the GitHub App dashboard, and private-key-file is a filepath ponting to the private key file that could downloaded from the dhashboard when you created the App. There is no way to supply the private key as a literal or an environment variable.

This requires that the App be installed in all namespaces that lorry is expected to mirror into. The App must be given the Administration: Read and Write, and Contents: Read and Write permissions.

Similairly, one can authenticate as an app when pulling in the confgit repo. The same configuration as above applies, except that the top-level field is called github-app. Again, once must make sure the app is installed in the confgit repo.