Together-Communications-LTD-CLOUD-NETWORK Together Communication LTD sells hosted capacity that still depends on racks, transit and repair windows

Summary

• Together Communication publicly markets Together Cloud, shared hosting, VPS and dedicated-server hosting, colocation, fixed addresses and protection services. It says customer equipment can be placed in the company's data centres, but it does not publish the sites, power design, rack inventory, storage architecture, recovery objectives or standard service levels behind that offer.
• AS34008 carries the precise registered name Together-Communications-LTD-CLOUD-NETWORK and belongs to Together Communication LTD's RIPE organisation. RIPEstat marked it unannounced on July 12, 2026, with no current prefixes or observed neighbours; the last widely observed route originated from it on January 15, 2019.
• The same registered organisation also holds AS42013, a separate and active network. RIPEstat observed 13 IPv4 prefixes, one IPv6 prefix, 5,120 IPv4 addresses, full visibility among reporting peers and four current neighbours. This is strong evidence that Together operates a live regional network, but it does not prove that every Together Cloud workload runs on AS42013 or in any particular facility.
• PeeringDB and the Palestine Internet Exchange show AS42013 connected at PSIX in the MTIT Building 01 in Ramallah on a 1 Gbps port. Public route observations also show paths through AS8551 and AS1680. Those facts support live connectivity; they do not establish diverse data-centre sites, physically separate fibre entrances or enough failover capacity for hosted customers.
• Network operating evidence for Together Communication as a whole is Medium. Evidence for the assigned AS34008 cloud-network surface is Negative, and confidence in the resilience of the customer-facing cloud is Weak. Buyers need named facility locations, asset ownership, power and carrier separation, tested restores, support escalation and export terms before treating the service as recoverable rather than merely reachable.

The offer is concrete; its failure domains are not

Together Communication's business-services page is unusually direct about the products it wants businesses to buy. It lists Together Cloud, shared hosting, virtual private servers, dedicated servers, colocation, fixed IP addresses, protection services, communications systems and SMS connectivity. Shared hosting is presented with DirectAdmin, while the cloud description names "NOD Controllers" and "VM NSX". The colocation offer says customers can rent space in the company's data centres for their own equipment and receive fast connectivity and public addresses.

That is enough to identify a real infrastructure proposition. It is not a generic consultancy page that only promises digital transformation. Shared hosting requires web and mail software, storage, name service, certificates and account administration. A VPS requires a virtualisation host, memory, CPU scheduling, network interfaces and persistent disks. A dedicated server requires a physical chassis and a replacement path when a component fails. Colocation requires rack units, power distribution, cooling, access control, cross-connects and someone authorised to touch a customer's machine.

Fixed addresses require address management and continued route availability.

The page does not disclose the physical map beneath those products. It uses the plural "data centers" but does not name them. It does not say whether the facilities are owned, leased or supplied by another operator. There is no public count of racks, power feeds, generators, batteries, carrier entrances or available server stock. There is no stated distinction between a primary site and a recovery site. Nor is there a public service-level schedule that turns "reliable" into a measurable availability target, response window or remedy.

This gap is not a verdict that the service fails. It is the reason the service must be evaluated from the bottom up. A customer does not recover from a cloud outage by pointing to the word cloud. Recovery comes from a surviving copy of the data, compatible compute, reachable routes, working credentials, enough spare capacity and staff who can make the change. Together may have those capabilities. Its public pages do not demonstrate them.

The distinction is especially important for a regional provider. A local operator can offer valuable advantages: Arabic-language support, nearby engineers, local commercial relationships, short escalation paths and the possibility of keeping workloads close to users. Those strengths can be more useful to a Palestinian small business than a long catalogue of distant hyperscale services. But proximity also concentrates risk if the primary platform, backup copy, transit handoff and support team share one city, one building or one provider contract.

Two ASNs describe different operating surfaces

The most revealing public evidence begins with an apparent contradiction. The assigned company name includes CLOUD-NETWORK, and AS34008's registry record links that exact name to Together Communication LTD. The record identifies the company organisation as ORG-TCL42-RIPE, gives Palestine as the country and shows the ASN as assigned from May 2015. Yet the same page reports zero IPv4 and zero IPv6 routes.

