-
Notifications
You must be signed in to change notification settings - Fork 0
3 Manage
The install page got her running. This page is everything after that: starting and stopping her, reading logs, changing the model, handling accounts, backups and updates.
Everything here assumes the install folder is called JunOS and sits in the folder your terminal opens in (your home folder on Linux, C:\Users\YourName on Windows). If you put her somewhere else, cd there first.
| I want to | Go to |
|---|---|
| Start, stop, restart her | Everyday commands |
| See what's wrong | Logs and Is she healthy? |
| Change a setting | Changing a setting |
| Give her a bigger/smaller brain | Swapping the model |
| Add or remove people | Accounts |
| Get back in after forgetting a password | Forgot your password |
| Keep my chats safe | Backups |
| Get the newest version | Updating |
Two very different layouts, because Linux runs her in Docker and Windows doesn't.
| What | Where |
|---|---|
Code, .env, start.sh
|
the JunOS folder |
| Accounts, chats, memories, settings | Docker volume omega_omega_state, mounted at /var/lib/omega inside the php container (the database is omega.sqlite, her notes are in memory/) |
| Downloaded model weights | Docker volume omega_ollama_data
|
| Logs | inside the containers, read with ./JunOS/start.sh logs
|
The omega_ prefix is the Compose project name (name: omega in docker-compose.yml), so the volumes are called that whatever you named the install folder. docker volume ls lists them.
The important consequence: deleting the JunOS folder does not delete your chats. They sit in the volumes and a reinstall picks them straight back up. That's uninstall's problem, not this page's.
Everything is inside the JunOS folder.
| What | Where |
|---|---|
Code, .env, start.ps1
|
JunOS\ |
| Accounts, chats, memories, settings |
JunOS\runtime\state\ (the database is omega.sqlite, her notes are in memory\) |
| Downloaded model weights | JunOS\runtime\ollama-models\ |
| Logs | JunOS\runtime\logs\ |
| Portable PHP | JunOS\runtime\php\ |
| Which processes she started | JunOS\runtime\pids.json |
Deleting the JunOS folder on Windows does take the chats and the weights with it. Back up first if you care: Backups.
Run these from the folder above JunOS:
| What | Command |
|---|---|
| Start | ./JunOS/start.sh |
| Stop | ./JunOS/start.sh stop |
Restart (after editing .env) |
./JunOS/start.sh restart |
| What's running | ./JunOS/start.sh status |
| Follow all logs | ./JunOS/start.sh logs |
| Follow one service's logs | ./JunOS/start.sh logs ollama |
restart rebuilds the containers before bringing them back up, so it's also what you run after pulling new code by hand.
If you said no to the docker group during the install, every one of those needs sudo in front.
Every start prints which card she landed on:
ollama is running on:
NVIDIA GeForce RTX 3060 (cuda, 12.0 GiB)
If the second line says CPU. no GPU at all, ollama gave up on the card and you have one, see NVIDIA or AMD.
Anything you type after the subcommand is passed to Docker Compose untouched, so ./JunOS/start.sh logs --tail 50 php works, and a bare ./JunOS/start.sh --build php rebuilds just the web container.
Forcing a backend. She auto-detects the card. To override for one run:
GPU=cpu ./JunOS/start.sh # also: GPU=nvidia, GPU=amdRun these from the folder above JunOS:
| What | Command |
|---|---|
| Start | powershell .\JunOS\start.ps1 |
| Start without opening the browser | powershell .\JunOS\start.ps1 -NoBrowser |
| Stop | powershell .\JunOS\start.ps1 stop |
| What's running | powershell .\JunOS\start.ps1 status |
There is no restart on Windows. Run stop, then start her again. (Starting her twice in a row mostly works: the web server and the memory worker get replaced, and an Ollama that's already up is reused. stop first is the version that always does what you meant.)
status prints one line per service and then pokes the web UI:
▸ service status
✓ php running (pid 18244)
✓ memory running (pid 18250)
✓ tts running (pid 18260)
✓ ollama running (pid 17012)
✓ web UI http://127.0.0.1:8080
memory is the background worker that tidies chats into long-term memories. llamacpp only shows up if you switched provider.
Linux: ./JunOS/start.sh logs <service>, Ctrl + C to stop watching. The services are nginx, php, ollama, tts, karaoke, and llamacpp / certbot if you use them.
Windows: plain text files in JunOS\runtime\logs\, two per service, <name>.log for normal output and <name>.err.log for errors. The names are php, memory, tts, ollama, llamacpp. Open them in Notepad, or tail one live:
Get-Content .\JunOS\runtime\logs\php.err.log -Wait -Tail 50Which one do you want? ollama (or llamacpp) for anything about the model - downloads, out-of-memory, it running on the CPU when it shouldn't. php for the app itself - login, chat, memory, settings. tts for the voice. karaoke for song splitting.
When you open an issue, the last ~50 lines of the relevant one is what we need.
Every knob lives in JunOS/.env. The full list of what each one does is on the Settings page and in docs/configuration.md. The mechanics are the same for all of them:
- Open
JunOS/.envin a text editor (nano JunOS/.envon Linux: edit, Ctrl + O, Enter, Ctrl + X). - Edit or add the line. One
KEY=valueper line, no spaces around the=, no quotes needed. - Restart her:
./JunOS/start.sh restarton Linux,stopthen start on Windows.
Nothing in .env is read while she's running, so a change that "did nothing" is almost always a missed restart.
A few that matter for day-to-day running:
| Line | What it does |
|---|---|
VOICE=off |
no speech. Stops the TTS service from starting at all |
KARAOKE=off |
no song splitting. On Linux this also skips building a large container image |
FLEE_BANS=off |
she can no longer time you out for being awful to her, see She walked out on me |
FREE_ROAM=on |
she no longer decides when you go out, every account gets the Force her buttons, see Dates |
OMEGA_NUM_CTX= |
how much conversation she keeps in her head. Bigger costs VRAM |
BIND_ADDR=0.0.0.0 |
let other devices on your wifi reach her. Needs OMEGA_ALLOW_INSECURE_PUBLIC_HTTP=1 too, and read the warning on the install page first |
.env holds your registration key and, if you use OpenRouter, an API key. Keep it to chmod 600 on Linux (the installer does this) and don't paste it into an issue.
The model she thinks with is OLLAMA_MODELS_TO_PULL= in .env. Pick a name from the table on the install page, put it in, restart. The new weights download on that start - watch ./JunOS/start.sh logs ollama (Linux) or JunOS\runtime\logs\ollama.log (Windows), because the first start with a new model is a 2-12 GB download and she won't answer until it lands.
The names all look like this:
OLLAMA_MODELS_TO_PULL=hf.co/efficiencyx/Jun-LoRA-E4B-GGUF:Q6_K
E2B is the small one, E4B the middle, 12B the big one. The :Q4_K_M / :Q6_K / :Q8_0 suffix is how much precision is kept, higher is smarter but heavier.
The old model is not deleted. The picker in the app's settings lists everything installed, so you can switch between pulled models without touching .env at all - .env only decides what gets downloaded and what she starts on.
Getting rid of a model you don't want any more:
docker exec omega-ollama ollama rm hf.co/efficiencyx/Jun-LoRA-12B-GGUF:Q8_0 # Linux$env:OLLAMA_MODELS = "$PWD\JunOS\runtime\ollama-models" # Windows
ollama rm hf.co/efficiencyx/Jun-LoRA-12B-GGUF:Q8_0That first line matters on Windows: start.ps1 keeps her weights inside the install folder rather than in Ollama's usual store, so a bare ollama rm would go looking in the wrong place and tell you the model isn't there.
If she answers slowly after a swap, she probably didn't fit on the card: see Is she healthy?.
The first account on a fresh install signs up with no key. Every account after that needs the key the installer generated and printed at the end. It lives in .env:
OMEGA_REGISTRATION_KEY=a1b2c3d4e5f6...
Hand that to the people you want to let in. Changing it is a normal .env edit plus a restart, and it locks out nobody who already has an account - the key only guards signup.
Opening signup to anyone who can reach her: set the line to nothing.
OMEGA_REGISTRATION_KEY=
Keep the empty line there. An empty value is read as "you meant this", and updates leave it alone; delete the line and the next install run generates a fresh key and quietly closes signup again.
Only do this if she's bound to 127.0.0.1, or you trust everyone on your network. It's not a password.
On the login screen press forgot password?, then type the account's email, its recovery code and a new password. The chats and memories stay, you're signed out everywhere else, and the same recovery code keeps working afterwards. Five tries an hour, then it makes you wait.
The recovery code is shown once at signup (older accounts got theirs on the first login after the encryption update). Lost both the password and the code? Then that account's chats and memory can't be opened any more. Not by you, not by an admin, not from a backup. The only way forward is a new account.
Do not reset a password by editing the database. The password also unlocks the account's encryption key, so a password written straight into the users table lets the login through the first check and then fails with "Your data key would not open. Use your recovery code." Use the recovery code instead.
There's no admin screen for this, on purpose - it's a one-user-per-house program. You do it in the database.
Linux - list who exists:
docker exec -i omega-php php -r 'foreach ((new PDO("sqlite:/var/lib/omega/omega.sqlite"))->query("SELECT id, email, role FROM users") as $u) echo "$u[id] $u[email] $u[role]\n";'Windows - same thing, from the folder above JunOS:
.\JunOS\runtime\php\php.exe -r 'foreach ((new PDO("sqlite:JunOS/runtime/state/omega.sqlite"))->query("SELECT id, email, role FROM users") as $u) echo "$u[id] $u[email] $u[role]\n";'Removing someone by the id the listing printed:
docker exec -i omega-php php -r 'echo (new PDO("sqlite:/var/lib/omega/omega.sqlite"))->exec("DELETE FROM users WHERE id = 3"), " row(s)\n";'On Windows it's the same line with .\JunOS\runtime\php\php.exe -r in front of the quoted code and sqlite:JunOS/runtime/state/omega.sqlite as the path.
Two warnings. Take a backup before anything with the word DELETE in it. And deleting the user leaves their conversations and memory files behind, orphaned to a user id nobody holds any more (still encrypted, so nobody can read them either) - if you want those gone too, sign in as them and run Factory Reset first, then delete the account.
On Windows, stop her before writing to the database, so the web server and the memory worker aren't holding it open. On Linux the docker exec goes through the same container the app runs in, so it's safe while she's up.
In the app: Settings > Account > Factory Reset. It erases every conversation, memory, relationship score, wardrobe preset and preference belonging to the account you're signed in as, and signs out your other sessions. The account and the password survive. Other accounts are untouched.
There is no undo. Back up first if you might want it back.
Should i even mention this if i want this to be secret? Well you ventured into the wiki and read all the yap before this so i think you deserve it. here you go: Admin is a hidden role that unlocks the developer panel, the on-screen stats HUD, mood editing, her status pill and the reset-pose button in the top bar, the Force her buttons in Dates, and the dataset review tool (SIKE! that's for my testers only!). It's off unless you deliberately turn it on.
-
Add a key of your choosing to
.env, then restart:OMEGA_DEV_KEY=whatever-you-like -
In the app, open Settings and tap the word About seven times. A "Developer access" row appears.
-
Paste the key, press Unlock. The page reloads with the developer tab visible.
Without OMEGA_DEV_KEY in .env the unlock is refused no matter what you type. Five wrong tries an hour and it stops answering for a while.
Jun can end a conversation and refuse to talk for a bit. It's deliberate. The lockout starts at 5 minutes and doubles each time it happens, capped at 30. A day without one resets the counter. history, settings and the rest of the app keep working the whole time if you decide to rip the lockout screen.
If you'd rather she couldn't: FLEE_BANS=off in .env, then restart. Clearing one by hand means deleting your row from the user_bans table, which is more work than waiting 5 minutes.
The whole of her - accounts, chats, memories, relationship state, wardrobe - is one folder: the SQLite database plus her memory notes next to it. The commands below copy the whole folder. Model weights are not worth backing up; they re-download.
Linux, with her stopped:
./JunOS/start.sh stop
docker run --rm -v omega_omega_state:/state -v "$PWD":/out alpine \
tar czf /out/junos-backup.tar.gz -C /state .
./JunOS/start.shRestoring, into an install that's stopped:
docker run --rm -v omega_omega_state:/state -v "$PWD":/in alpine \
sh -c 'rm -rf /state/* && tar xzf /in/junos-backup.tar.gz -C /state'Windows, with her stopped, copy the folder:
powershell .\JunOS\start.ps1 stop
Copy-Item .\JunOS\runtime\state -Destination .\junos-backup -RecurseRestore by copying it back over JunOS\runtime\state.
Copying the database while she's running can catch a half-written write. Stop her first, it takes four seconds.
And the boring reminder: chats and memories inside the backup are encrypted, but only with a key your password or recovery code unlocks. The backup is useless without one of them, so keep the recovery code somewhere safe (not in the same place as the backup). Emails, relationship scores and the wardrobe are stored unencrypted, and a backup made before the encryption update is plain readable text. Store it like you'd store a diary.
Run the same one-liner you installed with. It finds the existing folder, pulls the newest code into it, and restarts her. Your .env, your accounts and your chats are kept.
Linux:
curl -fsSL https://raw.githubusercontent.com/efficiencyx/JunOS/main/install.sh | bashWindows:
powershell irm https://raw.githubusercontent.com/efficiencyx/JunOS/main/install.ps1 -OutFile install.ps1; powershell -ExecutionPolicy Bypass -File .\install.ps1It runs from wherever you are - inside the JunOS folder or in the folder above it, both work, it walks up looking for the install before it considers cloning a second one.
If it says it couldn't fast-forward, you have local edits or a branch of your own, and it keeps the code that's on disk rather than stomping on it. Sort the git state out yourself and re-run:
git -C JunOS statusUpdates never rewrite an .env value you set. New settings arrive commented out in .env.example, so it's worth a look after a big update to see what's new.
Three questions, in order.
1. Are the services up? ./JunOS/start.sh status / powershell .\JunOS\start.ps1 status. Anything missing, go read that service's log.
2. Is she on the graphics card? Send her a message first so the model is loaded, then:
docker exec omega-ollama ollama ps # Linux
ollama ps # Windows, in a new terminal100% GPU in the PROCESSOR column is what you want. 73% GPU or 100% CPU means the model didn't fit and the rest is running on the processor, which is why she's slow. Either pick a smaller row from the model table or close whatever else is eating VRAM.
3. Is the web UI answering? https://localhost on Linux, http://127.0.0.1:8080 on Windows. The first reply after a start is always slow - the model is being loaded into the card. The second one tells you the truth about her speed.
For the specific "she's slow and I want her faster" conversation, see Performance.
She's four moving parts and you don't have to run them all. Each is one line in .env plus a restart.
| Line | What you lose | What you get back |
|---|---|---|
VOICE=off |
she stops speaking, text only | a few hundred MB of RAM, a faster start |
KARAOKE=off |
singing with jun | on Linux, a large image is never built |
AI_PROVIDER=openrouter |
she stops being local | your card does nothing, but read SECURITY.md first |
Turning something back on is the same line and another restart. KARAOKE=on on Linux will rebuild the image it skipped, so give that start a few minutes.