The Flask Mega-Tutorial Part XVIII: Deployment on Heroku

Posted by
on under

This is the eighteenth installment of the Flask Mega-Tutorial series, in which I'm going to deploy Microblog to the Heroku cloud platform.

For your reference, below is a list of the articles in this series.

In the previous article I showed you the "traditional" way to host a Python application, and I gave you two actual examples of deployment to Linux based servers. If you are not used to manage a Linux system, you probably thought that the amount of effort that needs to be put into the task was big, and that surely there must be an easier way.

In this chapter I'm going to show you a completely different approach, in which you rely on a third-party cloud hosting provider to perform most of the administration tasks, freeing you to spend more time working on your application.

Many cloud hosting providers offer a managed platform on which applications can run. All you need to provide to have your application deployed on these platforms is the actual application, because the hardware, operating system, scripting language interpreters, database, etc. are all managed by the service. This type of service is called Platform as a Service, or PaaS.

Sounds too good to be true, right?

I will look at deploying Microblog to Heroku, a popular cloud hosting service that is very friendly for Python applications. I picked Heroku not only because it is popular, but also because it has a free service tier that will allow you to follow me and do a complete deployment without spending any money.

The GitHub links for this chapter are: Browse, Zip, Diff.

Hosting on Heroku

Heroku was one of the first platform as a service providers. It started as a hosting option for Ruby based applications, but then grew to support many other languages like Java, Node.js and of course Python.

Deploying a web application to Heroku is done through the git version control tool, so you must have your application in a git repository. Heroku looks for a file called Procfile in the application's root directory for instructions on how to start the application. For Python projects, Heroku also expects a requirements.txt file that lists all the module dependencies that need to be installed. After the application is uploaded to Heroku's servers through a git push operation, you are essentially done and just need to wait a few seconds until the application is online. It's really that simple.

The different service tiers Heroku offers allow you to choose how much computing power and time you get for your application, so as your user base grows you may outgrow the free allowance and will need to buy more units of computing, which Heroku calls "dynos".

Ready to try Heroku? Let's get started!

Creating a Heroku account

Before you can deploy to Heroku you need to have an account with them. So visit heroku.com and create a free account. Once you have an account and log in to Heroku, you will have access to a dashboard, where all your applications are listed.

Installing the Heroku CLI

Heroku provides a command-line tool for interacting with their service called Heroku CLI, available for Windows, Mac OS X and Linux. The documentation includes installation instructions for all the supported platforms. Go ahead and install it on your system if you plan on deploying the application to test the service.

The first thing you should do once the CLI is installed is login to your Heroku account:

$ heroku login

Heroku CLI will ask you to enter your email address and your account password. Your authenticated status will be remembered in subsequent commands.

Setting Up Git

The git tool is core to the deployment of applications to Heroku, so you must install it on your system if you don't have it yet. If you don't have a package available for your operating system, you can visit the git website to download an installer.

There are a lot of reasons why using git for your projects makes sense. If you plan to deploy to Heroku, you have one more, because to deploy to Heroku, your application must be in a git repository. If you are going to do a test deployment for Microblog, you can clone my version of this application from GitHub:

$ git clone https://github.com/miguelgrinberg/microblog
$ cd microblog
$ git checkout v0.18

The git checkout command selects the specific commit that has the application at the point in its history that corresponds to this chapter.

If you prefer to work with your own code instead of mine, you can transform your own project into a git repository by running git init . on the top-level directory (note the period after init, which tells git that you want to create the repository in the current directory). Once the git repository is created, use the git add command to add all your source files, and git commit to commit them to the repository.

Creating a Heroku Application

To register a new application with Heroku, you use the apps:create command from the root directory of the application, passing the application name as the only argument:

$ heroku apps:create flask-microblog
Creating flask-microblog... done
http://flask-microblog.herokuapp.com/ | https://git.heroku.com/flask-microblog.git

Heroku requires that applications have a unique name. The name flask-microblog that I used above is not going to be available to you because I'm using it, so you will need to pick a different name for your deployment.

The output of this command will include the URL that Heroku assigned to the application, and also its git repository on Heroku's servers. Your local git repository will be configured with an extra remote, called heroku set to this repository. You can verify that it exists with the git remote command:

$ git remote -v
heroku  https://git.heroku.com/flask-microblog.git (fetch)
heroku  https://git.heroku.com/flask-microblog.git (push)

