Private-Hosting di Cipriano oscar and the account record behind protected hosting

Summary

• Private-Hosting di Cipriano oscar is best read as a small protected-hosting and network-services operator whose public surface combines VPS, dedicated servers, shared hosting, remote DDoS protection, BGP sessions, and AS211138.
• The decisive operating record is not the advertised mitigation capacity. It is the accepted customer account state: plan, IP allocation, route announcement, filter scope, backup status, billing status, support ownership, and recovery evidence.
• Public registry evidence supports the existence of AS211138 and a small visible routing footprint, while public product pages describe Frankfurt hosting, control-panel functions, snapshots, DDoS filtering, and support promises.
• Customer outcome evidence is thinner than the marketing language. The prudent buyer should test provisioning, mitigation handoff, restore behavior, route correctness, billing change handling, and escalation paths before treating the service as a continuity dependency.

Private-Hosting di Cipriano oscar sits in the part of the hosting market where the label "DDoS protected" can either mean a real operating discipline or a convenient headline. The difference matters because the customer buying this kind of service is rarely buying a generic server in isolation. It may be a developer with a game community that attracts cheap attacks, a small software team that needs a European VPS with root access, a web operator that wants shared hosting without managing packets, or a network-minded customer that wants to announce prefixes through a protected edge.

In each case, the product is only useful if the provider can keep the accepted account record intact when the customer changes something.

That account record is the core of the evaluation. It is the state the customer has actually accepted: what plan was ordered, what machine was provisioned, what IP address or prefix was attached, what mitigation policy applies, which billing cycle is active, which backup or snapshot exists, which support ticket owns the current issue, and which routing fact is visible outside the panel. A provider can describe multi-terabit filtering and low-latency Frankfurt hosting, but the value is realized only when this record survives repeated operational changes.

A new VPS order must result in the right instance, with the right credentials, in the right region. A BGP customer must see the intended prefix announced, not a stale or partial route. A remote DDoS customer must know where clean traffic enters, how the tunnel is configured, and who owns the handoff when the origin server is elsewhere. A backup promise must turn into a restore path that works under stress rather than a checkbox on a sales page.

The public surface for Private-Hosting is more concrete than many small hosting providers, but still uneven. The operator website presents VPS plans in Frankfurt with KVM virtualization, NVMe storage, IPv4 and IPv6, full root access, manual snapshots, RDNS control, open SMTP with a fair-use limit, instant-style provisioning claims, and a 99.9 percent uptime service level. Dedicated-server pages describe bare-metal machines in Frankfurt with monthly billing, root or administrator access, RAID options, 1 Gbit/s unmetered ports, 10 Gbit/s available on request, and support for Linux and Windows Server images.

Shared-hosting pages describe Plesk, managed SSL, daily backups, email accounts, MySQL, PHP version switching, Git deployment, SSH, and Layer 3, Layer 4, and Layer 7 protection. The network page presents BGP sessions, GRE and VXLAN delivery, BYOIP with authorization, public route monitoring, and AS211138. These are not vague categories. They form a checklist of account-state obligations.

The independent routing record gives the company a firmer identity boundary. RIPE data identifies AS211138 as PRIVATEHOSTING-NET Private-Hosting di Cipriano oscar, with assigned status and a creation date in June 2021. RIPE visibility data on July 12, 2026 showed the ASN announced, with two visible IPv4 /24 prefixes in the announced-prefixes result and routing-status visibility across most IPv4 RIS peers. PeeringDB lists Private-Hosting di Cipriano oscar, website private-hosting.eu, looking glass lg-de.private-hosting.eu, Europe scope, network-services profile, and a small traffic range.

Ipregistry also identifies the ASN as a hosting network for private-hosting.eu and reports two IPv4 ranges. This does not prove the provider's attack-mitigation capacity, support quality, or customer satisfaction. It does show that the public hosting brand is connected to a real AS-level operating surface rather than just a reseller landing page with no network identity.

That distinction is important, but it should not be overstated. Running an AS and publishing a BGP product page are signs of technical control, not proof of resilience. A small operator may be closer to the machines and more responsive than a mass-market platform, or it may have fewer layers of redundancy and fewer people available during simultaneous incidents. The public record does not disclose staffing depth, incident history, customer concentration, node inventory, DDoS scrubbing suppliers, upstream contracts, detailed restore success rates, or the exact division between owned infrastructure and supplier capacity.

