Django disable management commands

[Mojitaba34]

Code of Conduct

• I agree to follow Django's Code of Conduct

Feature Description

Add a new DISABLED_MANAGEMENT_COMMANDS setting that allows projects to prevent selected management commands from being executed from the command line with django-admin or manage.py.

This is useful for deployments or restricted environments where risky commands such as flush or migrate should not be run manually, while still allowing programmatic usage through call_command().

Problem

It solves the problem of preventing accidental or unauthorized execution of risky management commands from the command line.

Request or proposal

request

Additional Details

No response

Implementation Suggestions

The implementation adds a new DISABLED_MANAGEMENT_COMMANDS setting with an empty list as the default value.

During command-line execution, ManagementUtility checks the active settings after processing early options such as --settings and --pythonpath. If the requested subcommand is listed in DISABLED_MANAGEMENT_COMMANDS, Django exits with a CommandError before loading or executing the command.

This check is limited to django-admin and manage.py command-line execution. django.core.management.call_command() is intentionally not affected, so projects and third-party code can still invoke commands programmatically when needed.

[github-actions]

Thank you Mojitaba34 for sharing your idea! We have a lot of them so please be patient. You can see the current queue here.

Community instructions

For commenters, please use the emoji reactions on the issue to express support, and/or concern easily. Please use the comments to ask questions or contribute knowledge about the idea. It is unhelpful to post comments of "I'd love this" or "What's the state of this?"

Reaction Guide

• 👍 This is something I would use
• 👎 This is something that would cause problems for me or Django
• 😕 I’m indifferent to this
• 🎉 This is an easy win

[jacobtylerwalls]

Thanks for the idea, but I think the pattern we want to encourage is subclassing commands at the project level, e.g. override handle() to raise CommandError in all paths.

[Mojitaba34]

@jacobtylerwalls Exactly, this is one of the things that we are doing over and over again in each project. Basically, we repeat the same thing again and again, so because of this, I came up with this idea to handle it through environment variables in the settings.

This prevents us from repeating the same pattern and allows us to manage these commands easily in each environment where we deploy the project.

For example, if I need some commands on the stage server, I can set them to be available there and then easily disable them on the production server.

[jacobtylerwalls]

Gotcha. Can you extract that into an app, so that you just plug it into INSTALLED_APPS?

[Mojitaba34]

@jacobtylerwalls Yes, I can. But could you please explain why this can't be part of Django's built-in settings? Does it not follow Django's conventions?

[LilyFirefly]

The biggest reason is that anything we add has a cost - it's more things for users of Django to learn, it's more code that can receive bug reports, etc. This means that as a project we try to be careful only to add new features that are worth the cost. In this case, I think the benefit is small and only a few users would use it, which weighs strongly in the "it's not worth it" column.

You may be able to monkeypatch Django to implement this feature within your own project. If that worked you could also publish that as a third party package, so other people with the same need could use it. But I doubt there'll ever be enough people with this need to justify adding it into Django itself.

[nessita]

There is also the high level aspect of this request: the need is extremely narrow. This request asks for commands blocked on production and available on staging, keyed off the environment. The next report will ask for them blocked for some users and not others, or only outside a maintenance window, or blocked by default with an escape hatch. Each of those is just as reasonable, and none is served by DISABLED_MANAGEMENT_COMMANDS. We would end up adding a setting per variation or growing this one into a rules engine, and both are worse than the ten lines of project code that already solve any of them.

Django runs in a very large number of projects with wildly different deployment stories, from a single VM with a cron job to containers where nobody has shell access at all. The settings module cannot encode the union of those needs, and every attempt is permanent, documented, and has to be honored by every future refactor of the code it touches.

The other reason to leave this out is that it belongs one layer up. Blocking risky commands on production is a deployment concern, and deployment tooling has better answers for it: an image without a shell, a database user without DROP rights, a CI job that runs migrations so humans do not. A settings flag sits inside the process it is trying to constrain, which is why --settings and call_command() walk around it. An app-level solution gives the same per-environment behavior with none of that ambiguity.

Lastly, Django being a general purpose web framework, it gives projects the pieces to build the policy they need rather than shipping one policy for everyone. That is why commands are looked up through INSTALLED_APPS and can be shadowed, why the same is true of storages, backends, and template engines, and why so much of Django is a class you subclass instead of a flag you flip. Packaging this as a reusable app is not a workaround, it is the extension point working as intended, and it leaves you free to change the rules later without waiting on a Django release.

[Mojitaba34]

@LilyFirefly Thank you for your explanation. But with monkeypatching, we may break the entire management command functionality. Even call_command() could be affected, and that is not what I want because monkeypatching changes the behavior globally, beyond the scope where I need to apply the restriction. There is a solution for this but it get's complicated in this case.

[Mojitaba34]

@nessita Thank you for the detailed explanation. I understand the concern about keeping Django's API surface small.

My intention isn't to introduce a deployment policy engine or support every possible restriction (users, maintenance windows, schedules, etc.). The proposal is much narrower: provide a simple mechanism to disable selected management commands when they are invoked through the CLI, while leaving the existing programmatic API (call_command()) unchanged.

I also don't see this as being specific to production deployments. There are many situations where projects want to prevent accidental execution of destructive or organization-specific commands while still allowing automation to use them. Today, every project that needs this has to implement its own solution, even though the interception point is always the same.

From my perspective, this is similar to other settings that customize Django's behavior without becoming policy engines. DISABLED_MANAGEMENT_COMMANDS would simply define which commands are unavailable from the command line, without trying to answer why they are unavailable.

That said, I appreciate your explanation and understand the concern about the long-term maintenance cost.