kaba-enclave

A Kaba Enclave is a personal box running Kaba: your own hardware, holding your code, your data and your comms. See What is Kaba?.

There is nothing enclave-specific in the software: an Enclave runs the same kabactl as any other node. So this page covers the part that makes a box an enclave in practice, which is running it as an isolated deployment: a node, or a cluster, that makes no connection you did not choose.

[todo: add Kaba Enclave hardware details, setup steps and photos.]

What an isolated deployment means

A stock node makes a small number of outbound connections on its own: to a relay for the mesh, to filter-list and threat-feed publishers, and to a model mirror when asked for a model. An isolated deployment removes or redirects each of them.

Outbound connection	Default	Isolated setting
Mesh relay	https://relay.kaba.dev	Your own relay, or no mesh
Public discovery	off	Leave off
Public service directory	follows the first relay	Disable
Ad-block list download	EasyList	Empty list or an internal mirror
Threat feeds	abuse.ch and Phishing Army	Local file feeds
Model download	mirror, then Hugging Face	Pre-load files, or an internal mirror
Voice model download	at start	Turn off
Self-update	only when run	Do not run, or point at an internal host

Configuration

Change these sections in the node’s existing config.toml so it talks only to your own infrastructure:

[cluster_options]
cluster_enabled = true
relays = ["https://relay.internal.example"]
include_default_relays = false
n0_discovery = false
public_directory_url = ""
federation_seeds = []

[adblock_options]
enabled = true
blocklist_urls = ["https://mirror.internal.example/easylist.txt"]

[security_options]
block_malicious = true

[[security_options.feeds]]
name = "Internal blocklist"
type = "file"
path = "feeds/internal-domains.txt"
kind = "domain"
category = "custom"

For a node with no mesh at all, set cluster_enabled = false.

kabactl writes its default feeds into config.toml on first run. Remove the public ones, or set enabled = false on each, so only your local feeds remain. Put the feed file under <storage>/security/feeds/ and run kabactl security update.

Environment for the service:

KABA_VOICE_AUTOPROVISION=0     # do not fetch voice models at start
KABA_GEMMA_MIRROR=https://models.internal.example   # where `kabactl get` looks first

[todo: confirm the URL layout KABA_GEMMA_MIRROR expects, and document how to host an internal model mirror.]

Models without a network

On a connected machine:

kabactl get --model e4b

Copy <storage>/kaba-engine/ to the same path on the isolated node. kabactl doctor on the isolated node confirms the files are found. Adapters are plain files under kaba-engine/loras/ and move the same way.

Client settings

On desktops inside the environment:

Setting	Value
Updates → Check for updates automatically	off (the default)
Security & Privacy → DNS over HTTPS	Off, so your internal resolver is used
Security & Privacy → Ad block lists	Remove public lists, or point at a mirror
Desktop widgets	Remove any that fetch from outside services
Enable Memory, Enable Learning Data	Your choice; both are local either way

Network boundary

Because the API and proxy listen on all interfaces, pair the configuration above with a firewall:

• Block inbound 28832 and 28833 from outside the host unless something needs them.
• Allow outbound only to your relay and mirrors.

With those rules in place, a misconfiguration fails closed.

Containment of model-driven work

Isolation from the network is one layer. For work a model performs:

• Set the policy’s Sandbox networking to Off.
• Set Command execution to Ask or Off.
• Install gVisor (runsc) on Linux nodes so the sandbox uses it.
• Turn on Prevent overriding policy settings so projects cannot loosen any of this.

See security.

Verifying

kabactl doctor
kabactl security status
kabactl cluster list

Then watch the node’s outbound connections for a day with your usual network tooling. A correctly isolated node contacts only the hosts you configured.