Common Prerequisites
These prerequisites apply to every self-managed installation method. Review them before following the AWS (Helm), Azure (Helm), or Embedded Cluster guide, each of which adds its own platform-specific requirements on top of these.
Provided by JuliaHub
Contact your JuliaHub sales representative to obtain your licensing credentials. What you receive depends on the installation method:
- Helm installations (AWS, Azure) — a license ID and license email, used as the password and username when logging in to the Helm registry. The chart carries the license values itself, so there is no separate license file to install.
- Embedded Cluster — a license file (
license.yaml) and a license ID, uploaded during installation.
Your license also determines your entitlements, such as whether compute (batch jobs and interactive applications) is enabled.
Your installation authenticates to JuliaHub's package servers using a token carried in the license, so there is nothing to enter by hand and synchronization enables itself once the license is in place. See Admin Settings.
Initial administrator account
JuliaHub authenticates users through single sign-on, and that is how accounts should be managed on a running installation. But configuring an identity provider requires an administrator who can already sign in, so every installation is bootstrapped with one administrator account to start from.
Decide the email address that should own it before you begin. How you supply it depends on the installation method:
Embedded Cluster — set Administrator Email Address and Administrator Password in the Initial Administrator section of the Admin Console configuration screen. The password field is pre-filled with a randomly generated value; keep it or replace it with your own, and record it before continuing.
Helm installations (AWS, Azure) — set
settings.initialUsersin your Helm values, with a bcrypt-hashed password:settings: initialUsers: - name: Ada Lovelace email: ada@example.com role: admin bcryptPasswordHash: "<hash>"Generate the hash with
htpasswd -bnBC 10 "" <password> | tr -d ':\n'.
Once single sign-on is configured, add and manage users through your identity provider rather than creating further local accounts — local accounts cannot reset their own passwords.
If you configure an identity provider as part of the installation, the administrator does not need a local password at all. Clear the Administrator Password field (or omit bcryptPasswordHash from your Helm values) and the account is still created with administrator access, but signs in only through your provider.
Set the email address to one your provider will present for that person, so that their first single sign-on login lands on this account rather than creating a second one.
The initial password cannot be read back out of JuliaHub after installation, only replaced. These settings apply only when the account is first created — changing them later has no effect on an installation that has already been bootstrapped. Change it afterwards from Administration ➤ Server Configuration inside JuliaHub.
Provided by you
Hostname
Decide the hostname your installation will be reached at (referred to as <hostname> throughout these guides). It does not need to resolve yet, but it must be chosen before you begin, as it is baked into the TLS certificate and the platform configuration.
TLS certificate and private key
A certificate and key in PEM format covering both:
<hostname>— the main platform URLdocs.<hostname>— generated Julia package documentation
The certificate must include the full CA chain.
DNS records
A (or CNAME) records for <hostname> and docs.<hostname>, pointing at the machine or load balancer that fronts the installation. These are created after the install completes, once you know the ingress address.
PostgreSQL database (optional)
JuliaHub requires PostgreSQL. You may either let the installation provision an internal database, or point it at an existing server. An external server must require SSL and present a valid certificate, and you must create an empty database for JuliaHub to use.
An internally provisioned database is not reachable from outside the cluster.
Git host (optional)
Private registries and private packages require network connectivity to a Git platform. Self-hosted GitHub, GitLab, and Bitbucket are supported, as are their respective cloud services. See Registry Management.
Internal CA certificates (optional)
If your environment terminates or inspects TLS with an internal certificate authority, collect the CA certificates for:
- any internal GitHub or GitLab instance used as a private package registry
- any internal HTTP/HTTPS proxy
Concatenate them into a single PEM-encoded file, with a newline between certificates.
Outbound network access
Installations that are not air-gapped need outbound TCP 443 to the following hosts. If your environment restricts egress, allowlist them before installing.
| Host | Required | Purpose |
|---|---|---|
pkg.juliahub.com, juliahub.com | Yes | Package, documentation, and artifact synchronization. |
replicated.app | Yes | Application metadata and release YAML. Your license ID and application ID are sent to authenticate. |
proxy.replicated.com | Optional | Proxies the JuliaHub application container images. Authenticated with your license ID. |
auth.docker.io, registry-1.docker.io, index.docker.io, dseasb33srnrn.cloudfront.net, production.cloudflare.docker.com | Optional | Some installer dependencies are hosted as public Docker Hub images. |
replicated.app and proxy.replicated.com are operated by Replicated, Inc. The current IP ranges for both are published at replicatedhq/ips.
The optional hosts above can be avoided by mirroring the images through an internal registry such as Artifactory, or by using an air-gapped installation. See the air-gap section of your chosen installation guide, and Offline Package Bundles for supplying packages without internet access.
Next steps
Once these are in place, continue with the guide for your target environment: