deploy_feedback icon indicating copy to clipboard operation
deploy_feedback copied to clipboard

Web Console: Provide option for `root` in the Runtime Configuration settings

Open tolu opened this issue 2 months ago • 3 comments

What problem are you trying to solve?

Nitro based apps (like Nuxt, TanStackStart, SolidStart etc) produce build output in the .output folder.

For such apps to work on deno deploy the root must be set to .output, otherwise resulting in issues with serving static files (even if the server starts up just fine).

Using the framework-preset for Nuxt is great, since I gather that sets the root to .output, but fails if the nitro build is configured with the deno-deploy preset since that produces a server/index.ts file rather than a server/index.mjs files as entrypoint.

Being able to manually set a root in the settings via the web interface (as it is already possible to do when manually creating a deployctl github action) would enable many deploys to use the "connected" github repo variant that provides such a nice DX. 🙌

In my case, trying to deploy a TanStack Start app with Nitro v3, I could make this work today by:

  • using nitro preset node-server since that produces the entrypoint .output/index.mjs
  • using the Nuxt framework preset

this does feel rather backward though.

Describe the solution you'd like

An opt-in field to manually set a root for the runtime configuration would be fantastic.

This would (probably) enable many build systems and outputs without having to create a custom build script for deno deploy or manually set up the github action.

One more input field here, below Entrypoint, would do the trick:

Image

Describe alternatives you've considered

  • custom build script that moves files into root folder before starting
  • custom github action with a root option for deployctl set to .output
  • using the Nuxt framework preset and building with Nitro-preset node-server, even though I'm not deploying a Nuxt app or aiming to run as a node-server

Documentation, Adoption, Migration Strategy

It would be an opt-in configuration, available only when needed and so should not require any changes for all current set-ups.

Documentation wise it would be nice to provide (I'd be happy to help and contribute):

  • information on that customizing the CWD/root is possibel, and that it would affect the value entered in the Entrypoint-field since that has to be relative to what rootis set to.
  • a section on Nitro-based apps and how to get them running in general, especially since they provide deno-deploy presets that natively use Deno.serve in the generated index.ts file.

tolu avatar Oct 12 '25 07:10 tolu

Thanks for opening this issue.

Currently both the Nuxt and SolidStart presets work like this:

  • they automatically set SERVER_PRESET=deno_server before running the build
  • once the build is complete, they check that a .output folder exists
  • they check whether a .output/server/index.ts exists, otherwise they assume .output/server/index.mjs exists
  • the runtime configuration entrypoint is set to either .output/server/index.ts or .output/server/index.mjs
  • the CWD remains the root of the repository, not .output

I think the problem is that you are using SERVER_PRESET=deno_deploy instead of SERVER_PRESET=deno_server (I know, very confusing). The latter does not require you change the runtime cwd.

I have internally recorded two feature requests here:

  • Support TanStackStart with framework discovery and so forth out of the box
  • Support setting a root directory in the runtime config

lucacasonato avatar Oct 13 '25 11:10 lucacasonato

Oh great! Thanks 🙌 Yes that was a bit confusing 😆 (deno-server) Since they have a few options to choose from...

Image

I think I also got a bit influenced by reading the docs from Nuxt and Nitro, where they set the root in custom actions or deploy from local machine directly from the .output directory:

  • https://nuxt.com/deploy/deno-deploy
  • https://nitro.build/deploy/providers/deno-deploy

Personally I don't think having a TanStackStart preset is important, but that seems like a really good idea 👍

Setting the root manually however seems like a natural thing since you can do that with the deployctl-action. And it would hopefully make adoption of new build-output folder naming easy peasy.

tolu avatar Oct 13 '25 13:10 tolu

Given all I learned here I think I'll:

  • contribute to the Nitro docs on Deno Deploy to say something about deno-server
  • try to contribute to Nitro so it auto-detects the build is running on deno deploy (if possible) and selects the correct preset (this is how the Netlify builds work according to the docs). This ofc presumes that .output/server/index.{ts,mjs} would be auto-discovered by the runtime which I guess it does not?
  • better ideas for a smoother DX much appreciated 🙏

Any suggestions for the best way to detect the build is running on deno deploy, and would I have to differentiate between v1 and v2 of deploy @lucacasonato?

tolu avatar Oct 13 '25 15:10 tolu