Create a Minimal Configuration for Heroku

00:00 So far, you have started a Django project, you have created a local Git repository, and hooked it up to a Heroku app. Heroku recognized distinctive Python files, but it failed to build and host your project due to a misconfiguration.

00:16 In this lesson, you’ll configure your Django project for the Heroku platform. Start by looking at the Heroku CLI’s output, and don’t get scared off by the error messages as they will often point you in the right direction. In this case, Heroku automatically runs the collectstatic command, which is admittedly a bit tricky to set up. It’s a quick and dirty work around.

00:39 You can disable this static file collection for now. Just copy and paste the suggested command, setting an environment variable on a remote Heroku server.

00:49 You’ll learn more about managing configuration on Heroku in the next lesson. Now, push your code to Heroku again and wait until the build finishes.

01:03 This time, everything seems to work fine, but when you open the Heroku app in the browser, then you’ll see an unspecified error with a tip on how to investigate it.

01:12 Use this command to check the logs.

01:18 They might take a few seconds to load, though. Ah ha! So the build actually succeeded, but Heroku doesn’t know how to run your web application yet. You need to tell it explicitly by creating a Heroku-specific Procfile in your project root folder and define the command to run a web process.

01:39 For the sake of simplicity of this exercise, you’ll use the same Django development server as before. But please, never do this in production or else you’ll face severe performance issues and expose your project to a host of security vulnerabilities. In real life, you’d want to use a high-performance web server compliant with a WSGI interface, such as Gunicorn. I’ll show you how to use one in a bit.

02:04 Now, it’s essential to bind to the public network interface at 0.0.0.0 instead of the localhost address to allow inbound traffic from anywhere on the internet into your Django app hosted on Heroku.

02:17 Otherwise, your project would remain inaccessible to the outside world. You also need to specify the port number that Heroku will listen at. Conveniently, it provides one through an environment variable named PORT.

02:32 Remember that every time you make changes to your codebase, you need to commit them to your local Git repository before pushing them to Heroku.

02:50 The subsequent builds of your project will take less time as long as you haven’t modified your dependencies because Heroku has already cached them. When finished, go to your web browser and refresh the page or type heroku open in the terminal again.

03:08 Now you’ll see a familiar Django stack trace, which is enabled in debug mode. That’s a good sign. It means your Django development server is finally receiving HTTP requests, and it tells you exactly what to do.

03:21 You need to add the public domain address of your web app to ALLOWED_HOSTS in Django’s settings, so go ahead and do that.

03:35 This will prevent HTTP host header attacks by allowing only the specified domains to access Django. By the way, when deploying to production, be sure to disable the debug mode and provide the secret key through an environment variable rather than hard-coding it.

03:53 You might want to review the deployment checklist in the official Django documentation for more details and best practices.

04:04 Okay. Let’s commit your change and trigger the build once more.

04:26 Nice! You’ve just got yourself a working Django project in the cloud. Its configuration is far from being complete, and there’s much more left to tweak, but that’s the subject of the next lesson.