How can I detect Heroku's environment?

Similar to what Neil suggested, I would do the following:

debug = True
if 'SOME_ENV_VAR' in os.environ:
    debug = False

I’ve seen some people use if 'PORT' in os.environ: But the unfortunate thing is that the PORT variable is present when you run foreman start locally, so there is no way to distinguish between local testing with foreman and deployment on Heroku.

I’d also recommend using one of the env vars that:

1. Heroku has out of the box (rather than setting and checking for your own)
2. is unlikely to be found in your local environment

At the date of posting, Heroku has the following environ variables:

['PATH', 'PS1', 'COLUMNS', 'TERM', 'PORT', 'LINES', 'LANG', 'SHLVL', 'LIBRARY_PATH', 'PWD', 'LD_LIBRARY_PATH', 'PYTHONPATH', 'DYNO', 'PYTHONHASHSEED', 'PYTHONUNBUFFERED', 'PYTHONHOME', 'HOME', '_']

I generally go with if 'DYNO' in os.environ:, because it seems to be the most Heroku specific (who else would use the term dyno, right?).

And I also prefer to format it like an if-else statement because it’s more explicit:

if 'DYNO' in os.environ:
    debug = False
else:
    debug = True

Read more about it here: https://devcenter.heroku.com/articles/config-vars

My solution:

$ heroku config:set HEROKU=1

These environment variables are persistent – they will remain in place across deploys and app restarts – so unless you need to change values, you only need to set them once.

Then you can test its presence in your app.:

>>> 'HEROKU' in os.environ
True

First set the environment variable ON_HEROKU on heroku:

$ heroku config:set ON_HEROKU=1

Then in settings.py

import os

# define if on heroku environment
ON_HEROKU = 'ON_HEROKU' in os.environ

Short version: check that the time zone is UTC/GMT:

if not 'ORIGINAL_TIMEZONE' in os.environ:
    f = os.popen('date +%Z')
    tz = f.read().upper()
    os.environ['ORIGINAL_TIMEZONE']=tz


tz = os.environ['ORIGINAL_TIMEZONE']
if tz != '' and (not 'utc' in tz.lower()) and (not 'gmt' in tz.lower()):
    print 'Definitely not running on Heroku (or in production in general)'
else:
    print 'Assume that we are running on Heroku (or in production in general)'

This is more conservative than if tz=='UTCn': if in doubt, assume that we are in production. Note that we are saving the timezone to an environment variable because settings.py may be executed more than once. In fact, the development server executes it twice, and the second time the system timezone is already ‘UTC’ (or whatever is in settings.TIMEZONE).

Long version:

making absolutely sure that we never run on Heroku with DEBUG=True, and that we never run the development server on Heroku even with DEBUG=False. From settings.py:

RUNNING_DEV_SERVER = (len(sys.argv) > 1) and (sys.argv[1] == 'runserver')

DEBUG = RUNNING_DEV_SERVER

TEMPLATE_DEBUG = DEBUG

# Detect the timezone
if not 'ORIGINAL_TIMEZONE' in os.environ:
    f = os.popen('date +%Z')
    tz = f.read().upper()
    os.environ['ORIGINAL_TIMEZONE']=tz
    print ('DEBUG: %d, RUNNING_DEV_SERVER: %d, system timezone: %s ' % (DEBUG, RUNNING_DEV_SERVER, tz))


if not (DEBUG or RUNNING_DEV_SERVER):
    SECRET_KEY = os.environ['SECRET_KEY']
else:
    print 'Running in DEBUG MODE! Hope this is not in production!'

    SECRET_KEY = 'DEBUG_INSECURE_SECRET_KEY_ae$kh(7b%$+a fcw_bdnzl#)$t88x7h2-p%eg_ei5m=w&2p-)1+'

    # But what if we are idiots and are still somehow running with DEBUG=True in production?!
    # 1. Make sure SECRET_KEY is not set
    assert not SECRET_KEY in os.environ
    # 2. Make sure the timezone is not UTC or GMT (indicating production)

    tz = os.environ['ORIGINAL_TIMEZONE']
    assert tz != '' and (not 'UTC' in tz) and (not 'GMT' in tz)

    # 3. Look for environment variables suggesting we are in PROD
    for key in os.environ:
        for red_flag in ['heroku', 'amazon', 'aws', 'prod', 'gondor']:
            assert not red_flag in key.lower()
            assert not red_flag in os.environ[key].lower()

If you really want to run the development server on Heroku, I suggest you add an environment variable specifying the date when you can do that. Then only proceed if this date is today. This way you’ll have to change this variable before you begin development work, but if you forget to unset it, next day you will still be protected against accidentally running it in production. Of course, if you want to be super-conservative, you can also specify, say, a 1-hour window when exceptions apply.

Lastly, if you decided to adopt the approach suggested above, while you are at it, also install django-security, add djangosecurity to INSTALLED_APPS, and add to the end of your settings.py:

if not (DEBUG or RUNNING_DEV_SERVER):
    ### Security
    SECURE_SSL_REDIRECT = True
    SECURE_CONTENT_TYPE_NOSNIFF = True

    SECURE_HSTS_SECONDS = 86400000
    SECURE_HSTS_INCLUDE_SUBDOMAINS = True
    SECURE_BROWSER_XSS_FILTER = True

    SESSION_COOKIE_SECURE = True
    SESSION_COOKIE_HTTPONLY = True
    CSRF_COOKIE_HTTPONLY = True # May have problems with Ajax
    CSRF_COOKIE_SECURE = True

DATABASE_URL environment variable

in_heroku = False
if 'DATABASE_URL' in os.environ:
    in_heroku = True

I think you need to enable the database for your app with:

heroku addons:create heroku-postgresql:hobby-dev

but it is free and likely what you are going to do anyways.

Heroku makes this environment variable available when running its apps, in particular for usage as:

import dj_database_url
if in_heroku:
    DATABASES = {'default': dj_database_url.config()}
else:
    DATABASES = {
        'default': {
            'ENGINE': 'django.db.backends.sqlite3',
            'NAME': os.path.join(BASE_DIR, 'db.sqlite3'),
        }
    }

Not foolproof as that variable might be defined locally, but convenient for simple cases.

heroku run env

might also show other possible variables like:

• DYNO_RAM
• WEB_CONCURRENCY

but I’m not sure if those are documented like DATABASE_URL.

The most reliable way would be to set an environment variable as above.
If that’s not possible, there are a few signs you can look for in the filesystem, but they may not be / are not foolproof

• Heroku instances all have the path /app – the files and scripts that are running will be under this too, so you can check for the presence of the directory and/or that the scripts are being run from under it.

• There is an empty directory /etc/heroku

• /etc/hosts may have some heroku related domains added
  
~ $ cat /etc/hosts
<snip>.dyno.rt.heroku.com


Any of these can and may change at any moment.

Your milage may vary