Self-hosted: Frontend assets fail to load after update due to stale node process (deleted binary)

[prasana-k]

Describe the bug

After updating infisical-core on a self-hosted Linux installation, the frontend loads a blank page. The Node process continues running with the old binary (marked as deleted in /proc/<pid>/exe), but serves the new index.html which references updated asset filenames (hashed). Since the old process doesn't have access to the new assets, all CSS/JS requests return text/html (the SPA fallback), causing a blank UI.

To Reproduce

1. Self-host infisical-core on Ubuntu (runit/runsvdir managed)
2. Update infisical-core to a new version
3. Do NOT restart the service after update
4. Navigate to the Infisical web UI — page is blank

Expected behavior

Either the update process automatically restarts the service, or the documentation explicitly states that sudo systemctl restart infisical-runsvdir is required after every update.

Screenshots

Blank white page with browser console errors:

• Refused to apply style from '.../assets/index-*.css' because MIME type is 'application/json'
• Failed to load resource: 404 for JS bundle

Platform you are having the issue on:

• Self-hosted (bare metal / infisical-core standalone package)
• Ubuntu 24.04
• Service manager: systemd → runsvdir (infisical-runsvdir.service)
• Nginx reverse proxy in front

Fix

sudo systemctl restart infisical-runsvdir

Suggested improvement

The update script / installer should automatically restart infisical-runsvdir after replacing binaries, similar to how package managers handle service restarts post-upgrade.

[linear]

ENG-4907

[Ingole712521]

This seems to be caused by the service not being restarted after updating infisical-core.

After the update, the running Node process still uses the old (now deleted) binary, while serving the new index.html that references updated hashed assets. Since the old process doesn’t have those assets, requests fall back to index.html, resulting in incorrect MIME types and a blank UI.

Confirmed that restarting the service fixes it:

sudo systemctl restart infisical-runsvdir

It would be helpful if the update process either:

• automatically restarts infisical-runsvdir, or
• clearly documents that a manual restart is required after updates

Right now it fails silently with a blank page, which makes it a bit confusing to debug.

[akhilmhdh]

HI @Ingole712521

After installing the new version - did you do infisical-ctl reconfigure? Even after this - you have do the restart?

[akhilmhdh]

Hi @Ingole712521 ,

Just checking back on this?

[prasana-k]

Yes, I ran sudo infisical-ctl reconfigure after the update. It completed successfully but only updated 2/67 resources (fixing chown/chmod on standalone-entrypoint.sh). Importantly, reconfigure did not restart the service — the runit service action was explicitly skipped (action :nothing).

The root cause of the blank page was that the Node process was still running the old binary after the update — confirmed by

/proc/<pid>/exe pointing to a deleted file:
/proc/3813/exe -> '/opt/infisical-core/embedded/bin/node (deleted)'

The old process served the new index.html (which references updated hashed asset filenames), but couldn't serve the actual new CSS/JS files, causing the browser to receive application/json MIME type for stylesheets and 404s for scripts.

Fix that worked:

sudo infisical-ctl reconfigure
sudo systemctl restart infisical-runsvdir

Suggestion: The update process should either automatically restart infisical-runsvdir when the binary changes, or the update documentation should explicitly mention both steps. Currently the docs only mention reconfigure, which leaves the stale process running.

[prasana-k]

Also noticed the runit run script has a commented-out standalone-entrypoint.sh exec line, while the active line runs node --enable-source-maps ./dist/main.mjs directly. The reconfigure step fixed permissions on standalone-entrypoint.sh which appears unused. Is this script still needed?