CloudTeknoloji Cloud Teknoloji Bilisim Hizmetleri ve Ticaret A.S. sells hosted capacity that still depends on racks, transit and repair windows

Summary

• CloudTeknoloji is the company behind daha.net. The public commercial information page names CLOUD TEKNOLOJI BILISIM HIZMETLERI TICARET A.S. as the legal company, gives daha.net as the brand, lists the Istanbul address, phone, MERSIS number and trade registry number, and describes hosting, cloud server, domain, SSL, email and related IT services.
• The infrastructure claim is specific but not fully independent. The about page says daha.net systems are managed from Istanbul 4. Levent and hosted in Istanbul's ICS Datacenter, with Tier III, PCI/DSS, redundant internet capacity, operator-independent fiber, UPS, A+B power, physical security and cooling claims. Readers should treat those as company claims unless corroborated in customer contracts or facility certificates.
• The public routing footprint is current and narrow. RIPEstat's AS overview shows AS202048 announced for CloudTeknoloji, and announced-prefix data shows one visible prefix, 46.28.232.0/24, in the late-June-to-12-July-2026 window. RIS prefix counts show one IPv4 origin prefix, no transiting prefixes and no IPv6 origin prefix.
• The main customer question is not whether daha.net exists. It is how much of a customer's website, VPS, mail, DNS, backup and migration plan is tied to one Istanbul facility, a small routed address block, the currently observed ICS upstream path, support response windows and contract terms that place some backup and data-loss responsibility on the customer.

The company is clearer than many thin hosting names

CloudTeknoloji's public identity is unusually well defined for a small hosting operator. The daha.net commercial-information page gives the legal title as CLOUD TEKNOLOJI BILISIM HIZMETLERI TICARET A.S., states that daha.net is the brand, lists Maslak as the tax office, gives tax number 5470543764, MERSIS number 0547054376400001 and trade registry number 759033, and says the company was founded in 2010. The same page lists an address at Sultan Selim Mahallesi, NEF 09 Plaza 4. Levent B Blok No:7/121, Kagithane, Istanbul, plus telephone, fax, email and KEP details.

That matters because this is not merely a domain selling anonymous hosting. A buyer can connect the brand, company, address, registry identity and public network identity. RIPE's organisation record for ORG-SBHv1-RIPE lists Cloud Teknoloji Bilisim Hizmetleri ve Ticaret A.S. in Turkey, shows the same trade registry number, identifies the organisation type as LIR, and gives a Kagithane, Istanbul address and phone number. RIPE's aut-num record for AS202048 names the AS as CloudTeknoloji, describes it as Cloud Teknoloji Bilisim Hizmetleri ve Ticaret A.S., and links it to the same RIPE organisation.

The brand story then fills out the customer-facing offer. The about page says daha.net has operated since 2010 and serves individual and corporate customers with hosting and server services. It frames the brand as part of Cloud Teknoloji Bilisim Hizmetleri Ticaret Anonim Sirketi, and describes a service set that includes hosting, cloud server, reseller hosting, domain, SSL and corporate email. The contact page gives public phone, fax, support emails, address and KEP details, so buyers have a visible route for sales, support and formal notices.

The company is therefore not operating behind a completely opaque storefront. The evidence supports a real Turkish hosting provider, a named legal company, a branded retail channel, a RIPE LIR identity and an announced AS. The downgrade begins not at identity, but at scale and redundancy. Public records can prove the company and one routed network. They do not prove how much hardware is deployed, how many racks are under direct control, how much spare capacity is reserved, how often failover is tested, or whether customer recovery can be completed without the primary Istanbul site.

The routed footprint is real, current and small

The public network picture is straightforward. RIPEstat's AS overview for AS202048 showed the holder as CloudTeknoloji Cloud Teknoloji Bilisim Hizmetleri ve Ticaret A.S. and marked the AS as announced on 12 July 2026. RIPEstat announced-prefix data showed one visible prefix, 46.28.232.0/24, from 28 June 2026 through 12 July 2026. RIPEstat RIS-prefix counts showed one originating IPv4 prefix, zero transiting IPv4 prefixes, zero originating IPv6 prefixes and zero transiting IPv6 prefixes at the 12 July query time.

That is enough to show live public operation. RIPEstat prefix overview for 46.28.232.0/24 marks the /24 as announced by AS202048. RIPEstat routing-status data showed 325 of 326 IPv4 full-feed peers seeing the route at the sampled time, with one visible IPv4 prefix and 256 addresses of announced IPv4 space. It also showed zero visible IPv6 space and one observed neighbour. RPKI validation returned a valid ROA for AS202048 and 46.28.232.0/24, with max length 24.

The same evidence limits the claim. A single /24 is a small public address footprint. It may carry authoritative nameservers, hosting nodes, mail relays, management endpoints, customer VPS services or monitoring systems, but it is not evidence of a broad regional cloud region. The absence of visible IPv6 origin is especially notable for a modern cloud and hosting seller. IPv4-only visibility does not make the services unusable, but it indicates that customers needing dual-stack public services should ask for explicit IPv6 availability rather than assuming it exists.

There is also no public PeeringDB network entry for this ASN: the PeeringDB lookup for ASN 202048 returns an empty data set. PeeringDB absence is not proof of weak engineering. Many small providers rely on upstream transit and do not maintain public exchange profiles. Still, it removes one common independent place where operators publish facility presence, traffic levels, peering policy, NOC contacts and exchange connections. For CloudTeknoloji, the visible public data says "real routed AS, one current IPv4 /24, valid route authorization, no visible IPv6 origin, no public peering profile."

That is a medium evidence grade, not a negative one. The network is visible and current, but it leaves the customer to request private proof for multi-site capacity, transit diversity, spare host capacity and recovery path design.

The rack boundary is Istanbul, not a placeless cloud

The company's own facility language is precise enough to shape the risk conversation. The about page says the systems are managed from an operation center in Istanbul 4. Levent and hosted in the Istanbul-located ICS Datacenter, described as PCI/DSS certified and Tier III standard. It also claims more than 100 Gbps of redundant internet access capacity, operator-independent fiber, fully redundant UPS and energy systems, A+B dual power feed, physical security and cooling. The service policy repeats the location claim more simply: daha.net servers are hosted in Istanbul's ICS Datacenter, Tier III.

That turns the marketing word "cloud" into a place. The customer's service depends on racks in Istanbul, a facility operator, power distribution, cooling, cabling, cross-connects, switch ports, transit sessions, storage, hardware inventory and people who can perform repairs. Some of these may be directly controlled by CloudTeknoloji. Some sit with ICS Datacenter or upstream carriers. The public pages do not disclose which racks are leased, which equipment CloudTeknoloji owns, how much of the facility capacity is reserved for daha.net, or whether the same products can fail over to another Turkish city or another country.

The distinction is important for data locality. CloudTeknoloji's offer is attractive to Turkish customers partly because it appears to keep hosting and server capacity in Turkey. The VDS page advertises Istanbul location, VMware ESXi virtualization and SSD-backed VDS packages. The Pro Cloud page advertises Istanbul location again, with Xeon Gold 6138 processors, managed support and NVMe SSD storage. The hosting page advertises Istanbul-location hosting, Linux LiteSpeed, Windows IIS, free SSL and weekly backups. RIPEstat geolocation data for 46.28.232.0/24 also places the public prefix in Turkey at the time checked.

But locality is not the same as resilience. A Turkish facility can meet a customer's jurisdiction, latency or language-support requirements and still leave that customer exposed to one-site failure. If the main hosted service, backup copy, support portal and customer DNS all depend on the same campus or the same carrier handoff, the customer has local control but limited independence. A stronger continuity claim would name a second site, a tested restore location, a separate administrative domain, a defined recovery-time target and a clear export path.

The service catalogue sells layers, not just servers

