[GH-ISSUE #269] Support for non-github.com domains #2248

Closed
opened 2026-05-12 20:23:56 -05:00 by GiteaMirror · 7 comments
Owner

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

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
GiteaMirror added the question label 2026-05-12 20:23:56 -05:00
Author
Owner

@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?

8fac30fc02/src/lib/github.ts (L43)

<!-- 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
Author
Owner

@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.

<!-- 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.
Author
Owner

@arunavo4 commented on GitHub (Apr 20, 2026):

Documented this in the README and environment variables reference so it's discoverable for future users:

TL;DR:

# 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!

<!-- 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!
Author
Owner

@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):

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!

<!-- 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!
Author
Owner

@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.

<!-- 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.
Author
Owner

@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 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.
Author
Owner

@yeahitsjan commented on GitHub (Apr 20, 2026):

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 ;-)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea-mirror#2248