{"id":4929,"date":"2026-02-10T16:56:46","date_gmt":"2026-02-10T13:56:46","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/client-isolation-on-reseller-hosting-chroot-cagefs-and-separate-php-fpm-pools\/"},"modified":"2026-02-10T16:56:46","modified_gmt":"2026-02-10T13:56:46","slug":"client-isolation-on-reseller-hosting-chroot-cagefs-and-separate-php-fpm-pools","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/client-isolation-on-reseller-hosting-chroot-cagefs-and-separate-php-fpm-pools\/","title":{"rendered":"Client Isolation on Reseller Hosting: Chroot, CageFS and Separate PHP\u2011FPM Pools"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>On reseller hosting, one misconfigured client site can quietly become a security and performance problem for everyone on the server. A vulnerable plugin, a brute\u2011forced password or a single runaway script is often enough to consume CPU, fill disks or leak data between accounts if isolation is weak. That is why serious agencies and resellers treat <strong>client isolation<\/strong> as a core part of their hosting architecture, not an optional extra. In this article, we will walk through how isolation really works on modern Linux\u2011based reseller platforms using cPanel and DirectAdmin. We will look at Unix user separation, <strong>chroot jails<\/strong>, <strong>CloudLinux CageFS<\/strong> and <strong>separate PHP\u2011FPM pools<\/strong> per account or per site. The goal is simple: by the end, you should know which knobs to turn, what to ask your provider, and how we at dchost.com design reseller environments where one client cannot easily hurt another, even when something goes wrong.<\/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_Client_Isolation_Matters_So_Much_on_Reseller_Hosting\"><span class=\"toc_number toc_depth_1\">1<\/span> Why Client Isolation Matters So Much on Reseller Hosting<\/a><\/li><li><a href=\"#The_Building_Blocks_Unix_Users_chroot_CageFS_and_PHPFPM_Pools\"><span class=\"toc_number toc_depth_1\">2<\/span> The Building Blocks: Unix Users, chroot, CageFS and PHP\u2011FPM Pools<\/a><ul><li><a href=\"#Unix_users_and_peraccount_file_ownership\"><span class=\"toc_number toc_depth_2\">2.1<\/span> Unix users and per\u2011account file ownership<\/a><\/li><li><a href=\"#What_is_chroot\"><span class=\"toc_number toc_depth_2\">2.2<\/span> What is chroot?<\/a><\/li><li><a href=\"#What_is_CageFS\"><span class=\"toc_number toc_depth_2\">2.3<\/span> What is CageFS?<\/a><\/li><li><a href=\"#What_are_PHPFPM_pools\"><span class=\"toc_number toc_depth_2\">2.4<\/span> What are PHP\u2011FPM pools?<\/a><\/li><\/ul><\/li><li><a href=\"#chroot_and_CageFS_on_cPanel_and_DirectAdmin\"><span class=\"toc_number toc_depth_1\">3<\/span> chroot and CageFS on cPanel and DirectAdmin<\/a><ul><li><a href=\"#chroot_jailed_shells_on_cPanel\"><span class=\"toc_number toc_depth_2\">3.1<\/span> chroot \/ jailed shells on cPanel<\/a><\/li><li><a href=\"#Enabling_CageFS_on_cPanel\"><span class=\"toc_number toc_depth_2\">3.2<\/span> Enabling CageFS on cPanel<\/a><\/li><li><a href=\"#chrootstyle_isolation_on_DirectAdmin\"><span class=\"toc_number toc_depth_2\">3.3<\/span> chroot\u2011style isolation on DirectAdmin<\/a><\/li><li><a href=\"#What_CageFS_actually_prevents_in_practice\"><span class=\"toc_number toc_depth_2\">3.4<\/span> What CageFS actually prevents in practice<\/a><\/li><\/ul><\/li><li><a href=\"#Separate_PHPFPM_Pools_per_Account_or_Site\"><span class=\"toc_number toc_depth_1\">4<\/span> Separate PHP\u2011FPM Pools per Account or Site<\/a><ul><li><a href=\"#Why_shared_PHP_handlers_are_a_problem\"><span class=\"toc_number toc_depth_2\">4.1<\/span> Why shared PHP handlers are a problem<\/a><\/li><li><a href=\"#Peraccount_PHPFPM_on_cPanel\"><span class=\"toc_number toc_depth_2\">4.2<\/span> Per\u2011account PHP\u2011FPM on cPanel<\/a><\/li><li><a href=\"#Peruserperdomain_PHPFPM_on_DirectAdmin\"><span class=\"toc_number toc_depth_2\">4.3<\/span> Per\u2011user\/per\u2011domain PHP\u2011FPM on DirectAdmin<\/a><\/li><li><a href=\"#What_goes_into_a_safe_FPM_pool_configuration\"><span class=\"toc_number toc_depth_2\">4.4<\/span> What goes into a safe FPM pool configuration<\/a><\/li><li><a href=\"#Security_wins_from_separate_pools\"><span class=\"toc_number toc_depth_2\">4.5<\/span> Security wins from separate pools<\/a><\/li><\/ul><\/li><li><a href=\"#Designing_Reseller_Packages_Around_Isolation\"><span class=\"toc_number toc_depth_1\">5<\/span> Designing Reseller Packages Around Isolation<\/a><ul><li><a href=\"#Always_prefer_separate_accounts_over_addon_domains\"><span class=\"toc_number toc_depth_2\">5.1<\/span> Always prefer separate accounts over addon domains<\/a><\/li><li><a href=\"#Rightsizing_resource_limits_per_package\"><span class=\"toc_number toc_depth_2\">5.2<\/span> Right\u2011sizing resource limits per package<\/a><\/li><li><a href=\"#Positioning_isolation_as_a_feature_to_your_clients\"><span class=\"toc_number toc_depth_2\">5.3<\/span> Positioning isolation as a feature to your clients<\/a><\/li><li><a href=\"#When_to_move_heavy_clients_to_VPS_or_dedicated\"><span class=\"toc_number toc_depth_2\">5.4<\/span> When to move heavy clients to VPS or dedicated<\/a><\/li><\/ul><\/li><li><a href=\"#RealWorld_Scenarios_How_Isolation_Saves_You\"><span class=\"toc_number toc_depth_1\">6<\/span> Real\u2011World Scenarios: How Isolation Saves You<\/a><ul><li><a href=\"#Scenario_1_Vulnerable_plugin_on_a_lowbudget_client_site\"><span class=\"toc_number toc_depth_2\">6.1<\/span> Scenario 1: Vulnerable plugin on a low\u2011budget client site<\/a><\/li><li><a href=\"#Scenario_2_Runaway_cron_job_during_a_marketing_campaign\"><span class=\"toc_number toc_depth_2\">6.2<\/span> Scenario 2: Runaway cron job during a marketing campaign<\/a><\/li><li><a href=\"#Scenario_3_Compliancesensitive_client_sharing_infrastructure\"><span class=\"toc_number toc_depth_2\">6.3<\/span> Scenario 3: Compliance\u2011sensitive client sharing infrastructure<\/a><\/li><\/ul><\/li><li><a href=\"#How_We_Approach_Isolation_on_Reseller_Hosting_at_dchostcom\"><span class=\"toc_number toc_depth_1\">7<\/span> How We Approach Isolation on Reseller Hosting at dchost.com<\/a><\/li><li><a href=\"#Checklist_What_to_Configure_or_Ask_Your_Provider_Today\"><span class=\"toc_number toc_depth_1\">8<\/span> Checklist: What to Configure (or Ask Your Provider) Today<\/a><ul><li><a href=\"#Account_structure\"><span class=\"toc_number toc_depth_2\">8.1<\/span> Account structure<\/a><\/li><li><a href=\"#Filesystem_isolation\"><span class=\"toc_number toc_depth_2\">8.2<\/span> Filesystem isolation<\/a><\/li><li><a href=\"#PHPFPM_and_resources\"><span class=\"toc_number toc_depth_2\">8.3<\/span> PHP\u2011FPM and resources<\/a><\/li><li><a href=\"#Growth_path\"><span class=\"toc_number toc_depth_2\">8.4<\/span> Growth path<\/a><\/li><\/ul><\/li><li><a href=\"#Conclusion_Isolation_as_Your_Silent_Partner\"><span class=\"toc_number toc_depth_1\">9<\/span> Conclusion: Isolation as Your Silent Partner<\/a><\/li><\/ul><\/div>\n<h2><span id=\"Why_Client_Isolation_Matters_So_Much_on_Reseller_Hosting\">Why Client Isolation Matters So Much on Reseller Hosting<\/span><\/h2>\n<p>Reseller hosting is, by design, a multi\u2011tenant environment. One physical (or virtual) server hosts dozens or hundreds of separate cPanel\/DirectAdmin accounts, each belonging to a different client. Without strong isolation, the weakest link on that server defines the risk level for all others.<\/p>\n<p>Client isolation directly affects:<\/p>\n<ul>\n<li><strong>Security<\/strong>: Preventing a hacked site from reading or modifying another client\u2019s files or configuration.<\/li>\n<li><strong>Performance<\/strong>: Stopping one account\u2019s cron jobs, bots or bad code from exhausting CPU, RAM or I\/O for everyone else.<\/li>\n<li><strong>Privacy and compliance<\/strong>: Reducing the chance of cross\u2011tenant data exposure, which is especially important for GDPR\/KVKK or corporate clients.<\/li>\n<li><strong>Operational sanity<\/strong>: Making it easier to debug issues and attribute resource usage to the right customer.<\/li>\n<\/ul>\n<p>At dchost.com we see a clear pattern: resellers who understand and use isolation features like CageFS and separate PHP\u2011FPM pools spend far less time firefighting shared problems and far more time focusing on their own agency work. The rest of this article unpacks these features and explains how to put them to work on real reseller plans.<\/p>\n<h2><span id=\"The_Building_Blocks_Unix_Users_chroot_CageFS_and_PHPFPM_Pools\">The Building Blocks: Unix Users, chroot, CageFS and PHP\u2011FPM Pools<\/span><\/h2>\n<h3><span id=\"Unix_users_and_peraccount_file_ownership\">Unix users and per\u2011account file ownership<\/span><\/h3>\n<p>Every cPanel or DirectAdmin account maps to a distinct Unix user on the server. This is the first (and oldest) layer of isolation:<\/p>\n<ul>\n<li>Each account\u2019s files under <code>\/home\/username\/<\/code> are owned by that user.<\/li>\n<li>File permissions are set so that other users can\u2019t read or write them.<\/li>\n<li>Web server and PHP processes can be configured to run as that user instead of a shared user like <code>nobody<\/code>.<\/li>\n<\/ul>\n<p>On its own, this model is better than nothing, but traditional shared hosting often left gaps: processes running as a shared user, world\u2011readable directories or powerful binaries visible to everyone. That\u2019s where <strong>chroot<\/strong> and <strong>CageFS<\/strong> come in.<\/p>\n<h3><span id=\"What_is_chroot\">What is chroot?<\/span><\/h3>\n<p><strong>chroot<\/strong> (&#8220;change root&#8221;) is a classic Unix mechanism that lets you restrict a process to see only a subset of the filesystem as if it were the whole system. Think of it as putting a process in a directory and telling it, &#8220;this is now your <code>\/<\/code>&#8220;. From inside, other parts of the server simply do not exist.<\/p>\n<p>In the context of reseller hosting, chroot is used to:<\/p>\n<ul>\n<li>Limit SSH users to their own jail instead of the full server filesystem.<\/li>\n<li>Expose only a curated set of binaries and libraries.<\/li>\n<li>Reduce the impact of local privilege\u2011escalation or information\u2011disclosure bugs.<\/li>\n<\/ul>\n<p>Native chroot is powerful but can be clunky to manage at scale. CloudLinux\u2019s <strong>CageFS<\/strong> builds on the same idea but adds automation and safety for hosting environments.<\/p>\n<h3><span id=\"What_is_CageFS\">What is CageFS?<\/span><\/h3>\n<p><strong>CageFS<\/strong> is a virtualized per\u2011user filesystem available on CloudLinux\u2011based servers. It creates an isolated, &#8220;caged&#8221; view of the filesystem for each user while still letting the administrator manage the server centrally. From inside the cage, a user sees:<\/p>\n<ul>\n<li>Only their home directory and a limited, sanitized filesystem tree.<\/li>\n<li>No other users\u2019 home directories.<\/li>\n<li>Only approved binaries (e.g. <code>php<\/code>, <code>composer<\/code>, <code>git<\/code> if you allow them).<\/li>\n<\/ul>\n<p>CageFS also integrates with resource limits (LVE) and control panels, making it ideal for reseller hosting where you need a repeatable, policy\u2011driven way to isolate dozens or hundreds of accounts.<\/p>\n<h3><span id=\"What_are_PHPFPM_pools\">What are PHP\u2011FPM pools?<\/span><\/h3>\n<p><strong>PHP\u2011FPM<\/strong> (FastCGI Process Manager) runs PHP code through worker processes. A <strong>pool<\/strong> is simply a group of PHP workers with a shared configuration (user, memory limits, max children, etc.). When you use <strong>separate PHP\u2011FPM pools per account or per domain<\/strong>, you get:<\/p>\n<ul>\n<li>Security isolation \u2013 one site\u2019s PHP processes can\u2019t easily peek into another\u2019s environment.<\/li>\n<li>Stability \u2013 if one pool crashes or leaks memory, others keep running.<\/li>\n<li>Tuning flexibility \u2013 different pm settings, memory limits or even PHP versions per site.<\/li>\n<\/ul>\n<p>If you want to dig deeper into the performance side of this, we\u2019ve covered PHP\u2011FPM tuning in more detail in our article on <a href='https:\/\/www.dchost.com\/blog\/en\/wordpress-ve-woocommerce-icin-php-fpm-ayarlari-pm-pm-max_children-ve-pm-max_requests-hesaplama-rehberi\/'>PHP\u2011FPM settings for WordPress and WooCommerce<\/a>, and also in our story\u2011driven piece about <a href='https:\/\/www.dchost.com\/blog\/en\/ofiste-bir-sabah-php-yukseltmesi-ter-damlalari-ve-kucuk-bir-aydinlanma\/'>running multiple PHP versions and FPM pools on the same server<\/a>.<\/p>\n<h2><span id=\"chroot_and_CageFS_on_cPanel_and_DirectAdmin\">chroot and CageFS on cPanel and DirectAdmin<\/span><\/h2>\n<h3><span id=\"chroot_jailed_shells_on_cPanel\">chroot \/ jailed shells on cPanel<\/span><\/h3>\n<p>On cPanel\/WHM servers, SSH access can be configured as:<\/p>\n<ul>\n<li><strong>Disabled<\/strong> \u2013 safest for non\u2011technical end users.<\/li>\n<li><strong>Normal shell<\/strong> \u2013 full system view (not recommended for shared\/reseller use).<\/li>\n<li><strong>Jailed shell<\/strong> \u2013 a chroot\u2011style environment limited to a safe subset of the filesystem.<\/li>\n<\/ul>\n<p>For reseller hosting, you generally want <strong>jailed shell<\/strong> for technical clients that truly need SSH, and \u201cno shell\u201d for everyone else. The jailed shell chroots users into a restricted environment where they can manage files, run Git or Composer (if allowed), but cannot casually browse <code>\/home<\/code> or <code>\/etc<\/code>.<\/p>\n<h3><span id=\"Enabling_CageFS_on_cPanel\">Enabling CageFS on cPanel<\/span><\/h3>\n<p>On CloudLinux\u2011based cPanel servers, CageFS provides a much more complete isolation layer than chroot alone. At a high level, the process looks like this (on the server side):<\/p>\n<ul>\n<li>Install and enable CloudLinux with CageFS support.<\/li>\n<li>Configure which binaries and paths should be visible inside the cage.<\/li>\n<li>Enable CageFS globally and then per\u2011user or per\u2011reseller.<\/li>\n<li>Integrate CageFS with PHP handlers and SSH (jailed shell inside the cage).<\/li>\n<\/ul>\n<p>From a reseller perspective, the important question to ask your provider is straightforward: <strong>&#8220;Are my cPanel accounts running inside CageFS, and is SSH jailed?&#8221;<\/strong> On our infrastructure at dchost.com, we treat CageFS and jailed environments as standard security hygiene for shared and reseller hosting, not as an upscale feature.<\/p>\n<h3><span id=\"chrootstyle_isolation_on_DirectAdmin\">chroot\u2011style isolation on DirectAdmin<\/span><\/h3>\n<p>DirectAdmin has its own approach to jailing users. It supports:<\/p>\n<ul>\n<li><strong>Jailed SSH<\/strong> (chrooted environments) for accounts that need shell access.<\/li>\n<li>User\u2011level isolation via separate Unix users and hardened file permissions.<\/li>\n<li>Integration with CloudLinux CageFS where the OS supports it.<\/li>\n<\/ul>\n<p>For resellers on DirectAdmin, the pattern is similar: only grant jailed SSH to users who absolutely need it; for everyone else, file operations should go through SFTP\/FTP under their own user, with no ability to traverse other accounts.<\/p>\n<h3><span id=\"What_CageFS_actually_prevents_in_practice\">What CageFS actually prevents in practice<\/span><\/h3>\n<p>It helps to translate this into real\u2011world scenarios. With CageFS correctly enforced:<\/p>\n<ul>\n<li>A hacked WordPress plugin on <code>client1.com<\/code> cannot simply read <code>\/home\/client2\/config.php<\/code> because it is invisible inside the cage.<\/li>\n<li>A compromised SSH password grants the attacker only a minimal shell inside a sanitized filesystem, not full access to every tool and config on the server.<\/li>\n<li>Local information\u2011leakage bugs (e.g. reading <code>\/proc<\/code> or <code>\/etc\/passwd<\/code> for other users) are vastly harder to exploit.<\/li>\n<\/ul>\n<p>CageFS is not a silver bullet\u2014you still need firewalls, WAF and good application security\u2014but it significantly narrows the blast radius when something goes wrong.<\/p>\n<h2><span id=\"Separate_PHPFPM_Pools_per_Account_or_Site\">Separate PHP\u2011FPM Pools per Account or Site<\/span><\/h2>\n<h3><span id=\"Why_shared_PHP_handlers_are_a_problem\">Why shared PHP handlers are a problem<\/span><\/h3>\n<p>On older shared hosting setups, PHP ran via mod_php or a single shared PHP\u2011FPM pool under a generic user (e.g. <code>nobody<\/code>). That model has several drawbacks for resellers:<\/p>\n<ul>\n<li><strong>Security<\/strong>: All PHP scripts effectively run as the same identity, making it easier for one site to read others\u2019 files if permissions are loose.<\/li>\n<li><strong>Stability<\/strong>: A single memory leak or slow script can exhaust the entire pool, taking down all sites at once.<\/li>\n<li><strong>Lack of tuning per client<\/strong>: You can\u2019t give high\u2011value e\u2011commerce clients more PHP workers without also affecting small brochure sites.<\/li>\n<\/ul>\n<h3><span id=\"Peraccount_PHPFPM_on_cPanel\">Per\u2011account PHP\u2011FPM on cPanel<\/span><\/h3>\n<p>Modern cPanel servers typically use <strong>PHP\u2011FPM per domain<\/strong> or per account, often integrated with the MultiPHP system. That means:<\/p>\n<ul>\n<li>Each domain (or account) has its own FPM pool name, user and limits.<\/li>\n<li>Pools can run under the respective Unix user, aligning with file ownership.<\/li>\n<li>Different PHP versions can be assigned to different domains.<\/li>\n<\/ul>\n<p>As a reseller, what matters is that your clients are not all sharing one global FPM pool. When we design reseller servers at dchost.com, we make sure that each cPanel account\u2019s sites run in <strong>separate, per\u2011user PHP\u2011FPM pools<\/strong>, which are further confined by CageFS and LVE limits.<\/p>\n<h3><span id=\"Peruserperdomain_PHPFPM_on_DirectAdmin\">Per\u2011user\/per\u2011domain PHP\u2011FPM on DirectAdmin<\/span><\/h3>\n<p>DirectAdmin supports multiple PHP handlers including FPM. In modern setups, you can configure:<\/p>\n<ul>\n<li><strong>Per\u2011user pools<\/strong>: one pool per DirectAdmin user, hosting multiple domains.<\/li>\n<li><strong>Per\u2011domain pools<\/strong>: separate pools even between domains of the same user (useful for very busy sites).<\/li>\n<li>Different PHP versions per domain, similar to cPanel\u2019s MultiPHP.<\/li>\n<\/ul>\n<p>For typical reseller use, per\u2011user FPM pools already provide a big step up in isolation, but for high\u2011traffic projects it may be worth running the busiest store on its own dedicated pool even under the same user.<\/p>\n<h3><span id=\"What_goes_into_a_safe_FPM_pool_configuration\">What goes into a safe FPM pool configuration<\/span><\/h3>\n<p>From an isolation and stability standpoint, some key parameters to pay attention to (or ask your provider about) are:<\/p>\n<ul>\n<li><strong>pm<\/strong>: using <code>dynamic<\/code> or <code>ondemand<\/code> rather than <code>static<\/code> on shared environments.<\/li>\n<li><strong>pm.max_children<\/strong>: limits how many concurrent PHP processes a pool can spawn. This stops a single client from consuming all RAM.<\/li>\n<li><strong>pm.max_requests<\/strong>: recycling workers after a number of requests to avoid memory leaks accumulating forever.<\/li>\n<li><strong>memory_limit<\/strong> and <strong>max_execution_time<\/strong>: reasonable defaults, not &#8220;unlimited&#8221;.<\/li>\n<\/ul>\n<p>We go into this in more depth in our articles on <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\u2011side performance tuning for WordPress<\/a> and <a href='https:\/\/www.dchost.com\/blog\/en\/isolate-php-session-ve-queue-iscileri-icin-ayri-php-fpm-islem-havuzu-kurmak\/'>isolating PHP session and queue workers with separate FPM pools<\/a>, but the same ideas apply on reseller hosting: each client\u2019s pool gets sane, bounded resources.<\/p>\n<h3><span id=\"Security_wins_from_separate_pools\">Security wins from separate pools<\/span><\/h3>\n<p>Beyond stability, separate FPM pools are a security control in their own right:<\/p>\n<ul>\n<li>Environment variables (API keys, DB passwords) are not shared across pools.<\/li>\n<li>If you ever need to enable a slightly risky extension for one client, you can scope it to just their pool.<\/li>\n<li>Debugging tools (Xdebug, profiling) can be enabled only where needed, not globally.<\/li>\n<\/ul>\n<p>Combined with CageFS and correct file permissions, this makes it significantly harder for a compromised site to escalate laterally to others.<\/p>\n<h2><span id=\"Designing_Reseller_Packages_Around_Isolation\">Designing Reseller Packages Around Isolation<\/span><\/h2>\n<p>Technical isolation is only half the story. The way you design and sell your reseller plans determines how effectively those isolation features are used in practice.<\/p>\n<h3><span id=\"Always_prefer_separate_accounts_over_addon_domains\">Always prefer separate accounts over addon domains<\/span><\/h3>\n<p>One of the most common mistakes we see is agencies cramming multiple client sites into a single cPanel account as addon domains. It feels &#8220;simpler&#8221;, but it defeats much of the isolation we\u2019ve just discussed:<\/p>\n<ul>\n<li>All sites share one Unix user and one homedir.<\/li>\n<li>If an attacker gains access to one site, they can usually read or modify the others.<\/li>\n<li>PHP\u2011FPM pools, resource limits and email settings are shared.<\/li>\n<\/ul>\n<p>For client work, the rule of thumb is clear: <strong>one real client = one cPanel\/DirectAdmin account<\/strong>. We\u2019ve written a dedicated piece on this trade\u2011off in our article about <a href='https:\/\/www.dchost.com\/blog\/en\/ayri-cpanel-hesabi-mi-addon-domain-mi-guvenlik-e-posta-ve-seo-acisindan-dogru-secim\/'>separate cPanel accounts vs addon domains<\/a>; the security and email deliverability benefits alone make the separate\u2011account model worth it.<\/p>\n<h3><span id=\"Rightsizing_resource_limits_per_package\">Right\u2011sizing resource limits per package<\/span><\/h3>\n<p>Isolation works best when it\u2019s backed by appropriate limits: CPU, RAM, I\/O, inodes, processes and PHP workers. If you massively oversubscribe a server, even the best isolation tools will struggle.<\/p>\n<p>For reseller plans, we recommend designing tiers based on:<\/p>\n<ul>\n<li>Expected traffic (pageviews, concurrent users).<\/li>\n<li>Application type (simple site vs WooCommerce vs custom app).<\/li>\n<li>Storage usage (media\u2011heavy vs mostly text).<\/li>\n<\/ul>\n<p>If you want a deeper dive into numbers and strategies, we\u2019ve laid out concrete examples in our guide to <a href='https:\/\/www.dchost.com\/blog\/en\/cpanel-reseller-paketlerinde-limit-tasarimi-neden-bu-kadar-onemli\/'>designing cPanel reseller packages with sensible CPU, inode and disk limits<\/a>.<\/p>\n<h3><span id=\"Positioning_isolation_as_a_feature_to_your_clients\">Positioning isolation as a feature to your clients<\/span><\/h3>\n<p>Isolation is also a selling point. Instead of \u201cjust hosting\u201d, you can offer:<\/p>\n<ul>\n<li><strong>Per\u2011client sandboxes<\/strong> with separate logins, backups and PHP settings.<\/li>\n<li><strong>Reduced risk of cross\u2011infection<\/strong> when some clients are lax with updates.<\/li>\n<li><strong>Predictable performance<\/strong> because one customer\u2019s marketing campaign will not throttle everyone else.<\/li>\n<\/ul>\n<p>Our broader <a href='https:\/\/www.dchost.com\/blog\/en\/reseller-hosting-yonetimi-rehberi-paketler-limitler-ve-izolasyon\/'>reseller hosting management guide<\/a> goes into packaging, pricing and white\u2011label aspects, but the technical isolation described in this article is the foundation that makes those business promises credible.<\/p>\n<h3><span id=\"When_to_move_heavy_clients_to_VPS_or_dedicated\">When to move heavy clients to <a href=\"https:\/\/www.dchost.com\/vps\">VPS<\/a> or dedicated<\/span><\/h3>\n<p>Sometimes isolation on a shared reseller node is not enough\u2014for example, for very busy e\u2011commerce stores or custom applications with heavy background jobs. In those cases, it often makes sense to move the biggest workloads to a <strong>managed VPS or <a href=\"https:\/\/www.dchost.com\/dedicated-server\">dedicated server<\/a><\/strong> while keeping smaller clients on reseller hosting.<\/p>\n<p>We discuss this decision in more detail in our article on <a href='https:\/\/www.dchost.com\/blog\/en\/ajanslar-icin-reseller-hosting-mi-vps-mi-olceklenebilir-barindirma-stratejisi\/'>reseller hosting vs VPS for agencies<\/a>. The key point here is that the same isolation principles\u2014per\u2011user accounts, chroot\/CageFS, separate PHP\u2011FPM pools\u2014still apply; you simply get to dedicate more of the server to one client.<\/p>\n<h2><span id=\"RealWorld_Scenarios_How_Isolation_Saves_You\">Real\u2011World Scenarios: How Isolation Saves You<\/span><\/h2>\n<h3><span id=\"Scenario_1_Vulnerable_plugin_on_a_lowbudget_client_site\">Scenario 1: Vulnerable plugin on a low\u2011budget client site<\/span><\/h3>\n<p>Imagine a small client running an outdated CMS with a known file upload vulnerability. An attacker exploits it and uploads a PHP shell. With strong isolation in place:<\/p>\n<ul>\n<li>The shell can only see that account\u2019s CageFS jail and home directory.<\/li>\n<li>PHP runs under that user\u2019s FPM pool with strict <code>open_basedir<\/code> and resource limits.<\/li>\n<li>The attacker cannot list other <code>\/home\/<\/code> directories, access <code>wp-config.php<\/code> of other sites or dump system\u2011wide configs.<\/li>\n<\/ul>\n<p>You still need to clean the site, but the impact is contained to that one client. Other accounts remain safe, and you avoid a multi\u2011client incident.<\/p>\n<h3><span id=\"Scenario_2_Runaway_cron_job_during_a_marketing_campaign\">Scenario 2: Runaway cron job during a marketing campaign<\/span><\/h3>\n<p>A client\u2019s developer writes an inefficient cron script that loops over a big database table without proper indexing. During a peak campaign, the script runs too frequently and tries to spawn dozens of PHP processes.<\/p>\n<p>With separate PHP\u2011FPM pools and per\u2011account limits:<\/p>\n<ul>\n<li>The pool hits <code>pm.max_children<\/code> and resource limits for that client only.<\/li>\n<li>Other clients\u2019 pools remain healthy; their sites stay responsive.<\/li>\n<li>Server\u2011side monitoring quickly highlights which account is misbehaving.<\/li>\n<\/ul>\n<p>This turns a potential server\u2011wide outage into a single\u2011client performance issue that you can fix with the developer.<\/p>\n<h3><span id=\"Scenario_3_Compliancesensitive_client_sharing_infrastructure\">Scenario 3: Compliance\u2011sensitive client sharing infrastructure<\/span><\/h3>\n<p>Consider an agency hosting a mix of basic brochure sites and a more sensitive project (e.g. an internal portal, or a store that must follow stricter data\u2011handling rules). You might not be ready to move that project to its own dedicated environment yet, but you can harden isolation:<\/p>\n<ul>\n<li>Put the sensitive app in its <strong>own account<\/strong>, never as an addon domain.<\/li>\n<li>Verify that CageFS and jailed SSH are active for that account.<\/li>\n<li>Ensure its PHP\u2011FPM pool has constrained, auditable settings and uses separate logging.<\/li>\n<\/ul>\n<p>Combined with proper HTTPS and application\u2011level controls, this gives you a meaningful step towards the kind of <strong>data isolation<\/strong> we describe for SaaS and regulated workloads in our article on <a href='https:\/\/www.dchost.com\/blog\/en\/saas-uygulamalari-icin-musteri-verisi-ayristirma-ve-kvkk-gdpr-uyumlu-hosting-mimarisi\/'>GDPR\u2011compliant multi\u2011tenant hosting architectures<\/a>.<\/p>\n<h2><span id=\"How_We_Approach_Isolation_on_Reseller_Hosting_at_dchostcom\">How We Approach Isolation on Reseller Hosting at dchost.com<\/span><\/h2>\n<p>The theory is nice, but what does it look like in practice on our side?<\/p>\n<ul>\n<li><strong>Per\u2011account Unix users<\/strong> for every cPanel\/DirectAdmin account, never mixing unrelated clients under the same system user.<\/li>\n<li><strong>CageFS (where supported)<\/strong> enabled by default on our shared and reseller platforms, combined with jailed SSH for technical users.<\/li>\n<li><strong>Separate PHP\u2011FPM pools<\/strong> per account (and per domain where justified), running under the corresponding Unix user with tuned <code>pm<\/code>, <code>pm.max_children<\/code> and <code>pm.max_requests<\/code>.<\/li>\n<li><strong>Reasonable default resource limits<\/strong> (CPU, memory, I\/O, inodes, processes) aligned with each reseller tier, not &#8220;unlimited&#8221; marketing numbers.<\/li>\n<li><strong>Monitoring and alerting<\/strong> that tracks resource usage by account, so we can quickly identify when one client needs optimization, more resources or a step up to VPS\/dedicated.<\/li>\n<\/ul>\n<p>The result is a reseller environment where your clients are truly segmented from each other, and where your reputation is not tied to the least secure site on the server. As your portfolio grows, you can keep using the same mental model\u2014one account per client, per\u2011account isolation, clear resource limits\u2014and simply scale up to larger reseller tiers, VPS, dedicated servers or colocation within the same ecosystem.<\/p>\n<h2><span id=\"Checklist_What_to_Configure_or_Ask_Your_Provider_Today\">Checklist: What to Configure (or Ask Your Provider) Today<\/span><\/h2>\n<p>To wrap up, here is a practical checklist you can use on any cPanel\/DirectAdmin reseller environment, whether you are already with dchost.com or evaluating your current setup:<\/p>\n<h3><span id=\"Account_structure\">Account structure<\/span><\/h3>\n<ul>\n<li>Use <strong>one hosting account per real client<\/strong>; avoid piling multiple clients into one account via addon domains.<\/li>\n<li>Give each client their own panel login and keep credentials separate.<\/li>\n<\/ul>\n<h3><span id=\"Filesystem_isolation\">Filesystem isolation<\/span><\/h3>\n<ul>\n<li>Confirm that <strong>CageFS or an equivalent chroot\/jail<\/strong> is enabled for all accounts.<\/li>\n<li>Ensure SSH is either <strong>disabled<\/strong> or set to <strong>jailed shell<\/strong> for users who need it.<\/li>\n<li>Review file permissions to keep them at secure defaults (644\/755 typical), as described in our guide on <a href='https:\/\/www.dchost.com\/blog\/en\/linux-dosya-izinleri-644-755-777-paylasimli-hosting-ve-vps-icin-guvenli-ayarlar\/'>Linux file permissions for shared hosting<\/a>.<\/li>\n<\/ul>\n<h3><span id=\"PHPFPM_and_resources\">PHP\u2011FPM and resources<\/span><\/h3>\n<ul>\n<li>Verify that <strong>separate PHP\u2011FPM pools<\/strong> are in use per account or per domain (not a single global pool).<\/li>\n<li>Check that PHP pools run under the correct Unix user, not a shared generic user.<\/li>\n<li>Make sure each package has sane limits for <code>pm.max_children<\/code>, <code>memory_limit<\/code> and <code>max_execution_time<\/code> so no single pool can starve the server.<\/li>\n<\/ul>\n<h3><span id=\"Growth_path\">Growth path<\/span><\/h3>\n<ul>\n<li>Identify your heavier clients (e\u2011commerce, custom apps) and decide when they may need a move to a VPS or dedicated server for even stronger isolation.<\/li>\n<li>Keep your packaging flexible so you can upsell additional resources or a private server when metrics justify it.<\/li>\n<\/ul>\n<h2><span id=\"Conclusion_Isolation_as_Your_Silent_Partner\">Conclusion: Isolation as Your Silent Partner<\/span><\/h2>\n<p>Strong client isolation on reseller hosting is not about fancy buzzwords; it is about making sure that one weak site, one bad script or one hacked password does not become everyone\u2019s problem. By combining Unix user separation, chroot\/CageFS jails and <strong>separate PHP\u2011FPM pools<\/strong>, you can turn a shared server into a set of well\u2011defined sandboxes, each with its own resources and blast radius.<\/p>\n<p>At dchost.com, we design our reseller platforms with these principles baked in: per\u2011account users, jailed environments, tuned FPM pools and realistic resource limits, plus a clear growth path from reseller plans to VPS, dedicated and colocation when you need more power. If you are managing multiple client sites today, this is the moment to audit your existing structure: are you still using addon domains, shared handlers and unjailed shells, or are your clients properly segmented?<\/p>\n<p>If you\u2019d like to review your current setup or plan the next step\u2014whether that\u2019s re\u2011organising accounts, refining package limits or moving key projects to their own servers\u2014our team is ready to help you design an isolation strategy that matches your real workloads. With the right foundations in place, reseller hosting becomes a stable, predictable part of your business instead of a constant source of risk.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>On reseller hosting, one misconfigured client site can quietly become a security and performance problem for everyone on the server. A vulnerable plugin, a brute\u2011forced password or a single runaway script is often enough to consume CPU, fill disks or leak data between accounts if isolation is weak. That is why serious agencies and resellers [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":4930,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-4929","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\/4929","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=4929"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/4929\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/4930"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=4929"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=4929"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=4929"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}