The correct conclusion is not that Private-Hosting is weak or strong. It is that the buyer should evaluate it by the operational record the account creates, because that is where any small-hosting advantage or limitation will become visible.

The first test is provisioning truth. Private-Hosting advertises rapid VPS deployment and presents dedicated servers as in-stock or custom hardware, with dedicated access details arriving after provisioning. A buyer should ask what "provisioned" means in this environment. For a VPS, the record should include the selected plan, vCPU count, memory, storage, operating system, IP assignments, root credentials, reverse DNS ownership, firewall state, snapshot availability, billing cycle, and cancellation or refund terms.

For a dedicated server, it should include the actual CPU model, RAM, storage layout, RAID level, uplink, OS image, remote-access method, and any managed-service add-on. If a server is ordered for a production workload, the first risk is not a spectacular attack. It is a small mismatch between what was ordered and what was delivered.

Provisioning mismatch is expensive because it creates hidden labor. A developer who discovers that an IPv6 assignment is absent, that RDNS is not available where expected, that a custom ISO limit prevents an installation, or that a billing discount changed the actual plan spends time reconciling the account rather than shipping software. A platform team that ordered a dedicated server for database isolation needs to confirm that the RAID setting and storage model match the architecture. A small business that chose shared hosting for Plesk and email needs the mailbox, SSL, DNS, backup, and database records to align.

Every correction requires support attention, and every support exchange becomes part of the cost of the service. In small infrastructure markets, low monthly prices can be consumed quickly by human coordination when the record is unclear.

The second test is mitigation handoff. Private-Hosting's site describes always-on mitigation for VPS and dedicated products, shared-hosting filtering, and remote DDoS protection for origins that stay outside its facility. It uses language around Layer 3, Layer 4, and in some contexts Layer 7 filtering, with claims of traffic being scrubbed at the edge before reaching the server. A buyer should treat that as a design claim, then ask where the handoff happens in the actual account. On an integrated VPS, the protected IP should be the service IP and the customer should know which panel or ticket path controls filtering exceptions.

On a dedicated server, the customer should know whether mitigation is inline for the server's assigned addresses and how custom rules are requested. On a remote protection service, the customer should know which public IP is exposed, which tunnel protocol is used, which origin address is hidden, which ports are forwarded, and how legitimate traffic is distinguished from attack traffic.

This is where the account record becomes more valuable than the capacity claim. A statement such as "3.2 Tbps" may describe contracted or available filtering capacity, but a customer outage is usually decided by a narrower question: did the right traffic reach the right server while the wrong traffic was dropped? A Minecraft server, for example, can be protected at the network layer while still suffering if the tunnel adds unexpected latency, if the origin leaks in DNS, if game-specific ports are misconfigured, or if application-layer behavior is treated as normal traffic.

A web application can sit behind DDoS filtering and still fail because PHP workers, database limits, cache settings, or account-level resource caps become the constraint. Protected hosting reduces one class of risk; it does not remove the need to manage the service being protected.

The third test is routing ownership. Private-Hosting's BGP page is unusually specific for a small provider. It describes native eBGP sessions with AS211138, GRE and VXLAN tunnels, BYOIP support with LOA authorization, IPv4 and IPv6 dual-stack support, looking-glass monitoring, and 95th percentile bandwidth billing for larger transit use. Public RIPE records list imports and exports involving multiple ASNs, while PeeringDB frames the network as Europe-scoped with a small traffic range. That gives buyers a way to interrogate the service. If the customer brings a prefix, who validates the authorization?

If a prefix is announced through a tunnel, where is the route originated and how is it monitored? If mitigation is attached to a BGP service, what happens when the customer changes upstream policy, route objects, or RPKI state?

The failure modes are mundane and serious. A prefix can be accepted in a ticket but not visible globally. A route can be visible through one upstream and poorly propagated through another. A customer can believe an address is protected while a stale origin path remains reachable. A DNS change can expose an origin server that was meant to stay hidden. A tunnel can come up while MTU, keepalive, or firewall rules silently degrade application traffic. A small provider can solve these problems quickly if the network team owns the record and sees the same state the customer sees.

It can also lose time if sales, billing, routing, and support records are split across tools. The public pages promise public route monitoring and direct engineer support. The buyer's job is to test whether those promises map to an account trail that can be followed during a change window.

