LiveChat

LiveChat is a separate, optional product: a visitor chats from a widget embedded on your website, an agent answers from a console. FlowDesk works without it, and LiveChat works without FlowDesk. It is shipped by the same Helm chart (shftco/flowdesk-kubernetes) under the livechat section of values.yaml, and it is off by default.

One container, every surface

Unlike the Knowledge Base’s three images, LiveChat ships one image (ghcr.io/shftco/flowdesk-livechat) that serves everything:

Path	What it is	Who reaches it
/widget.js	The embeddable widget bundle — one <script> tag on your site	Your customers’ browsers
/v1/widget/*	The anonymous visitor API (rate-limited, visitor-token auth)	The widget
/v1/agent/*, /v1/admin/*	The staff API (JWT auth)	The console
/hubs/visitor, /hubs/agent	Realtime delivery (WebSockets)	Widget and console
/console/	The agent console (the root / redirects here)	Your agents, in a browser

Before you start

• A DNS record for the LiveChat hostname (for example chat.your-domain), pointing at your ingress, created before enabling — its hostname gets its own certificate, and cert-manager keeps retrying a challenge it cannot pass. An optional second hostname (ingress.apiHost, for example chat-api.your-domain) serves the same backend under an API-looking name for embed snippets; it joins the same certificate, so its DNS record must exist too.
• A database. LiveChat has its own database and its own databaseProvider (SqlServer or PostgreSql), independent of the FlowDesk API’s. A separate database on the same server is the usual choice.
• A JWT keypair of its own. Separate products, separate signing keys — do not reuse the FlowDesk or Knowledge Base keypair.
• No Redis and no message broker. Same stance as the Knowledge Base.

Secrets

The chart never renders credentials. Three keys join the application Secret (flowdesk-secret), and the keypair is its own Secret:

# Its own JWT keypair, mounted at /app/keys:
openssl genpkey -algorithm RSA -out private.pem -pkeyopt rsa_keygen_bits:2048
openssl rsa -in private.pem -pubout -out public.pem
kubectl -n flowdesk create secret generic flowdesk-livechat-jwt \
  --from-file=private.pem --from-file=public.pem

# Three keys added to the application Secret:
#   LIVECHAT_CONNECTION_STRING     e.g. Host=postgres;Port=5432;Database=livechat;Username=livechat;Password=...;Search Path=dbo
#   LIVECHAT_TOKEN_ENCRYPTION_KEY  openssl rand -base64 32
#   LIVECHAT_SEED_ADMIN_PASSWORD   the first-boot administrator agent (see below)

The seed admin password is required on a fresh database

On first boot LiveChat applies its migrations and seeds one administrator agent (livechat.seedAdminEmail, default admin@shft.co) with the password from LIVECHAT_SEED_ADMIN_PASSWORD. The boot fails without it — a chat product with no agent who can sign in is not running, it only looks like it is. Sign in at /console/ with that address and password, then create your real agents under Administration → Agents.

values.yaml

livechat:
  enabled: true
  image:
    tag: v0.3.0                 # pin it; see the release notes
  databaseProvider: PostgreSql
  ingress:
    host: "chat.your-domain"
    # apiHost: "chat-api.your-domain"   # optional second name for the same backend
  # The networks whose X-Forwarded-For the API trusts — set it to your cluster's
  # pod network (k3s default 10.42.0.0/16). Without it, every visitor behind the
  # ingress shares ONE rate-limit bucket and the first burst locks out every
  # customer's chat at once.
  trustedProxies:
    - "10.42.0.0/16"

Attachments (and the licence state) live on a PVC mounted at /var/lib/flowdesk-livechat (livechat.persistence, default 2 Gi). The boot proves the path is writable and refuses to start otherwise — a deployment that lost its volume fails loudly instead of failing on the first upload.

Verify

kubectl -n flowdesk rollout status deploy/flowdesk-livechat
curl -s -o /dev/null -w '%{http_code}\n' https://chat.your-domain/health   # 200

Then open https://chat.your-domain/ — it redirects to the console. Widget setup for your website, including handing over your signed-in user’s identity, is on the LiveChat widget page.