Cotton Candy Cloud puts recovery work inside the server bill

Summary

• The public record supports a narrow judgement: Cotton Candy Cloud is visible as a Singapore private company connected to ASN/IP network resources, and APNIC's public transfer log records it as the source organization for a 2025 IPv4 transfer to Zoho Corporation Private Limited. That is enough to study hosting-account economics, but not enough to claim current revenue, customer count or live infrastructure scale.
• The economic unit is a hosting, cloud or data-service continuity account. A buyer pays for server capacity, but the costly part is often the recovery hour: backups, restore judgement, abuse handling, IP reputation, routing continuity, invoice continuity, software licences, local support response and the avoided disruption of moving a production workload.
• The public evidence would become materially stronger if Cotton Candy Cloud disclosed recurring account revenue, active server count, backup success rates, support response times, upstream and data-centre contracts, churn, customer concentration, incident history and what happened economically after the IPv4 transfer.

The metric that would settle the question

The most useful public metric for Cotton Candy Cloud would not be a headline count of servers. It would be the median time, labour cost and customer-retention result for a restored account after a real outage, ransomware event, disk failure, account suspension or abuse complaint. If a hosting customer can recover a live site, mail service, application database or private workload in hours without moving away, the account is buying a managed continuity service. If the provider can only point to a rented machine and leave the customer to rebuild alone, the account is closer to a commodity virtual server.

That distinction matters because the public evidence for Cotton Candy Cloud is thin. The BTW directory page identifies Cotton Candy Cloud Pte Ltd as a Singapore private company connected with ASN/IP network resources. APNIC's public transfer log records Cotton Candy Cloud Pte Ltd as the source organization for the 103.84.216.0 to 103.84.219.255 IPv4 range transferred on 4 April 2025 to Zoho Corporation Private Limited. A current APNIC RDAP query for 103.84.216.0 resolves to Zoho-related contact and description data, not to Cotton Candy Cloud. Those records are enough to show that Cotton Candy Cloud has appeared in network-resource ownership or custody, but they do not reveal a live customer base, traffic profile, margins or support practice.

The article therefore uses Cotton Candy Cloud as a bounded hosting-economics case. It asks what has to be true for a small Singapore-linked cloud or hosting account to be worth buying when larger clouds, local rivals, website builders and delayed migration all exist. The answer is not "cheaper compute." Official price sheets already show that raw cloud capacity can be bought from very large suppliers. Amazon EC2 describes on-demand compute as pay-by-hour or by-second capacity without long-term commitments on its EC2 pricing page. DigitalOcean lists low-end droplets beginning at small monthly prices on its Droplet pricing page. Akamai Cloud, formerly Linode, presents simple shared and dedicated compute prices with bundled or low egress on its cloud pricing page. OVHcloud lists dedicated servers and bundled protection on its bare-metal pricing page. A small host cannot beat that universe by selling a processor and disk as if customers had no alternatives.

The survivable offer is narrower. It is the paid continuity account: a combination of usable capacity, human help, resource control and operational memory that reduces the cost of staying online and reduces the cost of not migrating today. The server bill is only the visible line item. The hidden line item is recovery work.

What the public record can prove

The strongest company-specific public record is APNIC's transfer data. APNIC says a transfer occurs when IP addresses or AS numbers move from one legal entity to another, and its transfers page distinguishes a transfer from an organizational name change. That distinction is important. Cotton Candy Cloud appearing as a source organization in a transfer log is not merely a marketing claim; it is a registry record of a resource movement. But the same record also narrows what can be concluded. Once a range has been transferred, the source no longer proves current operation of that range.

The transferred range matters because it is 103/8 space. IANA's IPv4 Address Space registry lists 103/8 under APNIC. APNIC's IPv4 exhaustion explainer states that new and existing APNIC members can still receive IPv4, but the maximum amount from policy-governed supply is limited and organizations needing more must consider transfers. APNIC also explains that its final-/8 and recovered-pool policies were designed to ration scarce IPv4 so new and emerging networks could still get small allocations. A /22, which contains 1,024 IPv4 addresses, is meaningful in that context because it can support many directly reachable services, but it is not large enough by itself to prove a major cloud platform.

APNIC's transfer conditions add another important boundary. They say recipients can be asked to provide plans for use, fees can apply, and when a transfer is complete the source no longer has rights to the transferred resources. That makes the Cotton Candy Cloud record economically interesting and operationally limited at the same time. It may indicate that Cotton Candy Cloud once controlled a scarce address block. It may indicate a monetizable resource position. It does not show whether the company retained other resources, whether customers were moved before transfer, whether the transfer was a sale, whether it was part of a corporate arrangement, or whether any hosting service remained afterward.