RIPEstat provides a more precise current view. Its AS34008 overview marked the network as not announced on July 12, 2026. The announced-prefixes view returned no prefixes for the preceding two weeks. The routing-status view showed no announced address space, no observed neighbours and no visibility among reporting IPv4 or IPv6 peers. Its last widely observed route was 185.99.44.0/22 on January 15, 2019.

Historical data shows that AS34008 was once operationally meaningful. RIPEstat's long-range prefix history records Together-related prefixes appearing from May 2015 through January 2019. These included parts of 185.99.44.0/22 and, for a period, 185.61.20.0/22. The record therefore looks like a retired or dormant routing surface, not an ASN that was merely reserved and never used.

The registered routing policy for AS34008 also names several intended connections. It contains import and export statements involving Palestinian and Israeli networks, including AS42013. Those statements describe policy entities, not live sessions. They were last materially updated years before publication and conflict with the absence of visible routes. A buyer should not count a listed policy as an available path until current route observation or an operator test confirms it.

Together has another ASN. The RIPE membership entry names Together Communication LTD in Ramallah and lists Palestine as its service area. The same organisation handle appears on AS42013, which is registered under the simpler name Together-Communication-LTD. On July 12, RIPEstat's AS42013 overview marked that network announced.

The contrast is sharp. AS34008 had no current routes. AS42013's routing status showed 13 IPv4 prefixes covering 5,120 addresses, one IPv6 prefix, and visibility from every reporting IPv4 and IPv6 RIPE RIS peer at the measured time. Its announced-prefix list included 2.58.132.0/22, 185.61.20.0/22, 185.99.44.0/22, 185.209.108.0/22, 91.229.247.0/24, 194.5.235.0/24, 212.47.82.0/23 and 2a0b:4d40::/29, along with more-specific routes.

This is strong evidence that Together Communication operates a live network. It is not permission to erase the distinction between the two ASNs. An ASN can separate products, routing policies, eras or administrative functions. Address space once originated by AS34008 may later originate through AS42013 without every server moving. A cloud brand can use the active network while retaining an older ASN name in public records. It can also rely on third-party infrastructure. Public BGP observations cannot choose among those explanations.

The correct conclusion is narrow: the organisation behind the assigned entity remains visibly active through a separate ASN, while the precise AS34008 surface is dormant in the global routing table. Customers should ask Together which ASN now carries Together Cloud, which prefixes contain hosted workloads, and whether AS34008 is retained for future use, legacy administration or another purpose. A clear answer would resolve an ambiguity that routing data alone cannot.

A live company website is an operating signal, not a cloud audit

Together's public domains add another piece of evidence. At publication, together.ps resolved to 185.209.108.171 and together-pal.com resolved to 185.209.108.18. Both addresses sit within 185.209.108.0/22, one of the blocks originated by AS42013. The public website therefore uses Together-routed address space. That is a direct sign that the active network carries at least one company service.

The signal has limits. A website address does not reveal whether customer VPS instances occupy the same platform. It does not show whether the web server is physical or virtual, whether it is in a Together rack or a supplier rack, or whether the site has a replica. It says nothing about the number of paying hosting customers or the condition of their backups. It proves reachability of a public endpoint, not the design of the commercial cloud.

The website also illustrated why small operational details matter. On July 12, its HTTPS endpoint presented a wildcard certificate for *.together.ps whose stated validity ended on June 24, 2026. Standard clients rejected the connection because the certificate was no longer valid, even though the web server still returned the site when certificate checking was bypassed. This is a time-bounded observation and could be corrected at any moment. It should not be inflated into a judgment about the entire platform.

It is nonetheless relevant. Certificate renewal is a modest but real reliability task. An expired certificate can make a working service look unavailable to users and automated clients. It can interrupt payment pages, administration portals, monitoring callbacks and software integrations. The event does not require a failed rack or fibre cut; it requires an ownership gap in a recurring maintenance duty.

