Skip to content

Helm

3 min read

The chart lives in deploy/helm/javo in the repository. It installs one image, javo, which runs the gateway (web UI, API and app proxy) and the controller. With the default SQLite database both run in one pod.

  • A Kubernetes cluster and kubectl and helm pointed at it. On 1.30 or newer the chart also installs admission policies that limit what the controller’s cluster-wide rights can change (see Configuration); older clusters install without them.
  • A default StorageClass, or one named in the values: the SQLite database lives on a volume (javo-data), and so do home folders.
  • A network plugin (CNI) that enforces NetworkPolicy. Apps have no sign-in of their own; a default-deny policy lets only the gateway reach them. k3s enforces it out of the box; check yours.
  • A container registry the cluster can pull from, since you build the image yourself.
  • Pods need internet access on a first start, to install their packages (see Environments).
  1. Build and push the image from the repository root. The default target of the Dockerfile is the javo image.

    Terminal window
    git clone https://github.com/nebari-dev/javo.git && cd javo
    docker build -t registry.example.com/javo/javo:0.1.0 .
    docker push registry.example.com/javo/javo:0.1.0
  2. Write a values file. This one serves Javo at javo.example.com through an Ingress with TLS, and makes members of the group javo-admins platform admins.

    values.yaml
    image:
    repository: registry.example.com/javo/javo
    tag: "0.1.0"
    ingress:
    enabled: true
    className: nginx
    host: javo.example.com
    tls:
    enabled: true
    secretName: javo-tls
    config:
    roles:
    platformAdmin: {groups: [javo-admins]}

    The host is set once: ingress.host is also the UI host (config.urls.uiHost), the host Panel and Bokeh check websocket origins against (publicHost) and the address in agents’ approve links (config.mcp.publicURL). Every value is described in the Helm values reference. The configuration guide walks through the ones most installs change.

  3. Install the release.

    Terminal window
    helm upgrade --install javo deploy/helm/javo \
    --namespace javo-system --create-namespace -f values.yaml --wait
  4. Create the first local account, in the javo-admins group. The password is generated and written to admin.password; it is never printed.

    Terminal window
    kubectl -n javo-system exec deploy/javo -- \
    /javo user add admin --group javo-admins --password-file - > admin.password
  5. Open https://javo.example.com and sign in as admin. Next: create a first app.

  • Namespace javo-system (the release) and javo-apps, where apps and their pods run. javo-apps is labelled for Pod Security “restricted” and kept on uninstall.
  • With SQLite: one Deployment javo and the volume javo-data, kept on uninstall. With Postgres: Deployments javo-gateway and javo-controller.
  • Service javo-gateway (port 80).
  • Secret javo-secrets-key, the key that protects people’s secrets. The controller makes it on its first start (the chart does not render it) and never changes it; upgrades and uninstall keep it. Back it up.
  • Secret javo-sessions-key, the key the gateway seals each session’s sign-in tokens with. The gateway makes it on its first start (the chart does not render it); losing it only signs everyone out.
  • Secret javo-secret-fingerprint-key, the key of the fingerprints that let the gateway hide people’s secret values in logs sent to an AI model. The gateway or the controller makes it on the first start (the chart does not render it).
  • The built-in templates, loaded into the database at start.
  • Sign-in: add an OpenID Connect provider such as Keycloak.
  • App addresses: serve apps on their own host, which sharing needs.
  • Backups: turn on scheduled backups before people store work.