daha.net's product range is broader than a narrow VPS shop. The commercial-information page says the company operates in web hosting, cloud server, domain registration, SSL certificates, email and related IT services. The navigation and product pages show the same breadth: standard VDS cloud servers, managed Pro Cloud servers, web hosting, WordPress hosting, reseller hosting, corporate hosting, domain services, SSL certificates, control-panel licenses, Microsoft 365, bulk email and server-maintenance services.

That breadth is commercially useful. A small business can buy domain, hosting, email, certificate, VPS and support from one provider. An agency can keep client domains and sites under one account. A Turkish e-commerce site can choose Istanbul-hosted infrastructure and Turkish-language support instead of learning a hyperscale console. A customer that has outgrown shared hosting can move to VDS or managed Pro Cloud without changing brand.

The same breadth also makes dependency harder to inspect. Domain registration depends on registry and registrar channels. Email may depend on outside platforms as well as local DNS and support. SSL depends on certificate authorities and validation timing. VDS depends on hypervisors, storage and network. Managed cloud depends on staff access and change discipline. Server maintenance depends on the skills and availability of engineers. A bundled invoice can make all of these feel like one service, while the fault chain still crosses several operators.

CloudTeknoloji's public pages do a decent job of naming some technical ingredients. The VDS page advertises VMware ESXi, SSD storage, full root access, Intel Xeon E5-2695 V4 processors and package sizes from smaller two-core machines up to six-core, 8 GB RAM and 80 GB SSD tiers. The Pro Cloud page advertises Xeon Gold 6138, NVMe SSD, allocated resources, managed service, security updates, optimization and technical follow-up. The hosting page advertises Linux LiteSpeed, Windows IIS, NVMe SSD, cPanel or Plesk and weekly backups. These are not empty buzzwords. They identify product families and some hardware classes.

Yet the public information stops before the hardest capacity questions. How many physical hosts support each plan family? What is the oversubscription ratio? How many spare nodes can absorb one host failure? Are VDS storage systems local, shared, replicated or backed by snapshots? Does the Pro Cloud tier run on different hosts from standard VDS, or simply on a higher resource class with managed support? Are backup repositories outside the production storage layer? Can a customer export a VM image, or only files and control-panel backups?

Those questions decide whether a sold plan is comfortable only during normal days or durable during repair days.

The route now appears to depend on the ICS side of the facility

The public routing path points to the facility/operator boundary. The RIPE database aut-num record for AS202048 contains import and export policy lines for AS48678, AS42910 and AS214588. However, RIPEstat AS-routing-consistency shows a difference between recorded policy and observed routing: AS214588 is in BGP and in the policy data, while AS48678 and AS42910 appear in policy data but were not observed in BGP at the sampled time. RIPEstat ASN-neighbours data also reported one unique left-side neighbour, AS214588, for the latest available time.

AS214588 is not an unrelated random hop. RIPE's AS214588 record names it as icsteknoloji, and RIPEstat's AS214588 overview gives the holder as ICS Bilisim Teknolojileri Danismanlik Hizmetleri A.S. The AS214588 policy data shows upstream relationships with Turkcell/Superonline, Turk Telekom and Vodafone. The BGP-state sample for 46.28.232.0/24 likewise shows global paths reaching AS202048 through AS214588 in the sampled routes.

This does not prove CloudTeknoloji has no private backup link, no dark-fiber path and no out-of-band recovery. Public BGP collectors only show what is globally visible at a time. But for a customer buying hosted capacity, the current public path is still meaningful. If AS202048's public internet service is currently reached through AS214588, then facility and upstream coordination with the ICS side is part of CloudTeknoloji's operating surface.

A routing error, commercial dispute, cross-connect fault, DDoS mitigation issue, power event, carrier failure or misconfigured handoff on that path can affect CloudTeknoloji customers even if their VM is healthy.

The practical question is transit diversity. CloudTeknoloji's own company page claims operator-independent fiber and 100 Gbps-plus redundant internet capacity for its infrastructure. That is a strong claim, but the public AS view shows one observed neighbour at the CloudTeknoloji edge. These two statements can coexist if the underlying facility has multiple carriers while CloudTeknoloji's own AS currently uses the ICS network as the public transit handoff. They can also coexist if backup options are reserved for facility use, private circuits or manual failover rather than being visible as simultaneous BGP sessions.

