Manage Django sites

salt.modules.djangomod.collectstatic(settings_module, bin_env=None, no_post_process=False, ignore=None, dry_run=False, clear=False, link=False, no_default_ignore=False, pythonpath=None, env=None, runas=None)

Collect static files from each of your applications into a single location that can easily be served in production.

CLI Example:

salt '*' django.collectstatic <settings_module>
salt.modules.djangomod.command(settings_module, command, bin_env=None, pythonpath=None, env=None, runas=None, *args, **kwargs)

Run arbitrary django management command

CLI Example:

salt '*' django.command <settings_module> <command>
salt.modules.djangomod.createsuperuser(settings_module, username, email, bin_env=None, database=None, pythonpath=None, env=None, runas=None)

Create a super user for the database. This function defaults to use the --noinput flag which prevents the creation of a password for the superuser.

CLI Example:

salt '*' django.createsuperuser <settings_module> user
salt.modules.djangomod.loaddata(settings_module, fixtures, bin_env=None, database=None, pythonpath=None, env=None)

Load fixture data


comma separated list of fixtures to load

CLI Example:

salt '*' django.loaddata <settings_module> <comma delimited list of fixtures>
salt.modules.djangomod.migrate(settings_module, app_label=None, migration_name=None, bin_env=None, database=None, pythonpath=None, env=None, noinput=True, runas=None)

Run migrate

Execute the Django-Admin migrate command (requires Django 1.7 or higher).

New in version 3000.


Specifies the settings module to use. The settings module should be in Python package syntax, e.g. mysite.settings. If this isn’t provided, django-admin will use the DJANGO_SETTINGS_MODULE environment variable.


Specific app to run migrations for, instead of all apps. This may involve running other apps’ migrations too, due to dependencies.


Named migration to be applied to a specific app. Brings the database schema to a state where the named migration is applied, but no later migrations in the same app are applied. This may involve unapplying migrations if you have previously migrated past the named migration. Use the name zero to unapply all migrations for an app.


Path to pip (or to a virtualenv). This can be used to specify the path to the pip to use when more than one Python release is installed (e.g. /usr/bin/pip-2.7 or /usr/bin/pip-2.6. If a directory path is specified, it is assumed to be a virtualenv.


Database to migrate. Defaults to 'default'.


Adds the given filesystem path to the Python import search path. If this isn’t provided, django-admin will use the PYTHONPATH environment variable.


A list of environment variables to be set prior to execution.

  - name: django.migrate
  - settings_module: my_django_app.settings
  - env:
    - DATABASE_USER: 'mydbuser'

Suppresses all user prompts. Defaults to True.


The user name to run the command as.

CLI Example:

salt '*' django.migrate <settings_module>
salt '*' django.migrate <settings_module> <app_label>
salt '*' django.migrate <settings_module> <app_label> <migration_name>
salt.modules.djangomod.syncdb(settings_module, bin_env=None, migrate=False, database=None, pythonpath=None, env=None, noinput=True, runas=None)

Run syncdb

Execute the Django-Admin syncdb command, if South is available on the minion the migrate option can be passed as True calling the migrations to run after the syncdb completes

NOTE: The syncdb command was deprecated in Django 1.7 and removed in Django 1.9. For Django versions 1.9 or higher use the migrate command instead.

CLI Example:

salt '*' django.syncdb <settings_module>