Support proxy registries for each package type #9595

New Issue

GiteaMirror · 2025-11-02T08:43:58-06:00

GiteaMirror commented

2025-11-02 08:43:58 -06:00

Originally created by @OverkillGuy on GitHub (Sep 20, 2022).

Feature Description

Spinning off https://github.com/go-gitea/gitea/issues/19270#issuecomment-1200472188 into its own ticket as recommended

I wish Gitea supported "remote", or "proxy" repositories.

These are package repositories that proxy an external source of packages, hence configured with proxy URL, but are otherwise same as local package repositories, as they can be pulled from as usual.

Example: A local Pypi.org proxy. Local build system would be configured to use both the private package registry for "internal" (private) packages, but now fetching dependencies on Pypi.org through local Gitea too.

Advantages:

Shorter round-trip to fetch packages = faster build times
Improved auditability of dependencies (one place for all $internet_stuff)
Offline-able build systems helps with disaster recovery, privacy...
Mitigate bad/rogue updates by having solid cacheing

This feature in Docker repositories would remove any need for Dockerhub ECR mirror, which many have to set up to avoid Dockerhub's recent rate-limiting.

The canonical example of the feature is in JFrog's Artifactory.

Effectively, Gitea would, for these proxy repositories, become a local package cache. The biggest technical decision is about when to invalidate cache (docker image's "latest" tag moves pretty quickly, but if you already have a local copy, do you serve it as-is? even if you got it 2 years ago?)

Pushing this feature to its extreme, Artifactory provides Virtual Repositories that aggregate both remote (public proxies) and local (private to org) repositories into one place.

I understand this feature can be a big investment, and acknowledge that there may be no particular need for it. I mostly envy the feature, and wish for Gitea to succeed by out-executing Artifactory, given the new Package Registry is already encroaching on that a bit.

Screenshots

Originally created by @OverkillGuy on GitHub (Sep 20, 2022). ### Feature Description > Spinning off https://github.com/go-gitea/gitea/issues/19270#issuecomment-1200472188 into its own ticket as recommended I wish Gitea supported "remote", or "proxy" repositories. These are package repositories that proxy an external source of packages, hence configured with proxy URL, but are otherwise same as local package repositories, as they can be pulled from as usual. Example: A local Pypi.org proxy. Local build system would be configured to use both the private package registry for "internal" (private) packages, but now fetching dependencies on Pypi.org through local Gitea too. Advantages: - Shorter round-trip to fetch packages = faster build times - Improved auditability of dependencies (one place for all `$internet_stuff`) - Offline-able build systems helps with disaster recovery, privacy... - Mitigate bad/rogue updates by having solid cacheing This feature in Docker repositories would remove any need for [Dockerhub ECR mirror](https://github.com/onfido/ecr-mirror), which many have to set up to avoid Dockerhub's recent rate-limiting. The canonical example of the feature is in [JFrog's Artifactory](https://www.jfrog.com/confluence/display/JFROG/Remote+Repositories). Effectively, Gitea would, for these proxy repositories, become a local package cache. The biggest technical decision is about when to invalidate cache (docker image's "latest" tag moves pretty quickly, but if you already have a local copy, do you serve it as-is? even if you got it 2 years ago?) Pushing this feature to its extreme, Artifactory provides [Virtual Repositories](https://www.jfrog.com/confluence/display/JFROG/Virtual+Repositories) that aggregate both remote (public proxies) and local (private to org) repositories into one place. I understand this feature can be a big investment, and acknowledge that there may be no particular _need_ for it. I mostly envy the feature, and wish for Gitea to succeed by out-executing Artifactory, given the new Package Registry is already encroaching on that a bit. ### Screenshots ![Artifactory remote repository](https://www.jfrog.com/confluence/download/attachments/89296179/JCenter%20in%20Artifact%20Browser.png?version=2&modificationDate=1578649683000&api=v2) ![Artifactory cache advanced settings](https://www.jfrog.com/confluence/download/attachments/89298954/cache-remote-settings.png?version=1&modificationDate=1562240252000&api=v2)

GiteaMirror added the topic/packages type/proposal type/feature labels 2025-11-02 08:43:58 -06:00

GiteaMirror commented

2025-11-02 08:43:59 -06:00

@OverkillGuy commented on GitHub (Sep 20, 2022):

Suggesting applying the label theme/package-registry, but I can't apply that on my own.

@OverkillGuy commented on GitHub (Sep 20, 2022): Suggesting applying the label [theme/package-registry](https://github.com/go-gitea/gitea/labels/theme%2Fpackage-registry), but I can't apply that on my own.

GiteaMirror commented

2025-11-02 08:43:59 -06:00

@lunny commented on GitHub (Mar 22, 2023):

About what should the proxy looks like. A proxy package should have the same url and database structures as an original one but with a mirror column just like repositories and mirror repositories. So this package is readonly from user and there is an internal time to fetch from remote?

@lunny commented on GitHub (Mar 22, 2023): About what should the proxy looks like. A proxy package should have the same url and database structures as an original one but with a mirror column just like repositories and mirror repositories. So this package is readonly from user and there is an internal time to fetch from remote?

GiteaMirror commented

2025-11-02 08:43:59 -06:00

@springeye commented on GitHub (Apr 19, 2023):

yes,I really need this feature

@springeye commented on GitHub (Apr 19, 2023): yes,I really need this feature

GiteaMirror commented

2025-11-02 08:43:59 -06:00

@kvaster commented on GitHub (May 28, 2023):

Also proxy should cache data from remote. That way you may be sure you'll be able to build your project even if data is reomved from remote.

@kvaster commented on GitHub (May 28, 2023): Also proxy should cache data from remote. That way you may be sure you'll be able to build your project even if data is reomved from remote.

GiteaMirror commented

2025-11-02 08:43:59 -06:00

@yekanchi commented on GitHub (Jul 10, 2023):

is this going to be something like Sonatype-Nexus or JFrog-Artifactory?

@yekanchi commented on GitHub (Jul 10, 2023): is this going to be something like Sonatype-Nexus or JFrog-Artifactory?

GiteaMirror commented

2025-11-02 08:44:00 -06:00

@TimberBro commented on GitHub (Sep 9, 2023):

A proxy package should have the same url and database structures as an original one but with a mirror column just like repositories and mirror repositories.

Wouldn't it be superfluous to keep a link to a remote repository for each package?

@lunny How do you feel about the idea of having mirror settings at the organization level?
As example, for any type of registry, the owner can check whether the registry is a mirror or not and if it is, the owner can set the remote-URL.

@TimberBro commented on GitHub (Sep 9, 2023): > A proxy package should have the same url and database structures as an original one but with a mirror column just like repositories and mirror repositories. Wouldn't it be superfluous to keep a link to a remote repository for each package? @lunny How do you feel about the idea of having mirror settings at the organization level? As example, for any type of registry, the owner can check whether the registry is a mirror or not and if it is, the owner can set the remote-URL.

GiteaMirror commented

2025-11-02 08:44:00 -06:00

@yekanchi commented on GitHub (Sep 10, 2023):

A proxy package should have the same url and database structures as an original one but with a mirror column just like repositories and mirror repositories.

Wouldn't it be superfluous to keep a link to a remote repository for each package?

@lunny How do you feel about the idea of having mirror settings at the organization level? As example, for any type of registry, the owner can check whether the registry is a mirror or not and if it is, the owner can set the remote-URL.

I think we can merge both.

packages could be uploaded locally without upstream source (as is now)
if any package or package version is requested and there is no file for the specified version the upstream sources will be checked.

So there is no need to specify upstream source for every pacakge/

@yekanchi commented on GitHub (Sep 10, 2023): > > A proxy package should have the same url and database structures as an original one but with a mirror column just like repositories and mirror repositories. > > Wouldn't it be superfluous to keep a link to a remote repository for each package? > > @lunny How do you feel about the idea of having mirror settings at the organization level? As example, for any type of registry, the owner can check whether the registry is a mirror or not and if it is, the owner can set the remote-URL. I think we can merge both. - packages could be uploaded locally without upstream source (as is now) - if any package or package version is requested and there is no file for the specified version the upstream sources will be checked. So there is no need to specify upstream source for every pacakge/

GiteaMirror commented

2025-11-02 08:44:00 -06:00

@PatrickHuetter commented on GitHub (Oct 1, 2023):

This feature would be awesome. We are running a nexus repository server since a few years and migrated from gitlab to gitea. With this feature we could also get rid of the nexus and have a more all in one experience in our development tasks.

@PatrickHuetter commented on GitHub (Oct 1, 2023): This feature would be awesome. We are running a nexus repository server since a few years and migrated from gitlab to gitea. With this feature we could also get rid of the nexus and have a more all in one experience in our development tasks.

GiteaMirror commented

2025-11-02 08:44:01 -06:00

@KarenArzumanyan commented on GitHub (Mar 11, 2024):

This is a highly requested feature.
We also use nexus now, which is very slow and has limitations in the oss edition.

From the characteristics of the registry operating in proxy mode:

Caching received packages
If the package is not found in the cache, then request from the external registry
Periodically clean old packages according to conditions - if they are not used for so many days, for example, i.e. if there was no request for them.
Cache size limit (when reached, the oldest packages are deleted)

We really hope for this feature.
Thanks.

@KarenArzumanyan commented on GitHub (Mar 11, 2024): This is a highly requested feature. We also use nexus now, which is very slow and has limitations in the oss edition. From the characteristics of the registry operating in proxy mode: 1) Caching received packages 2) If the package is not found in the cache, then request from the external registry 3) Periodically clean old packages according to conditions - if they are not used for so many days, for example, i.e. if there was no request for them. 4) Cache size limit (when reached, the oldest packages are deleted) We really hope for this feature. Thanks.