The customer should ask which interpretation applies.

For critical services, the answer should be contractual and technical. Customers need to know whether their public IPs remain reachable through a second upstream if AS214588 is impaired, whether there is automatic route failover, whether DDoS filtering depends on the same path, and whether DNS, management panels and support portals remain reachable if the primary AS202048 route is withdrawn. Without those answers, the public evidence supports a cautious view: the current route is real, cleanly authorized and visible, but externally concentrated.

Hosted capacity is sold as instant, but repair is not instant

The VDS page emphasizes fast setup and easy resource increases. It says cloud servers use VMware ESXi virtualization, SSD storage, full root access and isolated resources, and it advertises resource upgrades through the customer panel. The Pro Cloud page goes further, selling managed service, allocated resources, Xeon Gold processors and NVMe SSD for heavier sites, SaaS, agencies, e-commerce and high-traffic projects. This is the customer promise: take a server without owning a server.

The operating reality is slower. A virtual server may be created in minutes, but the physical substrate still fails in hours. Disks fail. RAID rebuilds consume I/O. Hosts require firmware updates. Switch ports misbehave. Hypervisors need patching. Backup jobs miss windows. A storage pool can be full even when an account page says the plan is active. A public cloud word does not remove the parts bin.

The service policy is useful because it admits some of this friction. It says credit-card-paid accounts can activate within a few minutes, but services beyond hosting and domain registration - including cloud servers, licenses, SSL certificates and bulk mail - can take up to eight hours to install or deliver outside business hours. It says bank transfer orders require payment notice and checks. It says unpaid hosting and cloud server services are removed from servers after 30 days. It also says Cloud Servers use a 10 Mbit shared pool unless the customer leases a line for a different limit.

Those details do not make the product bad. They make it finite. "Instant" is a sales experience for the common path. Delivery outside staffed hours, capacity upgrades, custom software installation, line changes and delinquent accounts have different rules. A customer planning a migration onto CloudTeknoloji should not assume that every resource change, licensing addition or bandwidth exception is automatic.

It should ask whether the plan's default bandwidth is enough, whether the paid option changes only rate limit or also route priority, whether IP renumbering is required for line changes, and whether resource increases have host-level constraints.

The 10 Mbit shared-pool language is especially important. Many VDS buyers think first about cores, RAM and disk. Network throughput often becomes visible only when a site is attacked, a backup restore runs, an e-commerce campaign begins or a media file must be distributed. A 10 Mbit shared pool can be sufficient for quiet business sites, but it is not a substitute for a tested high-throughput recovery path. If a customer expects to restore hundreds of gigabytes quickly or serve large traffic bursts, the network rate rule belongs in the design discussion before the order is placed.

Support commitments are visible, but they are not all the same

daha.net publishes several support statements, and they should be read together rather than selectively. The service policy lists phone support on weekdays from Monday to Friday, 09:00 to 17:30, accounting support on weekdays during the same window, and technical email support as seven days, 24 hours, with a 60-minute response guarantee. Later in the same policy, the customer-support section says daha.net commits to respond within 60 minutes during working hours and within eight hours outside working hours. The about page and contact page also refer to weekday phone availability and continuous email or support-ticket access.

The nuance matters. A response is not the same as repair. A response can confirm receipt, identify the affected service, ask for credentials or say a provider has been contacted. Repair may depend on facility staff, upstream engineers, hardware stock, a vendor license, a customer's own administrator or a domain registry. For routine hosting support, a 60-minute response may be good enough. For a downed e-commerce checkout, mail outage, inaccessible ERP, compromised server or failed database restore, the customer needs escalation terms, not just first-response terms.

CloudTeknoloji's support story is stronger than a no-contact budget host because it publishes phone numbers, support emails, a ticket path, business address, KEP address and written terms. The risk is that the same published terms also show natural limits: phone coverage is not 24-hour, some non-core service delivery can wait outside business hours, and outside-hours response timing is described in two ways.

