{"id":4070,"date":"2026-01-03T16:08:08","date_gmt":"2026-01-03T13:08:08","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/designing-cpanel-reseller-packages-cpu-inode-disk-and-email-limits-that-actually-work\/"},"modified":"2026-01-03T16:08:08","modified_gmt":"2026-01-03T13:08:08","slug":"designing-cpanel-reseller-packages-cpu-inode-disk-and-email-limits-that-actually-work","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/designing-cpanel-reseller-packages-cpu-inode-disk-and-email-limits-that-actually-work\/","title":{"rendered":"Designing cPanel Reseller Packages: CPU, Inode, Disk and Email Limits That Actually Work"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>If you run a cPanel reseller business, your real product is not just \u201cspace\u201d or \u201ctraffic\u201d \u2013 it\u2019s how intelligently you slice server resources between customers. Two clients with the same disk quota can create completely different loads on CPU, inodes and email. If you design your reseller packages only around GB and \u201cunlimited email accounts\u201d, you will either overload the server or leave money on the table. In this article, we\u2019ll walk through how we at dchost.com think about designing cPanel reseller packages: which limits matter, how they interact, and what realistic numbers look like for different client types (brochure sites, WordPress blogs, WooCommerce stores, email-heavy clients, and more). We\u2019ll focus on four critical levers you can control per cPanel account \u2013 CPU, inodes, disk and email \u2013 and show you how to turn them into clear, sustainable packages instead of guesswork. The goal: predictable performance for your clients, fewer support tickets for you, and a reseller business that stays profitable as you grow.<\/p>\n<div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#Why_Resource_Design_Matters_in_cPanel_Reseller_Hosting\"><span class=\"toc_number toc_depth_1\">1<\/span> Why Resource Design Matters in cPanel Reseller Hosting<\/a><\/li><li><a href=\"#Understanding_the_Main_Resource_Types_in_cPanel_Reseller_Packages\"><span class=\"toc_number toc_depth_1\">2<\/span> Understanding the Main Resource Types in cPanel Reseller Packages<\/a><ul><li><a href=\"#CPU_The_Real_Performance_Throttle\"><span class=\"toc_number toc_depth_2\">2.1<\/span> CPU: The Real Performance Throttle<\/a><\/li><li><a href=\"#Inodes_Count_of_Files_and_Folders_Not_Size\"><span class=\"toc_number toc_depth_2\">2.2<\/span> Inodes: Count of Files and Folders, Not Size<\/a><\/li><li><a href=\"#Disk_Space_Where_Overselling_Can_Hurt_You\"><span class=\"toc_number toc_depth_2\">2.3<\/span> Disk Space: Where Overselling Can Hurt You<\/a><\/li><li><a href=\"#Email_Limits_Storage_Throughput_and_Behavior\"><span class=\"toc_number toc_depth_2\">2.4<\/span> Email Limits: Storage, Throughput and Behavior<\/a><\/li><\/ul><\/li><li><a href=\"#Assessing_Your_Capacity_Before_You_Create_Reseller_Packages\"><span class=\"toc_number toc_depth_1\">3<\/span> Assessing Your Capacity Before You Create Reseller Packages<\/a><ul><li><a href=\"#1_What_Are_My_Real_Underlying_Resources\"><span class=\"toc_number toc_depth_2\">3.1<\/span> 1. What Are My Real Underlying Resources?<\/a><\/li><li><a href=\"#2_What_Mix_of_Clients_Do_I_Actually_Have_or_Want\"><span class=\"toc_number toc_depth_2\">3.2<\/span> 2. What Mix of Clients Do I Actually Have (or Want)?<\/a><\/li><li><a href=\"#3_How_Many_Accounts_per_Server_or_Reseller_Do_I_Want\"><span class=\"toc_number toc_depth_2\">3.3<\/span> 3. How Many Accounts per Server or Reseller Do I Want?<\/a><\/li><\/ul><\/li><li><a href=\"#Designing_cPanel_Reseller_Packages_CPU_Inode_and_Disk_Allocation_Models\"><span class=\"toc_number toc_depth_1\">4<\/span> Designing cPanel Reseller Packages: CPU, Inode and Disk Allocation Models<\/a><ul><li><a href=\"#Step_1_Decide_Your_Package_Tiers_and_Target_Use_Cases\"><span class=\"toc_number toc_depth_2\">4.1<\/span> Step 1: Decide Your Package Tiers and Target Use Cases<\/a><\/li><li><a href=\"#Step_2_Translate_Server_CPU_into_Per-Account_Budgets\"><span class=\"toc_number toc_depth_2\">4.2<\/span> Step 2: Translate Server CPU into Per-Account Budgets<\/a><\/li><li><a href=\"#Step_3_Set_Inode_Limits_That_Match_Each_Tier\"><span class=\"toc_number toc_depth_2\">4.3<\/span> Step 3: Set Inode Limits That Match Each Tier<\/a><\/li><li><a href=\"#Step_4_Set_Disk_Quotas_per_Package_with_Sensible_Oversell\"><span class=\"toc_number toc_depth_2\">4.4<\/span> Step 4: Set Disk Quotas per Package with Sensible Oversell<\/a><\/li><li><a href=\"#Step_5_Align_Email_Quotas_and_Limits_with_Each_Tier\"><span class=\"toc_number toc_depth_2\">4.5<\/span> Step 5: Align Email Quotas and Limits with Each Tier<\/a><\/li><\/ul><\/li><li><a href=\"#Designing_Email_Limits_and_Policies_That_Dont_Kill_Your_Margins\"><span class=\"toc_number toc_depth_1\">5<\/span> Designing Email Limits and Policies That Don\u2019t Kill Your Margins<\/a><ul><li><a href=\"#Per-Mailbox_and_Per-Account_Quotas\"><span class=\"toc_number toc_depth_2\">5.1<\/span> Per-Mailbox and Per-Account Quotas<\/a><\/li><li><a href=\"#SMTP_Sending_Limits_and_Abuse_Prevention\"><span class=\"toc_number toc_depth_2\">5.2<\/span> SMTP Sending Limits and Abuse Prevention<\/a><\/li><li><a href=\"#Retention_Archiving_and_Cleanup_Policies\"><span class=\"toc_number toc_depth_2\">5.3<\/span> Retention, Archiving and Cleanup Policies<\/a><\/li><\/ul><\/li><li><a href=\"#Monitoring_Tuning_and_Knowing_When_to_Upgrade_Your_Stack\"><span class=\"toc_number toc_depth_1\">6<\/span> Monitoring, Tuning and Knowing When to Upgrade Your Stack<\/a><ul><li><a href=\"#Key_Metrics_to_Track_per_Account_and_per_Server\"><span class=\"toc_number toc_depth_2\">6.1<\/span> Key Metrics to Track per Account and per Server<\/a><\/li><li><a href=\"#When_to_Tighten_Package_Limits_vs_When_to_Upgrade\"><span class=\"toc_number toc_depth_2\">6.2<\/span> When to Tighten Package Limits vs When to Upgrade<\/a><\/li><li><a href=\"#Segmenting_Noisy_Clients_to_Higher_Plans\"><span class=\"toc_number toc_depth_2\">6.3<\/span> Segmenting \u201cNoisy\u201d Clients to Higher Plans<\/a><\/li><\/ul><\/li><li><a href=\"#Example_Package_Templates_You_Can_Adapt_on_dchostcom\"><span class=\"toc_number toc_depth_1\">7<\/span> Example Package Templates You Can Adapt on dchost.com<\/a><ul><li><a href=\"#Starter_Package_Small_Single_Site\"><span class=\"toc_number toc_depth_2\">7.1<\/span> Starter Package \u2013 Small Single Site<\/a><\/li><li><a href=\"#Business_Package_Standard_WordPress_Site\"><span class=\"toc_number toc_depth_2\">7.2<\/span> Business Package \u2013 Standard WordPress Site<\/a><\/li><li><a href=\"#Commerce_Package_WooCommerce_and_Heavier_Apps\"><span class=\"toc_number toc_depth_2\">7.3<\/span> Commerce Package \u2013 WooCommerce and Heavier Apps<\/a><\/li><li><a href=\"#Agency_Package_Many_Small_Sites_Under_One_cPanel\"><span class=\"toc_number toc_depth_2\">7.4<\/span> Agency Package \u2013 Many Small Sites Under One cPanel<\/a><\/li><\/ul><\/li><li><a href=\"#Bringing_It_All_Together_A_Sustainable_cPanel_Reseller_Strategy\"><span class=\"toc_number toc_depth_1\">8<\/span> Bringing It All Together: A Sustainable cPanel Reseller Strategy<\/a><\/li><\/ul><\/div>\n<h2><span id=\"Why_Resource_Design_Matters_in_cPanel_Reseller_Hosting\">Why Resource Design Matters in cPanel Reseller Hosting<\/span><\/h2>\n<p>When you buy a reseller plan or a <a href=\"https:\/\/www.dchost.com\/vps\">VPS<\/a>\/<a href=\"https:\/\/www.dchost.com\/dedicated-server\">dedicated server<\/a> and carve it into multiple cPanel accounts, you\u2019re doing capacity planning, even if you never call it that. Every decision about disk quota, email limits or the number of accounts you sell per plan directly affects:<\/p>\n<ul>\n<li><strong>Performance<\/strong> \u2013 how fast client sites load, and whether they hit \u201cResource Limit Reached\u201d type errors.<\/li>\n<li><strong>Stability<\/strong> \u2013 whether one noisy neighbor account can impact everyone else.<\/li>\n<li><strong>Support load<\/strong> \u2013 how many tickets you handle about slow sites, full mailboxes or failed backups.<\/li>\n<li><strong>Profitability<\/strong> \u2013 how many accounts you can safely host on the resources you pay for.<\/li>\n<\/ul>\n<p>We\u2019ve already written in detail about <a href=\"https:\/\/www.dchost.com\/blog\/en\/cpanel-kaynak-limitleri-nedir-cpu-io-ram-ve-entry-processes-limitlerini-dogru-okumak\/\">understanding cPanel resource limits like CPU, IO, RAM and entry processes<\/a>. In reseller hosting, the same principles apply, but now you have to translate them into packages that non-technical clients can understand. They should see simple labels like \u201cStarter \/ Business \/ Pro\u201d, while underneath you\u2019re balancing CPU, inodes, disk and email usage so that no single package can silently destroy your margins.<\/p>\n<h2><span id=\"Understanding_the_Main_Resource_Types_in_cPanel_Reseller_Packages\">Understanding the Main Resource Types in cPanel Reseller Packages<\/span><\/h2>\n<p>Before we talk about numbers, let\u2019s align on what each resource really means in cPanel\/CloudLinux-style environments and how it behaves in a reseller context.<\/p>\n<h3><span id=\"CPU_The_Real_Performance_Throttle\">CPU: The Real Performance Throttle<\/span><\/h3>\n<p>On most modern cPanel servers (including our reseller infrastructure at dchost.com), CPU is enforced per account via an isolation layer (typically CloudLinux LVE). Instead of \u201c1 vCPU core\u201d, you\u2019ll usually see limits like:<\/p>\n<ul>\n<li><strong>CPU%<\/strong> \u2013 percentage of one full CPU core (e.g. 100% = 1 core, 200% = 2 cores).<\/li>\n<li><strong>EP (Entry Processes)<\/strong> \u2013 roughly, concurrent PHP processes or web requests in progress.<\/li>\n<\/ul>\n<p>For resellers, you may not expose CPU% or EP as a marketing feature, but you absolutely need to factor them into your package design. Typical cPanel account patterns we see:<\/p>\n<ul>\n<li><strong>Small brochure site<\/strong> \u2013 ~10\u201330% of a CPU core under peak, EP 5\u201310 is plenty.<\/li>\n<li><strong>Standard WordPress blog<\/strong> \u2013 ~50\u201375% CPU under peak, EP 10\u201320.<\/li>\n<li><strong>WooCommerce \/ small store<\/strong> \u2013 75\u2013150% CPU under load, EP 20\u201330.<\/li>\n<\/ul>\n<p>If your reseller plan (or your own VPS) is effectively \u201c4 CPU cores\u201d and you sell 40 \u201cWooCommerce-ready\u201d accounts all expecting 150% CPU bursts, you\u2019ll hit contention quickly. CPU is the first thing to model when deciding how many accounts each package tier supports.<\/p>\n<h3><span id=\"Inodes_Count_of_Files_and_Folders_Not_Size\">Inodes: Count of Files and Folders, Not Size<\/span><\/h3>\n<p>Inodes represent the <strong>number of files and directories<\/strong>, not their size. Every PHP file, image, email message, cache file and session file consumes one inode. On busy WordPress sites with many plugins, page-builder caches and large media libraries, inode usage climbs much faster than disk usage in GB.<\/p>\n<p>We\u2019ve covered inode management in detail in our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/paylasimli-hostingde-inode-limitine-takilmamak-icin-uygulamali-temizlik-rehberi\/\">how to avoid inode limits on shared hosting<\/a>. For resellers the key takeaways are:<\/p>\n<ul>\n<li>A typical fresh WordPress install: ~8\u201312K inodes.<\/li>\n<li>Real-world brochure site with a few plugins: 20\u201340K inodes.<\/li>\n<li>Heavier WooCommerce \/ media-heavy sites: 80\u2013200K+ inodes.<\/li>\n<li>Email-heavy accounts (IMAP, never deleting): hundreds of thousands of inodes just from mail.<\/li>\n<\/ul>\n<p>If you don\u2019t enforce inode limits per package, a single client with bad backup habits, gigantic email folders or a bloated cache directory can eat a disproportionate share of your file system and slow down backups and file operations for everyone.<\/p>\n<h3><span id=\"Disk_Space_Where_Overselling_Can_Hurt_You\">Disk Space: Where Overselling Can Hurt You<\/span><\/h3>\n<p>Disk quota is the number that clients look at first, but it\u2019s the <strong>easiest one to oversell<\/strong>. Because many clients never use their full quota, providers (including us) can safely oversubscribe disk to some extent \u2013 but there are constraints:<\/p>\n<ul>\n<li>Your <strong>physical disk<\/strong> and RAID overhead (e.g. NVMe vs SATA, RAID10, etc.).<\/li>\n<li><strong>Backup strategy<\/strong> \u2013 how many days of full\/incremental backups you store.<\/li>\n<li><strong>Filesystem performance<\/strong> \u2013 very full filesystems can become slow and fragile.<\/li>\n<\/ul>\n<p>If your reseller allocation is 200 GB on the parent server, selling five \u201c100 GB\u201d packages is only sustainable if your average real usage stays well under 40 GB per account. Otherwise you\u2019ll either run out of space, or pay for bigger backing storage earlier than expected. It\u2019s better to sell modest quotas that most clients actually use than huge numbers that force you into emergency upgrades and rushed migrations.<\/p>\n<h3><span id=\"Email_Limits_Storage_Throughput_and_Behavior\">Email Limits: Storage, Throughput and Behavior<\/span><\/h3>\n<p>\u201cUnlimited email accounts\u201d sounds attractive in marketing, but in practice, email is one of the <strong>most expensive<\/strong> parts of a shared server: it consumes storage, inodes, CPU (spam filtering, indexing) and I\/O. You have several levers in cPanel reseller packages:<\/p>\n<ul>\n<li><strong>Mailbox storage quota<\/strong> (per mailbox and per account).<\/li>\n<li><strong>Number of email accounts<\/strong> per domain\/account.<\/li>\n<li><strong>Sending limits<\/strong> (emails per hour\/day).<\/li>\n<li><strong>Retention policies<\/strong> \u2013 encouraging archiving and cleanup.<\/li>\n<\/ul>\n<p>Our detailed guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/cpanelde-e-posta-alani-yonetimi-kota-ek-temizligi-ve-dev-mail-kutularini-kucultme-rehberi\/\">managing email storage on cPanel<\/a> shows how multi-GB mailboxes quickly dominate a user\u2019s disk quota and inode usage. As a reseller, if you don\u2019t design email limits and policies upfront, a few \u201cwe never delete emails\u201d customers can consume more than your entire profit from their plan.<\/p>\n<h2><span id=\"Assessing_Your_Capacity_Before_You_Create_Reseller_Packages\">Assessing Your Capacity Before You Create Reseller Packages<\/span><\/h2>\n<p>Package design without capacity math is just wishful thinking. Whether you\u2019re using a reseller plan from dchost.com or running your own WHM on a VPS\/dedicated server, you should answer three questions first:<\/p>\n<h3><span id=\"1_What_Are_My_Real_Underlying_Resources\">1. What Are My Real Underlying Resources?<\/span><\/h3>\n<p>List the hard numbers you have:<\/p>\n<ul>\n<li><strong>vCPU \/ cores<\/strong> \u2013 e.g. 4 dedicated vCPU cores.<\/li>\n<li><strong>RAM<\/strong> \u2013 e.g. 8\u201316 GB.<\/li>\n<li><strong>Disk type and size<\/strong> \u2013 e.g. 500 GB NVMe.<\/li>\n<li><strong>IOPS \/ throughput constraints<\/strong> \u2013 depends on the storage backend.<\/li>\n<li><strong>Network bandwidth<\/strong> \u2013 monthly transfer and port speed.<\/li>\n<\/ul>\n<p>If you\u2019re using a reseller hosting plan instead of managing a full server, some of these will be abstracted away. You\u2019ll see high-level limits like:<\/p>\n<ul>\n<li>Total disk you can allocate to all your cPanel accounts.<\/li>\n<li>Total number of accounts you can create.<\/li>\n<li>Global CPU\/IO envelope for your reseller brand.<\/li>\n<\/ul>\n<p>These still have to be translated into realistic per-account expectations.<\/p>\n<h3><span id=\"2_What_Mix_of_Clients_Do_I_Actually_Have_or_Want\">2. What Mix of Clients Do I Actually Have (or Want)?<\/span><\/h3>\n<p>Not all clients are equal. We often group them into a few simple personas:<\/p>\n<ul>\n<li><strong>Static \/ brochure<\/strong> \u2013 corporate site, few pages, low traffic.<\/li>\n<li><strong>Standard WordPress<\/strong> \u2013 blogs, marketing sites, lead-gen landing pages.<\/li>\n<li><strong>WooCommerce \/ e-commerce<\/strong> \u2013 dynamic, logged-in users, cart\/checkout.<\/li>\n<li><strong>Email-heavy businesses<\/strong> \u2013 many accounts, large IMAP folders.<\/li>\n<li><strong>Agencies with multiple small sites<\/strong> \u2013 often many low-traffic domains in one account.<\/li>\n<\/ul>\n<p>Your package lineup should mirror the mix you want to attract. If you mostly serve agencies, you\u2019ll want a package tuned for \u201c10 low-traffic sites in one control panel\u201d rather than one massive WooCommerce store per account.<\/p>\n<h3><span id=\"3_How_Many_Accounts_per_Server_or_Reseller_Do_I_Want\">3. How Many Accounts per Server or Reseller Do I Want?<\/span><\/h3>\n<p>Every reseller business has a <strong>comfort zone<\/strong> for accounts per server. Some aim for 50\u201380 well-paying accounts on a mid-size server. Others aim for 150+ lighter accounts. Either way, decide a target like:<\/p>\n<ul>\n<li>\u201cOn this 4 vCPU \/ 8 GB \/ 200 GB reseller, I will host maximum 60 accounts.\u201d<\/li>\n<\/ul>\n<p>Then work backwards: if you sell three package tiers, roughly how many accounts of each type fit that total? That drives the per-package resource limits you can safely offer.<\/p>\n<h2><span id=\"Designing_cPanel_Reseller_Packages_CPU_Inode_and_Disk_Allocation_Models\">Designing cPanel Reseller Packages: CPU, Inode and Disk Allocation Models<\/span><\/h2>\n<p>Let\u2019s walk through a practical way to design 3\u20134 reseller package tiers using the resources you control in WHM and (when present) CloudLinux LVE Manager.<\/p>\n<h3><span id=\"Step_1_Decide_Your_Package_Tiers_and_Target_Use_Cases\">Step 1: Decide Your Package Tiers and Target Use Cases<\/span><\/h3>\n<p>A simple, effective structure we often recommend to agencies and freelancers using dchost.com reseller hosting:<\/p>\n<ul>\n<li><strong>Starter<\/strong> \u2013 1 small site, brochure\/low-traffic blog.<\/li>\n<li><strong>Business<\/strong> \u2013 1\u20132 WordPress sites or 1 heavier site.<\/li>\n<li><strong>Commerce<\/strong> \u2013 WooCommerce or other heavier PHP app.<\/li>\n<li><strong>Agency<\/strong> \u2013 multiple low-traffic sites in a single cPanel account.<\/li>\n<\/ul>\n<p>You don\u2019t have to expose \u201cCPU\u201d in the marketing, but each tier will map to different behind-the-scenes limits.<\/p>\n<h3><span id=\"Step_2_Translate_Server_CPU_into_Per-Account_Budgets\">Step 2: Translate Server CPU into Per-Account Budgets<\/span><\/h3>\n<p>Assume you\u2019re on a 4-core environment (400% CPU in LVE terms) and want a max of 60 accounts. A reasonable allocation model could look like this:<\/p>\n<ul>\n<li><strong>Starter<\/strong> \u2013 25% CPU, EP 10.<\/li>\n<li><strong>Business<\/strong> \u2013 50% CPU, EP 15.<\/li>\n<li><strong>Commerce<\/strong> \u2013 100% CPU, EP 25.<\/li>\n<li><strong>Agency<\/strong> \u2013 75% CPU, EP 25 (but fewer total Agency accounts).<\/li>\n<\/ul>\n<p>Now consider how many of each you expect to sell, for example:<\/p>\n<ul>\n<li>30\u00d7 Starter (30 \u00d7 25% = 750% CPU peak theoretical).<\/li>\n<li>20\u00d7 Business (20 \u00d7 50% = 1000% CPU).<\/li>\n<li>5\u00d7 Commerce (5 \u00d7 100% = 500% CPU).<\/li>\n<li>5\u00d7 Agency (5 \u00d7 75% = 375% CPU).<\/li>\n<\/ul>\n<p>If all those accounts maxed CPU at once, you\u2019d be well above 400%. In reality, not all accounts peak simultaneously. Still, this exercise helps you sanity check whether your mix is realistic. You might adjust down:<\/p>\n<ul>\n<li>Reduce Commerce CPU to 75% initially.<\/li>\n<li>Cap Commerce and Agency accounts more strictly.<\/li>\n<li>Raise prices on heavier packages to reflect their true CPU cost.<\/li>\n<\/ul>\n<p>Our earlier article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/cpanelde-kaynak-limitleri-cpu-io-ep-ram-ve-resource-limit-reached-hatasini-onlemek\/\">avoiding the \u201cResource Limit Reached\u201d error on shared hosting<\/a> is helpful here: you want limits that protect the server without constantly frustrating legitimate clients.<\/p>\n<h3><span id=\"Step_3_Set_Inode_Limits_That_Match_Each_Tier\">Step 3: Set Inode Limits That Match Each Tier<\/span><\/h3>\n<p>In WHM (with CloudLinux), you can assign inode limits per package. A practical starting point for most reseller stacks:<\/p>\n<ul>\n<li><strong>Starter<\/strong> \u2013 100K inodes.<\/li>\n<li><strong>Business<\/strong> \u2013 200\u2013300K inodes.<\/li>\n<li><strong>Commerce<\/strong> \u2013 400\u2013600K inodes.<\/li>\n<li><strong>Agency<\/strong> \u2013 400\u2013600K inodes (with clear policies on staging\/backup usage).<\/li>\n<\/ul>\n<p>Why these numbers?<\/p>\n<ul>\n<li>100K covers a typical WordPress site with some room for uploads and caching.<\/li>\n<li>300K gives space for WooCommerce plus media libraries and logs.<\/li>\n<li>600K allows for multiple sites or one very busy store, but still prevents runaway growth.<\/li>\n<\/ul>\n<p>Complementing this, teach clients to <strong>clean up old backups, unused themes\/plugins and mail folders<\/strong>. You can even turn your inode cleanup advice into a recurring \u201ccare plan\u201d service.<\/p>\n<h3><span id=\"Step_4_Set_Disk_Quotas_per_Package_with_Sensible_Oversell\">Step 4: Set Disk Quotas per Package with Sensible Oversell<\/span><\/h3>\n<p>Next, convert your total disk allocation into per-package quotas. Suppose your reseller has 200 GB usable disk and you aim for 60 accounts. A naive even split would be ~3.3 GB per account, but in practice you\u2019ll sell tiers like:<\/p>\n<ul>\n<li><strong>Starter<\/strong> \u2013 5 GB.<\/li>\n<li><strong>Business<\/strong> \u2013 10\u201315 GB.<\/li>\n<li><strong>Commerce<\/strong> \u2013 20\u201330 GB.<\/li>\n<li><strong>Agency<\/strong> \u2013 30\u201340 GB.<\/li>\n<\/ul>\n<p>You are overselling on paper \u2013 60 \u00d7 10 GB = 600 GB \u201cmarketed capacity\u201d vs 200 GB real capacity \u2013 but that\u2019s normal: most Starter accounts never reach 5 GB, and many Business accounts sit at 3\u20138 GB. Two important rules to keep this safe:<\/p>\n<ol>\n<li><strong>Track actual usage monthly<\/strong> \u2013 if averages creep up, adjust quotas for new sales.<\/li>\n<li><strong>Never oversell backups<\/strong> \u2013 if you keep 7\u201314 days of backups, factor that multiplied size into your storage planning.<\/li>\n<\/ol>\n<p>For e-commerce or media-heavy clients, combine disk quotas with education about <a href=\"https:\/\/www.dchost.com\/blog\/en\/object-storage-ile-medya-offload-stratejisi\/\">offloading media to object storage\/CDN<\/a>, especially when sites start storing thousands of product images or user uploads.<\/p>\n<h3><span id=\"Step_5_Align_Email_Quotas_and_Limits_with_Each_Tier\">Step 5: Align Email Quotas and Limits with Each Tier<\/span><\/h3>\n<p>Finally, translate disk and inode thinking into email rules. We\u2019ll go deeper in the next section, but at a high level:<\/p>\n<ul>\n<li><strong>Starter<\/strong> \u2013 up to 5\u201310 email accounts, 500 MB\u20131 GB per mailbox.<\/li>\n<li><strong>Business<\/strong> \u2013 20\u201330 email accounts, 1\u20132 GB per mailbox.<\/li>\n<li><strong>Commerce<\/strong> \u2013 similar to Business, but emphasize transactional email quality and limits.<\/li>\n<li><strong>Agency<\/strong> \u2013 often few mailboxes per site; consider hard per-mailbox caps to keep storage under control.<\/li>\n<\/ul>\n<p>Remember: large IMAP mailboxes consume both disk and inodes. A single 10 GB mailbox can skew the entire account\u2019s resource profile and slow down backups. Your packages should gently push email-heavy businesses either towards higher tiers or dedicated email solutions.<\/p>\n<h2><span id=\"Designing_Email_Limits_and_Policies_That_Dont_Kill_Your_Margins\">Designing Email Limits and Policies That Don\u2019t Kill Your Margins<\/span><\/h2>\n<p>Email is where many reseller businesses quietly bleed resources. You can design beautiful CPU\/disk packages, then watch them erode because a few clients keep every email forever. Here\u2019s how we recommend structuring email inside your cPanel reseller packages.<\/p>\n<h3><span id=\"Per-Mailbox_and_Per-Account_Quotas\">Per-Mailbox and Per-Account Quotas<\/span><\/h3>\n<p>In WHM\/cPanel you can control:<\/p>\n<ul>\n<li><strong>Default mailbox quota<\/strong> when new accounts are created.<\/li>\n<li>Maximum quota per mailbox (hard cap).<\/li>\n<li>Total disk quota per cPanel account (shared with web files and databases).<\/li>\n<\/ul>\n<p>Good starting defaults per package:<\/p>\n<ul>\n<li><strong>Starter<\/strong> \u2013 500 MB default, max 1 GB per mailbox.<\/li>\n<li><strong>Business<\/strong> \u2013 1 GB default, max 2 GB.<\/li>\n<li><strong>Commerce<\/strong> \u2013 1 GB default, max 3\u20134 GB (for support\/sales inboxes).<\/li>\n<li><strong>Agency<\/strong> \u2013 encourage smaller per-site mailboxes, 500 MB\u20131 GB typical.<\/li>\n<\/ul>\n<p>Make these rules explicit in your plan descriptions. Clients don\u2019t mind limits if they\u2019re clear from the start and aligned with pricing.<\/p>\n<h3><span id=\"SMTP_Sending_Limits_and_Abuse_Prevention\">SMTP Sending Limits and Abuse Prevention<\/span><\/h3>\n<p>Per-hour sending limits protect your IP reputation and keep one compromised mailbox from damaging all your clients. Reasonable values we often see on shared\/reseller setups:<\/p>\n<ul>\n<li><strong>Starter<\/strong> \u2013 100 emails\/hour per domain.<\/li>\n<li><strong>Business<\/strong> \u2013 200\u2013300 emails\/hour per domain.<\/li>\n<li><strong>Commerce<\/strong> \u2013 300\u2013500 emails\/hour per domain, plus encouragement to use dedicated transactional email services for newsletters.<\/li>\n<\/ul>\n<p>Document this clearly in your SLA\/FAQ and highlight that packages are <strong>not for bulk marketing campaigns<\/strong>. For recurring transactional email reliability, refer clients to a dedicated sending solution or to our guidance in <a href=\"https:\/\/www.dchost.com\/blog\/en\/wordpress-ve-woocommerce-icin-transactional-e%e2%80%91posta-altyapisi\/\">our transactional email guide for WordPress and WooCommerce<\/a>.<\/p>\n<h3><span id=\"Retention_Archiving_and_Cleanup_Policies\">Retention, Archiving and Cleanup Policies<\/span><\/h3>\n<p>The cheapest GB of disk is the one you never store. Build email hygiene into your reseller offers:<\/p>\n<ul>\n<li>Encourage clients to auto-archive or delete messages older than 12\u201324 months.<\/li>\n<li>Set up IMAP clients to <strong>not keep deleted emails<\/strong> indefinitely in Trash.<\/li>\n<li>Offer paid \u201cemail archiving\u201d on separate storage for legal retention if needed.<\/li>\n<li>Periodically review large mailboxes and send gentle nudges before they hit hard limits.<\/li>\n<\/ul>\n<p>Our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/cpanel-ve-vpste-e-posta-arsivleme-journaling-depolama-ve-yasal-saklama-politikalari\/\">email archiving and legal retention on cPanel and VPS<\/a> walks through how to design longer-term archive strategies when clients need to keep mail for many years.<\/p>\n<h2><span id=\"Monitoring_Tuning_and_Knowing_When_to_Upgrade_Your_Stack\">Monitoring, Tuning and Knowing When to Upgrade Your Stack<\/span><\/h2>\n<p>Package design is never \u201cset and forget\u201d. Once you launch your reseller tiers, you\u2019ll want to watch how real clients use them and adjust over time.<\/p>\n<h3><span id=\"Key_Metrics_to_Track_per_Account_and_per_Server\">Key Metrics to Track per Account and per Server<\/span><\/h3>\n<p>Inside WHM and (if available) CloudLinux tools, keep an eye on:<\/p>\n<ul>\n<li><strong>CPU usage peaks<\/strong> per account.<\/li>\n<li><strong>EP (entry process) faults<\/strong> \u2013 frequent faults mean concurrency is too low.<\/li>\n<li><strong>IO\/IOPS usage<\/strong> \u2013 constant high IO may indicate backup plugins or heavy exports.<\/li>\n<li><strong>Inode counts<\/strong> per account, especially for email-heavy or WooCommerce clients.<\/li>\n<li><strong>Disk usage growth<\/strong> over time (who grows fastest, at what rate?).<\/li>\n<\/ul>\n<p>You don\u2019t need a full observability stack, but basic charts and monthly reviews make a huge difference. For VPS-based reseller setups, we recommend combining WHM metrics with system-level tools like those we describe in our <a href=\"https:\/\/www.dchost.com\/blog\/en\/vps-kaynak-kullanimi-izleme-rehberi-htop-iotop-netdata-ve-prometheus\/\">VPS resource usage monitoring guide<\/a>.<\/p>\n<h3><span id=\"When_to_Tighten_Package_Limits_vs_When_to_Upgrade\">When to Tighten Package Limits vs When to Upgrade<\/span><\/h3>\n<p>As utilization rises, you have three broad levers:<\/p>\n<ol>\n<li><strong>Educate and optimize<\/strong> \u2013 help specific clients clean up mail, cache and backups.<\/li>\n<li><strong>Rebalance packages<\/strong> \u2013 adjust future package limits or pricing (grandfathering existing clients where possible).<\/li>\n<li><strong>Upgrade your underlying resources<\/strong> \u2013 move to a larger reseller plan, VPS or dedicated server.<\/li>\n<\/ol>\n<p>We often see resellers hold onto an undersized base server for too long, then suffer performance complaints that damage their brand. Watch for server-side signals like:<\/p>\n<ul>\n<li>CPU consistently above 70\u201380% during peak hours.<\/li>\n<li>IOwait or disk utilization frequently high.<\/li>\n<li>Many accounts hitting CPU\/EP limits despite reasonable site implementations.<\/li>\n<\/ul>\n<p>Our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/hosting-paketinizi-yukseltmeniz-gerektigini-gosteren-9-sunucu-tarafli-sinyal\/\">server-side signals that it\u2019s time to upgrade your hosting plan<\/a> can help you decide when to scale up, not just tune limits.<\/p>\n<h3><span id=\"Segmenting_Noisy_Clients_to_Higher_Plans\">Segmenting \u201cNoisy\u201d Clients to Higher Plans<\/span><\/h3>\n<p>Not every client is a good fit for entry-level reseller packages. Common \u201cnoisy neighbor\u201d profiles include:<\/p>\n<ul>\n<li>High-traffic WooCommerce stores with many plugins.<\/li>\n<li>Membership\/learning platforms with logged-in users all day.<\/li>\n<li>Custom PHP apps with inefficient queries or no caching.<\/li>\n<li>Clients with 10+ GB of email across many users who never delete messages.<\/li>\n<\/ul>\n<p>Your playbook should be:<\/p>\n<ol>\n<li>Identify them early from resource graphs and logs.<\/li>\n<li>Offer an honest performance review and optimization suggestions.<\/li>\n<li>Present an upgrade path (higher tier package, or migration to a VPS\/dedicated server) when appropriate.<\/li>\n<\/ol>\n<p>That way you protect your other reseller clients and increase revenue from those who truly need more power.<\/p>\n<h2><span id=\"Example_Package_Templates_You_Can_Adapt_on_dchostcom\">Example Package Templates You Can Adapt on dchost.com<\/span><\/h2>\n<p>Let\u2019s bring all of this together into concrete example packages. These numbers are illustrative; you will adapt them to your actual server and business model, but they\u2019re a solid baseline if you\u2019re starting from a typical 4 vCPU \/ 8\u201316 GB RAM \/ 200\u2013300 GB NVMe-backed environment.<\/p>\n<h3><span id=\"Starter_Package_Small_Single_Site\">Starter Package \u2013 Small Single Site<\/span><\/h3>\n<ul>\n<li><strong>Target client<\/strong>: brochure sites, low-traffic blogs, landing pages.<\/li>\n<li><strong>CPU<\/strong>: 25% of 1 core, EP 10.<\/li>\n<li><strong>RAM (soft guideline)<\/strong>: 512\u2013768 MB LVE limit (if exposed).<\/li>\n<li><strong>Disk quota<\/strong>: 5 GB.<\/li>\n<li><strong>Inodes<\/strong>: 100K.<\/li>\n<li><strong>Email<\/strong>:\n<ul>\n<li>Up to 5\u201310 mailboxes.<\/li>\n<li>500 MB default, 1 GB max per mailbox.<\/li>\n<li>100 emails\/hour sending limit.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>This package is intentionally tight. It keeps truly tiny sites fast and cheap while preventing Starter clients from quietly growing into full WooCommerce stores without paying more.<\/p>\n<h3><span id=\"Business_Package_Standard_WordPress_Site\">Business Package \u2013 Standard WordPress Site<\/span><\/h3>\n<ul>\n<li><strong>Target client<\/strong>: corporate WordPress, content marketing sites, more frequent updates.<\/li>\n<li><strong>CPU<\/strong>: 50% of 1 core, EP 15\u201320.<\/li>\n<li><strong>RAM<\/strong>: 1 GB LVE limit.<\/li>\n<li><strong>Disk quota<\/strong>: 10\u201315 GB.<\/li>\n<li><strong>Inodes<\/strong>: 200\u2013300K.<\/li>\n<li><strong>Email<\/strong>:\n<ul>\n<li>Up to 20\u201330 mailboxes.<\/li>\n<li>1 GB default, 2 GB max per mailbox.<\/li>\n<li>200\u2013300 emails\/hour sending limit.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>Most of your \u201cgood\u201d business clients will fit here. With appropriate caching and optimization (see our <a href=\"https:\/\/www.dchost.com\/blog\/en\/wordpress-icin-sunucu-tarafi-optimizasyon-php-fpm-opcache-redis-ve-mysql-ile-neyi-ne-zaman-nasil-ayarlamalisin\/\">server-side WordPress optimization guide<\/a>), this tier can handle comfortably busy sites.<\/p>\n<h3><span id=\"Commerce_Package_WooCommerce_and_Heavier_Apps\">Commerce Package \u2013 WooCommerce and Heavier Apps<\/span><\/h3>\n<ul>\n<li><strong>Target client<\/strong>: WooCommerce, booking systems, membership sites, heavier PHP apps.<\/li>\n<li><strong>CPU<\/strong>: 75\u2013100% of 1 core, EP 25\u201330.<\/li>\n<li><strong>RAM<\/strong>: 1.5\u20132 GB LVE limit.<\/li>\n<li><strong>Disk quota<\/strong>: 20\u201330 GB.<\/li>\n<li><strong>Inodes<\/strong>: 400\u2013600K.<\/li>\n<li><strong>Email<\/strong>:\n<ul>\n<li>Similar to Business, but steer bulk mail to dedicated services.<\/li>\n<li>300\u2013500 emails\/hour sending limit (strictly for transactional and day-to-day business mail).<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>Price this tier so that it can subsidize its heavier CPU and inode usage. Don\u2019t be afraid to recommend a move to a dedicated VPS if the store needs external caching layers, separate database servers or advanced queue workers; we cover those architectures in our materials on <a href=\"https:\/\/www.dchost.com\/blog\/en\/woocommerce-kapasite-planlama-rehberi-vcpu-ram-iops-nasil-hesaplanir\/\">WooCommerce capacity planning<\/a> and related scalability guides.<\/p>\n<h3><span id=\"Agency_Package_Many_Small_Sites_Under_One_cPanel\">Agency Package \u2013 Many Small Sites Under One cPanel<\/span><\/h3>\n<ul>\n<li><strong>Target client<\/strong>: agencies managing 5\u201320 small\/medium sites for their own customers.<\/li>\n<li><strong>CPU<\/strong>: 75% of 1 core, EP 25.<\/li>\n<li><strong>RAM<\/strong>: 1.5 GB LVE limit.<\/li>\n<li><strong>Disk quota<\/strong>: 30\u201340 GB.<\/li>\n<li><strong>Inodes<\/strong>: 400\u2013600K.<\/li>\n<li><strong>Email<\/strong>:\n<ul>\n<li>Depends on usage model; often fewer mailboxes as mail may be offloaded.<\/li>\n<li>Encourage using separate domains\/accounts when mail load grows.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>For agencies already reselling hosting, this can be very appealing: one cPanel login, many addon domains. Just be careful with inode and email growth; our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/paylasimli-ve-reseller-hostingde-coklu-web-sitesi-yonetimi\/\">managing multiple websites on shared and reseller hosting<\/a> explains the trade-offs between multiple addon domains vs separate cPanel accounts.<\/p>\n<h2><span id=\"Bringing_It_All_Together_A_Sustainable_cPanel_Reseller_Strategy\">Bringing It All Together: A Sustainable cPanel Reseller Strategy<\/span><\/h2>\n<p>Well-designed cPanel reseller packages are much more than a list of \u201c10 GB space \/ unlimited traffic\u201d. When you treat CPU, inodes, disk and email as first-class design elements, you can:<\/p>\n<ul>\n<li>Protect the stability and performance of your entire reseller stack.<\/li>\n<li>Give clients clear expectations about what each plan is for.<\/li>\n<li>Spot overgrown or misfit workloads early and move them to better-suited solutions.<\/li>\n<li>Grow profitably instead of constantly firefighting resource issues.<\/li>\n<\/ul>\n<p>At dchost.com we see agencies and freelancers succeed when they combine three things:<\/p>\n<ol>\n<li><strong>A simple, clear package lineup<\/strong> \u2013 Starter, Business, Commerce, Agency.<\/li>\n<li><strong>Thoughtful resource limits under the hood<\/strong> \u2013 CPU\/EP, inode and disk\/email limits matched to real use cases.<\/li>\n<li><strong>Ongoing monitoring and honest communication<\/strong> \u2013 reviewing usage, recommending optimizations, and offering upgrade paths when needed.<\/li>\n<\/ol>\n<p>If you\u2019re just starting with reseller hosting or you\u2019re redesigning your plans, pair this article with our broader <a href=\"https:\/\/www.dchost.com\/blog\/en\/reseller-hosting-yonetimi-rehberi-paketler-limitler-ve-izolasyon\/\">reseller hosting management guide on plans, limits and isolation<\/a> and our primer on <a href=\"https:\/\/www.dchost.com\/blog\/en\/reseller-hosting-nedir-ajanslar-ve-freelancerlar-icin-karli-hosting-is-modeli-kurma-rehberi\/\">what reseller hosting is and how agencies can turn it into a profitable business model<\/a>. Together, they\u2019ll give you both the business and technical angles you need.<\/p>\n<p>If you\u2019d like to design or tune a reseller stack on top of our infrastructure \u2013 whether on a classic reseller plan, a dedicated VPS or your own server in our data centers \u2013 our team can help you size CPU, disk and email limits for your specific client base. The sooner you align your packages with real resource usage, the quieter your support inbox will become and the easier it will be to scale your hosting business with confidence.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>If you run a cPanel reseller business, your real product is not just \u201cspace\u201d or \u201ctraffic\u201d \u2013 it\u2019s how intelligently you slice server resources between customers. Two clients with the same disk quota can create completely different loads on CPU, inodes and email. If you design your reseller packages only around GB and \u201cunlimited email [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":4071,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-4070","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-teknoloji"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/4070","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=4070"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/4070\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/4071"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=4070"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=4070"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=4070"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}