How to deploy on heroku

21.08.202221.08.2022 admin 0 Comments how, how to made, как, как сделать, как создать, совими руками

How to deploy on heroku

Deploy your front-end app in 20 lines of code

Sometimes you want to be the next Google. Sometimes you just want to get the app you developed on the internet to impress family and friends. For latter cases, the easiest way to serve an app based around a website with embedded CSS styles and JavaScript is to deploy Express server to a free Heroku account. This tutorial assumes you have some familiarity with Git and have Node, npm, and Git installed.

Step 1: Create a Heroku account and install the Heroku CLI to your local machine.

Tutorial for how to do that here.

Step 2: Ensure your repository has a package.json file and install Express

Make sure your your project directory (the folder that contains your project files) has a package.json file. This is where Node and later Heroku will look to see the configuration of your app. If you don’t already have a package.json file in your project directory, the easiest way to create one is to run the following command in your terminal:

This will ask you a few questions about the name of your project, what its license is, etc. If you don’t feel like answering them now, you can just keep pressing enter and edit the file later.

Next install Express using npm with this command:

This command will search in the npm repository for the most up to date version of the Express library, download it, and save it in your project directory in the node_modules directory (it will create a node_modules directory if one doesn’t always exist). The — save flag tells npm to automatically list Express as a dependency in package.json.

Step 3: Add a server script to the base directory of your project.

I’ve posted the code for my Express server below, and feel free to copy it from GitHub and use it for your own project. Below, I’ll walk through what all the lines of code are doing.

In lines 1–3, you are declaring all then dependencies for your server. On line 2, using Node’s require syntax, you are importing the Express library as a module into your project. On line 2, you call the express constructor (which is stored in the Express library that you imported on line 1) to create a new express object. Also on line 2, you declare a new variable (called app) which you point to the new express object you just created. On line 3, you import that path module (part of Node’s basic library), which makes working with the file system easier.

In lines 5–8, you are giving your Express server access to static files currently stored in your project directory (the folder that contains your project files). This directory will later be pushed to Heroku’s remote repository when you deploy your site. When your Express server is running, it cannot access the files directly, but instead must make HTTP requests for the files. But how will the server know where to make requests for the files?

In lines 5–8 above, you are explicitly stating which URLs your server needs to request these static files from. In this example, all the CSS stylesheets are stored in the styles directory of the project. Line 6 is telling the server that in order to access stylesheets stored in the styles directory, the server needs to make a HTTP request to [ base_URL]/styles. The base URL will be localhost followed by the port number if you’re running the server on your local machine or your Heroku URL if the app is deployed. The __dirname variable refers the the parent directory of your project (this highest level folder that contains all your project files).

Make sure to configure the static file request paths based on the structure of your project directory.