For a hosting buyer, the practical question is not whether one public certificate expired. It is how expiry, domain renewal, name service and application secrets are monitored across customer services. Are warnings sent to a staffed queue rather than one person's mailbox? Can a second engineer renew a certificate? Are credentials available during an incident? Does the service distinguish infrastructure availability from application availability in its commitments? A rack can be powered and a route can be healthy while customers still cannot complete a secure connection.

Ramallah is visible; the cloud's physical placement is not

Several sources point to Ramallah as Together's operating centre. RIPE lists Neleen Main Street in Ramallah. Together's contact page gives the Al-Ramouni Building in Ramallah. Its company history says the business began as an initiative serving villages west of Ramallah, used Al-Midya as a main hub, and later expanded fibre and wireless coverage across more areas.

The clearest independently visible facility association belongs to AS42013's exchange connection. PeeringDB lists Together at the Palestine Internet Exchange, or PSIX, on a 1 Gbps port, with IPv4 address 185.153.162.4 and IPv6 address 2a07:8780:ffff:1::4. It places that connection at MTIT Building 01 in Ramallah. The PSIX member list independently shows AS42013 with the same exchange addresses and 1 Gbps capacity.

This establishes a network presence at a named interconnection location. It does not establish that Together's customer servers are in that building. An exchange port can be reached directly from equipment in the facility or through transport from another site. A network may peer in one building while hosting compute elsewhere. Conversely, a company can place both routing and compute in the same facility. The public records do not say which arrangement applies.

The distinction matters because a place name is not a failure-domain map. If the cloud platform and PSIX connection are in one building, a power, cooling, access or building incident could affect both local hosting and local interconnection. If they are in separate sites connected by fibre, the fibre path and transport equipment become dependencies. If backups sit in a second room in the same building, they protect against disk failure but not against loss of the site.

The Internet Society's IXP tracker reported 20 PSIX members and 56 Gbps of total member capacity in May 2026. This indicates a meaningful local exchange, not an isolated two-network link. Local peering can keep suitable traffic within Palestine, reduce dependence on international transit for those destinations and improve latency. The Ministry has likewise described PSIX as a way to connect local networks more directly and reduce international-line costs.

An exchange is not an emergency substitute for the entire internet. A customer website still needs routes to users and services that do not peer locally. Software repositories, remote backup destinations, payment providers, certificate services and global customers may all require upstream transit. PSIX can improve the local path while international connectivity remains a separate dependency.

Together should therefore be able to answer two location questions separately. Where do production compute and primary storage run? Where do routing and exchange handoffs run? The answer should include the recovery copy, not just the primary rack. Without that map, "hosted locally" may describe legal geography while concealing a single physical failure domain.

Transit diversity is visible at the routing layer, but not the duct layer

RIPEstat's AS42013 neighbour view showed four observed neighbours on July 12. AS8551 and AS1680 appeared on the provider side of paths, while AS12975 and AS47546 appeared on the customer side. The registered AS42013 policy also names AS8551 and AS1680 as networks from which it accepts routes. This supports the presence of more than one external path at the BGP layer.

The two visible provider networks are operated by Bezeq International and Cellcom Fixed Line Communication respectively. Their presence matters because Palestinian internet connectivity has long operated under unusual geographic and regulatory constraints. The World Bank's Palestinian Digital Economy Assessment describes restrictions affecting equipment imports, spectrum and infrastructure deployment. Those conditions can influence hardware lead times, route options and the speed with which damaged or obsolete equipment is replaced.

Two provider ASNs do not automatically equal resilient transit. They could enter the same building through the same conduit. They could share a long-haul segment. Both sessions could terminate on one edge router, one switch or one power feed. One path could be a low-capacity backup unable to absorb normal demand. Routing policy might also prefer one provider so strongly that failover works outbound but not inbound.

PeeringDB's Together entry gives the whole network a self-reported traffic level of 10-20 Gbps and calls its traffic balanced. It also lists 5,000 IPv4 prefixes and 500 IPv6 prefixes, figures that do not align naturally with observed routing and appear to use a different meaning from globally announced prefixes. The page's general network details were last updated in 2022, while parts of the peering information were updated in 2023. These fields should be treated as operator-supplied profile data, not current audited capacity.

