One box.
Everyone's own AI.
Shared AI usually means shared memories — you ask about your meeting notes and get somebody else's deploy script. UPtrim keeps every person completely separate: their own memories, their own files, their own settings, their own budget. Nobody has to log into anything new, and nothing in your chat app has to change.
How it knows who's talking
Three things happen on every single message, before the model sees a token.
Resolve
UPtrim works down a five-source priority ladder until one of them names a user. Your chat app already sends this — nobody has to create another account.
Decide
Your identity mode says what happens when nothing on the ladder matches: block it, sandbox it, or fall back. The default is strict.
Load
That person's memories, files, budget and preferences come into the request. Nothing belonging to anyone else does.
ENABLE_FORWARD_USER_INFO_HEADERS=true in its environment. Without it Open WebUI never says who the user is, everyone lands in one pool, and this is comfortably the most common setup problem we see.Behind a reverse proxy, add its address to trusted_proxies — only listed addresses are allowed to identify users. Forwarded headers are checked for spoofing, and a request that arrived through a tunnel is never mistaken for a local one.
What happens to strangers
Four identity modes. Strict is the default, and it's the right one for almost everybody.
Strict
No valid identity, no request. Spoofing checks on, IP fallback off.
ships this way Click to learn moreRequired
Identity must be present or the request is blocked. Clear errors when it isn't.
middle ground Click to learn moreQuarantine
Strangers get the model but no memory — reads and writes both blocked.
guest-friendly Click to learn moreLegacy
IP-based fallback for single-user boxes. Unsafe behind a tunnel — and we say so in the settings.
compatibility Click to learn moreSeparately from identity, a security mode sets the overall posture: auto adjusts to how the proxy is reached and is the recommended setting, local_only keeps it to your own machine, and open is for when you have already put your own authentication in front. The admin dashboard is behind a password either way — salted PBKDF2, required even from localhost, no bypass.
Hard boundaries
Isolation isn't a filter applied at the end. Memories, uploads, conversations and settings are scoped to a user for their whole life, from the moment a fact is extracted.
- Facts learned from your chats are only ever stored under you
- No user can read or write another user's memories or files
- Uploads land in per-user folders — sharing a folder is a deliberate act
- Every user gets their own
/my-memorypage to view, pin, edit, rate or delete what's stored about them
Everyone keeps their own app
Several people can be mid-conversation at once, from different frontends, without touching each other. And when a group genuinely should share context, that's a team pool rather than an accident.
- Concurrent users across Open WebUI, SillyTavern, n8n, or any OpenAI-compatible client
- Nothing to install or configure inside the chat apps themselves
- Self-registration with optional invite codes, or create accounts from the dashboard
- Shared team memory pools with roles LIVE
- Account linking joins the same human arriving from different sources
What the operator gets
All of it from the dashboard. Nearly every setting applies live on save — the few that need a restart say so, and the save result tells you truthfully what took effect.
Users & what they've stored LIVE
Every user, their memory counts, their activity, their live usage against budget. Create accounts or let people self-register with an invite code. Review, export or delete anything.
Click to learn moreFair queues under load ONE SWITCH AWAY
Real per-backend queues with priority classes and per-user fairness, and an honest “queued #2” instead of a spinner. Preparation keeps running while you wait for a slot.
Click to learn moreScale profiles LIVE
home / team / business size ten interacting caps in one move — 40, 150 or 400 concurrent requests, with matching rate limits and queue depth. Blank means auto from your licence.
Click to learn moreBudgets that actually hold.
A shared family AI needs limits enforced somewhere a clever fourteen-year-old can't reach. UPtrim enforces them at the proxy, on its own page at /usage-dashboard: token budgets by day, week and month, timezone-aware allowed hours, and child accounts that can ask for more without being handed the keys.
Access schedules LIVE
Allowed hours per weekday, in the user's timezone rather than the server's. Enforced at the proxy, so there's no toggling anything inside the chat app and nothing to uninstall around.
Token budgets ONE SWITCH AWAY
Daily, weekly and monthly, as a global default with per-user overrides. Budgets are checked at request time and fail with an honest message. At 80% the proxy warns and starts trimming — research off, shorter context — rather than stopping dead at 100%.
Ask, don't beg LIVE
A child who runs out asks for more from inside the chat — no new app, no interrupting anyone. The request appears on the parent's dashboard, and unanswered ones expire on their own after thirty minutes.
The PIN LIVE
Approvals need the parent PIN. It's never displayed anywhere, it's compared in constant time, and it's masked out of every config API response. Approval rights are checked server-side against the real parent-child link, so a child can't approve their own request from a modified client.
Your family's AI, on your couch. No screenshots uploaded. No parents' portal in the cloud. Every rule, every chat, every memory stays on the box you already own.
Grants are capped and expire — a parent approving “a bit more” is not handing over the budget permanently. Budget tracking ships switched off, because most single-person installs have no use for it. Turning it on is not really a two-step job either: set any per-user budget above zero and enforcement arms itself, so there is no way to set a limit and then discover it was never enforced.
Several proxies.
One memory.
Once you outgrow one machine, the obvious move — run a second proxy — is also the move that quietly forks your memory into two corpora that slowly disagree. The fleet exists so that never happens. One master owns the database. Every worker funnels its reads and writes through it.
The corpus can't fork
Every id is a master id. Deduplication and contradiction resolution run once, in one place, over one set of facts. Reads are cached with bounded staleness, so workers stay fast without inventing their own truth.
Outages degrade in the open
If the master goes away, workers serve stale reads while they can, then fail honestly and journal what they couldn't write. What they never do is write locally and pretend — a silent local fork is the one failure mode there's no coming back from.
Workers never hold a key
A worker boots keyless and receives an HMAC-signed grant from the master. Seats are tracked and capped against your licence. There is no key to leak on the GPU box, and no key to rotate on ten of them.
One place to administer
Users and settings replicate down automatically — manage both on the master, and workers refuse identity edits with a clear error rather than diverging. One admin password for the whole cluster. Roles flip live from the dashboard's Fleet panel, without a restart, and the save result says exactly what took effect.
Before you ask us for one, the honest part
- Fleet transport is plain HTTP unless you terminate TLS yourself. A custom CA is supported via
memory_service_ca_file. Run it on a trusted network or put TLS in front — the proxy warns loudly either way rather than pretending the hop is safe. - Master and workers must run the same build. Upgrades are atomic across the cluster, not rolling. Plan a window.
- It ships dormant.
node_roleisstandaloneout of the box, and nothing about fleet behaviour happens until you deliberately choose otherwise. - Run the master on the machine that physically holds the database. SQLite over a network share is a corruption story, not a deployment.