The current RDAP record sharpens that point. The RDAP result for 103.84.216.0 lists the network as ZOHO-IN and describes Zoho Corporation Private Limited. It includes abuse and technical contacts tied to Zoho rather than Cotton Candy Cloud. That is exactly what one would expect after a completed transfer. It also means an analyst should not look at current use of the block and attribute it to Cotton Candy Cloud. The transfer record is a past-resource clue, not a live-operations map.

The BTW directory adds the identity layer: Cotton Candy Cloud Pte Ltd is treated as a Singapore private company connected with ASN/IP network resources. The directory page is useful as a public index of the company and its network-resource association, but it is not a substitute for financial statements, customer contracts, public service pages, status data or a company website. For this article, the company-specific conclusion is deliberately modest: Cotton Candy Cloud is visible where a scarce resource moved, and that visibility is enough to ask what kind of hosting economics could justify such a company in Singapore. It is not enough to declare a successful cloud operator.

What the customer actually buys

The customer buys a working account that keeps a workload reachable and recoverable. In the smallest version, it may be a virtual server, a dedicated server, a web-hosting account, DNS help, email, a backup add-on and a support relationship. In the larger version, it may include data migration, firewall rules, IP allocation, private networking, monitoring, managed databases, abuse mitigation and a named person who understands the customer's old configuration. The payment is monthly, but the value is episodic. It is proved when something goes wrong.

That creates a different price logic from the public cloud price sheets. Amazon's EC2 page describes variable compute and data-transfer economics. AWS also charges for public IPv4 addresses, and its VPC pricing page lists an hourly charge for in-use and idle public IPv4 addresses. AWS support is a separate product; the AWS Support pricing page shows premium tiers where minimums and percentages of monthly charges can become material for a small buyer. None of that is improper. It is the explicit modular economics of hyperscale cloud. The buyer assembles compute, storage, network, address, support and incident help from separate services and often pays separately for higher-touch assistance.

A smaller host's opportunity is to bundle some of that operational work into a less modular bill. The account may not be cheaper on pure CPU or storage. It may be cheaper when the customer includes time spent learning the console, repairing DNS, restoring from a snapshot, answering abuse mail, moving mailboxes, explaining a billing hold, or getting a human response during a failure. The small host's bill is therefore a claim on local support labour. If that labour is competent and available, the account can be rational even when commodity server prices elsewhere are lower. If that labour is slow, scripted or unavailable, the buyer should treat the account as weak commodity capacity.

The recovery moment exposes the economics. A site owner whose database is corrupted does not first ask whether the vCPU is priced at the lowest possible hourly rate. The owner asks whether the backup exists, whether it is restorable, whether DNS and SSL will still work, whether email will be lost, whether the public IPv4 address will change, whether a control-panel licence will break, whether an upstream provider has suspended traffic, and whether the support desk can tell the difference between a disk failure and an application error. Those are service costs, not merely hardware costs. They are costly because they require judgement, tools, retained configuration history and people who can work under time pressure.

The observable Cotton Candy Cloud record does not prove that the company delivered those services. It only places the company in a category where those services would be the economic reason to exist. The public question is therefore not "did Cotton Candy Cloud own servers?" It is "if a customer paid Cotton Candy Cloud, what job would have been expensive enough to justify staying with it instead of moving to a larger cloud?" The answer is continuity.

Why recovery work gets priced into hosting

Recovery work is expensive because it is irregular, urgent and asymmetric. The customer may pay the same monthly fee for months while nothing breaks. When failure arrives, the provider's labour cost is concentrated into a few hours. A competent technician may need to inspect logs, mount a disk image, test a database repair, restore files, check DNS, rebuild a firewall, contact an upstream abuse desk, explain options to a non-technical customer and preserve evidence for later review. The customer sees one server bill. The provider sees a queue of contingent liabilities.

This is why low monthly pricing can be dangerous. A provider that prices only for idle server capacity may not have margin to fund restore labour. A provider that prices for continuity has to build recovery work into the recurring bill, charge separately for managed support, or accept lower profitability when incidents occur. The difference is hard to observe publicly because support quality is private until a failure happens. A glossy page can promise support; only ticket history, restored-account evidence and churn after incidents can prove it.

Backups are the simplest example. DigitalOcean's public pricing page says backups can be percentage-based or usage-based, and snapshots are priced separately. That public structure makes the hidden economics visible. Backup storage, retention, restore tooling and support are not free features. They consume storage, bandwidth and staff time. A local host that includes backups inside a package must either charge enough to fund them or accept that backup quality will deteriorate. If Cotton Candy Cloud operated hosting accounts, the key private fact would be the ratio of charged backup revenue to actual restore cost and successful restore frequency.