The 1 Gbps PSIX port is more concrete, but it is only one port at one exchange. It cannot carry 10-20 Gbps by itself. That is not a contradiction if most traffic uses paid transit and only local traffic uses PSIX. It does show why capacity must be measured per path. A total traffic band says little about what remains usable when one upstream, router, cross-connect or exchange port fails.

A credible transit review would ask for the committed and physical rate of each handoff, the normal and peak utilisation, the expected reconvergence time and the result of the last failover exercise. It would ask whether the carriers use independent entrances and whether they remain independent beyond the building. It would also ask whether support and monitoring can reach the platform through a separate management path when customer traffic is disrupted.

Routing security deserves a similarly bounded reading. Several AS42013 prefixes have valid Route Origin Authorisations, and the active IPv6 route is visible broadly. RPKI validation helps participating networks reject an unauthorised origin. It does not prevent a correctly authorised router from advertising the wrong more-specific route, nor does it keep a powered-off edge online. It is one control in the route layer, not a statement about servers, storage or staffing.

"Capacity" needs a unit, a location and a failure condition

Together's about page says the company grew from a 30-megabyte data service to more than 100 gigabytes of "data capacity". The language does not identify whether this means a rate, a volume, traffic carried in a period or something else. The page also displays claims of more than 77 towers, more than 300,000 users, more than 89 companies and service across 17 cities.

These figures describe ambition and scale in the access business. They do not provide a usable measure of hosted compute. A VPS customer needs to know available CPU, memory, storage performance and network throughput. A colocation customer needs power per rack, permitted heat load, cross-connect availability and space for growth. A backup customer needs retained capacity, copy frequency and restore bandwidth. A number without a unit and a failure condition cannot answer any of those questions.

Installed capacity and usable capacity are different. A platform may have 100 physical cores but reserve some for the host, replication and failover. A storage array may have a large raw total but lose substantial space to mirroring, parity, snapshots and free-space requirements. A 10 Gbps uplink may be shared by many tenants, limited by an upstream commit or bottlenecked by a firewall. A second site may exist but have too little spare compute to absorb the primary site.

The most useful capacity figure is what can still be delivered after the largest credible failure. If one host fails, can every affected VPS restart elsewhere without evicting another workload? If a storage controller fails, does the surviving controller maintain the required input/output rate? If one transit provider disappears at the busiest hour, can the remaining links carry production and replication traffic? If the primary site is unavailable, which services are restored first and which wait for hardware?

This is also where hosting economics becomes physical. Keeping spare servers, disks, power supplies and optics idle costs money. Reserving failover capacity lowers average utilisation. A second site adds rent, power, transit and staff access. Many providers therefore sell a base service that protects against common component failures while charging separately for stronger recovery. That is reasonable if the boundary is explicit. It becomes dangerous when a customer assumes "cloud" includes site-level continuity that the price never funded.

Together publishes no standard instance catalogue, oversubscription policy or recovery tier. A customer should ask for those terms before comparing price. The cheapest monthly VPS can be appropriate for a replaceable web front end. It is not automatically suitable for the only copy of an accounting system, patient record, municipal service or retailer's order history.

Racks turn software promises into repair obligations

Every Together Cloud product eventually reaches a physical component. A virtual machine runs on processors and memory. Its disks depend on storage devices and controllers. Network traffic crosses interface cards, switches, optics and routers. All of those devices depend on power, cooling and firmware. Virtualisation changes how resources are allocated; it does not abolish hardware failure.

The company does not publish a hardware inventory or sparing policy. That leaves a practical question for each product. For shared hosting, can an account be restored on another server, and how long does that take? For a VPS, does high availability restart the machine on another host automatically, or is replacement manual? For a dedicated server, is there a matching spare chassis, or must a component be ordered? For colocation, does Together stock only network parts, leaving the customer responsible for its own server hardware?

Import conditions make this more than a theoretical procurement issue. The World Bank has repeatedly identified restrictions on ICT equipment as a constraint on Palestinian digital infrastructure. A failed drive or power supply is a short incident if an approved spare is on the shelf. It can become a much longer outage if the part must cross a constrained supply chain, if the exact model is unavailable, or if a replacement requires a maintenance window and customer approval.

