Repositories
A repository holds Maven artifacts and belongs to one account.
Find a repository
The Repositories page lists every repository you own and every one that is shared with you. The search box narrows the list to the repositories whose display name or repository name matches what you enter.
Create a repository
To create a repository, follow these steps:
Sign in to artifex.soh.gg.
Click New repository.
In the Name field, enter a display name.
In the Repository name field, enter the identifier that appears in the Maven repository URL.
Optional: In the Description field, describe what the repository holds.
Under Visibility, select Private or Public.
Click Create repository.
The Maven repository URL is https://artifex.soh.gg/maven/OWNER/REPOSITORY_NAME/, where OWNER is your username and REPOSITORY_NAME is the repository name.
In Advanced, Region selects a placement hint. Auto leaves placement to Cloudflare; a named region is a preference, not a guarantee. You can't change this choice after creation.
On Settings, Region shows the hint followed by the observed Cloudflare location code, such as Auto (MEL) or Oceania (MEL). If no location has been observed, the code is shown as Unknown.
Repository names must be unique within your account. Two accounts can use the same repository name because the owner's username is part of the URL.
| Field | Rules |
|---|---|
| Name | 1 to 80 characters |
| Repository name | Lowercase letters, digits, and single hyphens between them, up to 63 characters |
| Description | At most 500 characters |
Settings
To change a setting, follow these steps:
- Open the repository and go to Settings.
- Change the setting.
- Click Save changes.
Only someone with the repository's Admin role can change settings. For more information, see Share a repository.
| Setting | Default | What it does |
|---|---|---|
| Visibility | Private | Public lets anyone read the repository, including builds with no credentials. Private limits reading to the owner, people with repository roles, and tokens with access. |
| Pin authoritative upstreams | Off | Whether a version's missing files resolve only from its authoritative upstream. See Pin authoritative upstreams. |
| When requesting a missing file without write access | Always respond not found | What a build without write access gets for a file the repository doesn't hold. See Missing files. |
| Allow replacing files | Off | When on, deploying a file that already exists replaces it. See Immutability. |
| Allow deleting files | Off | When on, people with write access can delete files and versions, from the pages or from a build tool. |
| Allow snapshots | On | When off, a -SNAPSHOT version can't be deployed. See Snapshots. |
| What the search index covers | Only what you publish here | Which files the published Maven index describes. See The Maven index. |
A repository created before September 17, 2026, has Pin authoritative upstreams on and When requesting a missing file without write access set to Always resolve from upstreams.
Pin authoritative upstreams
With Pin authoritative upstreams on, a version's missing files resolve only from its authoritative upstream. This behavior matches Gradle, which resolves all of a module's files from the repository that supplied its metadata.
With Pin authoritative upstreams off, each missing file resolves from the first upstream in the list that has it. This behavior matches Maven, which can resolve files independently from its configured remote repositories.
The authoritative upstream is recorded in either case. For the actions that change it, see Authoritative upstreams.
All missing-file options work with either value of this setting.
Missing files
When requesting a missing file without write access sets what happens when a build without write access requests a file that the repository doesn't hold: an anonymous build on a public repository, or a token or person with the Read role only. A build with the Write or Admin role always resolves from the upstreams, whatever the setting.
| Option | What the build gets |
|---|---|
| Always respond not found | Artifex serves only files that the repository already holds. |
| Redirect to authoritative upstream when available | When the version has an authoritative upstream, Artifex redirects the build to that upstream for the file and doesn't cache the file. Otherwise, the file is reported as not found. |
| Resolve from upstreams if version already exists | For a known version, fetch, cache, and serve the missing file. With pinning on, request only its authoritative upstream; with pinning off, request upstreams in list order. An unknown version is reported as not found. |
| Always resolve from upstreams | The file is fetched from the upstreams, cached, and served, as it is for a build with write access. See Upstream repositories. |
A redirected build needs its own access to the authoritative upstream. Artifex doesn't pass saved upstream credentials to the build. For another Artifex repository, the build's token must also have access to that repository. A redirect from a custom domain can require signing in at the destination because clients can omit credentials when the hostname changes. Use a resolve option when the build has access only to the repository it originally requested.
This setting exists for a Gradle build that lists both an Artifex repository and another repository that is also one of the Artifex repository's upstreams. Gradle resolves a module from the first repository that has its metadata and then requests the module's other files only from that repository. When the Artifex repository holds only some of an artifact's files, such as one classifier or one Gradle variant, the build fails to resolve the rest instead of resolving them from the other repository. The redirect and resolve options let the build resolve the rest, and so does the upstream option Fetch Gradle variant files eagerly, which fetches every file that a .module file lists when the .module file is fetched.
Change the repository name
The repository name is the REPOSITORY_NAME part of its Maven repository URL. Changing the name changes that URL.
To change it, follow these steps:
- Open the repository and go to Settings.
- In the Repository name field, enter the new name.
- Click Change name.
Builds that use the previous Maven repository URL can no longer resolve from it, so update every pom.xml file, build.gradle.kts file, and continuous integration configuration that names it. A custom domain that points at the repository continues to work because its URL doesn't include the repository name.
Delete a repository
Deleting a repository removes its artifacts, its files, and its index. This can't be undone.
Only the owner can delete a repository.
To delete a repository, follow these steps:
- Open the repository and go to Settings.
- In the Delete this repository section, click Delete repository.
- In the confirmation field, enter the repository name exactly.
- Click Delete repository.
The following also happens:
- Everyone the repository was shared with loses access, and so does every token that named it.
- Custom domains connected to the repository are disconnected, and their certificates are released.
- Repositories that used this one as an upstream lose that upstream.
- The repository's activity is deleted with it, and its repository name becomes available again.
Request counts for the period the repository existed stay in your account's usage for the month.
Advanced
For builds without write access, locally generated Maven metadata remains available under every missing-file policy. Always resolve from upstreams also merges upstream metadata. The other resolve and redirect options apply to missing snapshot metadata only when the version already has an authoritative upstream. They don't fetch group-level or artifact-level upstream Maven metadata.