Talos web UI - self-hosted DevOps control plane for servers, K8s, databases and the clouds
324
The web interface for Talos, a self-hosted DevOps control plane for managing Frappe/ERPNext infrastructure, servers, containers, Kubernetes, databases and the four major clouds from one place.
This image is not usable on its own. It is a Next.js client that talks to
talosfleet/talos-backend, which in turn needs PostgreSQL (withpgvector) and Redis. Use the Compose stack below — running this image alone gives you a UI that cannot load anything.
The full stack, .env template and step-by-step instructions live on the backend image
page, which is the one to follow:
The short version:
services:
frontend:
image: talosfleet/talos-frontend:latest
ports: ['3000:3000']
environment:
# The backend as THIS CONTAINER sees it — a service name, not the address users type.
BACKEND_INTERNAL_URL: http://backend:3001
depends_on: [backend]
Then open http://localhost:3000.
| Variable | Default | Notes |
|---|---|---|
BACKEND_INTERNAL_URL | http://localhost:3001 | The backend as this container sees it. Inside Compose that is the service name, http://backend:3001 — never localhost, which would be this container itself. |
That is the only one, and it has nothing to do with the address your users type.
There is no public API URL to set. The browser calls this app on a relative /api and
this app forwards to the backend, so Talos works behind any hostname with no configuration
and no CORS to get wrong.
If you used an earlier version of this image, note that NEXT_PUBLIC_API_URL was documented
as a runtime setting and never worked as one. Next.js compiles NEXT_PUBLIC_* values into
the client bundle at build time, so the published image had the address fixed before you
pulled it — meaning any install not reached at localhost had a UI that could not talk to its
own API, and setting the variable changed nothing. It is now a build argument only, for the
split-deployment case below.
The page loads but every request fails, or the login form does nothing.
This container cannot reach the backend. Check the backend is up (docker compose ps) and
that BACKEND_INTERNAL_URL is the backend's service name, not localhost.
Blank page after an upgrade. A stale service worker or cached bundle. Hard-reload
(Ctrl-Shift-R), or docker compose up -d --force-recreate frontend.
The hypervisor VNC console will not connect, but everything else works. Expected without a
reverse proxy. That screen is the only WebSocket in the app, and a WebSocket upgrade is not
an HTTP request/response, so the frontend cannot forward it. Put nginx, Traefik or Caddy in front, routing /api to
the backend and everything else here — the shape you want anyway for a real hostname and TLS.
Only if you actually need it. Because the value is compiled in, it must be supplied at build time, which means building the image yourself:
docker build --build-arg NEXT_PUBLIC_API_URL=https://api.example.com/api -t my-talos-frontend .
The backend then needs that origin in its allow-list (FRONTEND_URL, or CORS_ORIGINS for
extras). The relative default avoids all of this.
Upgrade both images together — the client and API are released as a matched pair and are not guaranteed to be compatible across versions:
docker compose pull
docker compose up -d
For production, pin the same version on both:
image: talosfleet/talos-frontend:1.0.0
image: talosfleet/talos-backend:1.0.0
| Tag | Meaning |
|---|---|
latest | Most recent release. Convenient for a lab, not recommended for production |
1.0.0 | |
1.0.1 | Pinned release. Use this in production, matched with the same backend tag |
Content type
Image
Digest
sha256:cdab3b6a0…
Size
53.4 MB
Last updated
about 1 month ago
docker pull talosfleet/talos-frontend:sha-8bf951c