Backup and recovery are a sharper test because they resist marketing. Private-Hosting's VPS page describes manual snapshots that can be created from the panel and restored with one click, while noting that scheduled automatic backups are a roadmap item for that VPS context. The shared-hosting page describes daily backups, and the about page lists automatic backups among what is included across the service story. Those statements are not identical, and the difference matters. A snapshot is not a backup policy unless it is created, retained, isolated, and restored in a way that matches the customer's recovery objective.

A shared-hosting daily backup is useful for a small site but may not cover mail, databases, DNS, or application state in the way a customer assumes. A dedicated-server customer using its own storage layout may have to design backup separately.

For a buyer, the backup record should be boringly explicit. Which service has manual snapshots only? Which service has daily provider backups? How many restore points are retained? Are backups held outside the failed host or merely on adjacent storage? Can the customer restore individual files, a full VPS, a Plesk account, or only the entire service? What is the support path if the panel restore fails? What happens after non-payment, cancellation, suspension, or abuse investigation? Does the provider promise any recovery point objective or recovery time objective, or only best-effort help?

The public pages give enough detail to ask those questions, but not enough to treat recovery as proven. In protected hosting, this gap is common. DDoS receives the headline while restore evidence decides whether the customer survives an ordinary administrative mistake.

Billing and suspension are also part of continuity. The operating risk is not just a failed server; it is account suspension, billing dispute, or support delay at the wrong moment. Private-Hosting's public pages emphasize monthly billing, annual discounts in some VPS contexts, VAT-included prices, refund periods, and no long-term contract for dedicated servers. Those commercial features are attractive to small operators because they reduce commitment.

They also create state changes: monthly renewal, annual prepayment, coupon application, plan upgrade, cancellation, refund window, payment method failure, invoice dispute, and service termination. The technical record must remain aligned with the commercial record. A server that is routed correctly but suspended because an invoice state is wrong is still down.

The practical deployment conditions are therefore narrower than the sales surface suggests. A customer should be able to define which part of its service is actually protected by Private-Hosting and which part remains elsewhere. A VPS hosted on Private-Hosting's own platform is a single-provider dependency for compute, network edge, account panel, and billing. A remote tunnel service is different: Private-Hosting may be responsible for the protected address and tunnel endpoint, while the customer's origin provider remains responsible for compute, storage, and local firewall behavior.

A BYOIP BGP session is different again: the customer owns or controls the address space, the registry authorization must be valid, and Private-Hosting becomes a route origin or transit path. These models should not be mixed casually. Each one changes who must act when the account is attacked, moved, cancelled, or restored.

The supervision cost also changes by customer type. A technically mature buyer can keep a runbook with route objects, DNS records, tunnel configuration, panel screenshots, invoice numbers, backup times, and support contacts. That buyer may extract real value from a provider that is flexible and engineer-facing. A less technical buyer may see the same flexibility as ambiguity. If a shared-hosting customer assumes "daily backups" means all data can be rolled back instantly, or a game-server customer assumes "protected IP" means no application tuning is needed, the gap will appear during the first incident.

The provider can reduce this cost by making account state visible and specific. The customer can reduce it by testing the service before it becomes essential.

Identity and access controls are another quiet dependency. The public pages emphasize panels, Plesk, WHMCS-style ordering links, Discord contact, and support channels. A protected-hosting account is only as reliable as its access model. Who can open a ticket? Who can cancel a service? Who can reinstall an operating system? Who can change RDNS, upload an ISO, restore a snapshot, or approve a BGP announcement? For a solo developer, those questions may be simple. For a small company, they become governance.

A provider that offers powerful self-service without clear account roles can unintentionally turn a convenience feature into an outage trigger. A customer should decide whether Private-Hosting is being used as a personal operator account, a team infrastructure account, or a managed supplier relationship, and should configure access accordingly.

Monitoring is the bridge between account state and real continuity. Private-Hosting refers to graphing, route monitoring, status surfaces, uptime service levels, and public looking-glass visibility. These are useful signals, but they are not all the same kind of evidence. A looking glass can show whether a route appears from the provider's view. RIPE visibility can show whether an origin is broadly visible from route collectors. A status page can communicate known incidents if it is actively maintained. Customer monitoring should still sit outside the provider.