A buyer should ask which clause controls its specific product, whether managed Pro Cloud gets different escalation from unmanaged VDS, whether emergency response includes facility-level intervention, and whether there is a named severity system with time-to-repair targets.

Staffing also intersects with migration. The VDS page advertises free migration support, including moving websites and databases without data loss or service interruption. That is valuable if true in a customer's case, but it should be scoped. Moving a cPanel website is not the same as moving a custom application, Windows server, live database, mail archive, DNS zone, DNSSEC setup, firewall allowlist, cron jobs and third-party integrations.

Customers should ask what "free migration" covers, what must be prepared by the customer, whether migration is scheduled, whether rollback is included, and how long the old site must remain live.

Maintenance windows are explicit and large enough to matter

The maintenance clause is one of the clearest signs that CloudTeknoloji's cloud is still ordinary infrastructure. The service policy says that when server maintenance, moving or hardware updates are needed, customers are warned one week, three days and one day before interruption. It says such interruptions will not exceed a total of 96 hours in a year and will not be done during business hours unless necessary. It also excludes force-majeure liability for late, incomplete or non-performance.

Ninety-six hours per year is not an outage target; it is a maintenance ceiling as written in the policy. Even so, it is a meaningful customer planning number. A business that reads only the hosting page's uptime language may expect near-continuous service. A business that reads the policy sees that planned infrastructure work can consume a significant number of hours across a year. That may be acceptable for low-risk sites, development environments, small business brochures or non-critical local applications.

It is not enough for a customer whose order intake, call center, payment flows or clinic systems must run through every maintenance night.

The important question is how maintenance is isolated. Can one host be drained while workloads continue elsewhere? Are VDS customers live-migrated between hosts? Does storage maintenance require downtime? Are network maintenance events redundant at the switch or transit layer? Can Pro Cloud customers buy higher availability than standard VDS? Are backup restores tested after hardware replacement? Does the one-week, three-day, one-day notice apply to all maintenance or only expected downtime? The policy provides the public alert pattern, but the customer needs architecture details.

This also affects agency and reseller customers. If a reseller hosts dozens of client sites on daha.net, one maintenance event can become dozens of client emails. If a managed service provider uses daha.net as a Turkish VPS layer, a repair night can affect all downstream customers. If an e-commerce operator has a campaign scheduled, the maintenance notice must be compatible with freeze windows. Hosted capacity becomes a shared calendar, not just a resource graph.

Backup language is useful because it is not overly comforting

daha.net's backup language is more honest than many hosting pages, and it should be read carefully. The hosting and VDS product pages advertise weekly backup or periodic backup features. The service policy gives the harder rule: hosting servers are backed up weekly and monthly, server services are not backed up unless the customer buys backup service, backups may be defective or unusable, no guarantee is given to customers from those backups, and account backup is the customer's responsibility. It also says that when a customer needs a daha.net-taken backup, the company may provide an available backup at its discretion, depending on the backup system.

That language should push customers away from magical thinking. A backup label on a hosting plan is not the same as a guaranteed restore service. For shared hosting, weekly and monthly backups may help with accidental deletion or site failure, but the policy disclaims guaranteed recovery. For VDS and server services, the policy says backup is not included unless purchased. For critical workloads, the buyer should assume it needs its own tested backup plan until written terms say otherwise.

The difference between "backup exists" and "restore works" is central to this company. CloudTeknoloji sells hosted capacity, but the customer may still own data protection. A WordPress site can be backed up at the application level to an outside storage account. A VDS can snapshot to a separate region. A database can stream replicas or dumps to a second provider. DNS can be hosted with a separate operator. The customer can lower risk by making CloudTeknoloji the primary host without making CloudTeknoloji the only place where data exists.

The customer should ask five backup questions before using daha.net for anything important. First, is backup included for this exact product, or must it be purchased separately? Second, where is the backup stored relative to the primary ICS-hosted system? Third, how often is a restore tested? Fourth, who has encryption keys and admin rights? Fifth, how long would a full restore take at the default network rate? The public policy answers part of the first question and warns that the others matter.