Depending on how you created your git repository, the output of the above command could also include another remote called origin which is not used by Heroku.

The Ephemeral File System

The Heroku platform is different to other deployment platforms in that it features an ephemeral file system that runs on a virtualized platform. What does that mean? It means that at any time, Heroku can reset the virtual server on which your server runs back to a clean state. You cannot assume that any data that you save to the file system will persist, and in fact, Heroku recycles servers very often.

Working under these conditions introduces some problems for my application, which uses a few files:

  • The default SQLite database engine writes data in a disk file
  • Logs for the application are also written to the file system
  • The compiled language translation repositories are also written to local files

The following sections will address these three areas.

Working with a Heroku Postgres Database

To address the first problem, I'm going to switch to a different database engine. In Chapter 17 you saw me use a MySQL database to add robustness to the Ubuntu deployment. Heroku has a database offering of its own, based on the Postgres database, so I'm going to switch to that to avoid the file-based SQLite.

Databases for Heroku applications are provisioned with the same Heroku CLI. In this case I'm going to create a database on the free tier:

$ heroku addons:add heroku-postgresql:hobby-dev
Creating heroku-postgresql:hobby-dev on flask-microblog... free
Database has been created and is available
 ! This database is empty. If upgrading, you can transfer
 ! data from another database with pg:copy
Created postgresql-parallel-56076 as DATABASE_URL
Use heroku addons:docs heroku-postgresql to view documentation

The URL for the newly created database is stored in a DATABASE_URL environment variable that will be available when the application runs on Heroku's platform. This is very convenient, because the application already looks for the database URL in that variable.

To make sure that the DATABASE_URL variable is configured in your Heroku application, you can use the following command:

$ heroku config
DATABASE_URL:  postgres://...

An unfortunate problem with recent versions of SQLAlchemy is that they expect Postgres database URLs to begin with postgresql://, instead of the postgres:// that Heroku uses. To ensure that the application can connect to the database, it is necessary to update the URL to the format required by SQLAlchemy. This can be done with a string replacement operation in the Config class:

config.py: Fix Postgres database URLs to be compatible with SQLAlchemy.

class Config(object):
    # ...
    SQLALCHEMY_DATABASE_URI = os.environ.get('DATABASE_URL', '').replace(
        'postgres://', 'postgresql://') or \
        'sqlite:///' + os.path.join(basedir, 'app.db')
    # ...

This string replacement operation is safe to use even when the DATABASE_URL variable is set to a different database, in which case it will not affect it.

Logging to stdout

Heroku expects applications to log directly to stdout. Anything the application prints to the standard output is saved and returned when you use the heroku logs command. So I'm going to add a configuration variable that indicates if I need to log to stdout or to a file like I've been doing. Here is the change in the configuration:

config.py: Option to log to stdout.

class Config(object):
    # ...
    LOG_TO_STDOUT = os.environ.get('LOG_TO_STDOUT')

Then in the application factory function I can check this configuration to know how to configure the application's logger:

app/__init__.py: Log to stdout or file.

def create_app(config_class=Config):
    # ...
    if not app.debug and not app.testing:
        # ...

        if app.config['LOG_TO_STDOUT']:
            stream_handler = logging.StreamHandler()
            stream_handler.setLevel(logging.INFO)
            app.logger.addHandler(stream_handler)
        else:
            if not os.path.exists('logs'):
                os.mkdir('logs')
            file_handler = RotatingFileHandler('logs/microblog.log',
                                               maxBytes=10240, backupCount=10)
            file_handler.setFormatter(logging.Formatter(
                '%(asctime)s %(levelname)s: %(message)s '
                '[in %(pathname)s:%(lineno)d]'))
            file_handler.setLevel(logging.INFO)
            app.logger.addHandler(file_handler)

        app.logger.setLevel(logging.INFO)
        app.logger.info('Microblog startup')

    return app

So now I need to set the LOG_TO_STDOUT environment variable when the application runs in Heroku, but not in other configurations. The Heroku CLI makes this easy, as it provides an option to set environment variables to be used at runtime:

$ heroku config:set LOG_TO_STDOUT=1
Setting LOG_TO_STDOUT and restarting flask-microblog... done, v4
LOG_TO_STDOUT: 1

Compiled Translations

The third aspect of Microblog that relies on local files is the compiled language translation files. The more direct option to ensure those files never disappear from the ephemeral file system is to add the compiled language files to the git repository, so that they become part of the initial state of the application once it is deployed to Heroku.