Spare stock also ages. Drives held too long may not match the firmware or capacity of an array. A replacement motherboard may require a different processor revision. An optic that fits mechanically may not be accepted by a switch. Good operators therefore track compatibility, test stock and plan lifecycle replacement before equipment becomes difficult to support.

Remote hands are the human half of the rack. Someone must identify the correct chassis, follow access rules, move a cable without disturbing the adjacent tenant and record the change. In a small regional operation, a few experienced engineers may hold much of that knowledge. The service is stronger when rack maps, labels, console access and change records allow another authorised person to act safely.

Uptime Institute's 2024 outage analysis found that power remained the most common cause of serious and severe data-centre outages, while network problems were the largest single cause of IT-service outages. It also reported that many serious incidents could have been prevented through better management, procedures and configuration. Those global findings do not describe Together specifically. They show why a hosting review must cover maintenance and people alongside equipment counts.

Power redundancy must survive maintenance, not just a utility interruption

No public Together page describes utility feeds, uninterruptible power supplies, batteries, generators or fuel. The absence does not mean these systems are missing. It means customers cannot tell which power event the service is designed to survive.

A single UPS can bridge a short interruption but still be a single point of failure. Two UPS units help only if each can carry the required load and the downstream distribution remains separated. A generator provides longer autonomy only if it starts, has usable fuel, can be refuelled under local conditions and does not share a failed switchgear path. Dual power supplies in a server add little if both plug into one distribution unit.

Maintenance is the revealing condition. Can a UPS, generator, breaker panel or cooling unit be taken out of service without shutting down customer racks? Is maintenance announced, and does the customer know whether redundancy is temporarily reduced? Are batteries load-tested? Has the generator carried the actual facility load rather than only started without load?

Cooling has the same structure. A room can have multiple air-conditioning units but limited public evidence capacity after one is offline. A blocked airflow path can overheat one rack while room temperature looks acceptable. Dense compute or storage can exceed the design assumptions of an older room. Temperature and humidity alarms need a response path that works outside office hours.

For colocation customers, the power boundary should be written into the order. The provider controls facility supply and distribution; the customer may control equipment power supplies and in-rack layout. The contract should state the included power, allowable peaks, redundancy level, maintenance notice and remedy. Without these details, "rack space" conceals the resource most likely to determine whether the rack stays online.

Backup is not recovery until a workload has been restored

Together's public business page describes storage and hosting but does not publish a backup design. It does not say whether a VPS includes snapshots, whether shared-hosting accounts receive off-site copies, how long copies are retained, whether backups are immutable or how customers request a restore. There is no public recovery-point objective or recovery-time objective.

That omission affects the interpretation of every service. A snapshot on the same array can help reverse an accidental change but may disappear with the array. Replication can keep a second copy current, but it can also replicate deletion, corruption or ransomware. An off-site backup protects against loss of the primary facility only if the second location is independent and reachable. A customer-held copy improves provider-exit resilience but needs encryption, key custody and regular testing.

CISA's ransomware guidance recommends offline encrypted backups, regular restore tests and attention to cloud-provider responsibility. It also notes the value of separate environments and retained system images. That is general guidance, not evidence of Together's controls. It provides a useful benchmark for what a customer should ask.

The restore path should be tested at the right scale. Recovering one small file proves that a repository can return one entity. It does not prove a database can be restored consistently, a full VPS can boot, network rules can be rebuilt or all critical systems can return within the promised time. A site-level exercise should include identity, name service, certificates, firewall configuration, application dependencies and enough bandwidth to move the data.

Customers also need to know who initiates a restore. If the portal is unavailable, is there a telephone escalation? How is the request authenticated so an attacker cannot order a destructive rollback? Who decides which point in time is safe? Does restoration overwrite the only surviving copy? These are operational questions, not premium features.

A persuasive Together recovery claim would include the location and isolation of each copy, the age of the latest usable backup, the time taken by the last full restore and the capacity available at the recovery site. Until those facts are supplied, backup should be treated as an unverified option rather than an assumed property of the cloud.

Local hosting can improve sovereignty while increasing concentration

