[deno desktop] allow the second Deno.serve() without limitation?

[hanguokai]

Hi, I'm trying out the features of Deno Desktop. Its entry point is a Deno.serve() , which I'll call "the first Deno.serve()" for convenience. As mentioned in the official documentation, it has some limitations:

The bound address is always 127.0.0.1 (or [::1]). The compiled binary never binds to a public interface, even if you pass 0.0.0.0 to Deno.serve(). Other apps and other users on the same machine cannot reach your server.

If you need to serve users on other machines (a self-hosted local server), do not use deno desktop for that part of your stack. Use deno run with an explicit address, or build a separate service.

My application is an HTTP server that needs to be accessible from localhost or other devices on the local network at http://ip:port/. My solution is:

• The first Deno.serve() is the UI for users to start/stop the second Deno.serve()
• The second Deno.serve() is a local http server

I tested it, and this method works. The second server does not have the aforementioned network restrictions; it can be accessed from other device.

My question is will Deno desktop maintain this behavior? That is, only the entry point Deno.serve() is restricted, and other subsequent Deno.serve() are not restricted.

[lMysticl]

The docs are clear about the Desktop entry point: deno desktop sets DENO_SERVE_ADDRESS to 127.0.0.1:<port>, and that Deno.serve() ignores a different host or port. For a server that must be reachable from other machines, Deno recommends deno run with an explicit address or a separate service.

I could not find a documented exception for a second Deno.serve() in the same Desktop binary. Your test may work today, but I would treat it as implementation behavior, not a compatibility guarantee. If LAN access matters, keep that server outside the Desktop entry point.

Desktop serving docs · deno serve vs deno run

[hanguokai]

The deno run solution is not feasible. When you use deno desktop or deno compile for desktop users (in non cloud environments), you will face these issues:

• The user has not installed Deno
• You can't even use Deno.Command() to call other external programs because of the restrictions and review issues in the Apple App Store and Microsoft Store.

If the second Deno.serve() is compiled as a separate program via deno compile, then the combined size of the two is too large.

So my solution is starting the second Deno.serve() in the same process of Deno Desktop (as I mentioned earlier).

BTW: There is no good way to create a child process to execute another script in the process of deno desktop.

[lMysticl]

You're right — given the Desktop packaging constraints, my deno run suggestion does not solve your case.

I checked the implementation. DENO_SERVE_ADDRESS is deliberately consumed only once, and the regression test verifies that a second Deno.serve() keeps its own address. This was introduced intentionally in #31935, so your same-process approach is supported by the current implementation, not just an accidental result.

The remaining question is whether Deno Desktop considers this a stable public contract. The Desktop serving documentation still says the compiled binary never binds to a public interface and does not document the second-server exception. A maintainer clarification or documentation update would settle that.

[hanguokai]

Thank you for pointing out that PR. The restriction does indeed only apply to the first Deno.serve(), to ensure that the main GUI is secure.

[hanguokai]

Some points:

the second Deno.serve() can be accessed via http://ip:port (e.g., http://192.168.0.110:8001), but cannot be accessed via localhost or 127.0.0.1. This is likely due to the internal implementation mechanism.

For the worker, since it's a new, isolated JS context, that PR has no effect in the worker. Using Deno.serve() in the worker will fail the first time, succeeding on the second.

Using a low-level API like Deno.listen() can bypass the restrictions of Deno.serve().