A more elegant option, in my opinion, is to include the flask translate compile command in the start up command given to Heroku, so that any time the server is restarted those files are compiled again. I'm going to go with this option, since I know that my start up procedure is going to require more than one command anyway, asI also need to run the database migrations. So for now, I will set this problem aside, and will revisit it later when I write the Procfile.

Elasticsearch Hosting

Elasticsearch is one of the many services that can be added to a Heroku project, but unlike Postgres, this is not a service provided by Heroku, but by third parties that partner with Heroku to provide add-ons. At the time I'm writing this, there are three different providers of an integrated Elasticsearch service.

Before you configure Elasticsearch, be aware that Heroku requires your account to have a credit card on file before any third party add-on is installed, even if you stay within the free tier. If you prefer not to provide your credit card to Heroku, then skip this section. You will still be able to deploy the application, but the search functionality is not going to be enabled.

Out of the Elasticsearch options that are available as add-ons, I decided to try SearchBox, which comes with a free starter plan. To add SearchBox to your account, you have to run the following command while being logged in to Heroku:

$ heroku addons:create searchbox:starter

This command will deploy an Elasticsearch service and leave the connection URL for the service in a SEARCHBOX_URL environment variable associated with your application. Once more keep in mind that this command will fail unless you add your credit card to your Heroku account.

If you recall from Chapter 16, my application looks for the Elasticsearch connection URL in the ELASTICSEARCH_URL variable, so I need to add this variable and set it to the connection URL assigned by SearchBox:

$ heroku config:get SEARCHBOX_URL
<your-elasticsearch-url>
$ heroku config:set ELASTICSEARCH_URL=<your-elasticsearch-url>

Here I first asked Heroku to print the value of SEARCHBOX_URL, and then I added a new environment variable with the name ELASTICSEARCH_URL set to that same value.

Many other features of the application are also configured through environment variables, for example SECRET_KEY, MS_TRANSLATOR_KEY, MAIL_SERVER and a few more. These variables need to also be copied over to the Heroku deployment, so that they are accessible to the application. The heroku config:set can be used to transfer these variables from your .env file to Heroku.

The exampe below configures a secret key:

heroku config:set SECRET_KEY=7853fbd853a249c586f7d810a7938b43

Updates to Requirements

Heroku expects the dependencies to be in the requirements.txt file, exactly like I defined it in Chapter 15. But for the application to run on Heroku I need to add two new dependencies to this file.

Heroku does not provide a web server of its own. Instead, it expects the application to start its own web server on the port number given in the environment variable $PORT. Since the Flask development web server is not robust enough to use for production, I'm going to use gunicorn again, the server recommended by Heroku for Python applications.

The application will also be connecting to a Postgres database, and for that SQLAlchemy requires the psycopg2 or psycopg2-binary packages to be installed. The binary version is, in general, preferred as it installs an already built version of this package, as opposite to psycopg2 which requires a C compiler to be installed to build the package during installation.

Both gunicorn and psycopg2-binary need to be added to the requirements.txt file.

The Procfile

Heroku needs to know how to execute the application, and for that it uses a file named Procfile in the root directory of the application. The format of this file is simple, each line includes a process name, a colon, and then the command that starts the process. The most common type of application that runs on Heroku is a web application, and for this type of application the process name should be web. Below you can see a Procfile for Microblog:

Procfile: Heroku Procfile.

web: flask db upgrade; flask translate compile; gunicorn microblog:app

Here I defined the command to start the web application as three commands in sequence. First I run a database migration upgrade, then I compile the language translations, and finally I start the server.

Because the first two sub-commands are based on the flask command, I need to add the FLASK_APP environment variable:

$ heroku config:set FLASK_APP=microblog.py
Setting FLASK_APP and restarting flask-microblog... done, v6
FLASK_APP: microblog.py

The application also relies on other environment variables, such as those that configure the email server or the token for the live translations. Those need to be added with more heroku config:set commands.

The gunicorn command is simpler than what I used for the Ubuntu deployment, because this server has a very good integration with the Heroku environment. For example, the $PORT environment variable is honored by default, and instead of using the -w option to set the number of workers, heroku recommends adding a variable called WEB_CONCURRENCY, which gunicorn uses when -w is not provided, giving you the flexibility to control the number of workers without having to modify the Procfile.