Data locality is a plausible reason to choose Together. A Palestinian business may want low latency to local users, local support, familiar contracting and a clear answer about where its records reside. Public agencies and regulated organisations may place particular value on keeping primary data within Palestinian jurisdiction.

The policy context reinforces that interest. The World Bank's assessment described a Palestinian government preference for a private cloud with data kept within its borders and a disaster-recovery location potentially abroad. A more recent government cloud-strategy notice places data sovereignty and operational resilience among the goals of a unified hosting strategy. These are public-sector plans, not requirements imposed on Together or proof that its services meet them.

Locality must be defined component by component. Production disks may be local while backups are abroad. Logs may be sent to a foreign security service. Email filtering, domain name service, software updates, monitoring and support systems may cross borders. A provider may administer a local server through services hosted elsewhere. "Data stays in Palestine" is therefore meaningful only when the contract identifies production data, replicas, backups, metadata, support access and deletion copies.

Locality can also raise concentration risk. If production and backup are kept close together to meet a strict location preference, the same regional power, connectivity or access event may affect both. A remote copy can improve disaster recovery while creating another legal and supplier boundary. There is no universal answer. The customer must decide which data can leave, under what encryption and control, and which failure matters most.

The absence of published site names makes this decision harder. Together should disclose at least the country and city of production, backup and management locations under confidentiality if necessary. It should identify any subcontractor that can store or access customer content. It should also state how data is erased from active systems, backups and retired media after termination.

Support depth is part of available capacity

Together presents itself as both network operator and service provider. That can simplify escalation because the same organisation can see the hosted server and the route carrying it. It can also place several responsibilities on the same engineers. A widespread access incident may generate calls from residential, business, hosting and colocation customers at once, precisely when network staff are busiest.

The contact page offers sales contact details, a web form and a public telephone presence. PeeringDB publishes a network-operations email for AS42013. These are signs of reachable support channels. They do not describe hours, severity levels, response targets, named escalation roles or staffing at night and on holidays.

Support promises should distinguish response from repair. An acknowledgement in 15 minutes does not mean a failed server returns in 15 minutes. The repair time depends on diagnosis, site access, spare parts, backup condition and the authority to act. A customer should ask when the clock starts, which events stop it and what remedy applies if the target is missed.

Knowledge concentration is another risk. Who can access the hypervisor, storage, routers, backup system and facility? Are at least two people authorised for each critical task? Are emergency credentials protected but available? Can another engineer rebuild a tenant network from documented configuration? Does the customer hold its own administrator credentials and encryption keys where appropriate?

The strongest support design also provides an independent communications path. If Together connectivity is down, a status page or hotline hosted on the same network may disappear with it. Customers need a number, external status channel or named escalation that remains reachable when the primary platform is not.

Billing and provider contracts can create outages without broken hardware

The physical stack sits inside a commercial stack. Together may own some equipment, lease rack space, buy transit, license virtualisation and control-panel software, and obtain domains or certificates from other suppliers. A missed renewal, disputed invoice or terminated contract can interrupt service even while every server remains healthy.

Customers need to know which dependencies can suspend their workload. Does the VPS stop immediately after a missed payment, and is data retained during a grace period? Can a software licence failure prevent management or only new provisioning? Does Together have the right to move a workload between facilities? What notice is given before a product is retired or a supplier changes?

The company's public pages do not provide standard cloud terms, a service-level agreement or an exit schedule. That makes individual contract review essential. The agreement should identify data ownership, acceptable use, suspension rights, breach notification, backup responsibility, support hours, maintenance, liability, remedies and termination assistance.

Colocation adds a special split. Together may provide space, power and network while the customer owns the server. If the customer stops paying, who can enter the facility and retrieve the equipment? If Together changes facility, who pays for migration and downtime? If a drive fails, may Together replace it, and from whose stock? These questions determine whether ownership helps recovery or merely relocates responsibility.

Portability is the last resilience test

A hosted service is not fully recoverable if the only copy can run only under the current provider's control. NIST's cloud recommendations treat workload portability and standard interfaces as important limits on provider dependency. For Together customers, portability should be tested before an incident, not discovered during termination.