Abuse handling is another hidden cost. Hosting customers can be compromised, misconfigured or malicious. Spam, phishing pages, malware, scanning and copyright complaints create ticket work and upstream risk. A provider must decide whether to suspend immediately, notify the customer, preserve data, rate-limit traffic, rebuild the account, rotate credentials or terminate service. That is not merely a moral question; it is a supplier-dependence question. If the upstream transit provider or data centre sees the small host as slow to respond, the host can lose connectivity for many innocent customers. If the host is too quick to suspend, customers who are recoverable may leave. The economic value lies in precise response.

IP reputation turns abuse work into a balance-sheet-like problem. A public IPv4 address can carry history. It can be blocked by mail receivers, reputation services or security filters. If a host uses scarce IPv4 for many customers, one bad account can harm others. If a host has too few addresses, clean replacement options are limited. If the host transfers away a block, customers who depended on address continuity may need renumbering, allow-list updates or DNS changes. APNIC's Cotton Candy Cloud transfer record therefore raises the right question: did the address movement represent an orderly resource monetization with no customer harm, or did it indicate a shrinking resource base that made hosting continuity harder? Public data does not answer that.

Migration avoidance is a product

The cheapest hosting plan is often the one a customer does not have to move from this month. That sounds like complacency, but in small business infrastructure it is an economic fact. Migration costs are real: export the database, copy files, test application versions, move mailboxes, lower DNS time-to-live, replace SSL certificates, recreate cron jobs, set firewall rules, update payment records, preserve logs, test forms, redirect traffic, revise backup jobs, update search-console ownership and keep staff from making changes during the freeze. If the application is old, poorly documented or built by a departed contractor, the migration cost can exceed a year of hosting fees.

This is where a small host can be sticky without being dominant. It may hold the old control panel, the old backup schedule, the IP address, the email settings and the institutional memory of how the account was built. The buyer is not only comparing the monthly server price against AWS, DigitalOcean, Akamai, OVHcloud or another local host. The buyer is comparing the current bill against the full cost of moving, testing and taking blame if the move breaks. The customer's substitute is not always "a better cloud." It may be delayed migration.

Delayed migration has two faces. It can be rational when the current provider is stable, support is responsive and the move would consume scarce management attention. It is irrational when the provider is unstable, opaque or dependent on a single upstream facility. The hard part for outsiders is that both situations look similar from public records. A quiet company may be quietly competent or simply invisible. A sparse directory record does not tell the difference.

For Cotton Candy Cloud, the migration-avoidance thesis depends on private facts. Were there live customer workloads attached to the transferred IPv4 range? Were customers given replacement addresses or migrated to the recipient? Were there no customers at all because the resource position was held for another reason? Did the company retain a separate pool? Did recurring customers renew after the transfer? Did the firm have support staff capable of customer migrations, or was the resource transfer the central economic event? Public APNIC records cannot answer these questions.

The broader market still explains why the question matters. Large clouds have tooling, geographic redundancy and extensive documentation. They also have complex bills, separate support tiers and operational responsibility that can overwhelm small buyers. Local hosts and managed providers sell reduction of that burden. The buyer pays to avoid becoming a cloud engineer. In that sense, migration avoidance is not a failure of competition; it is part of the product. The risk is that customers may mistake avoidance for safety when the provider's own supplier chain is fragile.

Supplier and upstream dependence

A small hosting company is rarely self-sufficient. It depends on data-centre space, power, cooling, cross-connects, upstream transit, routers, hardware vendors, virtualization software, control panels, backup storage, domain registrars, certificate automation, payment processors, abuse desks and the regional internet registry system. Each supplier shapes the service the end customer experiences. The customer may think it is buying from one host. Economically, it is buying a managed bundle of several suppliers.

Data-centre dependence is the most physical dependency. Singapore is a strong connectivity hub, but data-centre space is expensive and power-constrained relative to many cheaper hosting markets. If a small provider leases racks or colocated machines, its margin depends on power pricing, renewal terms, remote-hands fees, cross-connect fees and whether it can spread fixed costs across enough accounts. If it rents servers from a larger platform, its margin depends on wholesale price, location, network quality and the ability to recover when the upstream supplier changes terms.

Transit dependence is the next layer. A hosting provider has to move traffic reliably and handle abuse pressure. A customer buying a small account may not care who the upstream carriers are until routing changes, latency rises or complaints trigger suspension. The host's bargaining power with upstreams depends on volume, reputation and payment history. A small host with limited address space and a thin customer base has less room to negotiate than a large cloud with global traffic and many interconnects.