The buyer needs its own checks for HTTP availability, game-port reachability, mail flow, latency, packet loss, DNS correctness, tunnel health, and backup age. Otherwise, the customer only knows what the provider's account surface reports.

This is especially important for DDoS mitigation because partial failure can look like success. The provider may correctly drop attack traffic while the customer's application remains overloaded by legitimate flash traffic. The route may stay up while one geographic path becomes poor. The protected IP may remain reachable while the tunnel to the origin experiences loss. The server may stay online while a database, mail queue, or storage volume becomes the bottleneck. A headline availability number does not capture these states.

The account record should therefore include not just whether the service is "up," but what was observed: route visible, protected endpoint reachable, origin hidden, traffic filtered, application responding, support owner assigned, and next action clear.

The buyer's acceptance test should be written before migration. For a VPS workload, the test can include order placement, OS install, SSH access, package update, firewall rule, RDNS change, snapshot creation, restore, reboot, billing change, cancellation simulation, and support ticket response. For a shared-hosting workload, it can include domain setup, SSL issuance, email sending and receiving, database import, application install, backup restore, PHP version change, and malware or abuse-response expectations.

For a dedicated server, it can include hardware inventory, RAID verification, reinstall, bandwidth graph, out-of-band access, and disk-failure procedure. For BGP, it can include route-object review, RPKI check, prefix announcement, route withdrawal, looking-glass confirmation, and contact escalation. These tests cost time, but they are cheaper than learning the account model during an outage.

The evidence also suggests a tension in positioning. Private-Hosting sells simple hosting products and more advanced network services under one brand. That can be coherent if the company treats them as layers of one operating system: shared hosting for low-control sites, VPS for flexible compute, dedicated servers for isolation, remote protection for existing origins, and BGP for customers that need address-space control. It becomes confusing if customers buy one layer while assuming guarantees from another. A shared-hosting buyer should not assume BGP-grade route control.

A remote-protection buyer should not assume the provider can repair the origin host. A dedicated-server buyer should not assume managed application operations unless a managed arrangement is explicitly accepted. The account record should make those boundaries visible.

That is why the accepted account record should be treated as a control system rather than a receipt. For a small business, the provider account is the place where technical authority, financial authority, and support authority meet. If the panel shows one service status, the invoice shows another, and a support ticket references a third, the customer has no reliable operating truth. Larger cloud platforms often solve this with mature identity, billing, logging, and support frameworks, but they may be expensive or impersonal. Smaller providers compete by being closer to the operator and more flexible.

Private-Hosting leans into that positioning with language about real engineers, Discord support, and direct network operation. The trade-off is that flexibility must be disciplined. Direct access is not a substitute for a coherent record.

The labor impact cuts both ways. Private-Hosting's products offer features that can reduce customer work: root access from first boot, Plesk for shared hosting, one-click applications, RDNS control, open SMTP with limits, custom ISO upload, snapshot controls, BGP add-ons, and protected tunnels. These features let a technical customer perform routine actions without waiting for a ticket. They also transfer responsibility. Root access means the customer can break the server. Open SMTP means the provider must manage abuse risk and the customer must manage mail reputation. BYOIP means route authorization must be correct.

Custom filtering means someone must understand which traffic is legitimate. The product is not fully managed continuity; it is a mix of self-service and operator help.

For developers and platform teams, that mix can be valuable. A small team may prefer a VPS provider that allows mail ports, custom kernels, and RDNS without forcing a managed-cloud abstraction. A game operator may prefer direct tunnel setup and DDoS-specific support over a hyperscaler that treats unusual traffic as a policy issue. A small web agency may value Plesk, SSL automation, and daily backups because it reduces routine administration. These are real workflow advantages if the provider's panel, network, and support queue behave consistently.

They become liabilities if the customer expects enterprise managed service and receives a self-service hosting account with friendly support but limited formal process.

The unit economics are therefore not just the listed monthly price. The VPS page positions annual plans from a low euro price point, shared hosting starts just above that range, and dedicated servers begin at a much higher monthly price for full hardware isolation. The BGP page describes two economic models: an add-on style session attached to VPS or dedicated products, and 95th percentile bandwidth billing for transit use. Remote DDoS protection introduces another model, where the customer can keep an existing origin and buy protected ingress plus tunnel delivery. Each model changes who pays for waste.

In shared hosting, the provider manages density and the customer accepts less control. In VPS, the provider manages node allocation while the customer manages the stack. In dedicated hosting, the customer pays for isolation even when the machine is underused. In BGP or remote protection, the customer pays for network control and must manage routing detail.

The commercial question is whether Private-Hosting reduces enough work and risk to justify that implementation cost. For a low-risk brochure site, a mainstream shared host or commodity VPS may be simpler. For a mission-critical application with compliance, audit, and contractual support requirements, a large cloud, managed hosting firm, or enterprise colocation arrangement may be more appropriate.

Private-Hosting's strongest fit is likely the middle: technically literate customers who need European hosting, visible network control, DDoS-aware support, and prices below enterprise managed infrastructure, while accepting that some governance must be done by the customer. The customer should not buy it as a magic shield. It should buy it as an operator-managed edge and hosting account that must be tested like any other dependency.

Substitutes frame the risk. A hyperscaler gives mature identity, logging, multi-region services, procurement features, and a large support ecosystem, but DDoS protection, bandwidth, IPv4, and support can become expensive or complex. A mass-market VPS provider gives low prices and large scale, but may not support BGP, custom mitigation, or fast abuse-sensitive use cases. A specialist DDoS provider can protect an existing origin, but may add tunnel complexity and another vendor boundary. A colocation provider gives hardware control, but shifts more operational burden to the customer.

Private-Hosting tries to combine protected hosting and network services under one account. That combination can simplify accountability if it works. It can also concentrate risk if the same small provider owns billing, routing, server provisioning, mitigation, and support.

Market evidence is modest. The operator website references Trustpilot ratings and review counts, and public review directories list Private-Hosting as a hosting provider with VPS, dedicated-server, shared-hosting, and DDoS-protection services. HostingCharges describes plans and contact details, while other listing pages surface the domain and services. These sources are useful for confirming that the brand is visible in the hosting market, but they are weak evidence of sustained customer outcomes. Review directories can be stale, compensated, incomplete, or based on small samples.

A rating displayed on a provider site should not be treated as independent operational proof unless the buyer reviews the underlying review corpus and recency. For this company, the public market signal is enough to show presence, not enough to establish reliability.

The same caution applies to performance and latency claims. The VPS page includes benchmark language and network latency statements, while service pages refer to Frankfurt, DE-CIX, Tier III facilities, ISO 27001, and low European latency. Those statements are plausible in the context of a Frankfurt-hosted European service, and the public AS record supports an internet routing footprint. But a buyer should not turn a page benchmark into a production assumption. Performance depends on node density, CPU generation, storage contention, noisy-neighbor behavior, upstream congestion, attack conditions, route path, and customer workload.

A benchmark from one instance or a latency table from one location is a starting point for testing, not a guarantee that a future account will behave the same way.

Identity boundaries should also stay precise. The company name in registry and directory contexts is Private-Hosting di Cipriano oscar, while the website presents the brand Private Hosting and refers to Oscar Cipriano as founder. Public sources do not require the reader to decide whether the exact legal string is a sole-proprietor style name, a company trading name, or a brand label; the safe boundary is the public service surface at private-hosting.eu and AS211138. The article should not attribute the conduct of customers, upstream suppliers, public authorities, data-center operators, or similarly named organizations to this entity.

Nor should it treat supplier capabilities as owned capacity unless the provider's public record clearly says so. In hosting, that distinction often matters because the customer experiences one brand while many upstream dependencies share responsibility.

Upstream dependency is unavoidable. RIPE import and export records show AS211138 relying on other AS paths, and public routing visibility shows the network as part of a broader internet transit ecosystem. DDoS mitigation may involve provider-owned filtering, supplier capacity, upstream cooperation, or a mix that is not fully visible from public pages. Frankfurt facility claims imply data-center dependency. Plesk implies control-panel software dependency for shared hosting. Let's Encrypt-style managed SSL implies certificate automation dependency. Email service depends on IP reputation and abuse controls.

Payment and billing depend on payment processors and the hosting panel. When something fails, the customer does not always care which supplier is responsible, but the support record must know. A provider that can coordinate dependencies quickly is valuable; one that merely points across the chain leaves the customer doing integration work.

