Python FAQ

Last Updated: 19 March 2014

python

Table of Contents

If you have questions about Python on Heroku, consider discussing it in the Python on Heroku forums. Both Heroku and community-based Python experts are available.

How is a Python application detected?

Python applications are detected by the presence of requirements.txt at the root of the repository.

What version of Python?

Your application will run by default on CPython 2.7.4 (64bit), contained within a distribute flavored virtualenv.

You can also specify an arbitrary version of Python to be used to run your application. See Specifying a Python Runtime for more details.

Can I use build systems other than pip?

No. Heroku uses pip to build your application. You must specify a requirements.txt file at the top level of your project.

Pip can be used for advanced dependency management. See Python Dependencies via Pip to learn more.

Does pip support packages in Git repositories?

It does! Pip can be used for advanced dependency management. See Python Dependencies via Pip to learn more.

Can I require modules with C extensions?

Yes. If the module will install properly with pip. Most libraries that are required for web applications are available at build time.

However, sometimes a shared library needed for a module isn’t available. If this becomes a problem for you, you should contact support@heroku.com for help.

Can I run Python applications free of charge?

Yes. The Heroku Cedar stack (the stack that supports Python) comes with 750 free dyno hours per app per month. Beyond that, you must pay for what you use.

Can I deploy WSGI Python web applications?

Yes. You can build and deploy Python any web applications that use the standard WSGI interface. The only requirement is that you explicitly declare dependencies, including your HTTP Server, using pip. Read the Introduction to Python for Heroku and check out the Django tutorial for more information.

Do Python applications run behind Nginx?

No. There is no need for using a reverse proxy on Heroku because the Heroku Cloud Platform takes care of everything those servers normally do for you.

Your application simply provides a Python server to respond to HTTP requests. Gunicorn, Gevent, and Eventlet are excellent options.

Because the web server is embedded in your application, you can easily test and debug the exact same code in any environment. This development and production parity makes it easy to troubleshoot problems during your development cycle.

If you have a Heroku specific problem, you can always contact support@heroku.com for help.

Can I spawn and control threads and subprocesses?

Yes.

Does my Python application have to be a webapp?

No. In fact, to Heroku there is no difference between a stand-alone application and a web application. They are both Python processes. The web application just happens to listen for web requests on a TCP port.

Your application can be run either as a worker process (that never exits) or as a one-off batch script that you launch with the heroku run command.

Can I read from and write to the file system?

Yes. But the file system is ephemeral. Any data you write to the file system will not be available to other processes of your application. Generally you can assume that a file written in the beginning of a request will be available for the duration of the request, subject to the previous constraint (your dynos may get restarted in the middle of a request). Do not rely on the local filesystem for any data you want to keep around.

What happens to data written to standard out?

Standard out is piped to the Heroku logging service. You can use the heroku logs command to retrieve this log stream (in streaming mode if you add the –tail options). You can also add syslog sinks that will retrieve the log stream and can store it in log files or index it for searching and reporting.

What constraints exist when developing applications on Heroku?

Here are some things to keep in mind when designing applications on Heroku

  • Your application source code plus built artifacts must be less than 200MB. Use .slugignore to prevent files in your git repo from being included in the deployed package.
  • You can have many process types in a single application, but only one of those types can be a web process type that receives requests from the routing layer.
  • The web process type must listen on one and only one port. The port must be the one specified in the $PORT environment variable. If your process listens on other ports, it will be shut down by Heroku.
  • HTTP Requests from clients will be distributed randomly to all dynos running your application.
  • Processes running on different dynos cannot communicate directly with each other. For example, they cannot replicate state between them. Heroku is a share-nothing architecture where each node is completely isolated.
  • A single dyno (for example, a single instance of your web process type) may be restarted by Heroku at any point in time. Your application must be designed to anticipate restarts without losing data or affecting the user experience in a material way. Your process will receive a SIGTERM signal before it is killed. You can trap this signal to perform an orderly shutdown.
  • Any data you write to the file system will not be available to other dynos of your application. Generally you can assume that a file written in the beginning of a request will be available for the duration of the request, subject to the previous constraint (your dyno may get restarted in the middle of a request). Do not rely on the local filesystem for any data you want to keep around.
  • Your application must boot in one minute or less.

Can I Use Heroku Postgres Databases With Python?

Yes. You can connect to a Heroku Postgres database from Python. You can use any database driver or any other means of connectivity that you’re used to. You can also connect to a Heroku Postgres database from your local machine to troubleshoot your application. The Dev Center has more information on Heroku Postgres.