- Get started
- Helm
Helm
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.
Requirements
Section titled “Requirements”- A Kubernetes cluster and
kubectlandhelmpointed 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).
Install
Section titled “Install”-
Build and push the image from the repository root. The default target of the
Dockerfileis thejavoimage.Terminal window git clone https://github.com/nebari-dev/javo.git && cd javodocker build -t registry.example.com/javo/javo:0.1.0 .docker push registry.example.com/javo/javo:0.1.0 -
Write a values file. This one serves Javo at
javo.example.comthrough an Ingress with TLS, and makes members of the groupjavo-adminsplatform admins.values.yaml image:repository: registry.example.com/javo/javotag: "0.1.0"ingress:enabled: trueclassName: nginxhost: javo.example.comtls:enabled: truesecretName: javo-tlsconfig:roles:platformAdmin: {groups: [javo-admins]}The host is set once:
ingress.hostis 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. -
Install the release.
Terminal window helm upgrade --install javo deploy/helm/javo \--namespace javo-system --create-namespace -f values.yaml --wait -
Create the first local account, in the
javo-adminsgroup. The password is generated and written toadmin.password; it is never printed.Terminal window kubectl -n javo-system exec deploy/javo -- \/javo user add admin --group javo-admins --password-file - > admin.passwordTerminal window kubectl -n javo-system exec deploy/javo-controller -c controller -- \/javo user add admin --group javo-admins --password-file - \--database-engine=postgres --database-dsn-file=/etc/javo-db/dsn > admin.password -
Open
https://javo.example.comand sign in asadmin. Next: create a first app.
What the chart creates
Section titled “What the chart creates”- Namespace
javo-system(the release) andjavo-apps, where apps and their pods run.javo-appsis labelled for Pod Security “restricted” and kept on uninstall. - With SQLite: one Deployment
javoand the volumejavo-data, kept on uninstall. With Postgres: Deploymentsjavo-gatewayandjavo-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.
Next steps
Section titled “Next steps”- 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.