Similarly, if a request is sent to the about URL (i.e. http://localhost:8080/about or http://yourapp.herokuapp.com/about ) the server will serve the about.html document.

Make sure to add router paths for every distinct webpage you want to serve.

Lastly, you have to tell your server where to listen for requests.

On line 20, we are telling to app to check if it was provided a port number stored in the environment variable process.env.PORT. When deploying the app, Heroku will specify which port your app will listen for requests on. For your local development server, the app will listen on http://localhost:8080.

You can also change the port number to whatever you want.

Whew! That’s the hardest part- you just configured your first Express server! To test it out locally to make sure everything works, just type the following command into your terminal at the project directory. (this is assuming that you named the file server.js)

You should be able to open your browser to http://localhost:8080 and see your beautiful website! At this point, it’s a good idea to open the developer tools console in your browser to check if there are any error messages (whenever I do this I invariably type in one of the paths wrong and the server can’t access my files).

Step 4: List your server as the start script in package.json

When Heroku looks to launch your app, it will look for a default start script. In your package.json, you can configure your start script to run the server.js script you just created. In the area marked scripts just add the following line (make sure to modify to the actual name of your server script)

You can test out that this works by running the following command and opening the browser to http://localhost:8080.

Step 5: Commit all your files

If you haven’t already initialized a Git repository for your project, now is a good time to create one with the command:

Next stage all your files to add to your repository:

This will add the current directory to the staging area. Note: it isn’t considered good practice in Git to stage and commit the entire directory at once, but this once I’ll allow it 😉️.

Next commit all the files you’ve staged:

Just to make sure all your files are committed, check your Git status:

You should see a message saying all files are committed and that your working directory is clean.

Once you have all your updates committed, it’s time to deploy to Heroku.

Step 6: Deploy to Heroku

Now that you’ve got your app running on your local machine, let’s get it out onto the open internets.

Assuming that you created a Heroku account and installed the Heroku CLI in Step 1, you just have to type the following commands into your terminal to push your project to Heroku. If you use GitHub this is very similar to pushing the current state of your repository to your GitHub remote.

This creates a new Heroku app with the name you give it, and adds Heroku as a remote to your Git repository.

This pushes the master branch of your Git repository to Heroku. You’ll see some output from Heroku, about uploading your files, building your app, and then voila, it will spit out a URL for your shiny new deployed app.

Introduction

This tutorial will have you deploying a Ruby app in minutes.

Hang on for a few more minutes to learn how it all works, so you can make the most out of Heroku.

The tutorial assumes that you have:

If you don’t follow the Windows guide, note that you cannot run bundle install as you may need to install OpenSSL and the Puma web server manually.

Verify the file is in the correct location:

Once this finishes run:

Set up

The Heroku CLI requires Git, the popular version control system. If you don’t already have Git installed, complete the following before proceeding:

In this step you’ll install the Heroku Command Line Interface (CLI). You use the CLI to manage and scale your applications, provision add-ons, view your application logs, and run your application locally.

Download and run the installer for your platform:

Download the appropriate installer for your Windows installation:

Once installed, you can use the heroku command from your command shell.

Use the heroku login command to log in to the Heroku CLI:

This command opens your web browser to the Heroku login page. If your browser is already logged in to Heroku, simply click the Log in button displayed on the page.

This authentication is required for both the heroku and git commands to work correctly.

If you’re behind a firewall that requires use of a proxy to connect with external HTTP/HTTPS services, you can set the HTTP_PROXY or HTTPS_PROXY environment variables in your local development environment before running the heroku command.

Prepare the app

In this step, you will prepare a sample application that’s ready to be deployed to Heroku.

If you are new to Heroku, it is recommended that you complete this tutorial using the Heroku-provided sample application.

However, if you have your own existing application that you want to deploy instead, see this article to learn how to prepare it for Heroku deployment.

To clone the sample application so that you have a local version of the code that you can then deploy to Heroku, execute the following commands in your local command shell or terminal:

You now have a functioning git repository that contains a simple application as well as a Gemfile file, which is used by Ruby’s dependency manager, bundler.

Deploy the app

In this step you will deploy the app to Heroku.

Create an app on Heroku, which prepares Heroku to receive your source code.

When you create an app, a git remote (called heroku ) is also created and associated with your local git repository.

Heroku generates a random name (in this case polar-inlet-4930 ) for your app, or you can pass a parameter to specify your own app name.

Now deploy your code:

The application is now deployed.

Now visit the app at the URL generated by its app name. As a handy shortcut, you can open the website as follows:

View logs

Heroku treats logs as streams of time-ordered events aggregated from the output streams of all your app and Heroku components, providing a single channel for all of the events.

Visit your application in the browser again, and you’ll see another log message generated.

Press Control+C to stop streaming the logs.

Define a Procfile

Use a Procfile, a text file in the root directory of your application, to explicitly declare what command should be executed to start your app.

The Procfile in the example app you deployed looks like this:

Procfiles can contain additional process types. For example, you might declare one for a background worker process that processes items off of a queue.

Scale the app

You can check how many dynos are running using the ps command:

To avoid dyno sleeping, you can upgrade to a hobby or professional dyno type as described in the Dyno Types article. For example, if you migrate your app to a professional dyno, you can easily scale it by running a command telling Heroku to execute a specific number of dynos, each running your web process type.

Scaling an application on Heroku is equivalent to changing the number of dynos that are running. Scale the number of web dynos to zero:

Access the app again by hitting refresh on the web tab, or heroku open to open it in a web tab. You will get an error message because you no longer have any web dynos available to serve requests.

Scale it up again:

For abuse prevention, scaling a non-free application to more than one dyno requires account verification.

Declare app dependencies

Heroku recognizes an app as a Ruby app by the existence of a Gemfile file in the root directory.

The Gemfile file specifies the dependencies that should be installed with your application. You can also use it to determine the version of Ruby that will be used to run your application on Heroku.

When an app is deployed, Heroku reads this file and installs the appropriate Ruby version together with the dependencies using the bundle install command.

A prerequisite to running any app locally is to install the dependencies locally as well. This particular Gemfile has a dependency pg which will only resolve if you have Postgres installed locally. Please install Postgres before you proceed.

You will know that Postgres is installed successfully when the command which psql returns a value on your command line (though your actual output may vary):

Now run bundle install in your local directory to install the dependencies, preparing your system for running the app locally:

Once dependencies are installed, you will be ready to run your app locally.

Run the app locally

The Rails app also uses a database, so you’ll have to create the appropriate database and table using the rake task:

Now start your application locally using the heroku local command, which was installed as part of the Heroku CLI:

Just like Heroku, heroku local examines the Procfile to determine what to run.

Open http://localhost:5000 with your web browser. You should see your app running locally.

To stop the app from running locally, in the CLI, press Ctrl + C to exit.

Push local changes

In this step you’ll learn how to propagate a local change to the application through to Heroku. As an example, you’ll modify the application to add an additional dependency and the code to use it.

Modify Gemfile to include a dependency for the cowsay gem by including a line gem ‘cowsay’ :

Modify app/views/welcome/index.erb so that it uses this gem, by changing the file so that its first few lines read as follows:

Now test locally:

Visit your application at http://localhost:5000. You should see a cute ASCII picture displayed.

Now deploy this local change to Heroku.

Almost every deploy to Heroku follows this same pattern. First, add the modified files to the local git repository:

Now commit the changes to the repository:

Now deploy, just as you did previously:

Finally, check that everything is working:

Provision add-ons

Add-ons are third-party cloud services that provide out-of-the-box additional services for your application, from persistence through logging to monitoring and more.

In this step you will provision one of these logging add-ons, Papertrail.

Provision the papertrail logging add-on:

To help with abuse prevention, provisioning an add-on requires account verification. If your account has not been verified, you will be directed to visit the verification site.

The add-on is now deployed and configured for your application. You can list add-ons for your app like so:

To see this particular add-on in action, visit your application’s Heroku URL a few times. Each visit will generate more log messages, which should now get routed to the papertrail add-on. Visit the papertrail console to see the log messages:

Your browser will open up a Papertrail web console, showing the latest log events. The interface lets you search and set up alerts:

Start a console

You can run a command, typically scripts and applications that are part of your app, in a one-off dyno using the heroku run command. It can also be used to launch a REPL process attached to your local terminal for experimenting in your app’s environment:

When the console starts, it has your entire app loaded. For example, you can type puts Cowsay.say(«hi»,»Cow») and an animal saying “hi” will be displayed. Type exit to quit the console.

Don’t forget to type exit to exit the shell and terminate the dyno.

Define config vars

At runtime, config vars are exposed as environment variables to the application. For example, modify app/views/welcome/index.erb so that the method repeats an action depending on the value of the TIMES environment variable. Change the file so that its first few lines read as follows:

To set the config var on Heroku, execute the following:

View the config vars that are set using heroku config :

Deploy your changed application to Heroku to see this in action.

Use a database

The add-on marketplace has a large number of data stores, from Redis and MongoDB providers, to Postgres and MySQL. In this step you will learn about the free Heroku Postgres add-on that is provisioned automatically on all Rails app deploys.

A database is an add-on, and so you can find out a little more about the database provisioned for your app using the addons command in the CLI:

Listing the config vars for your app will display the URL that your app is using to connect to the database, DATABASE_URL :

Heroku also provides a pg command that shows a lot more:

This indicates I have a hobby database (free), running Postgres 11.5, with a single row of data.

If you do visit the URL, you’ll see an error page appear. Check out the error message in using heroku logs or in Papertrail, and you’ll see something like this:

Now if you visit the /widgets page of your app again, you’ll be able to list and create Widget records.

You can also interact directly with the database if you have Postgres installed locally. For example, here’s how to connect to the database using psql and execute a query:

Next steps

You now know how to deploy an app, change its configuration, view logs, scale, and attach add-ons.

Here’s some recommended reading:

Getting Started on Heroku with Python

Introduction

This tutorial will have you deploying a Python app (a simple Django app) in minutes.

Hang on for a few more minutes to learn how it all works, so you can make the most out of Heroku.

The tutorial assumes that you have:

Set up

The Heroku CLI requires Git, the popular version control system. If you don’t already have Git installed, complete the following before proceeding:

Download and run the installer for your platform:

Download the appropriate installer for your Windows installation:

Once installed, you can use the heroku command from your command shell.

Use the heroku login command to log in to the Heroku CLI:

This command opens your web browser to the Heroku login page. If your browser is already logged in to Heroku, simply click the Log in button displayed on the page.

This authentication is required for both the heroku and git commands to work correctly.

Prepare the app

In this step, you will prepare a simple application that can be deployed.

Before continuing, make sure Git is installed (see Set up).

To clone the sample application so that you have a local version of the code that you can then deploy to Heroku, execute the following commands in your local command shell or terminal:

Deploy the app

In this step you will deploy the app to Heroku.

Before continuing, make sure both Git and the Heroku CLI are installed (see Set up).

Create an app on Heroku, which prepares Heroku to receive your source code:

When you create an app, a git remote (called heroku ) is also created and associated with your local git repository.

Heroku generates a random name (in this case serene-caverns-82714 ) for your app, or you can pass a parameter to specify your own app name.

Now deploy your code:

The application is now deployed. Ensure that at least one instance of the app is running:

If when running the ps:scale command above you see the error “ Couldn’t find that process type (web) ”, it means the first deploy of the application is taking a bit longer than normal, and the command should be repeated after waiting a few minutes.

Now visit the app at the URL generated by its app name. As a handy shortcut, you can open the website as follows:

View logs

Heroku treats logs as streams of time-ordered events aggregated from the output streams of all your app and Heroku components, providing a single channel for all of the events.

Visit your application in the browser again, and you’ll see another log message generated.

Press Control+C to stop streaming the logs.

Define a Procfile

Use a Procfile, a text file in the root directory of your application, to explicitly declare what command should be executed to start your app.

The example app you deployed contains a Procfile file like this:

Procfiles can contain additional process types. For example, you might declare one for a background worker process that processes items off of a queue.

Microsoft Windows

Scale the app

You can check how many dynos are running using the ps command:

Scaling an application on Heroku is equivalent to changing the number of dynos that are running. Scale the number of web dynos to zero:

Access the app again by hitting refresh on the web tab, or heroku open to open it in a web tab. You will get an error message because you no longer have any web dynos available to serve requests.

Scale it up again:

For abuse prevention, scaling a non-free application to more than one dyno requires account verification.

Install app dependencies locally

Heroku recognizes an app as a Python app by looking for key files. Including a requirements.txt in the root directory is one way for Heroku to recognize your Python app.

To install the dependencies locally, we first want to create a “Virtual Environment” (also known as a “venv”) into which we can install the packages without affecting your system Python installation. To do this, run the following command:

Next, the virtual environment needs to be activated.

If you’re on a Microsoft Windows system, activate the venv using:

Or if you’re on a macOS/Linux system, activate the venv using:

For help with setting up a virtual environment, see the Python documentation.

Finally, the dependencies can now be installed into the newly created environment:

Note: Postgres must be properly installed in order for this step to work properly.

If you’re running Linux, the libpq-dev system package (or equivalent for your distribution) must also be installed.

Installing the dependencies also caused several other dependencies to be installed. You can see them by using pip’s feature list :

Once dependencies are installed, you will be ready to run your app locally.

Run the app locally

Before continuing, make sure the app’s dependencies have been installed locally.

The app is almost ready to start locally. Django uses local assets, so first, you’ll need to run collectstatic :

Respond with “yes”.

If you’re on a Microsoft Windows system, run this:

Or if you’re on a macOS/Linux system, use the default Procfile by running:

Your local web server will then start up:

Just like Heroku, heroku local examines the Procfile to determine what to run.

Open http://localhost:5000 with your web browser. You should see your app running locally.

If you see “Not Found” errors in your console, check that the collectstatic step above was run before starting the web server.

To stop the app from running locally, go back to your terminal window and press Ctrl + C to exit.

Push local changes

Add the requests package to your requirements.txt file:

And then use pip to install the requests package via the updated requirements.txt file:

Modify hello/views.py so that it imports the requests module at the start:

Now modify the index method to make use of the module. Try replacing the current index method with the following code:

Now test again locally.

If you’re on a Microsoft Windows system, run this:

Or if you’re on a macOS/Linux system, use the default Procfile by running:

Visit your application at http://localhost:5000. You should now see the output of fetching http://httpbin.org/status/418, which is a lovely teapot:

Now deploy. Almost every deploy to Heroku follows this same pattern. First, add the modified files to the local git repository:

Now commit the changes to the repository:

Now deploy, just as you did previously:

Finally, check that everything is working:

Provision add-ons

Add-ons are third-party cloud services that provide out-of-the-box additional services for your application, from persistence through logging to monitoring and more.

In this step you will provision one of these logging add-ons, Papertrail.

Provision the papertrail logging add-on:

The add-on is now deployed and configured for your application. You can list add-ons for your app like so:

Your browser will open up a Papertrail web console, showing the latest log events. The interface lets you search and set up alerts:

Start a console

The Python shell is running in the context of your app and all its dependencies. From here you can import some of your application files. For example, you will be be able to run the following:

Don’t forget to type exit to exit the shell and terminate the dyno.

Define config vars

At runtime, config vars are exposed as environment variables to the application.

Now modify the index method so that it repeats an action depending on the value of the TIMES environment variable:

If you run the app with heroku local and then visit http://localhost:5000, you’ll see two “Hello!”‘s.

To set the config var on Heroku, execute the following:

View the config vars that are set using heroku config :

Deploy your changed application to Heroku to see this in action.

Provision a database

The add-on marketplace has a large number of data stores, from Redis and MongoDB providers, to Postgres and MySQL. In this step you will learn about the free Heroku Postgres add-on that was automatically provisioned when your app was deployed.

A database is an add-on, and so you can find out a little more about the database provisioned for your app using the addons command in the CLI:

Listing the config vars for your app will display the URL that your app is using to connect to the database, DATABASE_URL :

Heroku also provides a pg command that shows a lot more:

This indicates I have a hobby database (free), running Postgres 13.5, with no data.

However, accessing it now will yield a relation «hello_greeting» does not exist error, because while the database is configured, the tables have not yet been created.

To create the hello_greeting table, run the standard Django manage.py migrate command:

Now access the /db route again and you’ll see a simple page update every time you access it:

Whenever you visit the /db route of your app, the following method in the hello/views.py file is invoked which creates a new Greeting and then renders all the existing Greetings:

Assuming that you have Postgres installed locally, use the heroku pg:psql command to connect to the remote database and see all the rows:

A similar technique can be used to install MongoDB or Redis add-ons.

Next steps

You now know how to deploy an app, change its configuration, view logs, scale, and attach add-ons.

Here’s some recommended reading. The first, an article, will give you a firmer understanding of the basics. The second is a pointer to the main Python category here on Dev Center: