{"id":20468,"date":"2026-08-09T08:33:19","date_gmt":"2026-08-09T06:33:19","guid":{"rendered":"https:\/\/webhosting.de\/per-site-cagefs-shared-hosting-sicherheit-architektur\/"},"modified":"2026-08-09T08:33:19","modified_gmt":"2026-08-09T06:33:19","slug":"per-site-cagefs-shared-hosting-security-architecture","status":"publish","type":"post","link":"https:\/\/webhosting.de\/en\/per-site-cagefs-shared-hosting-sicherheit-architektur\/","title":{"rendered":"Per-Site CageFS: New Security Architecture for Shared Hosting"},"content":{"rendered":"<p><strong>Per-Site CageFS<\/strong> It strictly isolates individual websites within a shared hosting account, thereby limiting the risk of lateral movement following a breach. I\u2019ll explain the new security architecture, demonstrate practical use cases, and show you how to securely manage multiple projects within a single account.<\/p>\n\n<h2>Key points<\/h2>\n\n<ul>\n  <li><strong>Website Isolation<\/strong>: Additional segregation within an account reduces collateral risks.<\/li>\n  <li><strong>CloudLinux<\/strong>: Extension of the CageFS concept to the domain level.<\/li>\n  <li><strong>WordPress<\/strong>: Run multiple instances side by side securely.<\/li>\n  <li><strong>Resources<\/strong>: CPU, RAM, and I\/O limits complement the file view separation.<\/li>\n  <li><strong>Practice<\/strong>: Activation per domain and a clear rights\/path strategy.<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/sicherheitsserverraum-8432.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>What \u201ePer-Site CageFS\u201c Actually Does<\/h2>\n\n<p>The extension isolates individual <strong>Domains<\/strong> within an existing user CageFS, so that each website can only see its own files and processes. This prevents a compromised project from accessing configuration files, uploads, or keys belonging to other sites in the same account. According to <strong>CloudLinux<\/strong> Blog (Beta Announcement): Per-Site CageFS enhances isolation between websites within the same user account, thereby reducing the risk of cross-site propagation. For me, the benefit is obvious: I can neatly segment agency accounts, multisite setups, and test environments without disrupting the hosting structure. This background article provides a quick overview of how CageFS works: <a href=\"https:\/\/webhosting.de\/en\/cloudlinux-cagefs-file-system-isolation-security-hostingshield\/\">CageFS File System<\/a>, on which per-site isolation is based.<\/p>\n\n<h2>Why Account Isolation Alone Isn't Enough<\/h2>\n\n<p>A single account often combines several <strong>Projects<\/strong> \u2013 about two shops, three blogs, and a staging environment. If an exploit targets a vulnerable plugin, an attacker can, without additional segmentation, access neighboring directories and place additional payloads there. This is exactly where Per-Site CageFS isolates the view of the file system and processes so that each website operates as if in its own <strong>Jail<\/strong> works. Especially with separate WordPress instances sharing the same PHP user, this otherwise creates a risk of escalations, which I eliminate through domain isolation. This minimizes collateral damage, simplifies forensic analysis, and makes it easier to plan recoveries more quickly.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/sicherheitskonferenz_8765.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>How Website Isolation Works Technically<\/h2>\n\n<p>CloudLinux uses CageFS to create a virtual, per-user <strong>file system<\/strong>; the per-site layer extends this to domain boundaries. Each activated domain receives a separate scope within the user\u2019s CageFS, including restricted paths, its own temp directories, and isolated script execution. As a result, external wp-config.php files, upload folders, or key files disappear from the view of the compromised website. Cron jobs, PHP, and, if applicable, SSH commands access the same system libraries but can only see the assigned <strong>Subsets<\/strong> of the file system. According to the documentation, this separation can be enabled or disabled on a per-domain basis, which gives me fine-grained control over live, staging, and test instances.<\/p>\n\n<h2>Comparison: Account Isolation, Per-Site CageFS, and Containers<\/h2>\n\n<p>To make a well-thought-out decision, I compare three common <strong>Models<\/strong> based on isolation depth, effort, and compatibility. Account isolation separates clients, but leaves internal site boundaries open. Per-site CageFS closes this gap at the file system and process levels. Containers create hard boundaries but often require more maintenance and customization. This provides a thorough classification of process isolation: <a href=\"https:\/\/webhosting.de\/en\/process-isolation-hosting-chroot-cagefs-container-jails-security-comparison\/\">Comparison of Chroot, CageFS, and Jails<\/a>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Approach<\/th>\n      <th>Separation of Accounts<\/th>\n      <th>Separation of Websites Within an Account<\/th>\n      <th>Compatibility (PHP\/CGI\/SSH\/Cron)<\/th>\n      <th>Operating expenses<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Account Isolation (Classic)<\/td>\n      <td><strong>High<\/strong><\/td>\n      <td>Low<\/td>\n      <td>Very good<\/td>\n      <td>Low<\/td>\n    <\/tr>\n    <tr>\n      <td>Per-Site CageFS<\/td>\n      <td><strong>High<\/strong><\/td>\n      <td>Medium to high<\/td>\n      <td>Very good<\/td>\n      <td>Low to medium<\/td>\n    <\/tr>\n    <tr>\n      <td>Containers per Site<\/td>\n      <td><strong>Very high<\/strong><\/td>\n      <td>Very high<\/td>\n      <td>Good to very good<\/td>\n      <td>Medium to high<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>In shared hosting environments, Per-Site CageFS offers a powerful combination of fine-grained <strong>Separation<\/strong> and minimal changes, since scripts generally run without modification. This allows me to address the most common vulnerability: multiple independent websites under a single user account.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/sicherheitsarchitektur-cagefs-blog-4719.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Practical Guide: Running Multiple WordPress Instances Securely<\/h2>\n\n<p>I isolate each WordPress instance with <strong>Domain Isolation<\/strong> and set up separate PHP-FPM pools for each site so that logs, opcache, and limits remain clearly assignable. I also define separate SALTs\/KEYS for each site in wp-config.php and prevent any cross-site access through file permissions and open_basedir equivalents. I strictly store uploads within the respective document root and prohibit global shared upload directories. During deployments, I keep temporary paths site-internal and immediately clean up build artifacts so that no unnecessary attack surfaces remain. For Composer or NPM caches, I use site-local <strong>Directories<\/strong>, to prevent any cross-effects from occurring.<\/p>\n\n<h2>Performance and Resource Management in Synergy<\/h2>\n\n<p>Per-site CageFS addresses the file view; the <strong>Performance<\/strong> I set limits for CPU, RAM, I\/O, and processes at the account or pool level. This prevents a site from generating too much load due to faulty plugins and slowing down the entire account. In many setups, this is implemented through LVE or similar quotas, which I fine-tune per pool or account. I combine this with request throttling in the web server or WAF to ensure that traffic spikes are handled in an orderly manner. This combination of isolation and quotas enhances service reliability and predictability. <strong>Load distribution<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/techoffice_cagefs_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Protection Chain: What Per-Site CageFS Does Not Replace<\/h2>\n\n<p>The insulation blocks side views, but I keep updates, <strong>Hardening<\/strong> We continue to strictly enforce PHP and strong passwords. MFA for admin logins, minimal file permissions, and upload filters also remain mandatory. A WAF, rate limits, and continuous logging cover additional attack vectors that file-level isolation alone cannot control. I also regularly check cron jobs and integration tokens, which attackers often overlook. This guide to the interplay between client isolation and hardening provides more information on <a href=\"https:\/\/webhosting.de\/en\/shared-hosting-security-tenant-isolation-serverguard\/\">Shared Hosting Security<\/a>, which underscores this line of thinking.<\/p>\n\n<h2>Setup and Common Pitfalls<\/h2>\n\n<p>I enable domain isolation on a per- <strong>website<\/strong> and then test SSH, cron, and PHP access under real-world conditions. Absolute paths in deployment scripts or plugins can cause problems, so I rely on relative paths or variables. I avoid symlinks between projects because they undermine the principle of separation; I prefer to pull the necessary libraries into the repo for each site. For backups, I define separate archives and save logs per domain to keep restoration and forensics clean. For permissions, 640 for files and 750 for folders have proven effective, plus <strong>Owner<\/strong> corresponding to the respective PHP pool.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/sicherheit_shared_hosting_3647.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Cost-Benefit Analysis for Agencies and Freelancers<\/h2>\n\n<p>I weigh the security benefits against the administrative time and potential downtime costs that a cross-incident would cause, and conclude that <strong>Euro<\/strong>-basis. Even just a few hours of incident response often cost significantly more than a small monthly surcharge for better isolation. For agency accounts with multiple client projects, segmentation noticeably reduces liability and reputational risk. Backup and restore processes also run more smoothly because I can restore individual sites with precision. Overall, per-site CageFS pays off in terms of greater reliability <strong>Operational management<\/strong> with predictable processes.<\/p>\n\n<h2>Checklist: When Per-Site CageFS Becomes Mandatory<\/h2>\n\n<p>I'll enable domain isolation as soon as there are multiple <strong>Installations<\/strong> run under a single account but have different update cycles. Also important: separate project teams or external admin accounts, which increase the risk of unintended interventions. High upload volumes, file converters, or image processing further justify this separation, as these areas often serve as entry points for security breaches. Different compliance requirements (e.g., clients, markets, data protection) also call for finer segmentation. Those who operate staging, testing, and production environments in parallel benefit from clearly separated error domains and a clear <strong>Forensics<\/strong>.<\/p>\n\n<h2>Requirements and Compatibility in Practice<\/h2>\n\n<p>Before I deploy Per-Site CageFS in a production environment, I check the runtime environment: the PHP handler in use (such as PHP-FPM or lsapi), the active web server, available control panel integration, and how cron jobs and SSH sessions are managed. In typical shared environments, applications continue to run without any code changes. I ensure that each domain has its own document root, that the paths are unique (e.g., \/home\/user\/sites\/project-a\/public), and that a dedicated PHP-FPM pool is assigned to each site. For cron jobs, I use separate crontabs for each domain or\u2014where the control panel bundles them\u2014clear prefixes and log paths so that jobs remain within their <strong>Jails<\/strong> work.<\/p>\n\n<h2>Clearly Separate Databases, Caches, and Sessions<\/h2>\n\n<p>The file view is just one part of it. I extend this separation all the way to the database and the caches. For each website, I create a separate database and a separate database user with minimal privileges. For object or page caches (e.g., Redis, Memcached), I use separate instances for each site, or at least key prefixes and dedicated databases\/namespaces. PHP sessions are stored in site-specific paths; I set the `session.save_path` separately for each FPM pool. If I use a central queue or a search backend, I separate indexes and topics by site. This \u201eseparation down to the last mile\u201c principle prevents incidents from spreading to other systems.<\/p>\n\n<h2>CI\/CD and Deployments in Isolation<\/h2>\n\n<p>In build pipelines, I make isolation the standard: Each site has its own deploy job that accesses only the site directory. I extract artifacts within the domain root, then perform owner\/group fixes, and invalidate only the affected caches. WP-CLI commands run within their respective CageFS contexts, ensuring they do not affect other projects. I keep environment variables separate for each site, and secrets remain in the site\u2019s own configuration files or in the panel\u2019s secret store. For zero downtime, I use atomic symlink switches within the domain boundaries (e.g., current\/releases), but I make sure that symlinks do not point to neighboring projects. Post-deployment checks (health checks, 404\/500 scans, permission checks) are mandatory for every site.<\/p>\n\n<h2>Monitoring, Logging, and Forensics<\/h2>\n\n<p>I consistently separate logs: access and error logs by domain, separate PHP and cron logs\u2014including rotation and retention policies. This way, in the event of an incident, I can reconstruct the timeline for a single site without having to comb through the entire account. In addition, I rely on file integrity checks (checksums of core directories), distributed audit logs for admin actions, and simple canary files that detect tampering early on. Threshold values are often sufficient for alerts: sudden spikes in 500 errors, unusual upload sizes, rapidly increasing inode usage, or excessive PHP worker launches. I link these signals to clear runbooks: lock down the site, check backups, secure artifacts, and restart within an isolated scope.<\/p>\n\n<h2>WordPress Special Cases: Multisite, MU Plugins, and Upload Workflows<\/h2>\n\n<p>With WordPress Multisite, I weigh the pros and cons: A Multisite installation benefits less from per-site CageFS, since multiple sites intentionally share a codebase and structure. If I need stricter boundaries (independent teams, separate caches, clear forensics), I prefer to set up individual instances and isolate them. I distribute MU plugins, drop-ins, or global must-use libraries only within a single site and avoid shared folders. Media workflows (CDN, image optimization, converters) run within the domain jail; I prevent uploads from one site to directories on another. If a team wants to share asset pipelines, I replicate them per site or encapsulate them as a package that is integrated into the respective repository.<\/p>\n\n<h2>Migration Path: From a Monolithic Architecture to a Segmented Account<\/h2>\n\n<p>Many accounts start out with a large public_html directory and grow over time. I follow a five-step process: 1) Take inventory: Which sites, domains, cron jobs, databases, and secrets? 2) Define the directory structure: A separate root, temp, logs, and backups directory for each site. 3) Define PHP-FPM pools per domain and set limits. 4) Move files, adjust permissions, and clean up absolute paths and includes. 5) Enable CageFS per site, run load tests, and set up monitoring. Meanwhile, I have a rollback strategy in place (snapshots, separate backups). After the cutover, I verify that tools such as WP-CLI, Composer, image processing tasks, and cron jobs are running within the correct scope and adjust path variables as needed.<\/p>\n\n<h2>Error patterns and troubleshooting<\/h2>\n\n<ul>\n  <li>403\/404 after activation: Most often, rewrite rules or includes point to paths outside the domain root. I correct the paths to relative versions or use variables.<\/li>\n  <li>Composer\/NPM fails: Global caches are not visible. I set up site-local cache directories and adjust the HOME and TMP variables during deployment.<\/li>\n  <li>WP-CLI cannot find wp-config.php: It is not being run from the domain root. I set the working directory correctly or specify the path explicitly.<\/li>\n  <li>Cron jobs are silent: Cron users or paths are not configured on a per-domain basis. I check environment variables, binary paths, and log destinations within the site jail.<\/li>\n  <li>Uploads fail: `session.save_path` or `tmp_dir` points to the wrong directory. I assign site-specific temporary paths to each FPM pool.<\/li>\n  <li>Shared library is missing: The symlink to the neighboring project is blocked. I replicate the library to each site or include it as a package in the deployment.<\/li>\n<\/ul>\n\n<h2>Governance and Access Model<\/h2>\n\n<p>Even if everything is technically separated, the issue of access remains. I assign dedicated SSH\/SFTP access for each site or restrict control panel access to the respective domain. Developer and agency teams receive only the keys and permissions they truly need. For emergencies, I have a \u201cbreak-glass\u201d process in place (temporarily expanded permissions, full logging, and subsequent revocation). In audits, I document the following for each site: paths, pools, limits, responsible parties, RBAC assignments, and backups. This ensures that the segmentation remains robust not only technically but also organizationally.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/hosting-sicherheitskonzept-4812.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Briefly summarized<\/h2>\n\n<p>Per-Site CageFS supplements the existing user separation with a <strong>website<\/strong>-level, thereby effectively reducing the risk of lateral movement. I consider this a practical step because many accounts combine multiple independent projects. The combination of file-view separation and resource limits brings order to performance, security, and operations. Those who host multiple WordPress or e-commerce instances will save time on troubleshooting, backups, and recovery after incidents. With clear permissions, updates, MFA, and logging, a robust <strong>Safety Chain<\/strong>, which makes shared hosting significantly more resilient.<\/p>","protected":false},"excerpt":{"rendered":"<p>Per-Site CageFS enhances security in shared hosting with CloudLinux Isolates and clear website isolation within an account.<\/p>","protected":false},"author":1,"featured_media":20461,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[794],"tags":[],"class_list":["post-20468","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-sicherheit-computer_und_internet"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"114","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"Per-Site CageFS","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"20461","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/20468","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/comments?post=20468"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/20468\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media\/20461"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media?parent=20468"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/categories?post=20468"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/tags?post=20468"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}