GiteaMirror commented

2025-11-02 08:44:01 -06:00

@lunny commented on GitHub (Mar 12, 2024):

I think we can have two types proxies, one is a feature of Gitea which can connect to the source packages directly and pull. Another is an external proxy which could be depolyed in a DMZ and can pull packages from external of the network and then push to Gitea.

@lunny commented on GitHub (Mar 12, 2024): I think we can have two types proxies, one is a feature of Gitea which can connect to the source packages directly and pull. Another is an external proxy which could be depolyed in a DMZ and can pull packages from external of the network and then push to Gitea.

GiteaMirror commented

2025-11-02 08:44:01 -06:00

@KarenArzumanyan commented on GitHub (Mar 13, 2024):

Yes, a good option. It is important that the registry proxy has a cache to speed up the retrieval of packages, without having to request them from the outside each time.

@KarenArzumanyan commented on GitHub (Mar 13, 2024): Yes, a good option. It is important that the registry proxy has a cache to speed up the retrieval of packages, without having to request them from the outside each time.

GiteaMirror commented

2025-11-02 08:44:02 -06:00

@josh-hemphill commented on GitHub (Jun 7, 2024):

I've been tracking this same thing in GitLab, and just found this here. Didn't see it mentioned, so I thought I'd link to their current implementation: https://docs.gitlab.com/ee/user/packages/package_registry/dependency_proxy/
They've only released it for maven packages in a beta; in the issue threads, they've been running into lots of issues pulling it off and it's got pushed back several times, so if it get's added in Gitea, hopefully the issues GitLab have run into can be avoided here.