Billing, cancellation and data deletion are part of uptime

Infrastructure articles often focus on routes and racks, but CloudTeknoloji's terms show that commercial state can be just as important. The service policy says orders unpaid for seven days are automatically cancelled. It says hosting and cloud server services that are not renewed are completely removed from servers one month after the renewal period. It says service cancellation deletes the account together with backups. It also restricts refund eligibility for some add-ons, licenses, domains, SSL and other services, and says Cloud Server refund eligibility can disappear if the technical team installs add-ons or software at the customer's request.

For a consumer website, these terms may be routine. For a business workload, they are a dependency. A payment card failure, invoice dispute, procurement delay or change of staff can turn into data deletion if renewal is not controlled. A customer moving away from daha.net must export files, databases, DNS, mailboxes, certificates, keys, licenses and server images before cancellation or non-renewal. A customer that relies on backups for rollback must understand whether those backups disappear with the account.

This is where hosting economics meets risk. A bundled local provider can be cheaper and easier than building redundant infrastructure from scratch. But cheaper hosting often pushes some operational responsibility back onto the customer: renewal discipline, backups, migration preparation, storage of credentials, domain-lock management, DNS TTLs and off-provider restore copies. The customer should have a departure plan on day one, not after an incident.

The departure plan is simple in principle. Keep registrar access independent where possible. Keep DNS exports. Keep off-platform backups. Know which IP addresses are tied to allowlists. Keep a current list of SSL certificates and renewal dates. Test restoring a site to another provider. Keep email continuity outside a single web-hosting account if mail is critical. None of this means avoiding CloudTeknoloji. It means using it as a provider, not as the only copy of the business.

Data sovereignty is a real selling point with a recovery tradeoff

For Turkish customers, local hosting can be valuable. It can reduce latency to domestic users, simplify language and tax support, keep contracts under familiar jurisdiction, and support data-locality preferences. CloudTeknoloji's official pages lean into that local profile: Istanbul offices, Istanbul facility, Turkish support, Turkey-only order acceptance in the policy, Turkish legal identity, KEP address and a service set aimed at local hosting, domains and business email. The geolocation view for 46.28.232.0/24 also aligns the visible public prefix with Turkey.

Locality, however, can concentrate risk if it is not paired with independent recovery. A customer that must keep data in Turkey may still need a second Turkish site, a second provider, a second backup account or at least a separate DNS and restore arrangement. A customer that can use an overseas recovery copy may get easier geographic separation but must consider legal, privacy and contractual limits. CloudTeknoloji's public pages do not resolve that tradeoff. They show a Turkey-centered provider. They do not publish a full multi-site recovery architecture.

The right conclusion is not that Turkish-local hosting is weak. It is that sovereignty and resilience are separate design goals. The first asks where data lives and which law applies. The second asks whether a customer can continue after a site, route, storage, staff or account failure. CloudTeknoloji may help with the first by keeping services in Istanbul. The customer must still verify the second.

This is especially true for customers with regulated, reputational or revenue-sensitive workloads. A school, clinic, agency, e-commerce shop or professional office may choose daha.net because the support desk speaks the same language, the legal entity is reachable, and the server sits in Istanbul. That is rational. But if the same service is also the only DNS host, only mail host, only backup location and only route to support, then a local advantage becomes an operational single point. The fix is not abstract: separate backup, separate DNS, documented failover, tested restore and written escalation.

Who is affected when this system fails

The first affected group is shared-hosting customers. These are the users most likely to feel platform limits but least likely to understand the facility behind them. A shared-hosting failure can take websites, mailboxes, databases, control panels and SSL renewal paths offline at once. The customer may not have root access or direct backup control. The service policy's backup disclaimers therefore matter most to the least technical customers.

The second group is VDS and Pro Cloud customers. They have more control, but they also inherit more responsibility. An unmanaged VDS customer has root access and can build its own stack, but operating system updates, application security, database backup and restore planning may sit with the customer. A managed Pro Cloud customer may get more help, but should still confirm exactly which layers are managed, which are best-effort support and which remain customer-owned.

