-
Notifications
You must be signed in to change notification settings - Fork 21
Description
Summary
In a self-hosted Community Edition deployment, the tracking script path /swetrix.js was not reliably available after recreating the frontend container.
This caused website-side tracking integration to fail until the file was restored.
Environment
Observed in self-hosted CE using official images in a Docker-based deployment.
Observed on:
swetrix/swetrix-fe:v5.0.3swetrix/swetrix-api:v5.0.3
Actual behavior
After frontend container recreate / redeploy, requesting /swetrix.js was not reliably stable in the self-hosted setup.
In practice this broke website analytics initialization, because the tracking script URL was no longer consistently available as a valid JS asset.
Expected behavior
A self-hosted installation that expects users to load:
<script src="https://<self-hosted-domain>/swetrix.js" defer></script>should ensure that /swetrix.js remains available across container recreates.
Reproduction outline
- Run self-hosted CE with the frontend container serving the tracking script.
- Recreate the frontend container.
- Request
/swetrix.js. - Observe that the asset may no longer be reliably available unless it is explicitly restored into the served public path.
Local workaround
A local workaround that fixed the issue was adding a startup copy step in the frontend container:
cp -f /app/node_modules/swetrix/dist/swetrix.js /app/public/swetrix.jsThis made /swetrix.js available again on every container start.
Additional context
There is already some historical confusion around the self-hosted script path and where the file is expected to be served from. It would help if the official self-hosted setup either:
- guaranteed
/swetrix.jsas part of the frontend container lifecycle, or - documented the intended serving strategy more explicitly.
This report refers only to self-hosted CE behavior and does not include any private deployment details.