Known limitations
Running from memory with no writable application directory rules some things out. This section is the list — what each runtime cannot do, and what to do instead.
None of it is arbitrary. Every constraint here is the direct cost of the property you came for: an application that is never written to disk cannot install packages at runtime, cannot write files next to itself, and cannot compile on the host. Those follow from the architecture rather than from an incomplete implementation, and they are the same constraints any in-memory runtime would face.
Most applications hit none of these. The ones that do usually need a small, one-time change — and it is much cheaper to know before a migration than during one.
Technical White Paper (PDF)
</div>
</div>
The three pages
- Both runtimes — no writable application directory, memory residency, and building before you push.
-
Node.js runtime —
the shared package set, and how
listen()is handled. - .NET runtime — in-memory assemblies, no compilation on the host, and outbound network defaults.
Quick check
If your application does any of the following, read the relevant page before you plan a migration.
| If your app… | See |
|---|---|
| Writes uploads, caches or logs to local files | Both runtimes |
| Uses SQLite or any file-backed local store | Both runtimes |
| Installs npm packages at deploy time | Node.js |
Uses raw http.createServer or WebSockets | Node.js |
| Compiles Razor views at runtime | .NET |
Reads Assembly.Location or a physical assembly path | .NET |
| Calls a database or external API from .NET | .NET |