The deployed bundle had no API base URL baked in at all, so the app fell back to
relative /api/* requests, which the frontend's nginx forwards to a backend:8000
service that does not exist in this deployment.
Same cause as the backend: Dokploy writes its own .env into the build context
from the service's Environment tab after cloning, and that tab is empty, so the
committed file was replaced by a zero-byte one. The checkout showed .env at 0
bytes, and grepping the running container's bundle for the API host returned
nothing.
Vite loads .env.production for production builds and it takes precedence over
.env, so the config now travels under that name and survives. No Dockerfile
change is needed - Vite resolves it natively - and the --build-arg stays
unnecessary.
Verified by writing an empty .env over the checkout, exactly as Dokploy does,
and building: https://mcp.nearle.ai.in is still inlined into the bundle.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
VITE_API_BASE_URL is inlined into the public JS bundle at build time, so it is
readable by anyone who opens the site. Ignoring it protected nothing and only
meant the value had to be remembered and re-passed as --build-arg on every
deploy - which is exactly how the bundle ended up pointing at a host that did
not exist.
Vite reads .env during `npm run build`, so the Docker build now picks the domain
up on its own and needs no build arg. Verified: a build with no --build-arg
bakes in https://mcp.nearle.ai.in.
.env.local stays ignored for local overrides. Nothing secret belongs in a
VITE_-prefixed variable - it would be published in the bundle.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