The operating model should therefore be tested through small, deliberate changes before a critical workload moves in. Order a low-tier VPS and verify the provisioned resources, IP records, RDNS, OS reinstall path, firewall behavior, support response, cancellation flow, and snapshot restore. For shared hosting, test SSL issuance, mail delivery, database restore, PHP switching, Plesk access, and a recovery request. For a dedicated server, confirm hardware details, RAID state, out-of-band access, reinstall behavior, port speed, traffic graphs, and support escalation.

For DDoS protection, use a legitimate traffic simulation or controlled failover test rather than abusive traffic, and verify that the protected endpoint, tunnel, and origin-hiding assumptions are true. For BGP, validate route objects, RPKI state, LOA handling, propagation, withdrawal, and looking-glass visibility before announcing production address space.

The known failure modes are concrete. A provisioning mismatch can leave the customer with the wrong plan or missing network attributes. An IP or DNS error can expose the origin, break mail, or route users to the wrong service. A mitigation gap can leave an application reachable but unusable. A backup restore miss can turn a routine migration into data loss. Account suspension can convert a billing state into downtime. A billing dispute can freeze changes when the customer most needs support. A support delay can make a short outage long.

An upstream outage can leave the provider's own team waiting on transit, filtering, facility, or software dependencies. None of these risks is unique to Private-Hosting; they are the normal risk surface of protected hosting. The question is whether this provider's account record catches them early.

The company appears to understand some of that record discipline. Its public pages mention control-panel functions, route monitoring, visible network identity, support channels, and specific product mechanics. Those details are better than generic promises. The risk is that the same pages sometimes blend marketing, technical detail, and broad assurance in a way that can exceed what public evidence proves.

A buyer should separate claims into three categories: facts that can be independently seen, such as AS211138 and advertised product options; functions that can be tested after ordering, such as snapshots and RDNS; and outcomes that require history, such as uptime during attacks, restore success, and support quality. Only the first two categories are presently strong enough from public evidence.

Private-Hosting's best commercial argument is not that it is bigger than its substitutes. It is that a small provider with direct network operations can be more legible for certain customers. If the same team can provision the server, adjust filtering, inspect routing, and answer support, the customer may avoid the vendor maze that often appears around DDoS incidents. That is especially useful for game servers, small SaaS operators, independent developers, and agencies that do not want to assemble separate hosting, DDoS, DNS, and transit relationships.

The danger is the mirror image: if one small team is overloaded, or if the account state is not carefully maintained, the customer has fewer alternate paths inside the provider.

The practical way to resolve that trade-off is not a heroic stress test. It is a record test repeated across ordinary changes. A customer can make the first month deliberately uneventful and still learn a great deal: open a support request before there is an emergency, change a reverse DNS entry, restore a disposable snapshot, check whether a renewal invoice matches the active plan, move a non-critical hostname behind the protected address, withdraw a test route if BGP is involved, and confirm that every action leaves a trace the customer can understand later.

These are small actions, but they reveal whether Private-Hosting's account model is a dependable operating surface or a collection of separate panels, messages, and promises. They also reveal the customer's own cost. If every change requires a senior engineer to reconcile routing, billing, access, and backup state manually, the monthly hosting price is not the real price. If the records stay clear and support answers with the same state the customer sees, the small-provider model becomes more credible.

The final judgment is conditional. Private-Hosting di Cipriano oscar should be evaluated as a protected-hosting account system anchored by private-hosting.eu and AS211138, not as an abstract DDoS brand. Its public record supports a real service surface: European VPS, dedicated servers, shared hosting, remote protection, BGP options, and a small visible routing footprint. It also leaves important questions unanswered: staffing depth, independent uptime history, actual mitigation architecture, supplier roles, backup retention, restore evidence, incident transparency, and customer outcome data.

For non-critical workloads, the provider may offer a pragmatic balance of control, price, and protection. For continuity-sensitive workloads, the buyer should require a proof period in which the accepted account record is exercised under change.

That proof period is the central recommendation. Do not ask only whether Private-Hosting has DDoS protection. Ask whether a real customer account can move through ordering, provisioning, routing, filtering, backup, billing, support, and recovery without losing coherence. If the record stays aligned across those steps, the provider's small-operator model has practical value. If the record fragments, the mitigation claim will not save the customer from the ordinary failures that most often cause downtime. Protected hosting is not a shield painted on a plan table.

It is an operating record that has to remain true after the customer clicks buy.