Registry dependence sits under the addressing layer. APNIC's transfer conditions show that resource transfers come with policy, fees, registration updates and rights consequences. The IANA and APNIC records show that IPv4 is not an unlimited raw material. This matters to a host because public IPv4 still supports direct reachability, mail reputation, legacy applications and many customers' mental model of hosting. IPv6 is the long-term answer in policy terms, and APNIC says so explicitly in its exhaustion page. But many customers, applications and allow-list practices still price IPv4 as a scarce input.

Software dependence is less visible but often decisive. A host may rely on cPanel, Plesk, WHMCS, virtualization management tools, backup software and anti-spam systems. Licence price changes can alter margin. Security updates can break old workloads. Control-panel compromise can turn a support issue into a platform incident. The public record for Cotton Candy Cloud does not show its software stack, if any. That absence is not a minor detail; it is one of the facts that would change the judgement.

Payment dependence also matters. Small hosting providers often operate on monthly credit-card billing. Chargebacks, suspended payment gateways, tax compliance and customer non-payment can turn technical support into credit control. A customer who is late on a bill may need urgent restore help. The provider has to decide whether to help before payment, suspend access, keep backups, delete data or extend grace. These are economic choices embedded in operational policy.

Competition from larger clouds

The large-cloud substitute is powerful because it unbundles and documents the components. Amazon shows compute, data transfer, public IPv4, support and incident-response-related products as separate billable items. DigitalOcean exposes simple VM pricing, included transfer, backups and snapshots. Akamai Cloud emphasizes predictable pricing, low egress overage and optional managed service. OVHcloud emphasizes dedicated servers, network identity, additional IP and default anti-DDoS on its product pages. These are not identical offers, but they create a transparent benchmark against any small host.

This benchmark hurts small providers in three ways. First, customers can see commodity capacity prices. If a small host charges much more for a simple virtual server, it must explain why. Second, larger clouds have credibility from scale, documentation and public status systems. A small host's support promise has to overcome the perception that scale equals safety. Third, cloud ecosystems make migration in the opposite direction easier for new projects: a developer can start on AWS, DigitalOcean or Akamai without calling anyone.

But large clouds do not erase the smaller-host niche. Their modularity is a burden for customers who do not want to assemble a service. A small business may prefer a host that answers a ticket in local business language, understands legacy PHP, knows how the customer's DNS is arranged, and can restore a WordPress site without asking the owner to choose among block storage, snapshots, object storage, IAM roles and region-specific egress. The local support labour is the product, if it exists.

Support economics are the clearest comparison. AWS Basic Support is included, but premium support tiers have minimums and percentages of cloud spend. That pricing is rational for a hyperscale provider because specialized help is costly. It also creates space for smaller managed hosts to say: "our support is already in the bill." The statement is valuable only if response time and skill match the promise. If the provider's support is outsourced, slow or unable to act, the buyer would be better off paying a larger provider or hiring a consultant.

The local-host advantage is therefore fragile. It must be refreshed every time a customer opens a ticket. It cannot be sustained by scarcity alone. IPv4 control may create bargaining power, but not enough if uptime and help are poor. Conversely, good support can preserve accounts even when the host does not own much infrastructure. A reseller can be valuable if it absorbs operational complexity and takes responsibility. A resource holder can be weak if it merely passes through upstream problems.

Cotton Candy Cloud's visible resource transfer to Zoho makes this competition sharper. Zoho is a large software company with its own infrastructure needs. If a smaller Singapore company transferred a /22 to such a recipient, one possible economic reading is that scarce IPv4 was more valuable to a scaled software operator than to the source. Another possible reading is an ordinary resource realignment unrelated to hosting customers. The public record does not choose between those readings. It does show why scarce resources and scale interact: the larger platform can often monetize addresses across more products, users and internal systems.

The Singapore operating surface

Singapore gives hosting providers a credible regional location, but it also creates a serious operating surface. Connectivity, law, business trust and proximity to Asia-Pacific customers are advantages. Space, power, compliance, wage levels and customer expectations are costs. A Singapore-linked provider that claims low-price commodity hosting must explain how it absorbs those costs. A provider that claims managed continuity can justify a higher bill only if support and reliability are real.

Regulation matters because hosting and cloud services increasingly sit inside national cyber-resilience policy. The Cyber Security Agency of Singapore's Cybersecurity Act page says amendments passed in 2024 update oversight for critical information infrastructure and expand coverage to new classes of regulated entities. It states that companies providing digital infrastructure services foundational to the economy or way of life, such as cloud service providers and data centres, can be regulated as Foundational Digital Infrastructure and required to follow codes and report prescribed incidents. That does not automatically mean Cotton Candy Cloud is regulated under that category. It means the Singapore policy environment treats cloud and data-centre operations as infrastructure, not just ordinary web services.