Shared hosting may be portable as website files, databases, mailboxes and DNS records, but control-panel formats can complicate a move. A VPS may be exportable as a virtual disk image, yet the image may require different drivers, firmware or network configuration elsewhere. A dedicated server may hold ordinary data but depend on a licensed application bound to its hardware. Colocation equipment is physically portable but may use addresses that cannot move to the next provider.

The migration plan should specify format, time and cost. Can a customer download a current copy without opening a support ticket? Is there an egress charge or bandwidth limit? Will Together provide database consistency and a final delta transfer? How long are data and backups retained after exit? Can the customer keep its addresses, or must DNS and firewall rules change?

The dormant AS34008 makes this question concrete. Together's network arrangement has changed before: prefixes visible from AS34008 through January 2019 are now associated with the active AS42013 surface. That may have been a smooth routing transition. It still demonstrates that identifiers and origin paths can change while the company continues. Customer systems should be able to survive the next change without depending on undocumented history.

A good exit exercise can be small. Export one representative VPS, restore it in an independent environment, update a test DNS name and confirm that the application works. Recover one shared-hosting account without the original control panel. Retrieve a backup using customer-held credentials. Record the time and missing dependencies. The exercise turns portability from a contractual phrase into evidence.

What current evidence can and cannot support

Together Communication is not invisible. It maintains a current public website, describes a specific hosting and colocation offer, holds RIPE membership, originates substantial IPv4 and IPv6 space through AS42013, appears broadly in route collectors, and connects to PSIX at a named Ramallah facility. These are meaningful signs of a live regional network business.

The assigned cloud-network ASN is a different matter. AS34008 remains registered to the same organisation but has no current globally visible routes and has not originated a widely observed route since January 2019. Its old policy statements and historical prefixes are evidence of past operation, not present cloud reachability. On that narrow surface, the operating evidence is negative.

The active AS42013 cannot answer the larger cloud questions. Public evidence does not establish which facility hosts Together Cloud, whether there are multiple production sites, where backups reside, how storage is replicated, what power survives, how much spare compute exists, which support hours apply or how a customer exits. A live network can carry a fragile cloud just as easily as a resilient one.

This produces three separate judgments. Corporate and network continuity for Together Communication is supported. Current operation of AS34008 is not supported. Resilience of the hosted platform remains weakly evidenced. Keeping those judgments separate avoids both unfair dismissal and unwarranted confidence.

The due-diligence request should fit on one page

A prospective customer does not need sensitive diagrams or a tour of every rack to improve this evidence position. Together can answer the central questions in a compact service schedule.

First, name the operating boundary: which legal company contracts with the customer, which ASN carries the service, which party owns the servers and which suppliers provide facility and transit. Second, identify the city and failure domain for production, replica and backup copies. Third, state installed and failover capacity in units relevant to the product: compute, memory, storage, rack power and network throughput.

Fourth, describe power and cooling at the level of maintainability: independent feeds, UPS paths, generator autonomy, refuelling, cooling reserve and the last load test. Fifth, describe network diversity: carriers, physical entrances, edge devices, PSIX use, normal utilisation and capacity after one path fails. Sixth, state the hardware sparing and replacement policy for hosts, storage, switches and optics.

Seventh, publish recovery objectives and the result of the last full restore. Eighth, name support hours, severity definitions and escalation channels that remain available during a network outage. Ninth, provide the standard contract covering maintenance, suspension, security incidents and remedies. Tenth, demonstrate export of one representative workload and customer data set.

None of these requests assumes that Together must imitate a hyperscaler. A regional cloud can be smaller, more personal and more locally useful. Its advantage should be a shorter chain of accountable people and assets. To make that advantage credible, the chain must be visible enough that a customer knows what happens when the first link fails.

The present evidence supports a cautious commissioning decision. Together Communication operates a real network and publicly sells real hosting categories. Its precise cloud-network ASN is dormant, and the physical design behind the commercial cloud is not disclosed. Customers should treat the service as potentially useful but not yet proven for workloads that cannot tolerate a site, provider or recovery failure. The evidence that would change that conclusion is straightforward: current service mapping, separate failure domains, measured failover capacity, tested restores and a workable exit path.