Admin Settings

Reference for the platform settings available to administrators of a self-managed JuliaHub installation. Settings are found under Admin → Settings, which is organized into tabs for instance, platform, registry, and compute configuration.

For operational procedures such as restarts and volume expansion, see Common Administrative Tasks.

Server configuration

Upstream package server

Controls where this installation synchronizes packages from.

The authentication token is carried in your license, so it is supplied by the installation rather than entered in the admin UI, where it is read-only.

• The token is injected from the license field upstream_jh_auth_token. It can also be set directly as the Helm value bootstrap.upstreamJh.authToken, or supplied from an existing secret via bootstrap.upstreamJh.existingSecretName.
• The upstream host comes from bootstrap.upstreamJh.host, which defaults to https://juliahub.com.

Package synchronization enables itself automatically when an upstream token is present and the installation is not air-gapped, so no manual setup step is required. Air-gapped installations ingest packages from bundles instead — see Offline Package Bundles.

Credentials

Credentials used by the platform to reach external systems, under Admin → Settings → Credentials.

Tokens

Access tokens for Git hosts and package servers. Each entry has:

• Name — identifier for the token
• Token — the secret value
• URL — the URL prefix the token applies to

Where the host supports it, JuliaHub displays the token's associated account, expiry date, and scopes, and warns when a token has expired.

The upstream package server token is shown here but is read-only; see Upstream package server.

SSH

Used for registries and packages accessed over SSH.

• SSH Host key — the host's public key. Obtain it with ssh-keyscan <registry-host>.
• SSH Private Key — uploaded as a file.

GitHub Apps

An alternative to personal access tokens for GitHub-backed registries, with finer-grained permissions and no user-tied expiry.

• App ID
• App Private Key — uploaded as a file
• URL Prefix — the GitHub host the app applies to

Registries

A new installation is seeded with the General and JuliaHubRegistry registries, plus DyadRegistry where Dyad is enabled.

For day-to-day registry usage, see Registry Management. The settings below are the ones most relevant to installation and operations.

Registry details

Provider types

How JuliaHub obtains the registry's contents:

Git-backed providers additionally take a registry URL, the Git server type, and a credentials type — either a personal access token or a GitHub App.

Sync schedule

Controls when a synchronizing registry checks its upstream. Rather than a single interval, the schedule constrains sync to a window:

Restricting the window is useful when upstream bandwidth is shared or metered.

Cooldown period

Delays how quickly newly published upstream versions become available, expressed in days and hours. With a cooldown set, the registry serves the newest version that is older than the cooldown period rather than the newest version outright.

The served version never rewinds: once a version has been served, a later sync will not withdraw it. Cooldown requires a Git-backed registry download; bundle registries do not participate.

This is useful where you want a settling period before your users can resolve a brand-new release.

Registrator

Lets users register new packages into a registry, configured per registry under its Registrator tab.

Triggering a sync after registration

Registration merges a pull request in the registry repository, but the platform does not learn about it until its next scheduled sync. To pick up new registrations immediately, have your CI call the sync endpoint after the merge:

POST https://<hostname>/app/sync/start
Authorization: Bearer <long-term-token>

Generate the token under Token configuration. In GitHub Actions, store it as a repository secret and call the endpoint from a workflow triggered on pushes to the registry's default branch.

Token configuration

Generates long-term authentication tokens for programmatic access — CI jobs, JULIA_PKG_SERVER configuration, and the sync endpoint above.

Tokens can be downloaded as a token.toml for placing in a Julia depot.

Authentication

JuliaHub delegates authentication to an identity provider — LDAP or Active Directory, GitHub, GitLab, generic OpenID Connect, SAML, or an authenticating reverse proxy.

See Authentication for connector configuration, both through the admin console and at install time.

Authorization providers

Authorization providers let users grant JuliaHub delegated access to an external service on their behalf — for example to import a project from a private repository, or to write changes back to it. This is distinct from authentication, which controls who may log in.

Configure these under Admin → Settings → Authorization Providers.

The following provider and mechanism combinations are supported:

Registering the OAuth application

When creating the OAuth application on the provider's side, set the callback URL to:

https://<hostname>/user/authorization/callback

JuliaHub derives this from the installation's configured protocol and hostname, so there is no redirect URI field in the admin UI.

Scopes for project import

The default read-only scopes are enough to browse and clone. Importing a project and pushing changes back requires write access:

Without the write scope, imports succeed but pushing changes back fails.