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.
Every module runs inside the server process, with the server's disk and network position, so an ordinary User account is kept to settings that only affect its own chats:
- Paths, URLs, and models not downloaded yet are administrator-only. A user is not shown those fields, and a value posted anyway is discarded. A model nobody downloaded fails with a message to ask the administrator to install it, rather than being fetched.
- Some modules are administrator-only as a whole — the ones that are only a URL or a program on the machine, such as OpenAI Compatible, Claude Code and the local AI engines. Workspace (working folders, the shell, disk tools) is only set up on administrator accounts. Discord Bot can be added by administrators and by shared accounts.
- A module a user already had before it became administrator-only keeps working. Only adding one is gated.
An administrator's API keys run on the configuration that administrator saved, but cannot change an administrator-only field.
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.