By default, it's not possible to write files to the file system when creating Node.js deployments.
But there's an exception: The first time the build step (either using the build or now-build) runs, Node.js will be able to write to the file system. This is necessary for allowing applications to be bundled and/or transpiled on the server.
After either the start or now-start scripts have started running, the only writable location will be /tmp.
Inside this directory, temporary data can be saved. But please note that it will be removed each time each deployment goes to sleep and wakes up again. In turn, it is not safe to be used as a file-based database.
After now has taken care of setting up the base of your deployment, the first real interaction with your code will be installing the dependencies you've defined inside package.json.
For this process, we're using our so-called "ace" technology behind the curtains.
It not only comes with a global shared cache of public modules to avoid repetitive work in each deployment, but it also caches the artifacts of binary packages which requires packages like node-canvas to only get compiled once. Afterwards, our build servers securely share it with all our customers (which saves a lot of time).
In cases where you need to set the NODE_ENV variable to "production", but still need to have the devDependencies installed, then you can use the environment variable on the build script property as shown below:
"build": "NODE_ENV=production next build"
You can expose a HTTP service on any port of your choice (not multiple ones). now will then route requests to your deployment to that port and visitors will see the rendered output of your application.
Other than selecting the version of Node.js using the engines property,
there are no other ways to interfere with the image of your deployment. This means that if you want to use a custom runtime, a special version of Linux or some other form of low-level customization, you should consider a Docker deployment.
It will allow you to specify all of these things inside a Dockerfile. This results in much wider customization options.
Old deployments always stay around forever if you don't remove them using now remove.
However, if your deployment doesn't receive any HTTP(S) requests for a long time, it will most likely be added to the list of deployments that will fall into a light sleep if the platform experiences a lot of load.
There's no definite answer to how long it will take until such a deployment goes to sleep, because the time will automatically be calculated based on the platform's load and the amount of deployments on it. But if your deployment is linked to an alias, it's less likely to ever fall into a sleep when not being accessed.
All in all, sleeping deployments are here to reduce the effort the system has to push into keeping those running that aren't being accessed at all (which usually means they're inactive and not needed anymore).
Sleeping deployments will wake up in a matter of seconds once a request comes in. The visitor won't experience any errors, because the request will be kept alive until the deployment has woken up.
Eventually, we'll be working on adding support for non-sleeping deployments!