[GH-ISSUE #576] [Feature]: Support self-hosted Git platforms (Gitea / GitLab) for repository backups #378

New issue

BreizhHardware · 2026-05-07T00:09:26+02:00

BreizhHardware commented

2026-05-07 00:09:26 +02:00

Originally created by @StackOvenFlow on GitHub (Mar 3, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/576

Originally assigned to: @BurntOutHylian on GitHub.

Problem or Use Case

Currently, Bambuddy validates repository URLs strictly against the GitHub format: https://github.com/owner/repo

The validation rejects any other Git hosting platform URLs, including self-hosted Git services such as:
• Gitea
• GitLab (self-hosted)
• Forgejo
• Enterprise GitHub instances

This prevents users running local infrastructure from using Bambuddy with their internal Git platforms.
When attempting to use a self-hosted Gitea repository:

Failed to save: [{
  "type":"value_error",
  "loc":["body","repository_url"],
  "msg":"Value error, Invalid GitHub repository URL. Expected format: https://github.com/owner/repo",
  "input":"http://gitea.lan:3000/gitea/bambuddy",
  "ctx":{"error":{}}
}]

The validation logic appears to explicitly enforce github.com:
github.com/maziggy/bambuddy@662cedef5d/backend/app/schemas/github_backup.py (L36-L46)

Proposed Solution

Instead of validating strictly against github.com, consider:
• Validating against a configurable base URL
• Or validating only the /owner/repo pattern
• Or adding a selectable provider type (GitHub / GitLab / Gitea)

Alternatives Considered

No response

Feature Category

Other

Priority

Nice to have

Mockups or Examples

No response

Contribution

I would be willing to help implement this feature

Checklist

I have searched existing issues to ensure this feature hasn't already been requested

Originally created by @StackOvenFlow on GitHub (Mar 3, 2026). Original GitHub issue: https://github.com/maziggy/bambuddy/issues/576 Originally assigned to: @BurntOutHylian on GitHub. ### Problem or Use Case Currently, Bambuddy validates repository URLs strictly against the GitHub format: `https://github.com/owner/repo` The validation rejects any other Git hosting platform URLs, including self-hosted Git services such as: • Gitea • GitLab (self-hosted) • Forgejo • Enterprise GitHub instances This prevents users running local infrastructure from using Bambuddy with their internal Git platforms. When attempting to use a self-hosted Gitea repository: ``` Failed to save: [{ "type":"value_error", "loc":["body","repository_url"], "msg":"Value error, Invalid GitHub repository URL. Expected format: https://github.com/owner/repo", "input":"http://gitea.lan:3000/gitea/bambuddy", "ctx":{"error":{}} }] ``` The validation logic appears to explicitly enforce github.com: https://github.com/maziggy/bambuddy/blob/662cedef5d52608a1286806896126210a5b3ed69/backend/app/schemas/github_backup.py#L36-L46 ### Proposed Solution Instead of validating strictly against github.com, consider: • Validating against a configurable base URL • Or validating only the /owner/repo pattern • Or adding a selectable provider type (GitHub / GitLab / Gitea) ### Alternatives Considered _No response_ ### Feature Category Other ### Priority Nice to have ### Mockups or Examples _No response_ ### Contribution - [x] I would be willing to help implement this feature ### Checklist - [x] I have searched existing issues to ensure this feature hasn't already been requested

BreizhHardware

2026-05-07 00:09:26 +02:00

closed this issue
added the
enhancement

contrib
labels

BreizhHardware commented

2026-05-07 00:09:27 +02:00

@maziggy commented on GitHub (Mar 3, 2026):

Please use branch 0.2.2b2 as base.

@maziggy commented on GitHub (Mar 3, 2026): Please use branch 0.2.2b2 as base.

BreizhHardware commented

2026-05-07 00:09:27 +02:00

@devzwf commented on GitHub (Mar 7, 2026):

@StackOvenFlow where are you at with this ?
need any help ?

@devzwf commented on GitHub (Mar 7, 2026): @StackOvenFlow where are you at with this ? need any help ?

BreizhHardware commented

2026-05-07 00:09:27 +02:00

@StackOvenFlow commented on GitHub (Mar 7, 2026):

The whole implementation is “GitHub-specific” end-to-end, so adding other providers means touching a few more places than schemas/github_backup.py.
I started working on it but unfortunately I’m on-call this week and things went havoc.

Edit: this commit gives a better context on how GitHub support was originally implemented.

@StackOvenFlow commented on GitHub (Mar 7, 2026): The whole implementation is “GitHub-specific” end-to-end, so adding other providers means touching a few more places than `schemas/github_backup.py`. I started working on it but unfortunately I’m on-call this week and things went havoc. Edit: [this commit](https://github.com/maziggy/bambuddy/commit/4ea7f7c4aa4f4ea95a663ae8ea0d39888bf240b4) gives a better context on how GitHub support was originally implemented.

BreizhHardware commented

2026-05-07 00:09:27 +02:00

@devzwf commented on GitHub (Mar 7, 2026):

No worry was just checking

@devzwf commented on GitHub (Mar 7, 2026): No worry was just checking

BreizhHardware commented

2026-05-07 00:09:27 +02:00

@ddetton commented on GitHub (Mar 17, 2026):

I would definitely use this. I have a self hosted gitea instance.

@ddetton commented on GitHub (Mar 17, 2026): I would definitely use this. I have a self hosted gitea instance.

BreizhHardware commented

2026-05-07 00:09:27 +02:00

@WhirlingTort commented on GitHub (Apr 2, 2026):

I came here to request the same. Thanks for looking into this!

@WhirlingTort commented on GitHub (Apr 2, 2026): I came here to request the same. Thanks for looking into this!

BreizhHardware commented

2026-05-07 00:09:28 +02:00

@maziggy commented on GitHub (Apr 18, 2026):

@StackOvenFlow Any news?

@maziggy commented on GitHub (Apr 18, 2026): @StackOvenFlow Any news?

BreizhHardware commented

2026-05-07 00:09:28 +02:00

@BurntOutHylian commented on GitHub (Apr 26, 2026):

I love this idea, so I poked around to see how things are currently set up (I use gitlab mainly). After some manual jerry-rigging in my docker instance by adding environment variables to the YAML and some in-instance code changes, I was able to get things backed up into my own gitlab repo.

I thought of a possible solution with 2 implementation options. I'm willing to give it a try if needed but defer to the other interested parties on the right one (or alternates).

Proposed Solution:

Add a provider field and optional api_base_url field to the backup configuration UI. Users would select their Git provider from a dropdown in the UI; self-hosted providers also enter their instance base URL.

Providers supported in the initial cut: GitHub · Gitea / Forgejo · GitLab

What Changes

Add a location to store the 2 new fields (provider & api_base_url) <-- see options below
Provider abstraction layer in the backend — new providers are self-contained classes
Provider dropdown + conditional "Instance URL" field in the settings UI
URL validation modified to accept any hostname (not just github.com)

Option 1 - Database migration

Add 2 new DB columns (provider, api_base_url) to the GitHub_backup_config table. Use the existing migration pattern and set existing records to automatically default to GitHub (avoid breaking what is already working for users).

Option 2 - JSON Config File (no DB changes)

Create a small git_provider_config.json file for the 2 new fields (provider, api_base_url). Keep the repository URL, token, branch, and schedule in the database.

Best place to put this file appears to be the same data directory as the database. Mainly since both files would need to travel together b/c if someone restores the database w/o the JSON file, the backup would end up pointing to the wrong provider.

For most self-hosted users, the above issue would probably not be a problem (probably). But it is a consistency risk that the 1st option would avoid entirely.

I recommend option 1 mainly because it keeps backup/restore stuff in 1 place, and avoids any mess when performing restoration actions.

I offered the 2nd option b/c I'm not sure how this project feels about db migration changes like those proposed in option 1.

Anyway - thanks for coming to my TEDTalk - thoughts?

@BurntOutHylian commented on GitHub (Apr 26, 2026): I love this idea, so I poked around to see how things are currently set up (I use gitlab mainly). After some manual jerry-rigging in my docker instance by adding environment variables to the YAML and some in-instance code changes, I was able to get things backed up into my own gitlab repo. I thought of a possible solution with 2 implementation options. I'm willing to give it a try if needed but defer to the other interested parties on the right one (or alternates). ### Proposed Solution: Add a provider field and optional api_base_url field to the backup configuration UI. Users would select their Git provider from a dropdown in the UI; self-hosted providers also enter their instance base URL. Providers supported in the initial cut: GitHub · Gitea / Forgejo · GitLab ### What Changes - Add a location to store the 2 new fields (provider & api_base_url) <-- see options below - Provider abstraction layer in the backend — new providers are self-contained classes - Provider dropdown + conditional "Instance URL" field in the settings UI - URL validation modified to accept any hostname (not just github.com) ### Option 1 - Database migration Add 2 new DB columns (provider, api_base_url) to the GitHub_backup_config table. Use the existing migration pattern and set existing records to automatically default to GitHub (avoid breaking what is already working for users). ### Option 2 - JSON Config File (no DB changes) Create a small git_provider_config.json file for the 2 new fields (provider, api_base_url). Keep the repository URL, token, branch, and schedule in the database. Best place to put this file appears to be the same data directory as the database. Mainly since both files would need to travel together b/c if someone restores the database w/o the JSON file, the backup would end up pointing to the wrong provider. For most self-hosted users, the above issue would probably not be a problem (probably). But it is a consistency risk that the 1st option would avoid entirely. --- I recommend option 1 mainly because it keeps backup/restore stuff in 1 place, and avoids any mess when performing restoration actions. I offered the 2nd option b/c I'm not sure how this project feels about db migration changes like those proposed in option 1. Anyway - thanks for coming to my TEDTalk - thoughts?

BreizhHardware commented

2026-05-07 00:09:28 +02:00

@maziggy commented on GitHub (Apr 27, 2026):

Option 1)

@maziggy commented on GitHub (Apr 27, 2026): Option 1)

BreizhHardware commented

2026-05-07 00:09:28 +02:00

@BurntOutHylian commented on GitHub (Apr 27, 2026):

Cool - I'd like to take a crack at it then if you want to assign it to me

Add 2 new DB columns (provider, api_base_url) to the GitHub_backup_config table. Use the existing migration pattern and set existing records to automatically default to GitHub (avoid breaking what is already working for users).
Provider abstraction layer (minimal & scoped) in the backend where providers are self-contained classes
Provider dropdown + conditional "Instance URL" field in the settings UI
URL validation modified to accept any hostname (not just github.com - though consider SSRF protections and/or implications)
Wiki Updates for new Backup provider options

@BurntOutHylian commented on GitHub (Apr 27, 2026): Cool - I'd like to take a crack at it then if you want to assign it to me - [x] Add 2 new DB columns (provider, api_base_url) to the GitHub_backup_config table. Use the existing migration pattern and set existing records to automatically default to GitHub (avoid breaking what is already working for users). - [x] Provider abstraction layer (minimal & scoped) in the backend where providers are self-contained classes - [x] Provider dropdown + conditional "Instance URL" field in the settings UI - [x] URL validation modified to accept any hostname (not just github.com - though consider SSRF protections and/or implications) - [x] Wiki Updates for new Backup provider options

BreizhHardware commented

2026-05-07 00:09:28 +02:00

@maziggy commented on GitHub (May 3, 2026):

Thanks!

@maziggy commented on GitHub (May 3, 2026): Thanks!

BreizhHardware referenced this issue

2026-05-07 00:15:38 +02:00

[PR #411] [MERGED] v0.2.0 #1040

Sign in to join this conversation.