A feature list decides which icons appear in a client's cPanel. Every package points at one, and the client sees exactly what that list allows: nothing more, whether or not the server supports it.
This is the tool for shaping what hosting looks like to your customers, and it is also the tool most resellers never open.
What a feature list is not
Worth clearing up first, because getting this wrong produces a false sense of security.
A feature list controls the interface. It hides an icon. It does not remove the underlying capability, and it does not enforce a limit.
Hiding the Cron Jobs icon does not stop someone with SSH access from writing a crontab. Hiding the MySQL icon does not stop an application from using its database. If you need a real restriction, that is a package limit or a server setting. The feature list only decides what is on the screen.
Used correctly, that is still valuable: a cPanel showing forty icons a client will never use is worse than one showing fifteen they might.
Creating one
In WHM, open Feature Manager.
Do not edit the default list. It applies to anything without an explicit list, including accounts you create later without thinking about it, and changing it has consequences across your whole server.
Instead, add a new list. Give it a name matching the package it serves, starter, business, so the connection is obvious a year from now.
You get every feature with a checkbox. Start from everything enabled and remove, instead of starting from nothing and adding. It is far easier to spot something that should not be there than to notice something missing.
What to turn off, and why
The candidates fall into three groups.
Things that cost you money or resources. Backup generation on a plan where you provide backups anyway. Any feature tied to a licensed application you have not paid for; the icon appears and the client gets an error, which generates a support ticket for something they were never entitled to.
Things that will break something. Nameserver and DNS features on a plan where you control DNS centrally. A client editing a zone you manage is a fault report waiting to be filed.
Things that only produce confusion. Advanced tools on a starter plan bought by somebody who wanted a website. Every icon they do not understand is a possible support conversation.
What not to turn off
Restraint matters here, because hiding something useful generates more support than showing it.
Leave File Manager, Email Accounts, Backups (restore, at minimum) and SSL/TLS Status visible on every plan. Those are the things clients need at exactly the moment they cannot reach you.
A client who cannot restore a file or fix a certificate becomes a ticket. A client who can becomes nothing at all, which is the outcome you want.
Attaching it to a package
A list on its own does nothing. It applies through a package.
Edit the package and set its feature list. New accounts on that package get it immediately. Creating hosting packages deals with the rest of the package settings.
Existing accounts do not move on their own. Changing an account's package updates its feature list, and that is the only way an existing client's cPanel changes.
Changes are immediate and visible
Edit a list and every account using it changes on the next cPanel login. There is no rebuild step and no delay.
Which cuts both ways: removing a feature takes it away from clients who may have been using it that morning. If a feature is in use, tell people before you remove it rather than after they report it missing.
Overriding for one account
Sometimes one client needs something their plan does not include.
Set the feature list on that account directly rather than creating a package for one customer. It works, and it creates an account whose behaviour does not match its package.
Write it down somewhere. An exception nobody remembers is the reason a future support call makes no sense. Two clients on the same plan seeing different things, with no record of why.
A practical starting point
For a basic shared plan, a list that works: files, databases, email, domains and subdomains, backups, SSL, statistics, and the application installer.
Off: terminal and SSH, DNS zone editing, nameserver management, anything for licensed software you do not provide, and the more obscure security tooling.
For a developer-oriented plan, put terminal, Git and the PHP selector back. Those clients ask for exactly those three, and hiding them just means answering the question by email. There is more on what they get in cPanel terminal and SSH access.
Check it as a client would
Do not judge the result from the Feature Manager screen. Log in to a test account on that package and look at the cPanel a client actually sees.
Two things show up only this way: an icon you meant to remove and missed, and a group heading left behind with nothing under it, which looks broken rather than deliberate.
Keep a test account on each package for exactly this; it costs nothing and it is the only honest view of what you are selling.
Audit which list each account is on
Feature lists accumulate and drift, and the question of who has which is not answered by any single screen.
ls /var/cpanel/features/ for u in $(ls /var/cpanel/users); do printf '%-18s %s\n' "$u" "$(grep -m1 '^FEATURELIST=' /var/cpanel/users/$u | cut -d= -f2)" done | sort -k2 | uniq -c -f1 | head
What turns up is usually a list created for one customer years ago and still attached to several, plus lists attached to nobody at all.
Remove the unused ones and consolidate the near duplicates. A short list of feature lists is one somebody can reason about when creating a new account, which is when the wrong choice gets made.
Removing a feature does not remove what it created
Turning something off hides the tool. It does nothing to what the customer already built with it.
Disabling cron access leaves existing scheduled jobs running. Disabling a database tool leaves the databases in place. Disabling email filters leaves the filters active and invisible.
crontab -l -u username 2>/dev/null | grep -vc '^#' ls /var/cpanel/users/username 2>/dev/null && grep -c . /home/username/.cpanel/nvdata/* 2>/dev/null | head -3
That matters when the feature was removed for a reason. If cron was disabled because a job was consuming the server, the job is still consuming the server and the customer can no longer see it to stop it.