@josh-hemphill commented on GitHub (Jun 7, 2024): I've been tracking this same thing in GitLab, and just found this here. Didn't see it mentioned, so I thought I'd link to their current implementation: https://docs.gitlab.com/ee/user/packages/package_registry/dependency_proxy/ They've only released it for maven packages in a beta; in the issue threads, they've been running into lots of issues pulling it off and it's got pushed back several times, so if it get's added in Gitea, hopefully the issues GitLab have run into can be avoided here.

GiteaMirror commented

2025-11-02 08:44:02 -06:00

@uvulpos commented on GitHub (Jul 2, 2024):

I would not enable this feature by default, so that the original url is not inside the gitea pull url. I would rather say as an administrator you can configure organisations like dockerhub oder pip so the url would be something like gitea.yourcompany.com/packages/dockerhub/docker/nginx/1.0.0.

Also for security reasons, you could define, which images are approved to pull, and which not (maybe also via wildcards or something?). Would improve security and compliance.

One thing I want to point out is: in the past there were projects that just disappeared over night and our software relied on it so it wasn't buildable anymore (or our infrastructure even deployable anymore, we had weird sys requirement admins ruling harbor). Harbor has also a caching mechanism but according to their documentation they delete the cached versions as well, if the main resource is not available anymore.

I would disagree. In rare cases you still want to use that software I would like to have an opportunity to set custom defined invalidation durations like e.g. not pulled for 6 months and flags for specific packages or packages versions that I have to delete manually

