NestJS Static Assets 404 After Deploying to Render

NestJS static assets 404 after deploying to Render almost always traces back to one thing: a path that happened to work locally because of exactly where you were running the app from, not because the configuration was actually correct. The images, CSS, or static files load without a hitch on your machine, and the instant the same code runs on Render, every one of them comes back 404 — with no error suggesting your ServeStaticModule setup itself is wrong.

Short answer: check whether the path you're passing to ServeStaticModule.forRoot() is resolved relative to __dirname (which points at wherever the compiled file happens to sit, and shifts between environments) instead of something more stable, and confirm the static folder you're pointing at actually made it into Render's build output in the first place — nest build only compiles TypeScript, it doesn't copy asset folders for you.

Why NestJS Static Assets 404 on Render but Work Fine Locally

The default pattern most NestJS starters ship with looks like this:

1// app.module.ts — path resolution that only works from the exact directory you happened to build in
2import { Module } from '@nestjs/common';
3import { ServeStaticModule } from '@nestjs/serve-static';
4import { join } from 'path';
5
6@Module({
7  imports: [
8    ServeStaticModule.forRoot({
9      rootPath: join(__dirname, '..', 'public'),
10    }),
11  ],
12})
13export class AppModule {}

__dirname resolves to wherever the compiled file physically lives, and that location depends on your build output structure — how deep dist/ nests things, whether you're running via ts-node locally versus the compiled dist/main.js in production. Locally, this often lines up by coincidence. On Render, the build step and directory layout aren't guaranteed to match your local assumptions, and the moment the relative path is off by even one folder level, join(__dirname, '..', 'public') quietly resolves to somewhere that doesn't have your files — no error, just a 404 for everything.

(If you've been re-checking your ServeStaticModule import and decorator syntax for the tenth time — it's fine. The decorator was never the problem. The path underneath it was pointing at a folder that exists on your laptop and nowhere else.)

The Fix: Resolve From a Stable Location, and Verify the Build Actually Copies It

Two separate things need to be true, and people usually only fix one:

1// app.module.ts — resolve from the process's working directory instead of the compiled file's location
2import { Module } from '@nestjs/common';
3import { ServeStaticModule } from '@nestjs/serve-static';
4import { join } from 'path';
5
6@Module({
7  imports: [
8    ServeStaticModule.forRoot({
9      rootPath: join(process.cwd(), 'public'),
10    }),
11  ],
12})
13export class AppModule {}

process.cwd() reflects the directory the Node process was actually started from — typically wherever node dist/main.js gets invoked — which tends to be far more consistent across local dev, CI, and Render than __dirname's relationship to the compiled file's nesting depth.

That alone doesn't help if the public folder never made it into the build output to begin with. nest build compiles TypeScript — it has no idea your images and static HTML exist unless you tell it to carry them along:

1// package.json — make sure the build step actually copies non-TS assets into dist/
2{
3  "scripts": {
4    "build": "nest build && cp -r public dist/public",
5    "start:prod": "node dist/main.js"
6  }
7}

Check both. A correctly resolved path pointing at a folder that was never copied 404s exactly the same way as a wrong path pointing at a folder that does exist.

Checking Render's Actual Build Output

Before redeploying and hoping, Render's own deployment docs are worth a direct read for exactly what your build command produces — but the faster check is opening Render's shell for the running service and looking at the directory yourself: does dist/public (or wherever you've configured rootPath to point) actually exist, and does it contain the files you expect? If it's empty or missing entirely, the fix is in your build script, not in ServeStaticModule's configuration.

The Opinion Part

Here's the pattern worth naming plainly, because it's the same lesson underneath most of the "works locally, breaks on deploy" bugs in this genre: any path built from __dirname, any environment variable assumed to be set, any file assumed to exist because it does on your laptop — these are local-environment assumptions wearing the disguise of application logic. A defect like this costs a comment in code review to fix; it costs an afternoon of "is Render's build broken?" theories to find after a real deploy, because the error message tells you nothing about which of your assumptions was wrong. Treat any disk-relative path in a deployable service the same way you'd treat a hardcoded environment variable — something to double-check explicitly for every environment it'll actually run in, not just the one you're staring at right now.

Conclusion

If NestJS static assets are 404ing on Render, it's not your ServeStaticModule decorator and it's not a Render outage — it's a path assumption that only ever held in one specific local directory structure. Resolve the root path from something stable like process.cwd(), confirm your build step actually copies the asset folder into dist, and check Render's own shell to verify the files are really there before you touch the config again.

If you've already fixed this one and you're now chasing why the deployed service reports itself as unhealthy for an unrelated reason, our Render health check guide covers that specific failure mode — and if you're setting up the Docker build for this app for the first time, our multi-stage build guide covers exactly this class of "did the build actually include what I think it included" question from the container side.

Copy the folder, fix the path, redeploy — and enjoy the small, specific satisfaction of a 404 that turns back into an image.