Voxta Network exposure
What changes when Voxta is reachable from something other than the machine it runs on.
By default Voxta listens on loopback: only the machine it runs on can reach it. Binding it to your network — to use it from a phone, a headset, another PC — changes the threat model, and none of the local protections apply to it.
Nothing in Accounts & access protects a server you deliberately exposed. Hardening the loopback path and then binding to 0.0.0.0 is locking the inner door and leaving the front one open.
Before you expose it
- Set an account password. The passwordless grant is meant for a machine you are sitting at.
- Turn on encryption. It does not stop a live intruder, but it decides what a copy of the files is worth.
- Give every client an API key rather than relying on anything ambient.
- Prefer a VPN or an SSH tunnel to opening a port. Voxta serves plain HTTP unless you put something in front of it, so anything on the path can read a conversation.
- Never expose it to the internet without a reverse proxy terminating TLS and something in front of the login.
Network restrictions
Some deployments run with network restrictions enabled, which blocks the features that write to the shared Data folder — prompt formatting templates and similar — because those affect every user on that server rather than just the one changing them.
You will see the affected controls disabled rather than missing.
Multi-user servers
Encryption is what makes one account's content unreadable to another at rest, so on any server with more than one person on it, treat it as required rather than optional.
Remember that a running server holds unlocked content in memory and sends it to whatever providers are configured. Whoever administers the machine can see what passes through it.