Deploying the Application

All the preparatory steps are complete, so now it is time to run the deployment. To upload the application to Heroku's servers for deployment, the git push command is used. This is similar to how you push changes in your local git repository to GitHub or other remote git server.

There are a couple of variations on how to do this, depending on how you created your git repository. If you are using my v0.18 code, then you need to create a branch based on this tag, and push it as the remote main branch, as follows:

$ git checkout -b deploy
$ git push heroku deploy:main

If instead, you are working with your own repository, then your code is already in a main or master branch, so you first need to make sure that your changes are committed:

$ git commit -a -m "heroku deployment changes"

And then you can run the following to start the deployment:

$ git push heroku main  # you may need to use "master" instead of "main"

Regardless of how you push the branch, you should see the following output from Heroku:

$ git push heoroku deploy:main
Enumerating objects: 264, done.
Counting objects: 100% (264/264), done.
Delta compression using up to 12 threads
Compressing objects: 100% (183/183), done.
Writing objects: 100% (264/264), 59.44 KiB | 5.94 MiB/s, done.
Total 264 (delta 132), reused 143 (delta 62)
remote: Compressing source files... done.
remote: Building source:
remote:
remote: -----> Building on the Heroku-20 stack
remote: -----> Determining which buildpack to use for this app
remote: -----> Python app detected
remote: -----> No Python version was specified. Using the buildpack default: python-3.9.6
remote:        To use a different version, see: https://devcenter.heroku.com/articles/...
remote: -----> Installing python-3.9.6
remote: -----> Installing pip 20.2.4, setuptools 47.1.1 and wheel 0.36.2
remote: -----> Installing SQLite3
remote: -----> Installing requirements with pip
...
remote:
remote: -----> Discovering process types
remote:        Procfile declares types -> web
remote:
remote: -----> Compressing...
remote:        Done: 69.2M
remote: -----> Launching...
remote:        Released v7
remote:        https://flask-microblog.herokuapp.com/ deployed to Heroku
remote:
remote: Verifying deploy... done.
To https://git.heroku.com/flask-microblog.git
 * [new branch]      deploy -> main

The label heroku that we used in the git push command is the remote that was automatically added by the Heroku CLI when the application was created. The deploy:main argument means that I'm pushing the code from the local repository referenced by the deploy branch to the main branch on the Heroku repository. When you work with your own projects, you will likely be pushing with the command git push heroku main, which pushes your local main branch. Because of the way this project is structured, I'm pushing a branch that is not main, but the destination branch on the Heroku side always needs to be main or master as those are the only branch names that Heroku accepts for deployment.

And that is it, the application should now be deployed at the URL that you were given in the output of the command that created the application. In my case, the URL was https://flask-microblog.herokuapp.com, so that is what I need to type to access the application.

If you want to see the log entries for the running application, use the heroku logs command. This can be useful if for any reason the application fails to start. If there were any errors, those will be in the logs.

Deploying Application Updates

To deploy a new version of the application, you just need to run a new git push command with the new code. This will repeat the deployment process, take the old deployment offline, and then replace it with the new code. The commands in the Procfile will run again as part of the new deployment, so any new database migrations or translations will be updated during the process.

Become a Patron!

Hello, and thank you for visiting my blog! If you enjoyed this article, please consider supporting my work on this blog on Patreon!

