aviraldg
aviraldg

Reputation: 9154

How can I detect Heroku's environment?

I have a Django webapp, and I'd like to check if it's running on the Heroku stack (for conditional enabling of debugging, etc.) Is there any simple way to do this? An environment variable, perhaps?

I know I can probably also do it the other way around - that is, have it detect if it's running on a developer machine, but that just doesn't "sound right".

Upvotes: 43

Views: 15095

Answers (8)

paulmelnikow
paulmelnikow

Reputation: 17208

There is no need to set your own config variable.

The best one to use here is $DYNO. It is documented, and always set by Heroku, both during build time and runtime.

(Heroku Labs Dyno Metadata provides some other options, but they only are set when Dyno Metadata is turned on. They haven't changed in years nor been added to the platform, but theoretically they are more "subject to change.")

Upvotes: 0

Rebs
Rebs

Reputation: 4239

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

Upvotes: 2

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.

Upvotes: 1

Neil Middleton
Neil Middleton

Reputation: 22238

An ENV var seems to the most obvious way of doing this. Either look for an ENV var that you know exists, or set your own:

on_heroku = False
if 'YOUR_ENV_VAR' in os.environ:
  on_heroku = True

more at: http://devcenter.heroku.com/articles/config-vars

Upvotes: 27

Ryan Shea
Ryan Shea

Reputation: 4302

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

Upvotes: 19

Sergey Orshanskiy
Sergey Orshanskiy

Reputation: 7054

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=='UTC\n': 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

Upvotes: 0

ilovett
ilovett

Reputation: 3388

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

Upvotes: 16

Jabba
Jabba

Reputation: 20624

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

Upvotes: 3

Related Questions