The kLLM website

Note

Part of the upcoming 0.2 line. The website sources are in the web/ directory of the repository on the main branch. web/README.md and web/apps/admin/README.md describe the development scripts in more detail.

The kLLM website presents the project, the model library, the security model, the research and kLLM Enterprise, and hosts the application form for model keys. It is a set of static files: every route is rendered to HTML at build time, so the site can be served by GitHub Pages or any static host or CDN without a server-side runtime. A separate static application, the administration console, is used by the kLLM team to review key applications; it talks to the key-application service (The key-application service).

Repository layout

Path

Content

web/package.json

The npm workspace root, with one lockfile for all packages.

web/data/models.json

The website’s model catalog. The library bundled with kLLM is kept consistent with it (Model library and naming).

web/packages/ui/

Shared components, design tokens, motion definitions, icons and charts.

web/apps/site/

The public website.

web/apps/admin/

The administration console for key applications.

The site is built with Vite, React, TypeScript, Tailwind CSS and shadcn/ui components. Fonts are served with the site rather than from a third-party font service.

Building

The build needs Node.js 22 and npm 10. From the web directory:

$ npm ci
$ npm run build

npm ci installs the exact versions recorded in the lockfile. npm run build builds the public site and the administration console; each application writes its static files to its own dist/ directory, web/apps/site/dist and web/apps/admin/dist. npm run build:site and npm run build:admin build one of them, and npm run typecheck checks the TypeScript of every package. The site build prerenders every route, including one page per catalog model, writes the sitemap, robots.txt and 404.html, and fails if any route has no HTML.

Build-time settings are read from the environment. The production values are recorded in web/apps/site/.env.production and web/apps/admin/.env.production; variables set in the environment take precedence over them.

Variable

Meaning

VITE_SITE_URL

Site. The absolute origin used for canonical addresses, Open Graph metadata and the sitemap. Default https://kllm.agentnetwork.org.cn.

VITE_BASE

Site. The public base path, for example /kLLM/ for a GitHub Pages project site. Default /.

VITE_ACCESS_API

Site and console. The base address of the key-application service without the /api segment, for example https://access.example.org; every request path starts with /api. When it is unset or empty, requests go to /api on the same origin, which is the production deployment. In the site’s development server an unset value selects the email fallback instead, and / selects the same origin explicitly. For the site, off (also none, mailto or disabled) makes the application form open a prepared email instead of posting to the service.

VITE_ADMIN_BASE

Console. The public base path of the console. Default /admin/.

Deploying the public site

The public site is a directory of static files and can be deployed to any static host:

  • GitHub Pages. The workflow .github/workflows/web.yml installs the dependencies, builds the site and the console, and uploads the site as a Pages artifact. Its deploy job runs only on the main branch and only when the repository variable PAGES_ENABLED is true, so that nothing is published while the repository is private. The repository variables SITE_URL, SITE_BASE and ACCESS_API are passed to the site build as VITE_SITE_URL, VITE_BASE and VITE_ACCESS_API. Set them, set PAGES_ENABLED, and select GitHub Actions as the Pages source in the repository settings. GitHub Pages has no /api path, so set ACCESS_API to the service’s address, or to off for the email fallback.

  • Another static host or CDN. Upload the contents of web/apps/site/dist. Configure the host to serve the 404 page for unknown paths.

Serve the site over HTTPS only. The site sends personal data only through the application form, to the key-application service.

Deploying the administration console

The console is a static application without secrets: it holds no credentials, and every action is authorized by the key-application service. Deploy it separately from the public site:

  • Serve it from the same site as the key-application service, for example under a path behind the same reverse proxy. The service’s session cookie is SameSite=Strict, so a console served from another site cannot use it.

  • Do not link it from the public site, and restrict access to it at the proxy where possible, for example by network or by client certificate.

Administrator accounts are created on the service, not in the console; see Administrator accounts.

Production deployment

The production deployment serves the public website, the administration console and the key-application service from one origin, https://kllm.agentnetwork.org.cn, behind nginx:

Path

Content

Served as

/

web/apps/site/dist

Static files. Every route is prerendered to <path>/index.html; unknown paths receive 404.html with status 404. No single-page fallback.

/admin/

web/apps/admin/dist

Static single-page application: unknown paths under /admin/ fall back to /admin/index.html. /admin redirects to /admin/.

/api/

The key-application service

Reverse proxy to http://127.0.0.1:8080 with the path passed through unchanged (proxy_pass http://127.0.0.1:8080;, without a URI part).

Both applications are built with VITE_ACCESS_API unset, so the application form posts to /api/applications and the console calls /api/admin/... on the same origin; the service is configured with ACCESS_PUBLIC_BASE_URL, ACCESS_SITE_URL and ACCESS_ADMIN_ORIGINS set to https://kllm.agentnetwork.org.cn, so that verification links (/api/verify) and key-delivery links (/api/deliveries/...) resolve through the /api/ location. The complete nginx server block is in services/access/README.md, section Reverse proxy.

To publish a new build:

$ cd web
$ npm ci
$ npm run build
$ rsync -a --delete apps/site/dist/ <host>:/srv/kllm/site/
$ rsync -a --delete apps/admin/dist/ <host>:/srv/kllm/admin/

Content maintenance

  • Model catalog. Update web/data/models.json and the bundled src/kllm/models/library.json together; each library family names the catalog entries it covers in its catalog field. The site reads the library tags shown on the model pages directly from library.json at build time. The sealed_models section of models.json lists the official sealed models of the research team’s catalog, tools/catalog/models.json, and must follow it when an entry is added, held or given a new key version. Mark official sealed artifacts as published only when they are available in the ANetResearch organization on Hugging Face.

  • Application form. The catalog models offered on the application form are listed in web/apps/site/src/components/apply/catalog-models.json, generated from tools/catalog/models.json without the held entries. Regenerate it with node web/apps/site/src/components/apply/sync-catalog.mjs whenever the catalog changes; --check reports whether it is current. The key-application service keeps its own list (The key-application service).

  • Measured results. The benchmark and comparison pages show only published measured results, with their conditions: one NVIDIA A40 48 GB, SGLang 0.5.21 or vLLM 0.31.0, bf16, 1024 input and 128 output tokens, single runs on a GPU shared with another tenant’s light job (Benchmarking plain and sealed serving).

  • Security statements. The website’s security page states the same claims and limits as Claims and links to it.

See also