Omniroute Internal Server Error

[evogix]

Please Fix This Error

[diegosouzapw]

Hey @evogix! Good news from your first screenshot -- the server itself is fine (✔ OmniRoute is running! (started in 11.2s)). The Internal Server Error you see at localhost:20128 is the dashboard page (SSR) throwing -- and the browser only ever shows that generic 500. The real error is printed server-side, in your Termux terminal, not in the browser.

To pinpoint it I need the terminal output:

1. In the Termux window that's running the server, open localhost:20128 again, then scroll the terminal and paste the full output -- especially any line containing Error, DLOPEN, bindings, NODE_MODULE_VERSION, or better-sqlite3. For more detail, restart with APP_LOG_LEVEL=debug npx -y omniroute.
2. Paste node --version and uname -m (your CPU arch).

Heads-up: Termux/Android isn't an officially supported platform. By far the most common cause of a dashboard 500 there is the better-sqlite3 native binary not matching your CPU arch (ARM64/ARMv7) + Node ABI. The usual fix is to install the build toolchain and let it rebuild from source:

pkg install nodejs python build-essential
npx -y omniroute@latest

Full Termux setup + troubleshooting is in docs/guides/TERMUX_GUIDE.md. This is the same root cause we traced in #2890 -- paste the server log above and I'll confirm whether it's the ABI mismatch or something else. (Also worth a quick npx -y omniroute@latest regardless -- you're on 3.8.45 and the latest release has since shipped.)

[evogix]

• Not Resolved

[powellnorma]

You could try looking at the logs.. in your .env define:

APP_LOG_LEVEL=debug
APP_LOG_FILE_PATH=/some/path/app.log

[powellnorma]

Or APP_LOG_LEVEL=debug npx -y omniroute serve --log

[diegosouzapw]

Thanks @powellnorma -- that's exactly the right idea. @evogix, to actually fix this I still need the server-side error text; "Not Resolved" alone doesn't tell me what's throwing. The browser only ever shows the generic Internal Server Error (500); the real stack trace is printed in your Termux terminal.

Please restart with debug logging and paste the output:

APP_LOG_LEVEL=debug npx -y omniroute@latest serve --log

or capture it to a file (as @powellnorma suggested) via .env:

APP_LOG_LEVEL=debug
APP_LOG_FILE_PATH=/some/path/app.log

Then open localhost:20128 once, and paste the lines around the error -- especially anything mentioning better-sqlite3, DLOPEN, bindings, NODE_MODULE_VERSION, or MODULE_NOT_FOUND. Also paste node --version and uname -m.

