Introduction

A Go module proxy that:

1. Can front private repositories and supports authentication to GitHub repositories via GitHub App credentials.
2. Implements strong consistency so that .info, .zip and .mod always reflect the same copy of a module version across all server replicas. This is an important reliability property.
3. Uses Google Cloud Storage (see durability and availability) to realize scalable, reliable and low maintenance storage.
4. Supports client authentication and access control (but see #2).

Comparison

	Authentication to private repositories	Persistent storage	Strong consistency	Community (as of 6 May 2023)	Caches sumdb (privacy)	Pkgsite Index	Client authentication
This module proxy server	- Encapsulates git over HTTPS via internal credential helper server - Least-privilege authentication to GitHub via GitHub Apps - Supports only private GitHub repositories (and no other Version Control Systems)	Highly available, durable and scalable storage via Google Cloud Storage (GCS)	Yes	11 stars	No, see #1	No, see #228	- Identity-based access via Instance Identity JWTs - Username/password authentication - Access control lists
Athens	Athens documents how to setup authentication for all (if not most) Version Control Systems, but does not encapsulate it	Supports GCS and much more	No	4.1k stars	No	No	No
goproxy.io	Not documented	File system	No	5.5k stars	-	No	No

Strong consistency

The .info, .zip and .mod endpoints are strongly consistent. More formally:

1. Given a copy of a module version <m>@<v>: .info, .zip and .mod as reported by GET <m>/v@/<v>.info, <m>/v@/<v>.zip and <m>/v@/<v>.mod requests, respectively, reflect that copy and at no point (in the future) will GET <m>/v@/<v>.info, <m>/v@/<v>.zip and <m>/v@/<v>.mod requests reflect a different copy.
2. Given a module version <m>@<v>: if any one of .info, .zip and .mod as reported by GET <m>/v@<v>.info, <m>/v@/<v>.zip and <m>/v@/<v>.mod requests, respectively, reflect a copy of the module version then all future GET <m>/v@/<v>.info, <m>/v@/<v>.zip and <m>/v@/<v>.mod requests reflect that copy.

Similarly, list after read is strongly consistent (but list may return partial results in case of errors and list does not return pseudo-versions).

NOTE

Strong consistency is implemented using GCS atomic object creation.For example, Amazon S3 does not support atomic object creation, but can still be pluggged in.

Client authentication

Supports authentication using Google Compute Engine Instance Identity Tokens. This is similar to Hashicorp Vault's GCE login: https://www.vaultproject.io/docs/auth/gcp.html#gce-login. Supports authentication via username/password. Supports access control lists to configure fine grained access control on modules. See the example configuration config_example_clientauth.yaml.