For customers, this policy environment changes the risk conversation. A local host that serves critical or sensitive workloads may need clearer incident reporting, security controls, logging, access management, supplier resilience and customer communication than a hobby host. For the host, compliance work becomes part of the cost base. For the analyst, it raises private questions: what kinds of customers did Cotton Candy Cloud serve, if any? Were any regulated or enterprise customers involved? Did the company maintain security policies, incident reporting, access controls and supplier documentation? Public records do not answer.

Singapore's business reputation can also be a customer-acquisition asset. A buyer may prefer a Singapore company for contracting, tax, language, banking, legal recourse and proximity. That advantage is not infinite. Larger clouds operate Singapore regions or Asian regions, and local managed-service firms can build on top of them. The small provider has to turn jurisdictional trust into actual operational trust. A Singapore registration does not restore a server by itself.

The BTW directory lists Cotton Candy Cloud's registration jurisdiction and geography as Singapore. That identity matters, but only as a starting point. The business case depends on what the company did with that position: held address resources, sold hosting accounts, resold upstream cloud capacity, provided migration help, offered managed support, or simply held and transferred network assets. Public evidence supports the first and last possibilities more clearly than the middle ones.

Revenue logic and what can be inferred

There are several plausible revenue models for a company like Cotton Candy Cloud, but they have different risk profiles. The first is direct hosting revenue: customers pay monthly for servers, web hosting, backups, support and perhaps managed migration. The second is reseller or managed-service revenue: customers pay Cotton Candy Cloud, while underlying infrastructure is sourced from another provider. The third is resource monetization: scarce IPv4 addresses are leased, used, transferred or otherwise converted into value. The fourth is a mixed model where resource control supports hosting and later becomes a saleable asset.

The public record most directly supports resource monetization as an observable event, because the APNIC transfer is visible. It does not prove the consideration paid, if any. It does not prove that the transfer was a sale rather than a corporate or operational arrangement. It does not prove whether Cotton Candy Cloud's core business was hosting. It does, however, show that the company was named in a movement of scarce network resources. In hosting economics, that is not trivial.

If the revenue model was direct hosting, the key variable would be average revenue per account against support burden. Low-end web-hosting accounts can be numerous but support-heavy. Dedicated-server accounts have higher monthly revenue but more hardware and facility exposure. Managed cloud accounts can have better gross margin if the provider standardizes operations, but worse margin if every customer has a bespoke environment. Recovery work can turn a profitable account into a loss if incidents are frequent and not separately billed.

If the revenue model was resource monetization, the key variable would be the opportunity cost of holding addresses. IPv4 addresses can support services, but they can also be transferred to organizations with stronger need and higher willingness to pay. APNIC's transfer market exists because address scarcity creates a matching problem between holders and recipients. A /22 may be small relative to hyperscale demand, but large enough to matter for a focused SaaS operator, a hosting provider, a mail platform or a private network design. The public record shows Zoho as the recipient for the Cotton Candy Cloud range, which suggests the addresses had utility to a larger software operator after transfer.

If the revenue model was reseller support, the key variable would be labour efficiency. A small provider can earn margin by translating customer needs into cloud operations: deploy, patch, restore, secure, answer tickets and manage invoices. The risk is that the provider becomes squeezed between demanding customers and powerful upstream suppliers. It owns customer expectations but not always the infrastructure. If upstream prices rise or support fails, the reseller absorbs blame.

An analyst should not pick one model from public data alone. The correct conclusion is conditional. Cotton Candy Cloud is economically interesting if the company either used scarce resource control to support continuity accounts or converted a scarce resource into value. It would be less interesting as a cloud operator if the transfer reflected the end of a resource position with little remaining customer service. Only private revenue, customer and operating data can decide.

Cost base: the server is the easy part

A hosting provider's visible cost is compute. Its difficult cost is everything around compute. Hardware must be bought, leased or rented. Racks must be powered and cooled. Transit and cross-connects must be paid. Public IP addresses must be obtained, managed and defended. Software licences must be renewed. Backups must be stored, tested and occasionally restored. Staff must answer tickets. Abuse complaints must be handled. Billing systems must collect money. Customers must be retained.

The difference between a good and bad hosting account is often not the list of components, but the integrity of the operating loop. Does monitoring detect the failure before the customer does? Are backups tested or merely created? Does a support person know where the customer's database lives? Can the provider distinguish between upstream packet loss, application overload and disk failure? Is there a plan if the data-centre supplier terminates a server? Is there enough margin to spend two hours on a low-paying account without losing money?