223 comments
  • #1 Boudhayan said

    This has been my most enjoyable and knowledgeable tutorial series on the web. Thank you for providing such tremendous quality of knowledge for free.

    I was curious to know how do you implement the comment section of this blog ( https://blog.miguelgrinberg.com ) . Say, I made a website which allowed visitors to leave their feedback. How would I enable those comments to be seen publicly (as your blog does ) after I have reviewed them ? I realize that I'll need a database to store the feedbacks I receive. But how would I ensure a verification process (for the feedbacks) before they appear on the blog ? And also, if we are using a database to store the feedback, how do you read and verify them before allowing them on your blog ? Do you use the flask shell to load the feedback from the database starting from the last timestamp that you had covered or there is another way ?

    It would be really helpful if you could provide some light on this topic.

    Thanks and regards,
    Boudhayan

  • #2 Miguel Grinberg said

    @Boudhayan: I actually included comments and comment moderation in a class I gave at PyCon a few years ago: https://www.youtube.com/watch?v=FGrIyBDQLPg

  • #3 Bob said

    Hi Miguel,
    Is there any chance you could do some supplemental tutorials about best practices for handling user authorization/roles/permissions? Thanks for all the hard work. Your blog is great.

  • #4 Miguel Grinberg said

    @Bob: I'm not planning to expand this tutorial in the near future, but I have included a role system based on decorators in my Flask Web Development book. You can see the code here: https://github.com/miguelgrinberg/flasky.

  • #5 John Smith said

    I've managed to get everything up and running, except for search. Card is on file and I've followed the instructions for everything, but when running the actual app, attempting to add a new post or search for something results in an application error and shows urllib3.exceptions.ConnectTimeoutError: (<urllib3.connection.VerifiedHTTPSConnection object at 0x7f3fba7174a8>, 'Connection to thorin-us-east-1.searchly.com timed out. (connect timeout=10) in the logs. I tried using Bansai Elasticsearch to see if that helps, but that results in something similar elasticsearch.exceptions.NotFoundError: TransportError(404, 'index_not_found_exception', "no such index and [action.auto_create_index] ([*logstash*,*requests*,*events*,*.kibana*,*kibana-int*,*filebeat*]) doesn't match").

    It seems like it might be something to do with the indexes not getting created. I already tried Post.reindex(), which raises the same errors. Elasticsearch works fine locally in the development environment, so I am not sure what the issue is.

  • #6 Miguel Grinberg said

    @John: Connection timeout means that the service isn't accepting connections. Either the connection URL is wrong, or the service is down. You need to troubleshoot this outside of the application. Can you connect to this service directly, for example?

  • #7 John Smith said

    Thanks, Miguel. It turns out that it was two problems.

    The first was caused by using the SEARCHBOX_URL. When I switched to using the URL corresponding to SEARCHBOX_SSL_URL as the ELASTICSEARCH_URL it connected fine (Bansai always connected fine as it uses secure protocol by default). There was then the second problem which was caused by the lack of an index. When I created an index called 'post' in the 3rd-party service it started working perfectly.

  • #8 Sam said

    Hi Miguel,
    Thanks a lot for your fantastic tutorials. I've been learning almost all I know about Flask thanks to you.
    Regarding your Procfile for Heroku, wouldn't it be a good idea to include a line with:
    release: flask db upgrade
    It would tell Heroku to launch the upgrade script every time a new deploy occurs, as described here: https://devcenter.heroku.com/articles/release-phase

    It doesn't hurt to launch the db upgrade every time the dyno is started (like you do) but it seems better to run this only when needed (ie after a code deploy).

    Regards and thanks again,

    Samuel

  • #9 Miguel Grinberg said

    @Sam: I guess for the database migrations that would work, but that's not the only thing you need to do. For example, there is also compiling the language translations, which needs to be done every time a new dyno is started because the result is written to the ephemeral file system.

  • #10 Rohan said

    You said that "heroku recommends adding a variable called WEB_CONCURRENCY". Did you mean to set a value for that variable?

    Also, does StreamHandler have to be imported from logging.handlers, along with SMTPHandler and RotatingFileHandler?

  • #11 Miguel Grinberg said

    @Rohan: you can set WEB_CONCURRENCY, but if you don't Heroku provides a sensible default for it. And yes, StreamHandler needs to be imported. If you ever have questions regarding the code, remember that the GitHub repository for this project has working code that you can check to see the actual implementation.

  • #12 Rohan said

    When I deployed to Heroku, I got this error (in heroku logs):

    KeyError: 'LOG_TO_STDOUT'

    And as a result, the app never loaded. No idea what caused the error: I added the LOG_TO_STDOUT config var, I also edited app/init.py according to your instructions, and I set the LOG_TO_STDOUT environment var in Heroku.

    Then I commented out:

    <h1>if app.config['LOG_TO_STDOUT']:</h1>
        #    stream_handler = logging.StreamHandler()
        #    stream_handler.setLevel(logging.INFO)
        #    app.logger.addHandler(stream_handler)
        #else:
    

    After commenting out those lines, the app has deployed successfully.

    Separate question: How do I manage the database? I can't just use flask shell, like I could with SQLite while in development.

    Thanks, Miguel.

  • #13 Miguel Grinberg said

    @Rohan: for the LOG_TO_STDOUT problem, you forgot to add this configuration item to the Config class. You can compare your code against mine in GitHub if you need help finding out mistakes of this type. Regarding database management, there are a couple of ways to do it, but you can see in this article that I have included the database upgrade as part of the "web" task in the Procfile, so each time you deploy a new version the database will be upgraded. You can also use the "heroku run" command to run any commands in the context of your application, including those that manage the database.

  • #14 Rohan said

    Actually, I did add LOG_TO_STDOUT to the Config class, which makes this error even more bizarre. Can't figure it out.

    Another odd thing is that making a blog post is causing a ConnectTimeoutError:

    urllib3.exceptions.ConnectTimeoutError: (<urllib3.connection.HTTPConnection object at 0x7f5828730748>, 'Connection to thorin-us-east-1.searchly.com timed out. (connect timeout=10)')

    In the logs, it also says: "socket.timeout: timed out". There are no issues with making blog posts when I run the app in localhost. There don't seem to be any such issues in your app at flask-microblog.herokuapp.com. Any ideas why this is happening in my deployment? Thank you.

  • #15 Miguel Grinberg said

    @Rohan: your search service appears to be done, or you are using the wrong URL. Disable the search by removing the search URL configuration variable if you want to prevent this error from stopping your application.

  • #16 John said

    Hi Miguel. Thank you for both the mega tutorial and for your books. I'm new to programming and these have been extremely useful in my learning.

    I'm having a little bit of trouble when it comes to deploying to Heroku and wondered if you might be able to help. I've customised a wtforms field (I'm using a MultiCheckboxField with SelectMultipleField as its base). It works fine locally but when I try to deploy I get " ImportError: cannot import name 'MultiCheckboxField' ". I'm assuming this is just because the customised field is in my venv and the venv is included in the .gitignore file. How can I get my customised field deployed so that it is available to my app? Thank you.

  • #17 Miguel Grinberg said

    @John: did you update your requirements.txt file so that it includes all the dependencies that you are using?

  • #18 Diego said

    Hello Miguel, excellent tutorial so far, it's helped immensely. But now that I'm deploying my application, all the css is working perfectly but the JavaScripted (liked through a CDN) is not loading at all. Any ideas as to what the problem could be? Thanks!

  • #19 Miguel Grinberg said

    @Diego: it's impossible for me to know since I have no information on your set up. Look in the browser console to see what error you get, not sure what other advice I can give you with this little information. Maybe write a question with more details on stack overflow?

  • #20 Chris said

    I can't get Heroku to send email neither to request a password reset or to send my blog posts as instructed in Chapter 22. my .env file is in my .gitignore file, so it's not being pushed to Heroku. Online I read that Heroku handles this with config vars: https://devcenter.heroku.com/articles/config-vars. Is this what I should be doing? And how would that change my app to find those config vars that are no longer in my .env file?

  • #21 Miguel Grinberg said

    @Chris: There are a couple of examples in this article that show how to set environment variables for Heroku. For example, look at the LOG_TO_STDOUT variable. Any other variables that you need, such as MAIL_SERVER can be set in the same way.

  • #22 Bruno said

    I had the same problem as @Chris, even after I set all variables according to Chapter 10

    (venv) $ export MAIL_SERVER=smtp.googlemail.com
    (venv) $ export MAIL_PORT=587
    (venv) $ export MAIL_USE_TLS=1
    (venv) $ export MAIL_USERNAME=<your-gmail-username>
    (venv) $ export MAIL_PASSWORD=<your-gmail-password>

    What would you recommend I do? Am I misunderstanding something fundamental about how the emails are being sent when run on Heroku? Thank you for an incredible tutorial

  • #23 Miguel Grinberg said

    @Bruce: when you use "export", you are setting your variables on your own system, not on Heroku. To set an environment variable for your app running on Heroku you have to use the "heroku config:set" command. See in this article how I set the LOG_TO_STDOUT variable for an example.

  • #24 Bruno said

    I set them the correct way, for the above comment I copy and pasted the chapter 10 section to explain which variables I had set, but that wasn't my problem. I checked "heroku logs" and saw that I was getting a "ConnectionRefusedError" on one occasion and an Authentication Error on another, but after playing with my google security settings I got it to work. Problem resolved!

  • #25 Carlos said

    Hi Miguel, first I want to thank you for this awesome tutorial, and ask you if it's a good idea to create a table in the database to store the config parameters like posts per page, email settings, admin emails and thinks like the website name, etc.

    Thank Yout!

Leave a Comment