LogoفارسیFA

Customizing Workflow in DirectAdmin: Hooks, Feature Sets, Command Control, and Plugin Management

This article provides a complete overview of how to customize and extend DirectAdmin’s workflow. It covers pre/post hook scripts, command-level access control, feature sets, plugin permissions, and package-based plugin management. These tools allow administrators to tailor DirectAdmin’s behavior, restrict or expand user capabilities, and integrate custom automation safely and efficiently.

DirectAdmin customizationfeature setspre/post scripts

~3 min read • Updated Mar 1, 2026

1. Overview of DirectAdmin Workflow Customization


DirectAdmin includes several mechanisms that allow administrators to modify how the control panel behaves, what users can access, and how system tasks are executed. These customization layers include:


  • Pre/Post hook scripts
  • Command allow/deny rules
  • Feature Sets
  • Plugins and plugin-level permissions

---

2. Pre/Post Shell Scripts (Hooks)


Pre/Post scripts are powerful hooks that allow you to execute custom code before or after DirectAdmin performs a task. Examples include:


  • user_create_pre.sh — runs before a user is created
  • user_create_post.sh — runs after a user is created
  • Similar hooks exist for domains, DNS, email, packages, and more

Key behavior:


  • Pre-scripts can stop the operation by exiting with a non zero code
  • Post-scripts run after the operation completes and can extend functionality

Lists of available hooks:


  • All *_post.sh scripts
  • All *_pre.sh scripts

DirectAdmin’s KnowledgeBase also includes many examples for both types.


---

3. Command Allow/Deny Rules


Each DirectAdmin user can have their own commands.allow and commands.deny files. These files define which internal DirectAdmin commands the user is allowed or denied from executing.


This method is simpler than scripting because:


  • No scripting is required
  • You only list command names
  • It works per-user

Additionally, the Login Keys feature (introduced in DA 1.40.2) allows:


  • Multiple passwords per account
  • Command restrictions
  • IP restrictions
  • Expiration and usage limits

---

4. Feature Sets


Feature Sets provide a modular way to control which DirectAdmin commands a user or package can access. Unlike packages, which control limits, Feature Sets control functionality.


4.1 How Feature Sets Work


Each user or package can include:


feature_sets=view_domain:tickets:dns_only

Rules:


  • Values are colon-separated
  • Invalid or missing sets are ignored
  • Leaving the value blank removes the variable

4.2 Feature Set Storage


Default sets:


/usr/local/directadmin/data/templates/feature_sets/

Custom sets:


/usr/local/directadmin/data/templates/custom/feature_sets/

4.3 Default Feature Sets


  • dns_only — DNS management only
  • email_only — Email-related features
  • tickets — Message/Ticket system
  • view_domain — Basic domain overview and password changes
  • core_functions — Combination of view_domain + tickets

---

5. Creating a Custom Feature Set


5.1 Create the directory


mkdir -p /usr/local/directadmin/data/templates/custom/feature_sets
cd /usr/local/directadmin/data/templates/feature_sets/
cp -rp core_functions ../custom/feature_sets/example_set

5.2 Name the feature set


/usr/local/directadmin/data/templates/feature_sets/example_set/lang/en.name.txt

5.3 Add allowed commands


Edit:


example_set/commands.allow

To discover command names:


  • Use DirectAdmin debug mode
  • Use API:

curl -s $(da api-url --user=[DA_USER])/api/session | jq '.allowedCommands'

5.4 Assign the feature set


To a user:


Admin Level → Show All Users → Modify → Feature Sets

To a package:


Admin Level → Manage User Packages → Modify/Create → Feature Sets

---

6. Plugins


Plugins allow you to add custom functionality to DirectAdmin. They run with the user’s permissions, making them safe by default.


Important: Plugins can run as root only if you create a setuid binary (chmod 4755), which is dangerous unless coded securely.


---

7. Plugin Permissions in Packages


Plugins can be enabled or disabled per user or per package.


7.1 Storage locations


User package:


/usr/local/directadmin/data/users/USERNAME/packages/PACKAGE_NAME

User configuration:


/usr/local/directadmin/data/users/USERNAME/user.conf

7.2 Allowing or denying plugins


Allow only specific plugins:


plugins_allow=plug1:plug2

Deny specific plugins:


plugins_deny=plug3:plug4

7.3 Logic rules


  • If neither variable exists → all plugins allowed
  • If plugins_allow exists → only listed plugins allowed
  • If plugins_deny exists → listed plugins denied
  • If both exist → plugins_allow overrides everything

7.4 Clearing plugin lists


plugins_allow=[clear]
plugins_deny=[clear]

Note: Setting plugins_allow= (empty) blocks all plugins.


Written & researched by Dr. Shahin Siami

Next Article