This is where larger clouds have an advantage. Their infrastructure costs are spread across enormous customer bases. Their automation is deep. Their documentation is extensive. Their procurement power is large. They can expose granular charges and let customers decide how much support to buy. Smaller providers must either specialize, provide better human care for a narrow customer group, or live dangerously on thin margins.

Cotton Candy Cloud's public footprint does not reveal its cost base. There is no public server inventory, staffing count, data-centre contract, network map, customer mix or audited financial statement in the sources used here. That absence prevents a margin conclusion. It also prevents a reliability conclusion. A company can be small and excellent; a company can be small and fragile. The public record only tells us where to look.

One cost clue is the transferred IPv4 range. If Cotton Candy Cloud no longer controls that range, it no longer bears the opportunity cost or registry responsibility for it. That may have improved liquidity or simplified operations. It may also have reduced the company's ability to serve customers requiring dedicated IPv4 addresses. Which interpretation is right depends on whether addresses were surplus, customer-attached or central to the offer.

Another cost clue is the Singapore location. Local support labour in Singapore is not a low-cost input relative to many offshore hosting markets. If the business promises responsive human help, that help must be either priced properly, limited to higher-value accounts, automated heavily or delivered from a different labour market. A low-price unlimited-support model would be suspect without scale.

Customer dependence and support response

Hosting customers are sticky until they lose trust. The dependence is practical, not emotional. DNS points to the host. Mailboxes sit there. Backups sit there. Billing history sits there. The customer may not know how to migrate. The provider may hold administrative access to old systems. The site may contain years of business records. A clean move requires cooperation.

This gives a host bargaining power, but only temporarily. A customer who survives a bad incident may leave afterward. A provider that mishandles a restore can lose more future revenue than the account was worth. A provider that responds well can keep a customer for years. The retention value of support response is therefore central to the economics.

For Cotton Candy Cloud, the public record has no customer reviews, no status history and no ticket metrics in the sources found for this article. That is a major evidence gap. Bounded informal searches around the company name did not surface a reliable body of public customer chatter. The absence should not be treated as praise or criticism. It may mean the company served few public retail customers, used another brand, operated privately, or simply left little indexable trace. Informal silence is a market signal only in the weak sense that there is no visible consumer-review base to corroborate support claims.

The private facts that matter are concrete. What was the first-response time for urgent tickets? How many recoveries succeeded on the first restore attempt? How many abuse complaints led to suspension? What percentage of customers churned within 90 days of a serious incident? Did customers receive root access, managed access or only control-panel access? Were backups included, optional or customer-owned? Did support cover applications, or only infrastructure? Did Cotton Candy Cloud publish service terms that defined data-retention and suspension rules? Without those facts, any customer-dependence judgement is conditional.

Support response also changes the substitute set. If a customer's main problem is lack of technical labour, a larger cloud may be a poor direct substitute unless paired with a managed-service provider. If the customer's main problem is scale, reliability engineering or global footprint, a small host may be the wrong substitute no matter how responsive. The economic question is not "local host or hyperscale cloud" in the abstract. It is which party owns the recovery burden.

Address scarcity as evidence, not destiny

IPv4 is not destiny, but it remains a priced input. AWS's explicit public IPv4 charge shows that even the largest cloud now treats public IPv4 as a separately visible cost. APNIC's exhaustion page shows why additional address space is policy-constrained. IANA's registry shows the global RIR allocation structure. APNIC's transfer log shows that addresses move between legal entities. These official records make resource control economically meaningful.

Yet address scarcity can mislead analysts. A company associated with a block is not automatically a durable host. A company that transfers a block is not automatically failing. A company without an ASN may still deliver valuable managed services on leased infrastructure. A company with an ASN may still have weak customer economics. Public number-resource data is an evidence layer, not a full business model.

In Cotton Candy Cloud's case, the resource evidence cuts both ways. On the positive side, being named in an APNIC transfer suggests the company once had a registrable resource position. That is more substantive than a generic website claim. On the negative side, the transfer out to Zoho means the specific visible block cannot be used as proof of current Cotton Candy Cloud operations. If the company's business depended on that /22, the transfer would be a major change. If the block was surplus or held for transfer value, the transfer may have been economically rational.

The best interpretation is that Cotton Candy Cloud should be monitored through resource events, not through marketing claims. Future APNIC, RDAP, routing and directory changes would be more informative than a static description. If new addresses, ASNs, route objects or official service pages appear, the operating picture changes. If no further public resource evidence appears, the company remains a sparse resource-transfer case.

Abuse handling and supplier risk