The third group is agencies and resellers. They turn one upstream provider into many downstream promises. If they buy reseller hosting, VDS capacity or managed servers from daha.net, their own clients may see the agency as the operator. A daha.net maintenance window, support queue or route issue becomes an agency incident. These customers need status updates, client communication templates, migration backups and clear service boundaries before trouble starts.

The fourth group is domain and email customers. Domain expiry, transfer limitations, DNS errors and mail routing failures can outlast a web outage. The service policy describes domain-renewal notices, automatic renewal, restore periods and transfer conditions. Customers who place domain, DNS, hosting and mail under one account get convenience. They also put renewal, credentials and support escalation in one place. Separating ownership access from hosting control can reduce that risk.

The final affected group is CloudTeknoloji itself. A small public AS and a concentrated route do not automatically mean operational weakness, but they do mean each public incident can carry reputational weight. If customers see the brand as a local reliability partner, they will expect clear notices, honest status pages, fast repair updates and practical migration help. The public service policy already acknowledges maintenance notices and support response. The next maturity signal would be transparent incident history and product-specific recovery terms.

What would settle the open questions

The public record is enough for a cautious profile, but not enough for a high-confidence resilience assessment. Five additional disclosures would materially change the grade.

First, CloudTeknoloji could publish or provide under contract a facility and ownership boundary: which services run in ICS Datacenter, which are CloudTeknoloji-owned hardware, which are leased capacity, and which rely on third-party vendors. Second, it could publish product-specific backup terms: included backups, paid backups, retention, offsite location, restore time, restore testing and customer responsibility. Third, it could state transit design for AS202048: current upstreams, failover behavior, DDoS handling, IPv6 availability and whether AS48678 or AS42910 remain available backup options or only historical policy lines.

Fourth, it could provide maintenance and emergency commitments by product tier, distinguishing response from repair. Fifth, it could document exit rights: VM exports, control-panel backups, DNS zone export, domain transfer support, IP portability limits and account-deletion timing.

Some of these details may already exist in customer contracts or sales proposals. The issue is public verifiability. From the outside, the company has a stronger identity footprint than many hosts, a live and authorized route, and a coherent Istanbul hosting story. It also has a small visible public network, no visible IPv6 origin, an observed upstream path through ICS, and service terms that place meaningful backup and renewal responsibility on the customer.

The buyer's job is to match workload criticality to that evidence. A low-risk brochure site, small WordPress site, local business mail setup or development VPS may fit comfortably. A high-traffic storefront, regulated data store, public emergency service, payment-critical application or multi-client reseller platform should require written redundancy and restore evidence before moving production.

Bottom line

CloudTeknoloji Cloud Teknoloji Bilisim Hizmetleri ve Ticaret A.S. deserves neither dismissal nor blind trust. The company behind daha.net is identifiable, has operated under a visible Turkish commercial identity, publishes contact and legal information, sells a broad hosting catalogue, claims Istanbul facility hosting and carries a live public AS. The public route for AS202048 is announced, visible to collectors and covered by a valid RPKI authorization for 46.28.232.0/24.

The caution is that the public footprint is narrow. One visible IPv4 /24, no visible IPv6 origin, no public PeeringDB profile and one currently observed AS neighbour do not prove broad redundancy. The official service terms also remind customers that cloud servers, backups, maintenance, support hours, bandwidth and renewal state have limits. In plain terms, CloudTeknoloji sells hosted capacity that can be valuable for Turkish businesses, but that capacity still depends on racks, transit, power, hardware replacement, staff response and a customer's own backup and migration discipline.

The right buyer posture is practical: use the local provider when its Istanbul hosting, Turkish support and bundled services fit the workload, but make the provider show the recovery path. Ask where the data sits, where the backup sits, which route fails over, how repairs are escalated, how fast a full restore can run, what happens after non-renewal, and how the customer leaves cleanly. Until those answers are written and tested, the public evidence supports a medium-confidence infrastructure profile: real operation, limited public network depth and recovery questions that matter more than the word "cloud."