Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
DJANGO-ADMIN(1)			    Django		       DJANGO-ADMIN(1)

       django-admin - Utility script for the Django Web	framework

       django-admin is Django's	command-line utility for administrative	tasks.
       This document outlines all it can do.

       In addition, is automatically created in each Django project.  does	the same thing as django-admin but takes care of a few
       things for you:

       o It puts your project's	package	on sys.path.

       o It sets the DJANGO_SETTINGS_MODULE environment	variable  so  that  it
	 points	to your	project's file.

       The  django-admin script	should be on your system path if you installed
       Django via its utility.	If it's	not on your path, you can find
       it  in  site-packages/django/bin	 within	your Python installation. Con-
       sider symlinking	it from	some place on  your  path,  such  as  /usr/lo-

       For  Windows users, who do not have symlinking functionality available,
       you can copy django-admin.exe to	a location on your  existing  path  or
       edit  the  PATH settings	(under Settings	- Control Panel	- System - Ad-
       vanced -	Environment...)	to point to its	installed location.

       Generally, when working on a single Django project, it's	easier to  use  than	django-admin.  If  you need to switch between multiple
       Django settings files, use django-admin with DJANGO_SETTINGS_MODULE  or
       the --settings command line option.

       The  command-line examples throughout this document use django-admin to
       be consistent, but any example can use	or  python  -m	django
       just as well.

       python -m django	was added.

	  $ django-admin <command> [options]
	  $ <command>	[options]
	  $ python -m django <command> [options]

       command	should	be  one	 of the	commands listed	in this	document.  op-
       tions, which is optional, should	be zero	or more	of the options	avail-
       able for	the given command.

   Getting runtime help
       django-admin help

       Run  django-admin  help	to display usage information and a list	of the
       commands	provided by each application.

       Run django-admin	help --commands	to display a  list  of	all  available

       Run  django-admin  help <command> to display a description of the given
       command and a list of its available options.

   App names
       Many commands take a list of "app names." An "app name" is the basename
       of  the	package	 containing  your  models.  For	 example,  if your IN-
       STALLED_APPS contains the string	'', the app name is blog.

   Determining the version
       django-admin version

       Run django-admin	version	to display the current Django version.

       The output follows the schema described in PEP 386:


   Displaying debug output
       Use --verbosity to specify the amount of	notification and debug	infor-
       mation that django-admin	should print to	the console. For more details,
       see the documentation for the --verbosity option.

   check <appname appname ...>
       django-admin check

       Uses the	system check framework to inspect the  entire  Django  project
       for common problems.

       The  system check framework will	confirm	that there aren't any problems
       with your installed models or your admin	registrations.	It  will  also
       provide warnings	of common compatibility	problems introduced by upgrad-
       ing Django to a new version.  Custom checks may be introduced by	 other
       libraries and applications.

       By default, all apps will be checked. You can check a subset of apps by
       providing a list	of app labels as arguments:

	  python check auth admin myapp

       If you do not specify any app, all apps will be checked.

       --tag <tagname>

       The system check	framework performs many	 different  types  of  checks.
       These  check types are categorized with tags. You can use these tags to
       restrict	the checks performed to	just those in a	 particular  category.
       For  example,  to  perform  only	security and compatibility checks, you
       would run:

	  python check --tag security	--tag compatibility


       List all	available tags.


       The --deploy option activates some additional checks that are only rel-
       evant in	a deployment setting.

       You  can	 use  this  option  in your local development environment, but
       since your local	development settings module may	not have many of  your
       production  settings, you will probably want to point the check command
       at a different settings	module,	 either	 by  setting  the  DJANGO_SET-
       TINGS_MODULE environment	variable, or by	passing	the --settings option:

	  python check --deploy --settings=production_settings

       Or  you	could run it directly on a production or staging deployment to
       verify that the correct settings	are in use (omitting --settings).  You
       could even make it part of your integration test	suite.

       django-admin compilemessages

       Compiles	 .po  files  created by	makemessages to	.mo files for use with
       the builtin gettext support. See	/topics/i18n/index.

       Use the --locale	option (or its shorter version -l) to specify the  lo-
       cale(s) to process. If not provided, all	locales	are processed.

       Use the --exclude option	(or its	shorter	version	-x) to specify the lo-
       cale(s) to exclude from processing. If not provided, no locales are ex-

       You  can	 pass --use-fuzzy option (or -f) to include fuzzy translations
       into compiled files.

       compilemessages now matches the operation of makemessages, scanning the
       project tree for	.po files to compile.

       Added --exclude and --use-fuzzy options.

       Example usage:

	  django-admin compilemessages --locale=pt_BR
	  django-admin compilemessages --locale=pt_BR --locale=fr -f
	  django-admin compilemessages -l pt_BR
	  django-admin compilemessages -l pt_BR	-l fr --use-fuzzy
	  django-admin compilemessages --exclude=pt_BR
	  django-admin compilemessages --exclude=pt_BR --exclude=fr
	  django-admin compilemessages -x pt_BR
	  django-admin compilemessages -x pt_BR	-x fr

       django-admin createcachetable

       Creates	the cache tables for use with the database cache backend using
       the information from your settings file.	See /topics/cache for more in-

       The  --database	option	can be used to specify the database onto which
       the cache table will be installed, but since this information is	pulled
       from your settings by default, it's typically not needed.

       The --dry-run option will print the SQL that would be run without actu-
       ally running it,	so you can customize it	or use the  migrations	frame-

       The --dry-run option was	added.

       django-admin dbshell

       Runs  the command-line client for the database engine specified in your
       ENGINE setting, with the	connection parameters specified	in your	 USER,
       PASSWORD, etc., settings.

       o For PostgreSQL, this runs the psql command-line client.

       o For MySQL, this runs the mysql	command-line client.

       o For SQLite, this runs the sqlite3 command-line	client.

       o For Oracle, this runs the sqlplus command-line	client.

       This  command  assumes  the  programs are on your PATH so that a	simple
       call to the program name	(psql, mysql, sqlite3, sqlplus)	will find  the
       program	in  the	right place. There's no	way to specify the location of
       the program manually.

       The --database option can be used to specify the	database onto which to
       open a shell.

       django-admin diffsettings

       Displays	differences between the	current	settings file and Django's de-
       fault settings.

       Settings	that don't appear in the defaults are followed by  "###".  For
       example,	 the  default settings don't define ROOT_URLCONF, so ROOT_URL-
       CONF is followed	by "###" in the	output of diffsettings.

       The --all option	may be provided	to display all settings, even if  they
       have Django's default value. Such settings are prefixed by "###".

   dumpdata <app_label app_label app_label.Model ...>
       django-admin dumpdata

       Outputs to standard output all data in the database associated with the
       named application(s).

       If no application name is provided, all installed applications will  be

       The output of dumpdata can be used as input for loaddata.

       Note  that dumpdata uses	the default manager on the model for selecting
       the records to dump. If you're using a custom manager  as  the  default
       manager	and  it	 filters some of the available records,	not all	of the
       objects will be dumped.

       The --all option	may be provided	to specify that	 dumpdata  should  use
       Django's	 base  manager,	 dumping records which might otherwise be fil-
       tered or	modified by a custom manager.

       --format	<fmt>

       By default, dumpdata will format	its output in JSON, but	 you  can  use
       the --format option to specify another format. Currently	supported for-
       mats are	listed in serialization-formats.

       --indent	<num>

       By default, dumpdata will output	all data on a single line. This	 isn't
       easy  for  humans  to  read,  so	 you  can  use	the --indent option to
       pretty-print the	output with a number of	indentation spaces.

       The --exclude option may	be provided to prevent	specific  applications
       or  models (specified as	in the form of app_label.ModelName) from being
       dumped. If you specify a	model name to dumpdata,	the dumped output will
       be  restricted  to that model, rather than the entire application.  You
       can also	mix application	names and model	names.

       The --database option can be used to specify the	 database  from	 which
       data will be dumped.


       When  this option is specified, Django will use the natural_key() model
       method to serialize any foreign key and	many-to-many  relationship  to
       objects	of  the	 type that defines the method. If you are dumping con-
       trib.auth Permission objects or	contrib.contenttypes  ContentType  ob-
       jects,  you  should  probably  be using this flag. See the natural keys
       documentation for more details on this and the next option.


       When this option	is specified, Django will not provide the primary  key
       in the serialized data of this object since it can be calculated	during


       By default, dumpdata will output	all the	records	of the model, but  you
       can  use	 the --pks option to specify a comma separated list of primary
       keys on which to	filter.	 This  is  only	 available  when  dumping  one


       By  default  dumpdata  will  output all the serialized data to standard
       output.	This option allows you to specify the file to which  the  data
       is to be	written.  When this option is set and the verbosity is greater
       than 0 (the default), a progress	bar is shown in	the terminal.

       The progress bar	in the terminal	was added.

       django-admin flush

       Removes all data	from the database and  re-executes  any	 post-synchro-
       nization	 handlers.  The	table of which migrations have been applied is
       not cleared.

       If you would rather start from an empty database	and re-run all	migra-
       tions,  you  should drop	and recreate the database and then run migrate

       The --noinput option may	be provided to suppress	all user prompts.

       The --database option may be used to specify the	database to flush.

       django-admin inspectdb

       Introspects the database	tables in the database pointed-to by the  NAME
       setting	and  outputs a Django model module (a	file) to stan-
       dard output.

       Use this	if you have a legacy database with which  you'd	 like  to  use
       Django.	 The  script  will inspect the database	and create a model for
       each table within it.

       As you might expect, the	created	models will have an attribute for  ev-
       ery  field in the table.	Note that inspectdb has	a few special cases in
       its field-name output:

       o If inspectdb cannot map a column's type to a model field type,	 it'll
	 use  TextField	and will insert	the Python comment 'This field type is
	 a guess.' next	to the field in	the generated model.

       o If the	database column	name  is  a  Python  reserved  word  (such  as
	 'pass',  'class' or 'for'), inspectdb will append '_field' to the at-
	 tribute name. For example, if a table has a column 'for', the	gener-
	 ated  model  will have	a field	'for_field', with the db_column	attri-
	 bute set to 'for'. inspectdb will insert the  Python  comment	'Field
	 renamed because it was	a Python reserved word.' next to the field.

       This  feature  is  meant	as a shortcut, not as definitive model genera-
       tion. After you run it, you'll want to look over	the  generated	models
       yourself	 to  make  customizations.  In	particular, you'll need	to re-
       arrange models' order, so that models that refer	to  other  models  are
       ordered properly.

       Primary	keys  are automatically	introspected for PostgreSQL, MySQL and
       SQLite, in which	case Django puts in the	primary_key=True where needed.

       inspectdb works with PostgreSQL,	MySQL and SQLite.  Foreign-key	detec-
       tion only works in PostgreSQL and with certain types of MySQL tables.

       Django  doesn't create database defaults	when a default is specified on
       a model field.  Similarly, database defaults aren't translated to model
       field defaults or detected in any fashion by inspectdb.

       By  default,  inspectdb	creates	 unmanaged  models. That is, managed =
       False in	the model's Meta class tells Django not	to manage each table's
       creation, modification, and deletion. If	you do want to allow Django to
       manage the table's lifecycle, you'll need to change the managed	option
       to True (or simply remove it because True is its	default	value).

       The  --database	option	may  be	used to	specify	the database to	intro-

   loaddata <fixture fixture ...>
       django-admin loaddata

       Searches	for and	loads the contents of the named	fixture	into the data-

       The  --database	option	can be used to specify the database onto which
       the data	will be	loaded.


       The --ignorenonexistent option can be used to ignore fields and	models
       that may	have been removed since	the fixture was	originally generated.


       The  --app  option can be used to specify a single app to look for fix-
       tures in	rather than looking through all	apps.

       --ignorenonexistent also	ignores	non-existent models.

   What's a fixture ?
       A fixture is a collection of files that contain the serialized contents
       of  the	database.  Each	 fixture has a unique name, and	the files that
       comprise	the fixture can	be distributed over multiple  directories,  in
       multiple	applications.

       Django will search in three locations for fixtures:

       1. In the fixtures directory of every installed application

       2. In any directory named in the	FIXTURE_DIRS setting

       3. In the literal path named by the fixture

       Django  will load any and all fixtures it finds in these	locations that
       match the provided fixture names.

       If the named fixture has	a file extension, only fixtures	of  that  type
       will be loaded. For example:

	  django-admin loaddata	mydata.json

       would only load JSON fixtures called mydata. The	fixture	extension must
       correspond to the registered name of a serializer (e.g.,	json or	xml).

       If you omit the extensions, Django will search  all  available  fixture
       types for a matching fixture. For example:

	  django-admin loaddata	mydata

       would look for any fixture of any fixture type called mydata. If	a fix-
       ture directory contained	mydata.json, that fixture would	be loaded as a
       JSON fixture.

       The fixtures that are named can include directory components. These di-
       rectories will be included in the search	path. For example:

	  django-admin loaddata	foo/bar/mydata.json

       would  search  <app_label>/fixtures/foo/bar/mydata.json	for  each  in-
       stalled	application,  <dirname>/foo/bar/mydata.json for	each directory
       in FIXTURE_DIRS,	and the	literal	path foo/bar/mydata.json.

       When fixture files are processed, the data is saved to the database  as
       is.   Model  defined save() methods are not called, and any pre_save or
       post_save signals will be called	with raw=True since the	instance  only
       contains	 attributes that are local to the model. You may, for example,
       want to disable handlers	that access related fields that	aren't present
       during fixture loading and would	otherwise raise	an exception:

	  from django.db.models.signals	import post_save
	  from .models import MyModel

	  def my_handler(**kwargs):
	      #	disable	the handler during fixture loading
	      if kwargs['raw']:

	  post_save.connect(my_handler,	sender=MyModel)

       You could also write a simple decorator to encapsulate this logic:

	  from functools import	wraps

	  def disable_for_loaddata(signal_handler):
	      Decorator	that turns off signal handlers when loading fixture data.
	      def wrapper(*args, **kwargs):
		  if kwargs['raw']:
		  signal_handler(*args,	**kwargs)
	      return wrapper

	  def my_handler(**kwargs):

       Just  be	 aware	that this logic	will disable the signals whenever fix-
       tures are deserialized, not just	during loaddata.

       Note that the order in which fixture files are processed	is  undefined.
       However,	all fixture data is installed as a single transaction, so data
       in one fixture can reference data in another fixture. If	 the  database
       backend	supports  row-level  constraints,  these  constraints  will be
       checked at the end of the transaction.

       The dumpdata command can	be used	to generate input for loaddata.

   Compressed fixtures
       Fixtures	may be compressed in zip, gz, or bz2 format. For example:

	  django-admin loaddata	mydata.json

       would look for any of mydata.json,, mydata.json.gz,  or
       mydata.json.bz2.	 The  first file contained within a zip-compressed ar-
       chive is	used.

       Note that if two	fixtures with the same name but	different fixture type
       are  discovered	(for  example,	if  mydata.json	and mydata.xml.gz were
       found in	the same fixture  directory),  fixture	installation  will  be
       aborted,	and any	data installed in the call to loaddata will be removed
       from the	database.

	  MySQL	with MyISAM and	fixtures

		 The MyISAM storage engine of MySQL doesn't  support  transac-
		 tions	or  constraints,  so  if you use MyISAM, you won't get
		 validation of fixture data, or	a rollback if multiple	trans-
		 action	files are found.

   Database-specific fixtures
       If  you're  in a	multi-database setup, you might	have fixture data that
       you want	to load	onto one database, but not onto	another. In this situ-
       ation,  you  can	 add a database	identifier into	the names of your fix-

       For example, if your DATABASES setting has a 'master' database defined,
       name  the  fixture  mydata.master.json or mydata.master.json.gz and the
       fixture will only be loaded when	you specify you	want to	load data into
       the master database.

       django-admin makemessages

       Runs over the entire source tree	of the current directory and pulls out
       all strings marked for translation. It creates (or updates)  a  message
       file in the conf/locale (in the Django tree) or locale (for project and
       application) directory. After making changes to the messages files  you
       need to compile them with compilemessages for use with the builtin get-
       text support. See the i18n documentation	for details.


       Use the --all or	-a option to update the	message	files for  all	avail-
       able languages.

       Example usage:

	  django-admin makemessages --all


       Use  the	 --extension or	-e option to specify a list of file extensions
       to examine (default: ".html", ".txt").

       Example usage:

	  django-admin makemessages --locale=de	--extension xhtml

       Separate	multiple extensions with commas	or use -e or --extension  mul-
       tiple times:

	  django-admin makemessages --locale=de	--extension=html,txt --extension xml

       Use  the	--locale option	(or its	shorter	version	-l) to specify the lo-
       cale(s) to process.

       Use the --exclude option	(or its	shorter	version	-x) to specify the lo-
       cale(s) to exclude from processing. If not provided, no locales are ex-

       Example usage:

	  django-admin makemessages --locale=pt_BR
	  django-admin makemessages --locale=pt_BR --locale=fr
	  django-admin makemessages -l pt_BR
	  django-admin makemessages -l pt_BR -l	fr
	  django-admin makemessages --exclude=pt_BR
	  django-admin makemessages --exclude=pt_BR --exclude=fr
	  django-admin makemessages -x pt_BR
	  django-admin makemessages -x pt_BR -x	fr


       Use the --domain	or -d option to	change	the  domain  of	 the  messages
       files.  Currently supported:

       o django	for all	*.py, *.html and *.txt files (default)

       o djangojs for *.js files


       Use  the	--symlinks or -s option	to follow symlinks to directories when
       looking for new translation strings.

       Example usage:

	  django-admin makemessages --locale=de	--symlinks


       Use the --ignore	or -i option to	ignore files or	 directories  matching
       the given glob-style pattern. Use multiple times	to ignore more.

       These patterns are used by default: 'CVS', '.*',	'*~', '*.pyc'

       Example usage:

	  django-admin makemessages --locale=en_US --ignore=apps/* --ignore=secret/*.html


       Use  the	 --no-default-ignore  option  to disable the default values of


       Use the --no-wrap option	to disable breaking long  message  lines  into
       several lines in	language files.


       Use  the	 --no-location	option	to suppress writing '#:	filename:linea
       comment lines in	language files.	Note that using	this option  makes  it
       harder for technically skilled translators to understand	each message's


       Use the --keep-pot option to prevent Django from	deleting the temporary
       .pot  files  it	generates before creating the .po file.	This is	useful
       for debugging errors which may prevent the final	 language  files  from
       being created.

       SEE ALSO:
	  See  customizing-makemessages	 for  instructions on how to customize
	  the keywords that makemessages passes	to xgettext.

   makemigrations [<app_label>]
       django-admin makemigrations

       Creates new migrations based on the changes detected  to	 your  models.
       Migrations,  their relationship with apps and more are covered in depth
       in the migrations documentation.

       Providing one or	more app names as arguments will limit the  migrations
       created	to the app(s) specified	and any	dependencies needed (the table
       at the other end	of a ForeignKey, for example).

       The --noinput option may	be provided to suppress	all user prompts. If a
       suppressed  prompt  cannot  be resolved automatically, the command will
       exit with error code 3.


       The --empty option will cause makemigrations to output an empty	migra-
       tion  for  the  specified apps, for manual editing. This	option is only
       for advanced users and should not be used unless	you are	familiar  with
       the  migration  format,	migration operations, and the dependencies be-
       tween your migrations.


       The --dry-run option shows what migrations would	be made	without	 actu-
       ally writing any	migrations files to disk. Using	this option along with
       --verbosity 3 will also show the	complete migrations files  that	 would
       be written.


       The --merge option enables fixing of migration conflicts.

       --name, -n

       The --name option allows	you to give the	migration(s) a custom name in-
       stead of	a generated one.

       --exit, -e

       The --exit option will cause makemigrations to exit with	error  code  1
       when no migrations are created (or would	have been created, if combined
       with --dry-run).

   migrate [<app_label>	[<migrationname>]]
       django-admin migrate

       Synchronizes the	database state with the	current	set of models and  mi-
       grations.   Migrations,	their relationship with	apps and more are cov-
       ered in depth in	the migrations documentation.

       The behavior of this command changes depending on  the  arguments  pro-

       o No arguments: All apps	have all of their migrations run.

       o <app_label>: The specified app	has its	migrations run,	up to the most
	 recent	migration. This	may involve  running  other  apps'  migrations
	 too, due to dependencies.

       o <app_label>  <migrationname>:	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.

       The --database option can be used to specify the	database to migrate.


       The  --fake  option  tells Django to mark the migrations	as having been
       applied or unapplied, but without actually running the  SQL  to	change
       your database schema.

       This is intended	for advanced users to manipulate the current migration
       state directly if they're manually applying changes; be warned that us-
       ing  --fake  runs  the risk of putting the migration state table	into a
       state where manual recovery will	be needed to make migrations run  cor-


       The  --fake-initial option can be used to allow Django to skip an app's
       initial migration if all	database tables	with the names of  all	models
       created	by all CreateModel operations in that migration	already	exist.
       This option is intended for use when first running migrations against a
       database	 that  preexisted the use of migrations. This option does not,
       however,	check for matching database schema beyond matching table names
       and  so	is  only  safe	to use if you are confident that your existing
       schema matches what is recorded in your initial migration.


       The --run-syncdb	option allows creating tables for apps without	migra-
       tions.  While this isn't	recommended, the migrations framework is some-
       times too slow on large projects	with hundreds of models.

       Deprecated since	version	1.8: The --list	option has been	moved  to  the
       showmigrations command.

   runserver [port or address:port]
       django-admin runserver

       Starts  a  lightweight  development Web server on the local machine. By
       default,	the server runs	on port	8000 on	the IP address  You
       can pass	in an IP address and port number explicitly.

       If  you run this	script as a user with normal privileges	(recommended),
       you might not have access to start a port on a  low  port  number.  Low
       port numbers are	reserved for the superuser (root).

       This  server uses the WSGI application object specified by the WSGI_AP-
       PLICATION setting.

       DO NOT USE THIS SERVER IN A PRODUCTION SETTING. It has not gone through
       security	 audits	or performance tests. (And that's how it's gonna stay.
       We're in	the business of	making Web frameworks, not Web servers,	so im-
       proving	this  server  to be able to handle a production	environment is
       outside the scope of Django.)

       The development server automatically reloads Python code	for  each  re-
       quest, as needed. You don't need	to restart the server for code changes
       to take effect.	However, some actions like adding files	don't  trigger
       a restart, so you'll have to restart the	server in these	cases.

       If  you	are  using Linux and install pyinotify,	kernel signals will be
       used to autoreload the server (rather than  polling  file  modification
       timestamps  each	second). This offers better scaling to large projects,
       reduction in response time to code modification,	more robust change de-
       tection,	and battery usage reduction.

       When  you  start	the server, and	each time you change Python code while
       the server is running, the system check framework will check  your  en-
       tire  Django project for	some common errors (see	the check command). If
       any errors are found, they will be printed to standard output.

       You can run as many concurrent servers as you want, as long as  they're
       on separate ports. Just execute django-admin runserver more than	once.

       Note  that  the	default	 IP address,,	is not accessible from
       other machines on your network. To make your development	 server	 view-
       able  to	 other	machines  on the network, use its own IP address (e.g. or or :: (with IPv6	enabled).

       You  can	 provide  an  IPv6  address  surrounded	 by   brackets	 (e.g.
       [200a::1]:8000).	This will automatically	enable IPv6 support.

       A hostname containing ASCII-only	characters can also be used.

       If the staticfiles contrib app is enabled (default in new projects) the
       runserver command will be overridden with its own runserver command.

       If migrate was not previously executed, the table that stores the  his-
       tory of migrations is created at	first run of runserver.


       Use the --noreload option to disable the	use of the auto-reloader. This
       means any Python	code changes you make while the	server is running will
       not  take  effect  if  the  particular Python modules have already been
       loaded into memory.

       Example usage:

	  django-admin runserver --noreload


       The development server is multithreaded by default. Use the --nothread-
       ing option to disable the use of	threading in the development server.

       --ipv6, -6

       Use  the	 --ipv6	 (or shorter -6) option	to tell	Django to use IPv6 for
       the development server.	This  changes  the  default  IP	 address  from to ::1.

       Example usage:

	  django-admin runserver --ipv6

   Examples of using different ports and addresses
       Port 8000 on IP address

	  django-admin runserver

       Port 8000 on IP address

	  django-admin runserver

       Port 7000 on IP address

	  django-admin runserver 7000

       Port 7000 on IP address

	  django-admin runserver

       Port 8000 on IPv6 address ::1:

	  django-admin runserver -6

       Port 7000 on IPv6 address ::1:

	  django-admin runserver -6 7000

       Port 7000 on IPv6 address 2001:0db8:1234:5678::9:

	  django-admin runserver [2001:0db8:1234:5678::9]:7000

       Port 8000 on IPv4 address of host localhost:

	  django-admin runserver localhost:8000

       Port 8000 on IPv6 address of host localhost:

	  django-admin runserver -6 localhost:8000

   Serving static files	with the development server
       By  default,  the development server doesn't serve any static files for
       your site (such as CSS files, images, things  under  MEDIA_URL  and  so
       forth).	If  you	 want  to configure Django to serve static media, read

       django-admin sendtestemail

       Sends a test email (to confirm email sending through Django is working)
       to the recipient(s) specified. For example:

	  django-admin sendtestemail


       Use the --managers option to mail the email addresses specified in MAN-
       AGERS using mail_managers().


       Use the --admins	option to mail the email addresses specified in	ADMINS
       using mail_admins().

       Note that you may use any combination of	these options together.

       django-admin shell

       Starts the Python interactive interpreter.

       Django  will use	IPython	or bpython if either is	installed. If you have
       a rich shell installed but want to force	use of the "plain" Python  in-
       terpreter, use the --plain option, like so:

	  django-admin shell --plain

       If  you	would like to specify either IPython or	bpython	as your	inter-
       preter if you have both installed you can specify an alternative	inter-
       preter interface	with the -i or --interface options like	so:


	  django-admin shell -i	ipython
	  django-admin shell --interface ipython


	  django-admin shell -i	bpython
	  django-admin shell --interface bpython

       When  the  "plain" Python interactive interpreter starts	(be it because
       --plain was specified or	because	 no  other  interactive	 interface  is
       available) it reads the script pointed to by the	PYTHONSTARTUP environ-
       ment variable and the ~/ script. If you don't wish this be-
       havior you can use the --no-startup option. e.g.:

	  django-admin shell --plain --no-startup

   showmigrations [<app_label> [<app_label>]]
       django-admin showmigrations

       Shows all migrations in a project.

       --list, -l

       The  --list option lists	all of the apps	Django knows about, the	migra-
       tions available for each	app, and whether or not	each migration is  ap-
       plied (marked by	an [X] next to the migration name).

       Apps  without  migrations  are  also  listed,  but have (no migrations)
       printed under them.

       --plan, -p

       The --plan option shows the migration plan Django will follow to	 apply
       migrations.  Any	supplied app labels are	ignored	because	the plan might
       go beyond those apps. Same as --list, applied migrations	are marked  by
       an [X]. For a verbosity of 2 and	above, all dependencies	of a migration
       will also be shown.

       django-admin sqlflush

       Prints the SQL statements that would be executed	for the	flush command.

       The --database option can be used to specify the	database for which  to
       print the SQL.

   sqlmigrate <app_label> <migrationname>
       django-admin sqlmigrate

       Prints  the  SQL	for the	named migration. This requires an active data-
       base connection,	which it will use to resolve  constraint  names;  this
       means you must generate the SQL against a copy of the database you wish
       to later	apply it on.

       Note that sqlmigrate doesn't colorize its output.

       The --database option can be used to specify the	database for which  to
       generate	the SQL.


       By  default,  the  SQL created is for running the migration in the for-
       wards direction.	Pass --backwards to generate the  SQL  for  unapplying
       the migration instead.

       To increase the readability of the overall SQL output the SQL code gen-
       erated for each migration operation is preceded by the operation's  de-

   sqlsequencereset <app_label app_label ...>
       django-admin sqlsequencereset

       Prints  the  SQL	 statements  for resetting sequences for the given app

       Sequences are indexes used by some database engines to track  the  next
       available number	for automatically incremented fields.

       Use  this command to generate SQL which will fix	cases where a sequence
       is out of sync with its automatically incremented field data.

       The --database option can be used to specify the	database for which  to
       print the SQL.

   squashmigrations <app_label>	[<start_migration_name>] <migration_name>
       django-admin squashmigrations

       Squashes	 the  migrations  for  app_label  up  to  and including	migra-
       tion_name down  into  fewer  migrations,	 if  possible.	The  resulting
       squashed	 migrations can	live alongside the unsquashed ones safely. For
       more information, please	read migration-squashing.

       When start_migration_name is given, Django will only include migrations
       starting	 from and including this migration. This helps to mitigate the
       squashing  limitation  of  RunPython  and   django.db.migrations.opera-
       tions.RunSQL migration operations.


       By  default,  Django will try to	optimize the operations	in your	migra-
       tions to	reduce the size	of the resulting file. Pass  --no-optimize  if
       this  process  is  failing  for	you  or	creating incorrect migrations,
       though please also file a Django	bug report about the behavior, as  op-
       timization is meant to be safe.

   startapp <app_label>	[destination]
       django-admin startapp

       Creates	a Django app directory structure for the given app name	in the
       current directory or the	given destination.

       By default the directory	created	contains a  file  and	 other
       app  template files. (See the source for	more details.) If only the app
       name is given, the app directory	will be	created	in the current working

       If  the optional	destination is provided, Django	will use that existing
       directory rather	than creating a	new one. You can use '.' to denote the
       current working directory.

       For example:

	  django-admin startapp	myapp /Users/jezdez/Code/myapp


       With  the  --template option, you can use a custom app template by pro-
       viding either the path to a directory with the app template file, or  a
       path  to	 a  compressed file (.tar.gz, .tar.bz2,	.tgz, .tbz, .zip) con-
       taining the app template	files.

       For example, this would look for	an app template	in the given directory
       when creating the myapp app:

	  django-admin startapp	--template=/Users/jezdez/Code/my_app_template myapp

       Django  will also accept	URLs (http, https, ftp)	to compressed archives
       with the	app template files, downloading	and  extracting	 them  on  the

       For  example,  taking advantage of GitHub's feature to expose reposito-
       ries as zip files, you can use a	URL like:

	  django-admin startapp	--template=	myapp

       When Django copies the app template  files,  it	also  renders  certain
       files through the template engine: the files whose extensions match the
       --extension option (py by default) and the files	whose names are	passed
       with the	--name option. The template context used is:

       o Any  option  passed to	the startapp command (among the	command's sup-
	 ported	options)

       o app_name -- the app name as passed to the command

       o app_directory -- the full path	of the newly created app

       o camel_case_app_name --	the app	name in	camel case format

       o docs_version -- the version of	the documentation: 'dev' or '1.x'

       camel_case_app_name was added.

	  When the app template	files are rendered with	 the  Django  template
	  engine  (by  default	all  *.py files), Django will also replace all
	  stray	template variables contained.  For  example,  if  one  of  the
	  Python  files	 contains  a docstring explaining a particular feature
	  related to template rendering, it might result in an incorrect exam-

	  To work around this problem, you can use the templatetag templatetag
	  to "escape" the various parts	of the template	syntax.

   startproject	<projectname> [destination]
       django-admin startproject

       Creates a Django	project	directory structure for	the given project name
       in the current directory	or the given destination.

       By  default, the	new directory contains and a project package
       (containing a and other files). See the template source for

       If  only	 the  project  name  is	 given,	both the project directory and
       project package will be named <projectname> and the  project  directory
       will be created in the current working directory.

       If  the optional	destination is provided, Django	will use that existing
       directory as the	 project  directory,  and  create  and  the
       project package within it. Use '.' to denote the	current	working	direc-

       For example:

	  django-admin startproject myproject /Users/jezdez/Code/myproject_repo

       As with the startapp command, the --template option lets	you specify  a
       directory,  file	 path  or  URL	of  a custom project template. See the
       startapp	documentation for details of supported project	template  for-

       For example, this would look for	a project template in the given	direc-
       tory when creating the myproject	project:

	  django-admin startproject --template=/Users/jezdez/Code/my_project_template myproject

       Django will also	accept URLs (http, https, ftp) to compressed  archives
       with the	project	template files,	downloading and	extracting them	on the

       For example, taking advantage of	GitHub's feature to  expose  reposito-
       ries as zip files, you can use a	URL like:

	  django-admin startproject --template=	myproject

       When  Django copies the project template	files, it also renders certain
       files through the template engine: the files whose extensions match the
       --extension option (py by default) and the files	whose names are	passed
       with the	--name option. The template context used is:

       o Any option passed to the startproject command	(among	the  command's
	 supported options)

       o project_name -- the project name as passed to the command

       o project_directory -- the full path of the newly created project

       o secret_key -- a random	key for	the SECRET_KEY setting

       o docs_version -- the version of	the documentation: 'dev' or '1.x'

       Please also see the rendering warning as	mentioned for startapp.

   test	<app or	test identifier>
       django-admin test

       Runs tests for all installed models. See	/topics/testing/index for more


       The --failfast option can be used to stop running tests and report  the
       failure immediately after a test	fails.


       The  --testrunner  option  can be used to control the test runner class
       that is used to execute tests. If this value is provided, it  overrides
       the value provided by the TEST_RUNNER setting.


       The  --liveserver  option  can  be used to override the default address
       where the live server (used with	LiveServerTestCase) is expected	to run
       from. The default value is localhost:8081-8179.

       In earlier versions, the	default	value was localhost:8081.


       The  --keepdb  option can be used to preserve the test database between
       test runs. This has the advantage of skipping both the create  and  de-
       stroy  actions  which can greatly decrease the time to run tests, espe-
       cially those in a large test suite. If the test database	does  not  ex-
       ist,  it	 will  be created on the first run and then preserved for each
       subsequent run. Any unapplied migrations	will also be  applied  to  the
       test database before running the	test suite.


       The --reverse option can	be used	to sort	test cases in the opposite or-
       der.  This may help in debugging	the side effects of tests that	aren't
       properly	 isolated. Grouping by test class is preserved when using this


       The --debug-sql option can be used to enable SQL	 logging  for  failing
       tests. If --verbosity is	2, then	queries	in passing tests are also out-


       The --parallel option can be used to run	tests in parallel in  separate
       processes.  Since  modern  processors  have multiple cores, this	allows
       running tests significantly faster.

       By  default  --parallel	runs  one  process  per	 core	according   to
       multiprocessing.cpu_count(). You	can adjust the number of processes ei-
       ther by providing it as the option's value, e.g.	 --parallel=4,	or  by
       setting the DJANGO_TEST_PROCESSES environment variable.

       Django  distributes test	cases a	unittest.TestCase subclasses a to sub-
       processes. If there are fewer test  cases  than	configured  processes,
       Django will reduce the number of	processes accordingly.

       Each process gets its own database. You must ensure that	different test
       cases don't access the same resources. For instance,  test  cases  that
       touch  the filesystem should create a temporary directory for their own

       This option requires the	third-party tblib package  to  display	trace-
       backs correctly:

	  $ pip	install	tblib

       This  feature isn't available on	Windows. It doesn't work with the Ora-
       cle database backend either.

       If you want to use pdb while debugging tests, you must disable parallel
       execution  (--parallel=1). You'll see something like bdb.BdbQuit	if you

	  When test parallelization is enabled and a test fails, Django	may be
	  unable  to  display the exception traceback. This can	make debugging
	  difficult. If	you encounter this  problem,  run  the	affected  test
	  without parallelization to see the traceback of the failure.

	  This is a known limitation. It arises	from the need to serialize ob-
	  jects	in order to exchange them between processes. See What  can  be
	  pickled and unpickled? for details.

   testserver <fixture fixture ...>
       django-admin testserver

       Runs  a Django development server (as in	runserver) using data from the
       given fixture(s).

       For example, this command:

	  django-admin testserver mydata.json

       ...would	perform	the following steps:

       1. Create a test	database, as described in the-test-database.

       2. Populate the test database with fixture data	from  the  given  fix-
	  tures.   (For	 more  on fixtures, see	the documentation for loaddata

       3. Runs the Django development server (as  in  runserver),  pointed  at
	  this	newly  created	test database instead of your production data-

       This is useful in a number of ways:

       o When you're writing unit tests	of how your  views  act	 with  certain
	 fixture  data,	you can	use testserver to interact with	the views in a
	 Web browser, manually.

       o Let's say you're developing your Django application and have a	"pris-
	 tine"	copy  of  a database that you'd	like to	interact with. You can
	 dump your database to a fixture  (using  the  dumpdata	 command,  ex-
	 plained  above), then use testserver to run your Web application with
	 that data.  With this arrangement, you	have the flexibility of	 mess-
	 ing  up  your	data  in  any  way, knowing that whatever data changes
	 you're	making are only	being made to a	test database.

       Note that this server does not automatically  detect  changes  to  your
       Python  source  code  (as  runserver  does).  It	 does, however,	detect
       changes to templates.

       --addrport [port	number or ipaddr:port]

       Use --addrport to specify a different port, or  IP  address  and	 port,
       from the	default	of This	value follows exactly the same
       format and serves exactly the same function  as	the  argument  to  the
       runserver command.


       To run the test server on port 7000 with	fixture1 and fixture2:

	  django-admin testserver --addrport 7000 fixture1 fixture2
	  django-admin testserver fixture1 fixture2 --addrport 7000

       (The above statements are equivalent. We	include	both of	them to	demon-
       strate that it doesn't matter whether the options come before or	 after
       the fixture arguments.)

       To run on with a test fixture:

	  django-admin testserver --addrport test

       The --noinput option may	be provided to suppress	all user prompts.

       Some  commands  are  only available when	the django.contrib application
       that implements them has	been  enabled.	This  section  describes  them
       grouped by their	application.

       django-admin changepassword

       This  command  is  only	available  if  Django's	 authentication	system
       (django.contrib.auth) is	installed.

       Allows changing a user's	password. It prompts you to enter a new	 pass-
       word twice for the given	user. If the entries are identical, this imme-
       diately becomes the new password. If you	do not supply a	user, the com-
       mand  will  attempt  to	change the password whose username matches the
       current user.

       Use the --database option to specify the	 database  to  query  for  the
       user. If	it's not supplied, Django will use the default database.

       Example usage:

	  django-admin changepassword ringo

       django-admin createsuperuser

       This  command  is  only	available  if  Django's	 authentication	system
       (django.contrib.auth) is	installed.

       Creates a superuser account (a user who has all permissions).  This  is
       useful  if  you	need  to create	an initial superuser account or	if you
       need to programmatically	generate superuser accounts for	your site(s).

       When run	interactively, this command will prompt	for a password for the
       new  superuser account. When run	non-interactively, no password will be
       set, and	the superuser account will not be able to log in until a pass-
       word has	been manually set for it.



       The  username  and email	address	for the	new account can	be supplied by
       using the --username and	--email	arguments on the command line. If  ei-
       ther  of	those is not supplied, createsuperuser will prompt for it when
       running interactively.

       Use the --database option to specify the	database into which the	 supe-
       ruser object will be saved.

       You  can	 subclass the management command and override get_input_data()
       if you want to customize	data input and validation. Consult the	source
       code for	details	on the existing	implementation and the method's	param-
       eters. For example, it could be useful if you have a ForeignKey in  RE-
       QUIRED_FIELDS  and want to allow	creating an instance instead of	enter-
       ing the primary key of an existing instance.

       This command is only available if GeoDjango (django.contrib.gis)	is in-

       Please refer to its description in the GeoDjango	documentation.

       django-admin clearsessions

       Can be run as a cron job	or directly to clean out expired sessions.

       This  command  is only available	if the Sitemaps	framework (django.con-
       trib.sitemaps) is installed.

       Please refer to its description in the Sitemaps documentation.

       This  command  is  only	available  if  the  static  files  application
       (django.contrib.staticfiles) is installed.

       Please refer to its description in the staticfiles documentation.

       This  command  is  only	available  if  the  static  files  application
       (django.contrib.staticfiles) is installed.

       Please refer to its description in the staticfiles documentation.

       Although	some commands may allow	their own custom options,  every  com-
       mand allows for the following options:


       Example usage:

	  django-admin migrate --pythonpath='/home/djangoprojects/myproject'

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

       Note  that  this	 option	 is unnecessary	in, because it takes
       care of setting the Python path for you.


       Example usage:

	  django-admin migrate --settings=mysite.settings

       Explicitly 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

       Note that this option is	unnecessary in, because it uses set-	from the current project by default.


       Example usage:

	  django-admin migrate --traceback

       By default, django-admin	will show a simple error  message  whenever  a
       CommandError occurs, but	a full stack trace for any other exception. If
       you specify --traceback,	django-admin will also	output	a  full	 stack
       trace when a CommandError is raised.


       Example usage:

	  django-admin migrate --verbosity 2

       Use  --verbosity	to specify the amount of notification and debug	infor-
       mation that django-admin	should print to	the console.

       o 0 means no output.

       o 1 means normal	output (default).

       o 2 means verbose output.

       o 3 means very verbose output.


       Example usage:

	  django-admin runserver --no-color

       By default, django-admin	will format the	output to  be  colorized.  For
       example,	 errors	 will  be printed to the console in red	and SQL	state-
       ments will be syntax highlighted. To prevent this and have a plain text
       output, pass the	--no-color option when running your command.

       The  following options are not available	on every command, but they are
       common to a number of commands.


       Used to specify the database on which a command will  operate.  If  not
       specified, this option will default to an alias of default.

       For example, to dump data from the database with	the alias master:

	  django-admin dumpdata	--database=master


       Exclude	a specific application from the	applications whose contents is
       output. For example, to specifically exclude the	auth application  from
       the output of dumpdata, you would call:

	  django-admin dumpdata	--exclude=auth

       If  you	want  to exclude multiple applications,	use multiple --exclude

	  django-admin dumpdata	--exclude=auth --exclude=contenttypes


       Use the --locale	or -l option to	specify	the locale to process.	If not
       provided	all locales are	processed.


       Use  the	 --noinput option to suppress all user prompting, such as "Are
       you sure?" confirmation messages. This is useful	if django-admin	is be-
       ing executed as an unattended, automated	script.	You can	use --no-input
       as an alias for this option.

       The --no-input alias was	added.

   Syntax coloring
       The django-admin	/ commands will use pretty color-coded  out-
       put  if	your  terminal	supports ANSI-colored output. It won't use the
       color codes if you're piping the	command's output to another program.

       Under Windows, the native console doesn't support ANSI escape sequences
       so by default there is no color output. But you can install the ANSICON
       third-party tool, the Django commands will detect its presence and will
       make  use of its	services to color output just like on Unix-based plat-

       The colors used for syntax highlighting can be customized. Django ships
       with three color	palettes:

       o dark, suited to terminals that	show white text	on a black background.
	 This is the default palette.

       o light,	suited to terminals that show black  text  on  a  white	 back-

       o nocolor, which	disables syntax	highlighting.

       You select a palette by setting a DJANGO_COLORS environment variable to
       specify the palette you want to use. For	example, to specify the	 light
       palette under a Unix or OS/X BASH shell,	you would run the following at
       a command prompt:

	  export DJANGO_COLORS="light"

       You can also customize the colors that are  used.  Django  specifies  a
       number of roles in which	color is used:

       o error - A major error.

       o notice	- A minor error.

       o success - A success.

       o warning - A warning.

       o sql_field - The name of a model field in SQL.

       o sql_coltype - The type	of a model field in SQL.

       o sql_keyword - An SQL keyword.

       o sql_table - The name of a model in SQL.

       o http_info - A 1XX HTTP	Informational server response.

       o http_success -	A 2XX HTTP Success server response.

       o http_not_modified - A 304 HTTP	Not Modified server response.

       o http_redirect - A 3XX HTTP Redirect server response other than	304.

       o http_not_found	- A 404	HTTP Not Found server response.

       o http_bad_request  - A 4XX HTTP	Bad Request server response other than

       o http_server_error - A 5XX HTTP	Server Error response.

       o migrate_heading - A heading in	a migrations management	command.

       o migrate_label - A migration name.

       success was added.

       Each of these roles can be assigned a  specific	foreground  and	 back-
       ground color, from the following	list:

       o black

       o red

       o green

       o yellow

       o blue

       o magenta

       o cyan

       o white

       Each  of	 these colors can then be modified by using the	following dis-
       play options:

       o bold

       o underscore

       o blink

       o reverse

       o conceal

       A color specification follows one of the	following patterns:

       o role=fg

       o role=fg/bg

       o role=fg,option,option

       o role=fg/bg,option,option

       where role is the name of a valid color	role,  fg  is  the  foreground
       color,  bg  is the background color and each option is one of the color
       modifying options. Multiple color specifications	are then separated  by
       a semicolon. For	example:

	  export DJANGO_COLORS="error=yellow/blue,blink;notice=magenta"

       would  specify  that errors be displayed	using blinking yellow on blue,
       and notices displayed using magenta. All	other  color  roles  would  be
       left uncolored.

       Colors  can also	be specified by	extending a base palette. If you put a
       palette name in a color specification, all the colors implied  by  that
       palette will be loaded. So:

	  export DJANGO_COLORS="light;error=yellow/blue,blink;notice=magenta"

       would specify the use of	all the	colors in the light color palette, ex-
       cept for	the colors for errors and notices which	would be overridden as

   Bash	completion
       If  you use the Bash shell, consider installing the Django bash comple-
       tion script, which lives	in extras/django_bash_completion in the	Django
       distribution.  It  enables tab-completion of django-admin and
       commands, so you	can, for instance...

       o Type django-admin.

       o Press [TAB] to	see all	available options.

       o Type sql, then	[TAB], to see all available options whose names	 start
	 with sql.

       See  /howto/custom-management-commands  for  how	 to add	customized ac-
       tions., *args,	**options)

       To call a management command from code use call_command.

       name   the name of the command to call.

       *args  a	list of	arguments accepted by the command.

	      named options accepted on	the command-line.


	  from django.core import management
	  management.call_command('flush', verbosity=0,	interactive=False)
	  management.call_command('loaddata', 'test_data', verbosity=0)

       Note that command options that take no arguments	are passed as keywords
       with True or False, as you can see with the interactive option above.

       Named arguments can be passed by	using either one of the	following syn-

	  # Similar to the command line
	  management.call_command('dumpdata', '--natural-foreign')

	  # Named argument similar to the command line minus the initial dashes	and
	  # with internal dashes replaced by underscores
	  management.call_command('dumpdata', natural_foreign=True)

	  # `use_natural_foreign_keys` is the option destination variable
	  management.call_command('dumpdata', use_natural_foreign_keys=True)

       The first syntax	is now supported thanks	to management  commands	 using
       the  argparse  module.  For the second syntax, Django previously	passed
       the option name as-is to	the command, now it is always using  the  dest
       variable	name (which may	or may not be the same as the option name).

       Command options which take multiple options are passed a	list:

	  management.call_command('dumpdata', exclude=['contenttypes', 'auth'])

       Note  that  you	can  redirect standard output and error	streams	as all
       commands	support	the stdout and stderr options. For example, you	 could

	  with open('/path/to/command_output') as f:
	      management.call_command('dumpdata', stdout=f)

       Django Software Foundation

       Django Software Foundation and contributors

1.9			       December	01, 2015	       DJANGO-ADMIN(1)


Want to link to this manual page? Use this URL:

home | help