Abuse handling is where small-host economics can collapse. A single compromised customer can generate spam, phishing, scanning or malware traffic. Upstream providers and data centres may not care that the rest of the host's customers are innocent. They care whether the host responds fast enough to protect their network and reputation. If the host cannot act quickly, the upstream supplier can rate-limit, null-route, suspend or terminate.

This creates a hidden insurance problem. The host must keep enough operational capacity to investigate abuse, reach the customer, preserve data, clean the account and satisfy upstream expectations. That work does not always generate extra revenue. If customers are low-paying and incidents are frequent, abuse handling consumes margin. If customers are high-value and recoverable, careful abuse handling preserves revenue. The difference is customer quality and support process.

The Cotton Candy Cloud public record provides no abuse history. That absence is important. It prevents any claim that the company had a good or bad abuse posture. It also means the article cannot use reputation lists, forum comments or unverified chatter as main evidence. The proper conclusion is mechanical: any hosting account economics for Cotton Candy Cloud would depend heavily on abuse response because address reputation and upstream trust are central to continuity.

The transferred block highlights the point. If a block has poor reputation, a transfer recipient may need to clean or manage it. If a block is clean, it has higher operational value. Public APNIC transfer data does not publish address-reputation condition. RDAP after transfer shows who currently holds the registration; it does not tell whether the block had abuse history at transfer. The private facts that would change the judgement include mail-blocking history, RPKI and route hygiene, complaint counts, upstream notices and the operational reason Zoho wanted the range.

Billing practice and trust

Billing is not a back-office detail in hosting. It governs data access, suspension, backup retention and migration timing. Customers who pay monthly need to know what happens after a failed card, a dispute, a renewal missed by one day, a chargeback, a cancelled add-on or a migration request near renewal. A fair billing policy can reduce conflict. A vague policy can turn an ordinary payment issue into business interruption.

Large cloud providers expose much of this through account consoles, service terms and usage reports. Smaller providers often rely on invoices and ticket exchanges. That can be more human, but also less predictable. A customer may value a provider who calls before suspension. A different customer may prefer an automated global platform with detailed usage exports. The economics depend on the customer's tolerance for ambiguity and the provider's discipline.

For Cotton Candy Cloud, no public terms, service-level commitments or billing pages were found in the sources used here. That is one of the largest gaps. If the company sold hosting, public terms would clarify data retention, backup obligations, prohibited use, suspension, support scope, refund practice and migration assistance. Without those documents, an outside analyst can only describe the economics that would matter, not the actual policy.

The absence of visible terms also affects valuation. A hosting business with recurring accounts, clear terms, reliable billing and low churn can be valuable even if small. A hosting business with undocumented customer obligations and ad hoc support can be fragile. If Cotton Candy Cloud's value was mostly in an IPv4 asset, the absence of retail terms matters less. If value was in customer accounts, it matters more.

The larger-cloud price umbrella

Large clouds create a price umbrella in two directions. They cap what a small provider can charge for raw capacity, because customers can point to public prices. They also reveal how much fully supported operations cost when support, incident help, public IPv4, backups and managed services are unbundled. A small provider can survive under that umbrella if it offers a simpler total cost for a specific customer segment.

Consider a small company with one production application, one database, email, DNS and a limited technical team. The cheap visible option may be a low-cost droplet or shared VM. But the full solution may require snapshots, backup storage, monitoring, firewall rules, mail deliverability, DNS management and someone accountable during failure. The monthly bill from a local host may look high against the VM line item and low against the labour needed to operate the VM safely.

Now consider a growing SaaS company. It may need multiple regions, IAM controls, infrastructure-as-code, observability, managed databases, compliance evidence and 24-hour incident response. A small host's human support may not compensate for missing platform depth. The larger cloud becomes the rational choice even if the bill is complex. The small provider should not chase that customer unless it has genuine managed-service depth.

Cotton Candy Cloud's thesis sits in the first zone, not the second. The article title says recovery work inside the server bill because that is the defensible small-host mechanism. It does not say Cotton Candy Cloud can compete feature-for-feature with hyperscale cloud. Public evidence would not support that. The business would make sense if it served customers whose main economic pain was continuity, migration avoidance and support response, not global platform breadth.

What informal signals add, and what they do not

Informal signals are weak here. Searches around the exact company name did not produce a reliable public body of customer reviews, forum complaints, outage reports or social discussion in the sources used for this article. That absence can be read several ways. The company may have been small. It may have served private or wholesale customers. It may have used another trading name. It may have been primarily a resource holder. It may simply have avoided public controversy.

The absence does not prove quality. A quiet support desk can be excellent or nonexistent. A lack of forum complaints may reflect satisfied customers, few customers or low visibility. A lack of review pages may suggest enterprise/private relationships rather than retail hosting. For that reason, informal silence is used only as a boundary: there is no public customer-chatter base strong enough to carry the business conclusion.

