Hi! This tool looks promising. Currently having access to a Github Enterprise Cloud instance I would like to ask if its possible to also connect to those and mirror them accordingly? Theoretically the REST API or OctoKit should be compatible with it.
Many thanks!
Jan
Originally created by @yeahitsjan on GitHub (Apr 15, 2026).
Original GitHub issue: https://github.com/RayLabsHQ/gitea-mirror/issues/269
Originally assigned to: @arunavo4 on GitHub.
Hi! This tool looks promising. Currently having access to a Github Enterprise Cloud instance I would like to ask if its possible to also connect to those and mirror them accordingly? Theoretically the REST API or OctoKit *should* be compatible with it.
Many thanks!
Jan
<!-- gh-comment-id:4252316694 -->
@yeahitsjan commented on GitHub (Apr 15, 2026):
As I can see, it seems that `GH_API_URL` can be set as it is loaded from environment variables. Is that true?
https://github.com/RayLabsHQ/gitea-mirror/blob/8fac30fc022c37fdaa1afc0d91802a2495539db2/src/lib/github.ts#L43
Yes @yeahitsjan set GH_API_URL to your Enterprise API endpoint (e.g. https://HOSTNAME/api/v3 for GHE Server, or https://api.<tenant>.ghe.com for GHEC with data residency) and it'll route Octokit there. Standard GHEC on github.com already works out of the box.
<!-- gh-comment-id:4262497333 -->
@arunavo4 commented on GitHub (Apr 16, 2026):
Yes @yeahitsjan set `GH_API_URL` to your Enterprise API endpoint (e.g. `https://HOSTNAME/api/v3` for GHE Server, or `https://api.<tenant>.ghe.com` for GHEC with data residency) and it'll route Octokit there. Standard GHEC on github.com already works out of the box.
# GHES (self-hosted)GH_API_URL=https://ghe.example.com/api/v3
# GHEC with data residencyGH_API_URL=https://api.TENANT.ghe.com
Closing as answered — feel free to reopen if you hit any Enterprise-specific issues. Thanks for the nudge to document it!
<!-- gh-comment-id:4277721163 -->
@arunavo4 commented on GitHub (Apr 20, 2026):
Documented this in the README and environment variables reference so it's discoverable for future users:
- README: [GitHub Enterprise (GHES / GHEC with Data Residency)](https://github.com/RayLabsHQ/gitea-mirror/blob/main/README.md#github-enterprise-ghes--ghec-with-data-residency)
- Env reference: [`GH_API_URL`](https://github.com/RayLabsHQ/gitea-mirror/blob/main/docs/ENVIRONMENT_VARIABLES.md#github-enterprise-ghes--ghec-with-data-residency)
- `.env.example` now includes a `GH_API_URL` example
TL;DR:
```bash
# GHES (self-hosted)
GH_API_URL=https://ghe.example.com/api/v3
# GHEC with data residency
GH_API_URL=https://api.TENANT.ghe.com
```
Closing as answered — feel free to reopen if you hit any Enterprise-specific issues. Thanks for the nudge to document it!
Hi @arunavo4,
thanks for documenting it! I currently use the dev.yml, and inserted GH_API_URL into it. When authenticating, it still points to the api.github.com URL, which is indeed wrong (due to data residency):
I also ran docker exec gitea-mirror-dev env and can clearly see that it set GH_API_URL as expected.
What did I do wrong here?
Thank you!
<!-- gh-comment-id:4278329372 -->
@yeahitsjan commented on GitHub (Apr 20, 2026):
Hi @arunavo4,
thanks for documenting it! I currently use the `dev.yml`, and inserted `GH_API_URL` into it. When authenticating, it still points to the `api.github.com` URL, which is indeed wrong (due to data residency):
```js
GitHub connection test failed: 119 | request: requestOptions
120 | });
121 | }
122 | if (status >= 400) {
123 | octokitResponse.data = await getResponseData(fetchResponse);
124 | throw new RequestError(toErrorMessage(octokitResponse.data), status, {
^
HttpError: Bad credentials - https://docs.github.com/rest
status: 401,
request: {
method: "GET",
url: "https://api.github.com/user",
headers: [Object ...],
request: [Object ...],
},
response: {
url: "https://api.github.com/user",
status: 401,
headers: [Object ...],
data: [Object ...],
},
```
I also ran `docker exec gitea-mirror-dev env` and can clearly see that it set `GH_API_URL` as expected.
What did I do wrong here?
Thank you!
@yeahitsjan Found the Root cause: GH_API_URL was only honored by createGitHubClient(), but several Octokit call sites (including the one behind Test Connection) constructed new Octokit(...) directly, so they always hit api.github.com regardless of the env var. That's exactly the 401 you were seeing.
Fix is up in #273. It routes every Octokit construction through createGitHubClient(), which means the Test Connection button, public-repo sync, metadata/force-push detection, and the scheduler's auto-discovery/auto-mirror/auto-start paths now all respect GH_API_URL.
Once it merges and the dev.yml image rebuilds, your existing config (GH_API_URL=https://api.TENANT.ghe.com) should just work. Reopening this issue so it stays visible until you confirm.
<!-- gh-comment-id:4278401231 -->
@arunavo4 commented on GitHub (Apr 20, 2026):
@yeahitsjan Found the Root cause: `GH_API_URL` was only honored by `createGitHubClient()`, but several Octokit call sites (including the one behind **Test Connection**) constructed `new Octokit(...)` directly, so they always hit `api.github.com` regardless of the env var. That's exactly the 401 you were seeing.
Fix is up in #273. It routes every Octokit construction through `createGitHubClient()`, which means the Test Connection button, public-repo sync, metadata/force-push detection, and the scheduler's auto-discovery/auto-mirror/auto-start paths now all respect `GH_API_URL`.
Once it merges and the `dev.yml` image rebuilds, your existing config (`GH_API_URL=https://api.TENANT.ghe.com`) should just work. Reopening this issue so it stays visible until you confirm.
Released as v3.15.3. Docker image is building now (run) — typically ~5 min from tag push to ghcr.io/raylabshq/gitea-mirror:v3.15.3 + :latest.
Once it's up, pull the new image (or rebuild from main if you're tracking dev), and your existing GH_API_URL=https://api.TENANT.ghe.com config should route the Test Connection call (and every other GitHub call) to your tenant endpoint. Please confirm when you've had a chance to verify and I'll close this.
<!-- gh-comment-id:4278689171 -->
@arunavo4 commented on GitHub (Apr 20, 2026):
Released as **[v3.15.3](https://github.com/RayLabsHQ/gitea-mirror/releases/tag/v3.15.3)**. Docker image is building now ([run](https://github.com/RayLabsHQ/gitea-mirror/actions/runs/24654201352)) — typically ~5 min from tag push to `ghcr.io/raylabshq/gitea-mirror:v3.15.3` + `:latest`.
Once it's up, pull the new image (or rebuild from `main` if you're tracking dev), and your existing `GH_API_URL=https://api.TENANT.ghe.com` config should route the Test Connection call (and every other GitHub call) to your tenant endpoint. Please confirm when you've had a chance to verify and I'll close this.
This works insanely great @arunavo4! Many thanks - will come back to you eventually later ;-)
<!-- gh-comment-id:4278742019 -->
@yeahitsjan commented on GitHub (Apr 20, 2026):
This works insanely great @arunavo4! Many thanks - will come back to you eventually later ;-)
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @yeahitsjan on GitHub (Apr 15, 2026).
Original GitHub issue: https://github.com/RayLabsHQ/gitea-mirror/issues/269
Originally assigned to: @arunavo4 on GitHub.
Hi! This tool looks promising. Currently having access to a Github Enterprise Cloud instance I would like to ask if its possible to also connect to those and mirror them accordingly? Theoretically the REST API or OctoKit should be compatible with it.
Many thanks!
Jan
@yeahitsjan commented on GitHub (Apr 15, 2026):
As I can see, it seems that
GH_API_URLcan be set as it is loaded from environment variables. Is that true?https://github.com/RayLabsHQ/gitea-mirror/blob/8fac30fc022c37fdaa1afc0d91802a2495539db2/src/lib/github.ts#L43
@arunavo4 commented on GitHub (Apr 16, 2026):
Yes @yeahitsjan set
GH_API_URLto your Enterprise API endpoint (e.g.https://HOSTNAME/api/v3for GHE Server, orhttps://api.<tenant>.ghe.comfor GHEC with data residency) and it'll route Octokit there. Standard GHEC on github.com already works out of the box.@arunavo4 commented on GitHub (Apr 20, 2026):
Documented this in the README and environment variables reference so it's discoverable for future users:
GH_API_URL.env.examplenow includes aGH_API_URLexampleTL;DR:
Closing as answered — feel free to reopen if you hit any Enterprise-specific issues. Thanks for the nudge to document it!
@yeahitsjan commented on GitHub (Apr 20, 2026):
Hi @arunavo4,
thanks for documenting it! I currently use the
dev.yml, and insertedGH_API_URLinto it. When authenticating, it still points to theapi.github.comURL, which is indeed wrong (due to data residency):I also ran
docker exec gitea-mirror-dev envand can clearly see that it setGH_API_URLas expected.What did I do wrong here?
Thank you!
@arunavo4 commented on GitHub (Apr 20, 2026):
@yeahitsjan Found the Root cause:
GH_API_URLwas only honored bycreateGitHubClient(), but several Octokit call sites (including the one behind Test Connection) constructednew Octokit(...)directly, so they always hitapi.github.comregardless of the env var. That's exactly the 401 you were seeing.Fix is up in #273. It routes every Octokit construction through
createGitHubClient(), which means the Test Connection button, public-repo sync, metadata/force-push detection, and the scheduler's auto-discovery/auto-mirror/auto-start paths now all respectGH_API_URL.Once it merges and the
dev.ymlimage rebuilds, your existing config (GH_API_URL=https://api.TENANT.ghe.com) should just work. Reopening this issue so it stays visible until you confirm.@arunavo4 commented on GitHub (Apr 20, 2026):
Released as v3.15.3. Docker image is building now (run) — typically ~5 min from tag push to
ghcr.io/raylabshq/gitea-mirror:v3.15.3+:latest.Once it's up, pull the new image (or rebuild from
mainif you're tracking dev), and your existingGH_API_URL=https://api.TENANT.ghe.comconfig should route the Test Connection call (and every other GitHub call) to your tenant endpoint. Please confirm when you've had a chance to verify and I'll close this.@yeahitsjan commented on GitHub (Apr 20, 2026):
This works insanely great @arunavo4! Many thanks - will come back to you eventually later ;-)