My strong suspicion is still the better-sqlite3 native-binary/ABI mismatch on Termux/ARM (same root cause as #2890) -- the fix there is pkg install nodejs python build-essential then npx -y omniroute@latest so it rebuilds from source. But I won't guess blindly; the debug log will confirm it in one line. See docs/guides/TERMUX_GUIDE.md for the full Termux setup.

[W8SOJIB]

I fixed the issue and uploaded the complete project to GitHub. If you need to inspect the full source code, you can find it here:

https://github.com/W8SOJIB/W8OmniRouteTermux-Moded

Please review the code and let me know if you find any issues or have suggestions for improvements.

Also, a huge thank you to the original developer for creating this project. This is not my project—I only made some modifications and fixes to support the community. I really appreciate all the work that went into building it.

and install here is Command:

curl -fsSL "https://raw.githubusercontent.com/W8SOJIB/W8OmniRouteTermux-Moded/main/install.sh" | bash

[powellnorma]

"This is not my project—I only made some modifications and fixes to support the community. I really appreciate all the work that went into building it."

Then why not make A PR? That way one can clearly see what changes you have done, and they can be upstreamed.

You directly sharing the install command without mentioning how/what you fixed it seems quite suspicious to me.. Malware?

[W8SOJIB]

CHeck Your Self i Alredy Give Full Project

[diegosouzapw]

Hey @evogix! Still need the actual server-side error to diagnose this -- "Not Resolved" by itself doesn't tell me what's throwing. @powellnorma's suggestion is the right next step:

1. Add to your .env:

   APP_LOG_LEVEL=debug
   APP_LOG_FILE_PATH=/some/path/app.log
   

2. Restart OmniRoute and reproduce the dashboard error at localhost:20128
3. Paste the relevant lines from that log file here (or run APP_LOG_LEVEL=debug npx -y omniroute serve --log and copy what prints to console)

That will tell whether it's a DB/migration issue, a port conflict, or something else on the server side. Without the actual stack trace I can't pin down the fix.

[dimaslanjaka]

same here, internal error after update. the database auto renamed like below

[dimaslanjaka]

here my app log

app.log

[diegosouzapw]

@dimaslanjaka thanks -- your "database auto renamed" + app.log is exactly the signature we need, and it's a different root cause from @evogix's original Termux report. What you're hitting is the DB probe-failed / auto-rename loop: on startup OmniRoute probes storage.sqlite, and if the open fails it renames it to storage.sqlite.probe-failed-<timestamp> to preserve your data (it never deletes it) -- but if the reopen keeps failing it loops, and the dashboard then 500s.

This is a known post-3.8.46 regression cluster -- tracked in #6594, #6628, #6631 and #6802. Common triggers:

• storage.sqlite larger than ~100MB (OOM in the sql.js fallback) -- fix(startup): hangs at startup — probe-failed/restore loop on storage.sqlite > 100MB #6631
• native better-sqlite3 ABI mismatch after the update (DLOPEN / NODE_MODULE_VERSION / Wrong API use) -- fix(startup): Electron desktop v3.8.46 — 500 on every route + probe-failed loop caused by better-sqlite3 'Wrong API use: failed to load connections' #6802

To recover now:

1. Look in your data dir (~/.omniroute or %APPDATA%\omniroute) for storage.sqlite.probe-failed-* files. Several of them confirms the loop.
2. Stop OmniRoute, rename the most recent intact probe-failed-* back to storage.sqlite, restart.
3. Check its size -- if >100MB you're in fix(startup): hangs at startup — probe-failed/restore loop on storage.sqlite > 100MB #6631.
4. If the log mentions better-sqlite3 / DLOPEN / NODE_MODULE_VERSION, reinstall so the native module rebuilds for your Node/Electron.

Could you drop the first ~30 lines your app.log prints around [DB] (especially any Could not probe existing DB: ... line) into #6631? That tells us which trigger you're on, and I'll consolidate there.

---

@evogix -- if you're still stuck, your case is most likely the Termux better-sqlite3 ARM ABI rebuild (pkg install nodejs python build-essential, then npx -y omniroute@latest). Paste the [DB] lines from your terminal and I'll confirm.

[itsBash92]

guyssss i found the soultion finally
simplly just close the termenalor the cmd and search for folder named:
.omniroute
FOR WINDOWS users
method 1:
you can find it "C:\Users\yourusername.omniroute"
method 2:
simply just go to the folder on your desktop that you find the windows main folders system like downloads/videos/pictures...etc

inside that folder you will fine ".omniroute" folder
what did is SHFT+DEL
then i opened the cmd/windows terminal RUN as Administrator
and write
"omnroute"
and hit enter
it will start the server and t wll be running no any issue
and wll open the dash board auto on the browser and it wll show you the logn page
i just had the same problem you had guys and t was as simple as that
LET ME KNOW GUYS F YOU NEEDED HELP OR ANYTHING

[diegosouzapw]

Hey all -- this thread has three different situations mixed together, so let me untangle them.

@itsBash92's fix (deleting the .omniroute folder and reinstalling) does work, but it wipes all your data -- connections, API keys, combos, usage history. It's a reset, not a repair: it resolves the symptom because it discards the corrupted storage.sqlite, not because anything was actually fixed.

@dimaslanjaka's case (the "database auto renamed" + app.log) is the real signature here: this is the post-3.8.46 DB probe-failed/auto-rename loop, already tracked in #6594, #6628, #6631, and #6802. Before nuking .omniroute, check whether you have a storage.sqlite.probe-failed-<timestamp> file sitting next to storage.sqlite -- if so, your original DB was preserved, not deleted, and one of those linked issues has a fix/workaround that doesn't cost you your data.

@W8SOJIB -- please don't run third-party install scripts posted in a discussion without a way to audit what actually changed. A PR against this repo is the right way to contribute a fix, exactly as @powellnorma said, so it can be reviewed line-by-line before anyone pipes it into a shell.

@evogix -- are you still hitting this? If so, the debug-logging steps from earlier in the thread are still what I need to trace your original Termux case, since it may be a different root cause than the DB-rename issue above.

[shuvo4578]

Hi, having the same issue on Termux (Android, aarch64) — and also reproduced on a PC, so it doesn't seem device-specific.
Environment:
OmniRoute v3.8.48
Node v26.4.0
aarch64 (Termux) + also tested on PC, same result
What I've already tried (no change):
Fresh install via npx -y omniroute — 500 on every request
Global install + npm rebuild better-sqlite3 after installing python build-essential — rebuild succeeded, still 500
Renamed ~/.omniroute to start with a completely fresh state — still 500 (so not a corrupted DB/config issue)
APP_LOG_LEVEL=debug npx -y omniroute — no additional output printed anywhere, even while hitting the server with curl
Ran the entry file directly: node --trace-uncaught --trace-warnings bin/omniroute.mjs — still no stack trace in stdout/stderr
NODE_ENV=development node bin/omniroute.mjs — response body is still just the plain text "Internal Server Error", no detail
~/.omniroute/logs/application/app.log exists but is completely empty
Confirmed dist/head-response-guard.cjs is present (the file that was missing in the 3.8.47 hotfix)
curl -I and curl -v both just show HTTP/1.1 500 Internal Server Error with a 21-byte plain text body, no JSON detail
The server itself reports ✔ OmniRoute is running! and starts in ~15s, but every single dashboard/API request returns 500 with absolutely nothing logged anywhere (terminal, log file, or response body). This is blocking me completely — any pointers on where else to look, or is there a way to force a verbose error response body?

[imishbahu-commits]

Good news guys in mobile through termux first show internel server error I got frustrated because everyone set up on pc or laptop not face any issue I only face the issue I am non technical background so fixing this is a very taught job for me I don't know coding or anything so for this I use claude and he told me some thing like creat a ubuntu container or some thing like I told claude to create a force Linus environment in termux and he give me commands like this and I solve the error really I am so happy because last 4 to 5 days through I found the solution 🥳🥳🥳🥳

[imishbahu-commits]

Bro I give you the commands that I paste in the termux.

If you see any issue take a screen short and give to the claude that help you to fix this

Here's the plain-text version — no markdown formatting, so everything (including the commands) copies together as one clean block:

---

Fix for "Internal Server Error" on Termux/Android — confirmed working

The real problem:
OmniRoute uses Next.js, which has a platform check that crashes when it detects Android. You won't see this in the browser (just a generic "Internal Server Error"), but the real error is:

Error: An error occurred while loading instrumentation hook: Unsupported platform: android

The fix — patch the platform check:

1. Install OmniRoute globally (not with npx):

npm install -g omniroute --force

2. Go to the install folder:

cd $(npm root -g)/omniroute

3. Confirm dist/server.js exists:

ls dist

4. Patch the file to force it to report "linux" instead of "android":

echo "Object.defineProperty(process, 'platform', { value: 'linux' });" > patch.js
cat dist/server.js >> patch.js
mv patch.js dist/server.js

5. Run it:

omniroute

The dashboard should now load correctly instead of showing Internal Server Error.

Notes:
Make sure you're on Node 22.x or 24.x, not 20.x — check with node --version. If wrong, run pkg install nodejs (not nodejs-lts, which installs the outdated version).
You'll need to reapply this patch after every reinstall/update, since it edits the compiled file directly.
Credit to the patch idea from issue #3450 — tested and confirmed working end-to-end on a real device.

[imishbahu-commits]

Good news guys in mobile through termux first show internel server error I got frustrated because everyone set up on pc or laptop not face any issue I only face the issue I am non technical background so fixing this is a very taught job for me I don't know coding or anything so for this I use claude and he told me some thing like creat a ubuntu container or some thing like I told claude to create a force Linus environment in termux and he give me commands like this and I solve the error really I am so happy because last 4 to 5 days through I found the solution 🥳🥳🥳🥳

…

On Sat, 25 Jul 2026, 04:09 Shoikat Hossain, ***@***.***> wrote: Hi, having the same issue on Termux (Android, aarch64) — and also reproduced on a PC, so it doesn't seem device-specific. Environment: OmniRoute v3.8.48 Node v26.4.0 aarch64 (Termux) + also tested on PC, same result What I've already tried (no change): Fresh install via npx -y omniroute — 500 on every request Global install + npm rebuild better-sqlite3 after installing python build-essential — rebuild succeeded, still 500 Renamed ~/.omniroute to start with a completely fresh state — still 500 (so not a corrupted DB/config issue) APP_LOG_LEVEL=debug npx -y omniroute — no additional output printed anywhere, even while hitting the server with curl Ran the entry file directly: node --trace-uncaught --trace-warnings bin/omniroute.mjs — still no stack trace in stdout/stderr NODE_ENV=development node bin/omniroute.mjs — response body is still just the plain text "Internal Server Error", no detail ~/.omniroute/logs/application/app.log exists but is completely empty Confirmed dist/head-response-guard.cjs is present (the file that was missing in the 3.8.47 hotfix) curl -I and curl -v both just show HTTP/1.1 500 Internal Server Error with a 21-byte plain text body, no JSON detail The server itself reports ✔ OmniRoute is running! and starts in ~15s, but every single dashboard/API request returns 500 with absolutely nothing logged anywhere (terminal, log file, or response body). This is blocking me completely — any pointers on where else to look, or is there a way to force a verbose error response body? — Reply to this email directly, view it on GitHub <#6573?email_source=notifications&email_token=CFS5727BKC4FA3RB7BOQZFD5GPQSVA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZXG4ZDQOJWUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-17772896>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CFS5725WSL5YHVALPAO26XT5GPQSVAVCNFSNUABJKJSXA33TNF2G64TZHMYTCNJXGEYDEMRYGI5UI2LTMN2XG43JN5XDWMJQGM4DMNRRGGQXMAQ> . You are receiving this because you commented.Message ID: ***@***.*** com>

[diegosouzapw]

@imishbahu-commits -- this is the breakthrough on this thread. That error line (Unsupported platform: android) is what nobody had captured before, and it turned a five-month mystery into a one-line fix. Thank you for pushing through five days of it and coming back to share the commands instead of just walking away.

I traced it to the exact cause, and there is a much simpler fix than patching dist/server.js.

What is actually happening. It is not OmniRoute code -- it is Next.js, in getCacheDirectory():

if (process.platform === 'linux')       { /* XDG_CACHE_HOME || ~/.cache -- no existence check */ }
else if (process.platform === 'darwin') { ... }
else if (process.platform === 'win32')  { ... }
else {
    // un-handled platform: requires the directory to ALREADY EXIST
    for (const dir of [path.join(os.homedir(), '.cache'), path.join(os.tmpdir())]) {
        if (fs.existsSync(dir)) { systemCacheDirectory = dir; break; }
    }
    if (!systemCacheDirectory) { console.error(new Error('Unsupported platform: ' + process.platform)); process.exit(0); }
}

android is not one of the three handled platforms, so it lands in the else branch -- and that branch, unlike the linux one, only accepts a directory that already exists. On Termux, /tmp does not exist (Termux uses $PREFIX/tmp) and ~/.cache may not exist yet on a fresh install. Neither passes, so Next.js exits before the server can serve anything.

The simpler workaround. That branch does check ~/.cache -- so just create it:

mkdir -p ~/.cache

Then start OmniRoute normally. I verified this by simulating the Termux conditions: with both directories missing I reproduced your exact error, and with ~/.cache present it resolves cleanly. The advantage over the dist/server.js patch is that it survives reinstalls and updates -- no reapplying after every npm install -g omniroute.

Your platform-override patch also works, and for the same reason: the linux branch never calls existsSync. It is just more fragile because it edits compiled output.

Tracking. Opened #8519 to fix this properly so nobody has to do either -- the CLI should ensure the cache directory itself on Android. Worth saying plainly: this was already reported in #3450 back in v3.8.15, that issue was closed once the Termux guide was added, but the troubleshooting section for this specific crash never actually made it into the guide. That is on me, and #8519 covers fixing the guide too.

@shuvo4578 -- your report is what made the root cause findable, thank you for the detail. Two things:

1. Try mkdir -p ~/.cache and report back -- your "renamed ~/.omniroute for a fresh state, still 500" fits this perfectly, since the missing directory is ~/.cache, not anything under ~/.omniroute.
2. You mention it also reproduces on a PC. That cannot be this cause, which is Android-specific -- so that is likely a separate problem. If it persists on the PC after the above, please open a dedicated issue with the OS and Node version, and I will triage it on its own.

And you are right that the silent failure is itself a bug: a fatal instrumentation-hook error should never leave an empty app.log and a 21-byte response body. #8519 covers that too.

[imishbahu-commits]

Hi owner in before I am trying to fix this and finally fixed it visit the website dashboard ,enter password setting freetier models to omniroute generate api key cloud ,server all are running and then I set up to hermes but some time after when again I visit the website show server connection error not internel server error both are different when I close the omniroute website tab and again visit show internel server error again the same error can you told me the fix thanks from my heart for creating this amazing website called omniroute ♥️

[imishbahu-commits]

Hi owner I fix the error for a temporary time I visit the dashboard set password select free tier providers cloud , server , all are running and I generate api key and setup with hermes all are working but after sometime when I visit the website a message popup in yellow colour server connection error I clearly mention that server connection error and internel server connection are different when I close the omniroute tab from the chrome and again visit the website show internel server error and I can't reach to the website please help me

…

On Sat, 25 Jul 2026, 09:15 Diego Rodrigues de Sa e Souza, < ***@***.***> wrote: @imishbahu-commits <https://github.com/imishbahu-commits> -- this is the breakthrough on this thread. That error line (Unsupported platform: android) is what nobody had captured before, and it turned a five-month mystery into a one-line fix. Thank you for pushing through five days of it and coming back to share the commands instead of just walking away. I traced it to the exact cause, and *there is a much simpler fix than patching dist/server.js.* *What is actually happening.* It is not OmniRoute code -- it is Next.js, in getCacheDirectory(): if (process.platform === 'linux') { /* XDG_CACHE_HOME || ~/.cache -- no existence check */ }else if (process.platform === 'darwin') { ... }else if (process.platform === 'win32') { ... }else { // un-handled platform: requires the directory to ALREADY EXIST for (const dir of [path.join(os.homedir(), '.cache'), path.join(os.tmpdir())]) { if (fs.existsSync(dir)) { systemCacheDirectory = dir; break; } } if (!systemCacheDirectory) { console.error(new Error('Unsupported platform: ' + process.platform)); process.exit(0); }} android is not one of the three handled platforms, so it lands in the else branch -- and that branch, unlike the linux one, *only accepts a directory that already exists*. On Termux, /tmp does not exist (Termux uses $PREFIX/tmp) and ~/.cache may not exist yet on a fresh install. Neither passes, so Next.js exits before the server can serve anything. *The simpler workaround.* That branch does check ~/.cache -- so just create it: mkdir -p ~/.cache Then start OmniRoute normally. I verified this by simulating the Termux conditions: with both directories missing I reproduced your exact error, and with ~/.cache present it resolves cleanly. The advantage over the dist/server.js patch is that *it survives reinstalls and updates* -- no reapplying after every npm install -g omniroute. Your platform-override patch also works, and for the same reason: the linux branch never calls existsSync. It is just more fragile because it edits compiled output. *Tracking.* Opened *#8519 <#8519>* to fix this properly so nobody has to do either -- the CLI should ensure the cache directory itself on Android. Worth saying plainly: this was already reported in #3450 <#3450> back in v3.8.15, that issue was closed once the Termux guide was added, but the troubleshooting section for *this specific crash* never actually made it into the guide. That is on me, and #8519 <#8519> covers fixing the guide too. ***@***.*** <https://github.com/shuvo4578>* -- your report is what made the root cause findable, thank you for the detail. Two things: 1. Try mkdir -p ~/.cache and report back -- your "renamed ~/.omniroute for a fresh state, still 500" fits this perfectly, since the missing directory is ~/.cache, not anything under ~/.omniroute. 2. You mention it also reproduces *on a PC*. That cannot be this cause, which is Android-specific -- so that is likely a separate problem. If it persists on the PC after the above, please open a dedicated issue with the OS and Node version, and I will triage it on its own. And you are right that the silent failure is itself a bug: a fatal instrumentation-hook error should never leave an empty app.log and a 21-byte response body. #8519 <#8519> covers that too. — Reply to this email directly, view it on GitHub <#6573?email_source=notifications&email_token=CFS5726VWG27SSC63DQJBK35GQUMJA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZXG42TGMJYUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-17775318>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CFS5724C73C3JJ4M7S5MVJL5GQUMJAVCNFSNUABJKJSXA33TNF2G64TZHMYTCNJXGEYDEMRYGI5UI2LTMN2XG43JN5XDWMJQGM4DMNRRGGQXMAQ> . You are receiving this because you were mentioned.Message ID: ***@***.*** com>

[sonnysin805-bit]

Multiple vendored copies of better-sqlite3 ship prebuilt-only binaries for wrong arch — every DB route 500s on Termux/aarch64

Environment:

• Platform: Termux (Android), non-officially-supported
• CPU: aarch64 (ARM64)
• Node.js: v24.17.0 (within supported range >=24.0.0 <25)
• Install method: pnpm install -g omniroute (npm install OOM'd repeatedly on this device; pnpm succeeded)
• OmniRoute version: 3.8.48 (also reproduced on 3.8.44/3.0.0 after downgrade attempt)

Summary:
After a clean install with all native builds properly compiled for aarch64, the server starts fine (✔ OmniRoute is running!) and the dashboard SSR renders correctly. However, every route that touches the database (login, /health, /v1/models, /api/logs/console) returns a generic 500 with no server-side console output, even with APP_LOG_LEVEL=debug, and an empty ~/.omniroute/logs/application/app.log.

Root cause found:
The app bundles at least two separate internal copies of better-sqlite3 under different nested paths inside node_modules/omniroute/app/node_modules/better-sqlite3 (observed versions 12.6.2 and 12.8.0, differing from the top-level dependency's 12.11.1). These vendored copies contain only a prebuilt .node binary compiled for EM_X86_64, with no binding.gyp, src/, or build/ scaffolding — so they cannot be rebuilt for EM_AARCH64 even after installing Python, setting up the android_ndk_path gyp workaround, and confirming the toolchain works (verified working against the top-level better-sqlite3@12.11.1 in the same install).

Error surfaced once dashboard SSR started rendering (after unrelated fixes):

[proxyLogger] Failed to load from DB: dlopen failed: ".../better-sqlite3/build/Release/better_sqlite3.node" is for EM_X86_64 (62) instead of EM_AARCH64 (183)
[Middleware] settings_error: Settings read failed: dlopen failed: ...same...
[AUTH] Login failed: TypeError: Cannot read properties of undefined (reading 'safeParse')

What I tried:

1. Confirmed Node version, aarch64, correct pnpm-based build of the top-level better-sqlite3 (gyp info ok)
2. Manually copied the working built copy over one broken vendored copy → dashboard started rendering, but login still failed pointing at a second, differently-versioned vendored copy
3. Attempted node-gyp rebuild directly inside that second copy → same failure, no binding.gyp present

Ask: Could the build/packaging process either (a) dedupe to a single better-sqlite3 instance across the app bundle, or (b) include full source (or platform-appropriate prebuilds for arm64/android) in all vendored copies rather than an x86_64-only binary? Happy to provide full logs/paths if usefull

[diegosouzapw]

@sonnysin805-bit — excellent root-cause analysis. You nailed the exact problem: vendored copies of better-sqlite3 ship with x86_64-only prebuilt binaries, and they lack the binding.gyp/src/ scaffolding needed to rebuild for aarch64.

This is a packaging issue, not an OmniRoute code bug. The fix needs to happen at the build/packaging level.

Short-term workaround (for anyone hitting this now): after pnpm install -g omniroute, manually replace the vendored x86_64 .node binaries with the one you built for the top-level better-sqlite3@12.11.1:

# Find all vendored copies
find ~/.nvm/versions/node/*/lib/node_modules/omniroute -name "better_sqlite3.node" -path "*/build/Release/*"
# Replace each with the working aarch64 build
cp <top-level-working-copy>/better_sqlite3.node <each-vendored-path>/build/Release/

(You mentioned this only partially worked because of a second differently-versioned copy — the find above should catch ALL of them.)

Proper fix — I have opened #8669 to track: the packaging process should either (a) dedupe to a single better-sqlite3 instance, or (b) include platform-appropriate prebuilds for arm64/android in all vendored copies. The pnpm install OOM you hit with npm is also worth investigating — that suggests the install graph is heavier than it should be.

Thanks for the detailed report — this is the kind of issue that is invisible on x86_64 dev machines and only surfaces on ARM devices.

[dedsec1121fk]

For Termux issues like this, I would debug the environment in layers instead of repeatedly reinstalling things:

1. Confirm the architecture with uname -m
2. Confirm the Node version with node --version
3. Capture the actual server-side error from the Termux terminal
4. Check whether the failing dependency contains a native binary built for a different ABI/architecture
5. Only then rebuild or reinstall the affected dependency

The browser's 500 page usually isn't enough to diagnose the actual failure.

I maintain a Termux-focused project and troubleshooting resource called DedSec, where I use the same "identify the failing layer first" approach:

https://github.com/dedsec1121fk/DedSec

Hope this helps narrow it down before another full reinstall.

[diegosouzapw]

Hey @evogix, thanks for holding this thread together with real error reports.

I still need one concrete artifact from your setup before I can close this for your case:

1. APP_LOG_LEVEL=debug APP_LOG_FILE_PATH=/tmp/app.log npx -y omniroute@latest serve --log
2. Reproduce the 500 at localhost:20128
3. Share the exact server-side error block (stack + first thrown message)
4. Include uname -m and node --version

For Termux/desktop mixed errors we already validated these likely roots: better-sqlite3 binary mismatch and Android startup path issues. If your log maps to one of those, I will send a one-shot remediation right away.

Reference: docs/guides/TROUBLESHOOTING.md