The better weak signal is comparative market behaviour. Public cloud providers are explicit about backups, snapshots, support, IP charges, egress and managed-service options because customers price those items. Hosting forums and review sites across the industry often revolve around the same problems: slow support, migration pain, abuse suspensions, backups that fail, and surprise billing. Those themes are useful for understanding the market, but they are not proof about Cotton Candy Cloud unless tied directly to the company. This article does not treat generic chatter as company evidence.

The APNIC transfer remains the company-specific signal. It is stronger than review chatter because it is official and tied to a resource movement. It is weaker than financial or customer records because it does not show revenue, margin or service quality. That mixed status is the right level of confidence.

Private facts that would change the judgement

The first private fact is revenue composition. If Cotton Candy Cloud's revenue came mostly from recurring hosting accounts with low churn, the continuity-account thesis strengthens. If revenue came mostly from a one-off IPv4 transfer, the company looks more like a resource monetization case. If revenue was negligible, the article's hosting lens becomes a category analysis rather than a company-strength conclusion.

The second private fact is active workload count. How many servers, accounts, domains, mailboxes, databases and customer applications were live before and after the April 2025 transfer? If many active workloads used 103.84.216.0/22, the transfer required careful migration or customer impact management. If no active workloads used it, the transfer was less operationally risky. If workloads moved to Zoho because of an acquisition or service arrangement, the meaning changes again.

The third private fact is support performance. Median first response, median resolution time, urgent-ticket response, restore success rate, on-call coverage, customer satisfaction after incidents and churn after serious tickets would reveal whether support was truly priced into the bill. A provider that restores fast can earn a premium. A provider that cannot restore is selling hope.

The fourth private fact is supplier structure. Did Cotton Candy Cloud own hardware? Lease dedicated servers? Resell another cloud? Use a Singapore data centre? Use overseas infrastructure? Maintain multiple upstreams? Hold insurance? Have remote-hands agreements? A small host can be resilient with good supplier design or fragile with a single upstream dependency.

The fifth private fact is the economics of the IPv4 transfer. Was there sale consideration? Was the block transferred because it was unused, because a customer needed it, because the company changed strategy, because of a corporate transaction or because address monetization was more attractive than hosting? Was any proceeds reinvested in service continuity, distributed, used to pay debts or unrelated to operating accounts? Public transfer logs do not disclose this.

The sixth private fact is customer concentration. A small number of high-value customers can make a hosting business attractive if contracts are sticky and support is disciplined. The same concentration can be dangerous if one customer leaves or one incident damages trust. Cotton Candy Cloud's public record provides no customer list.

The seventh private fact is legal and security posture. Written terms, data-retention policy, backup responsibility, incident notification, abuse policy, access controls, audit logs and regulatory exposure would shape the risk profile. Singapore's cyber-resilience environment makes this especially relevant for any provider serving important workloads.

Judgement

Cotton Candy Cloud should be treated as a sparse but real network-resource case, not as a proved cloud platform. The public record supports three facts: BTW's public directory identifies Cotton Candy Cloud Pte Ltd as a Singapore private company connected with ASN/IP network resources; APNIC's transfer log records Cotton Candy Cloud as the source organization for a /22 IPv4 transfer to Zoho in April 2025; current APNIC RDAP for part of that range points to Zoho, not Cotton Candy Cloud. Everything beyond that requires inference.

The most defensible inference is not that Cotton Candy Cloud has large current operations. It is that a company in this position matters to hosting economics because resource control, support response and migration avoidance can carry value even when public evidence is sparse. A customer buying a hosting account is not simply buying a server. The customer is buying a continuity relationship that becomes valuable when an account has to be restored, moved, cleaned, renumbered or defended from upstream pressure.

The investment or market judgement is therefore conditional. If Cotton Candy Cloud had recurring customers, tested backups, responsive support, clean supplier contracts and a planned explanation for the IPv4 transfer, the business could have represented a rational small-provider continuity model. If it had little recurring revenue and the main visible value was the transferred address block, the public record points more to resource monetization than to durable hosting economics. If the transferred block supported customer workloads and the company lacked a migration plan, the transfer would be a risk event. Public data does not decide among these outcomes.

The watchpoints are straightforward: new APNIC resource records, new RDAP or routing evidence, a company website or terms page, customer support traces, legal filings, data-centre or upstream announcements, and any public explanation of the 2025 transfer. Until those appear, Cotton Candy Cloud is best understood as a narrow evidence case: a Singapore company visible in network-resource records, useful for asking how much recovery work, migration avoidance and scarce IPv4 control can be hidden inside a server bill.