Categories
Node.js

Node.js and Express.js on Heroku – deploying node.js application

The main description how you should properly deploy your app on Heroku is here: Heroku – deploying node.js. However, what is there is truth, albeit not the whole truth and following the description can make you frustrated with – for instance – something like:

heroku[router]: at=error code=H10 desc=”App crashed”

The initial problems are partly related to the fact, that your local environment and Heroku environment (dynos etc etc) are different.

The general idea of using Heroku for node.js is that you install Heroku stuff on your local machine, which connects to Heroku and you push code/modifiacations to Heroku git repositories used to deploy your application and make it visible out there, in the Internet, with url like: https://blah-moon-143.herokuapp.com. Heroku generates random subdomain part, which is name for your application, but during your local development you can set it to something different:

heroku create blah-different-123

before you do git push heroku master.

Another important bit is the Procfile – better set it right from the beginning. This is simple text file, without any extension, which has to be named exactly: Procfile, that is: uppercase “P” and all other characters in lowercase. Inside the file place this:

web: node index.js

if your main file is index.js. Heroku assumes your main node server file is web.js. Look again above: just after “web” you write “:” NO SPACES, and after colon “:” place one space, and write your main filename.

For something useful like nodemon write it into package.json file:

"devDependencies": {
  "nodemon": "^2.0.7"
},

It means, that nodemon will work on local development environment only, but not in production. Don’t forget to add to package.json:

"main": "index.js",

pointing to your main application file. And, important as well, add:

"engines": {
  "node":"14.x"
 }

Except that in package.json there should be all other dependencies, obviously.

One rather common reason for error code=H10 can be also fact, that you set PORT number in your main server app for, let’s say:  const PORT=5000 or app.listen(5000, () => { ….

Well, don’t do that. Instead, write somewhere at the top of your application and let Heroku choose the port number:

var port = process.env.PORT || 5000;

and use port variable in your code, because Heroku system will decide which PORT number and when it will use for your application. The above way gives precedence to Heroku port. If you like to know what is the current set of Heroku environmental variables, including port, write this command:

heroku run printenv

and result can be, for instance:

Running printenv on ⬢ blah-different-1... up, run.8873 (Free)
MEMORY_AVAILABLE=512
PWD=/app
PORT=51444
NODE_ENV=production
NODE_HOME=/app/.heroku/node
LINES=24
HOME=/app
COLUMNS=167
TERM=xterm-256color
SHLVL=0
WEB_MEMORY=512
WEB_CONCURRENCY=1
PS1=\[\033[01;34m\]\w\[\033[00m\] \[\033[01;32m\]$ \[\033[00m\]
PATH=/app/.heroku/node/bin:/app/.heroku/yarn/bin:/usr/local/bin:/usr/bin:/bin:/app/bin:/app/node_modules/.bin
DYNO=run.8873
_=/usr/bin/printenv

For quick check if your dyno on Heroku is working:

heroku ps:scale web=1, which can produce result like:

Scaling dynos… done, now running web at 1:Free

The above information should help in avoiding error code=H10 or some other related codes too. Command: heroku logs –tail shows some information, but it can show error code=H10 without any clue what and where is going on.

Having said the above deployment with Heroku looks good, especially that you can have deployed your application for free, with some limitations. Also, the idea that you develop locally, on your machine and the application via Git is synced with Heroku repositories out there – this sounds good and looks like working smoothly.