Yesterday I updated my Ghost installation on Azure Websites and my test blog stopped working: I enabled error logging and the error I got was:

[31m
ERROR:[39m [31m Cannot find module './binding\Release\node-v11-win32-x64\node_sqlite3.node' [39m

Error: Cannot find module './binding\Release\node-v11-win32-x64\node_sqlite3.node'
    at Function.Module._resolveFilename (module.js:338:15)
    at Function.Module._load (module.js:280:25)
    at Module.require (module.js:364:17)
    at require (module.js:380:17)
    at Object.<anonymous> (D:\home\site\wwwroot\node_modules\sqlite3\lib\sqlite3.js:7:15)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Module.require (module.js:364:17) 

Ghost uses node-sqlite3 which is a binding toward sqlite and thus requires the native binary for the OS and architecture of the server: the download is done during the npm installation and depends on the architecture on which npm is running. In my case, since I have a free windows azure web site, the architecture is 32bit, so after installing the package I got node_modules\sqlite3\lib\binding\Release\node-v11-win32-ia32\node_sqlite3.node, which seems to be legit.

The dynamic reference is done based on the process.arch variable, so you would expect it to be ia32 as well, since my website is configured as 32bit. So why is the sqlite3 module trying to reference the x64 version?

I did some debugging through the amazing Kudu Debug Console to try and understand why: I tried getting the process.arch variable both via console (which should reflect the condition seen by npm) and via a small node.js app running in the same web site.

Running on the console node -e "console.log(process.arch)" I got ia32.

On the other end, trying to detect the same variable via the website I got x64.

var http = require('http');
http.createServer(function (req, res) {
  res.writeHead(200, {'Content-Type': 'text/plain'});
  res.end('Architecture:'+process.arch+'\n');
}).listen(process.env.PORT, '127.0.0.1');

Node-sqlite is behaving correctly: installing ia32 as npm runs under 32bit and requiring x64 as the website process is running 64bit.

Now I fixed my problem by running npm install sqlite3 --target_arch=x64 via the kudu debug console and forcing the installation of the 64bit version of the binary file for sqlite, but question still remains: why if the web site is configured as 32bit, the node.js process runs as 64bit while the console and deply process runs under 32bit?

UPDATE: I just installed the latest from Ghost master which references node-sqlite version 2.2 which changed binary dependency installation to node-pre-gyp. This installs the 64bit version of sqlite, so my problem is solved. Nevertheless, having the 64bit version when my web site is configured as 32bit seems a bug.