Agent index (llms.txt) — fetch this first, then the page it names.

Hardening checklist

The reasons are on Security model and Secrets and keys. This page is what to check on a node you operate, with the command for each, and what the installer already does for you.

Run these on the node (orama ssh <ip>), as root or with sudo. Most are also watched by orama status, which raises an alert when one drifts.

What the installer sets up

You do not configure these. Install and upgrade write them, and orama status warns if they drift.

AreaWhat is in place
NetworkFirewall ufw with only 22, 53 (nameservers), 80, 443, 51820/udp, plus TURN ports when WebRTC is on; the mesh admitted on wg0 only; IPv6 disabled system-wide; every Orama rule tagged orama
ListenersRQLite, Olric, gateways, pub/sub, Kubo and IPFS Cluster on loopback or the WireGuard address only
AuthenticationRQLite always started with -auth (a missing auth file refuses to start); every internal endpoint requires an overlay source address and a MAC made from the cluster secret. Coordination stamps (v3) bind the method, path, body, a nonce and the destination port, so a stamp for the index gateway is no good at a namespace gateway on the same node; node-api and ACME stamps carry a single-use nonce that the receiver remembers for two minutes. Stamps from the previous release (v2, un-nonced) are still accepted for one release during a rolling upgrade, and a captured one can be replayed once inside that window
VaultGuardians require a session token and an Ed25519 ownership signature on every share read and write, and the guardian port is reachable only over WireGuard (Vault guardians)
AccountsServices as orama (CoreDNS as orama-coredns, the SFU as orama-sfu, Tor as debian-tor, ntfy as ntfy); /opt/orama/bin is root:orama 0750
systemdProtectSystem=strict, NoNewPrivileges, PrivateDevices and more on the namespace units
MemoryMemorySwapMax=0 on secret-bearing units, swap off, suid core dumps off, core dumps discarded, apport masked, kernel.yama.ptrace_scope=1
SoftwareArchives verified against /etc/orama/archive-signers before anything is installed

Verify

The firewall and listeners

bash
sudo ufw status verbose            # only the ports above, rules tagged "orama"
sudo ss -tlnup                     # nothing from Orama listens on 0.0.0.0 except 80, 443, 53, 22, 51820

Anything else on a public interface is a finding. Rules without the orama comment are yours; Orama never removes them. Do not add rules for the internal ports (10000 and up).

The mesh

bash
sudo wg show wg0                   # one peer per other node, recent handshakes
orama status mesh --env <env>     # from your computer: peers against the N-1 a full mesh needs

The archive trust anchor

bash
cat /etc/orama/archive-signers     # one lowercase 0x address per line: yours, and only yours
ls -l /etc/orama/archive-signers   # root:root 0644, in a root-only directory

A signer you do not recognise means someone with the old signer's key rotated the list (Build and sign).

Secrets and keys

bash
sudo ls -l /opt/orama/.orama/secrets/          # cluster-secret, rqlite-password, rqlite-auth.json, api-key-hmac-secret, node-key.pem: mode 0600
sudo ls -ld /var/lib/orama-gateway-keys/index  # root, 0400 files
sudo ls -l /etc/wireguard/wg0.conf             # 0600
SecretPurpose
cluster-secretCluster identity; the root for MAC keys and the IPFS Cluster private network
rqlite-password, rqlite-auth.jsonHTTP and Raft access to every RQLite. rqlited requires them
api-key-hmac-secretHMAC key for API key hashing
node-key.pemThis node's Ed25519 identity key

These are generated at genesis and delivered to joining nodes in the encrypted join response. A disk snapshot of an Ubuntu node exposes them. Treat the node's disk like a credential, and never copy a secret off a node or paste one into a ticket.

Memory hygiene

bash
sysctl fs.suid_dumpable kernel.core_pattern kernel.yama.ptrace_scope net.ipv6.conf.all.disable_ipv6
# fs.suid_dumpable = 0, kernel.core_pattern = |/bin/false, kernel.yama.ptrace_scope = 1, disable_ipv6 = 1
swapon --show                      # nothing
systemctl is-enabled apport        # masked

Tor

bash
sudo orama node status             # orama-namespace-tor@index active
sudo ss -tlnp | grep 9050          # bound on 127.0.0.1 only

Certificates and DNS

bash
orama status dns --env <env>      # certificate days left, resolution

Time

Clocks must agree: the certificate store's lease, MACs (one minute either side), join tickets (30 seconds) and Raft all depend on it. Every node should run NTP; orama status warns above 5 seconds of skew and goes critical above 60.

Habits that keep a cluster safe

  • +Never fix a node by hand. Fix in source, test, then roll out a signed archive. A hand edit is lost on the next deployment and invisible to the audit trail.
  • +Roll out signed archives only, with orama maint rollout, one node at a time (Upgrades).
  • +Use the CLI, not systemctl, on nodes. The CLI checks quorum and ordering.
  • +Keep the RootWallet account that signs archives offline-safe. Its recovery phrase is the cluster's upgrade key. Rotate signers with two builds when a key may be exposed.
  • +Rotate the index gateway signing key after upgrading from 0.122.x, and orama maint operator rotate-secrets --rotate after any suspicion that a node's disk was read (Cluster administration).
  • +Run orama maint operator rotate-secrets once every gateway is upgraded. A deployment's environment is sealed to its namespace and deployment id (enc:v2), so a ciphertext copied onto another row does not open. A cluster created on this release has that from its first row; an upgraded cluster keeps writing the unbound form, because a gateway from before the change cannot open enc:v2, until rotate-secrets turns bound writes on.
  • +Back up the registry and test a restore (Upgrades).
  • +Remove nodes properly. orama node remove revokes the node's key at once; wipe does not tell the cluster anything.

When a node is suspect

  1. +orama node remove --env <env> --node <ip> from your computer (it checks quorum first).
  2. +Rotate secrets: orama maint operator rotate-secrets --rotate and orama maint operator rotate-signing-key.
  3. +Wipe the machine, and treat its disk as compromised (Wipe a node).
  4. +If the cluster secret itself may be known, plan a full rebuild: rotating the cluster secret and WireGuard keys has no tooling and needs a maintenance window.

Known gaps to plan around

  • +Ubuntu node operators have root and SSH. Admit operators you trust, or wait for OramaOS.
  • +Disk encryption on Ubuntu nodes is a design only.
  • +ntfy has no auth file (loopback is the control); Olric memberlist is not encrypted (WireGuard is the control).
  • +WireGuard key rotation and cluster-secret rotation are manual.
  • +See the full list on Security model.