You just have to google for incidents. You'll find enough of them 🙁
https://www.darkreading.com/application-security/recent-code-sabotage-incident-latest-to-highlight-code-dependency-risks

@uvulpos commented on GitHub (Jul 2, 2024): I would not enable this feature by default, so that the original url is not inside the gitea pull url. I would rather say as an administrator you can configure organisations like dockerhub oder pip so the url would be something like `gitea.yourcompany.com/packages/dockerhub/docker/nginx/1.0.0`. Also for security reasons, you could define, which images are approved to pull, and which not (maybe also via wildcards or something?). Would improve security and compliance. One thing I want to point out is: in the past there were projects that just disappeared over night and our software relied on it so it wasn't buildable anymore (or our infrastructure even deployable anymore, we had weird sys requirement admins ruling harbor). Harbor has also a caching mechanism but according to their documentation they delete the cached versions as well, if the main resource is not available anymore. I would disagree. In rare cases you still want to use that software I would like to have an opportunity to set custom defined invalidation durations like e.g. not pulled for 6 months and flags for specific packages or packages versions that I have to delete manually You just have to google for incidents. You'll find enough of them 🙁 https://www.darkreading.com/application-security/recent-code-sabotage-incident-latest-to-highlight-code-dependency-risks

GiteaMirror commented

2025-11-02 08:44:02 -06:00

@sunchezz89 commented on GitHub (Jul 1, 2025):

Any plans, when this will be implemented?

@sunchezz89 commented on GitHub (Jul 1, 2025): Any plans, when this will be implemented?

GiteaMirror commented

2025-11-02 08:44:02 -06:00

@LeeTeng2001 commented on GitHub (Aug 29, 2025):

bump

@LeeTeng2001 commented on GitHub (Aug 29, 2025): bump

GiteaMirror commented

2025-11-02 08:44:02 -06:00

@KarenArzumanyan commented on GitHub (Oct 13, 2025):

I would disagree. In rare cases you still want to use that software I would like to have an opportunity to set custom defined invalidation durations like e.g. not pulled for 6 months and flags for specific packages or packages versions that I have to delete manually

I agree. Such a setting would be useful. Specifically disable cache deletion for specific packages or by mask, for example, using a regexp expression.

@KarenArzumanyan commented on GitHub (Oct 13, 2025): > I would disagree. In rare cases you still want to use that software I would like to have an opportunity to set custom defined invalidation durations like e.g. not pulled for 6 months and flags for specific packages or packages versions that I have to delete manually I agree. Such a setting would be useful. Specifically disable cache deletion for specific packages or by mask, for example, using a regexp expression.

GiteaMirror commented

2025-11-02 08:44:03 -06:00

@okbrown commented on GitHub (Oct 14, 2025):

In regards to Nexus, there are many like myself in that same boat who are eager to find a replacement that has a proxy/pull through like cache to support many of the noted reasons here.

To me sounds like an amazing opportunity to poach a lot of Nexus OSS/Community Edition users over to Gitea.

@okbrown commented on GitHub (Oct 14, 2025): In regards to Nexus, there are many like myself in that same boat who are eager to find a replacement that has a proxy/pull through like cache to support many of the noted reasons here. To me sounds like an amazing opportunity to poach a lot of Nexus OSS/Community Edition users over to Gitea.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#9595