The agent-first platform on Kubernetes for notebooks, internal tools, dashboards and AI-built apps.

Notebooks, apps and jobs that you and your AI agents run through the API or MCP.

Javo runs notebooks, web apps and scheduled jobs on Kubernetes, from one place.

Who it's for

• Data scientists: work in JupyterLab, then share the results as live dashboards and apps.
• Engineers: deploy internal tools and APIs from a Git repository.
• People who don't code (ops, finance, marketing, project managers, etc.): ask an AI agent for a sales dashboard or a project burndown, and get a working app your team can open, in a safe sandbox.
• Platform teams: run all of it on your own Kubernetes, with GPU sizes, idle shutdown and backups built in.

Warning

Javo is experimental. It is under active development: the API, the Helm values and the Kubernetes resources it creates may change between releases without a migration path, and it has not been run in production yet. Try it on a test cluster, and expect to reinstall when you upgrade.

Features

• Apps: JupyterLab, Whybook, VS Code, RStudio, marimo, Streamlit, Dash, Panel, Bokeh, Gradio, Voila, FastAPI, static sites, Node and Go back-ends, coding agents, or any container image.
• Code from anywhere: run from your home folder or a Git repository, with a preview app for every pull request.
• Jobs: run scripts and notebooks on demand or on a schedule, with logs and history.
• Sharing: keep an app private, or share it with people, groups, everyone signed in, or the public.
• Secrets and environment variables: encrypted at rest and handed to apps and jobs by reference.
• Sizes: admin-defined sizes, optionally with GPUs, or custom CPU and memory, controlled by role.
• Operations: stop apps when idle, back up to any S3-compatible bucket, admin views of every app and its usage.
• Sign-in: local accounts or any OpenID Connect provider, such as Keycloak.

Quick start

On one machine with Docker Engine and Compose v2:

cd deploy/compose
docker compose --profile build up -d
docker compose logs -f installer   # ends with the URL
docker compose exec k3s cat /var/lib/javo-secrets/admin.password

On an existing Kubernetes cluster, install the Helm chart in deploy/helm/javo (Helm install).

Docker Compose

The quick start above is deploy/compose/compose.yaml: single-node k3s in a privileged container, and the Helm chart installed into it.

deploy/compose/docker.yaml runs Javo without Kubernetes instead: one container, which starts every app and job as a hardened container of the same Docker daemon (executor: docker, see configuration).

cd deploy/compose
docker compose -f docker.yaml up -d --build
docker compose -f docker.yaml exec javo /javo user add admin --group javo-admins --password-file - --database-path /home/nonroot/javo.db

The second command prints the password of admin; sign in at http://localhost:8080. Javo runs as uid 65532 and uses the Docker socket through the socket's group: when that is not group 0, set JAVO_DOCKER_GID first (on a Linux host, stat -c %g /var/run/docker.sock). Whoever holds the Docker socket is root on the host, so a remote code execution in Javo is root on that host; rootless Docker is recommended. Group folders, home backups, home sizes and pull request previews need Kubernetes.

On your own machine

One binary, for one person, with no cluster, no Docker and no config file. It carries the web UI and the templates, and runs apps and jobs as your own processes (nothing is isolated from your account):

make local                     # builds bin/local/<os>_<arch>/javo (Linux and macOS)
bin/local/darwin_arm64/javo local

javo local listens on http://127.0.0.1:8686 only (--port), prints a link that signs you in, and keeps everything in ~/.local/share/javo (--dir). Environments are installed by pixi, found beside the binary or on PATH. See configuration.

Development

Requires Go, Node with pnpm, Docker with Compose v2, kubectl and Helm.

make test        # unit and integration tests
make up          # local cluster with this checkout, prints the URL
make reload      # rebuild and roll out after a change
make e2e-quick   # core end-to-end tests
make down        # delete the local cluster

Architecture

The gateway serves the UI, the API and the apps; the controller turns database changes into pods. They share only the database (SQLite in one pod, or Postgres with a Deployment each). The architecture page walks through every piece.

Javo builds one image, javo. Apps and jobs run upstream images as they are published: the templates run the pixi image in a pixi environment of their own (pod/files/envs: conda-forge packages pinned by a committed pixi.lock), installed into the person's home on the first start and reused after. An app can bring its own environment instead, with a pixi.toml and pixi.lock at the root of its Git repository or a Nebi environment. RStudio runs the Rocker project's image and static sites run nginx, both unmodified. Samples and other files pods need come from the javo image (pod/files).

How an app is created, from the New app form to Open:

Documentation

The documentation is the site in site/ (sources in site/src/content/docs; make docs-serve previews it):

• Getting started: Docker Compose and Helm installs
• Administer: configuration, backups, secrets and keys, Nebi environments (optional)
• Development: local clusters, end-to-end tests, single-host deploys
• Dependencies
• Contributing
• Security policy