Portland Internet Hosting LLC sells hosted capacity that still depends on racks, transit and repair windows

Summary

• Portland Internet Hosting LLC has stronger operating evidence than many thin directory entries: ARIN associates AS36791 with Portland Internet Hosting LLC, the PDXHosting site sells active hosting products, PeeringDB records PDXHosting as AS36791, and third-party BGP views show routed IPv4 and IPv6 prefixes.
• The infrastructure story is local and physical. The company publishes a Hillsboro address, PeeringDB places AS36791 at Opus Interactive Hillsboro and Stack Infrastructure Portland PORO2, and the service catalogue includes colocation and wholesale internet access at 921 SW Washington in Portland; none of that proves ownership of a data-center building.
• PDXHosting's own terms and acceptable-use policy are central reliability documents. They show shared CPU, disk I/O and network-port constraints, optional DDoS filtering, suspension risk for disruptive use, non-portable IP address terms and customer obligations that can affect recovery as much as router design.
• The evidence grade is medium. AS36791, NWAX participation, public products and facility records make the company operating and monitorable, while missing public details on rack count, power design by service, spare hardware, uptime history, backup architecture, staff coverage and cross-site recovery prevent a stronger grade.

The useful story begins with an Oregon provider, not a borderless cloud

Portland Internet Hosting LLC is visible in several public layers. ARIN's autonomous-system record for AS36791 names the AS as PDXHOSTING and associates it with Portland Internet Hosting LLC, with an AS registration date in April 2011 and a later record update in February 2023. ARIN's organization record for PIHL-1 places Portland Internet Hosting LLC at a Hillsboro, Oregon address and lists PDXHosting Support as the administrative, technical, abuse and network-operations contact. The company-facing layer is the PDXHosting website, which presents a compact service catalogue rather than a dormant placeholder page.

That combination matters because it establishes a company that can be evaluated from operating evidence, not only from a directory card. The public record shows a named legal entity, an autonomous system, a routeable network, public service pages, a customer-facing domain, facility presence in network databases and policy documents. It does not, however, support treating the company as a hyperscale cloud platform.

The PDXHosting website uses hosting language and sells cloud-like units, but the observable business is a smaller infrastructure provider standing on top of data-center space, wholesale connectivity, servers, storage systems, customer portals and support processes.

The difference is important for readers because "hosted capacity" can hide failure domains. A customer may buy a KVM instance, a physical server, a virtual dedicated server or a colocation slot through a simple order path, but the service still lands on specific hardware, in specific racks, with specific upstreams and policies. PDXHosting's public materials do not publish a multi-region availability architecture, a formal zone model, a historical uptime series or a facility-by-facility map of power feeds and carriers.

The correct reading is narrower: this is an Oregon-centered provider with a global customer surface because remote customers can buy services over the internet, not a global facilities platform.

That narrower reading is still valuable. Portland and Hillsboro sit inside an increasingly important West Coast infrastructure market. STACK describes its Portland market in Hillsboro as a scalable digital-infrastructure location, while Opus Interactive describes its Oregon data-center presence as Hillsboro-based colocation and infrastructure. PDXHosting appears in that local ecosystem through AS36791 records and facility databases. For a customer choosing a low-cost or specialized Oregon host, that makes the company more concrete than a generic reseller with no routing evidence.

The public story also has an identity wrinkle. The directory and ARIN records use Portland Internet Hosting LLC. The footer of the PDXHosting website uses a longer "Portland Internet Hosting Co. LLC" wording. That is not enough to infer a separate entity; it is best treated as brand and site-label variation unless a formal corporate record proves otherwise. The article therefore uses Portland Internet Hosting LLC for the entity and PDXHosting for the service brand.

The storefront shows multiple products, each with a different failure model

The most direct source of customer-service evidence is the product catalogue. PDXHosting's KVM instances page lists standard and premium virtual-server plans, with memory, CPU core counts, SSD or NVMe storage, bandwidth and monthly prices. The LXC instances page offers lower-cost annual container-style plans with guaranteed and burst memory. The VDS page positions virtual dedicated servers between low-cost VPS plans and dedicated servers, using dedicated CPU cores while still sharing I/O and network ports. The physical servers page lists finite quantities of physical server inventory by CPU, memory, storage, bandwidth and port options.

Those pages show a provider packaging infrastructure in several ways. KVM and LXC products rely on host nodes and shared storage or local disks. VDS products offer stronger CPU isolation but still depend on shared storage transport, switch ports and support response. Physical servers depend on the provider's stock, remote access, repair process and the customer's ability to rebuild on replacement hardware. Colocation, listed on the Products and Services page, shifts part of the hardware responsibility to the customer while leaving space, power, connectivity and remote coordination with the provider.

The same page also lists VPN, SAN storage, wholesale internet access at 921 SW Washington in Portland, web hosting, domain and SSL services, and system administration. This breadth looks useful for small businesses because the provider can supply several adjacent pieces: compute, storage, connectivity, basic managed help and customer-owned hardware space. It also means a failure analysis has to separate product families. A web-hosting customer, a colocation customer and a wholesale-internet customer may all pay the same brand, but they do not face the same recovery path when a node, rack, switch or billing account becomes impaired.

Pricing and product shape are infrastructure evidence. Low monthly KVM plans, annual LXC plans, VDS plans and limited physical-server quantities suggest a provider serving budget-conscious or small-business customers. That is not a criticism. Low-cost hosting fills real needs: development systems, monitoring nodes, hobby services, small SaaS components, secondary DNS, backup endpoints, simple websites, VPN use and workloads that do not justify enterprise colocation contracts. But low prices change what customers should audit.

There is less room for idle spare capacity, deep support staffing, extensive public documentation and fully reserved failover pools.

The SAN storage line is also worth reading carefully. The product tables say SAN storage is not a standalone product and is available with compatible products such as KVM, VDS or physical dedicated servers. They list iSCSI, CIFS and NFS transport and mark the storage as redundant. That is useful because it exposes a storage dependency that a basic VPS buyer might miss. A workload may survive local server maintenance if storage is robust, but it may also inherit storage-network, protocol, controller or support risks.

Public product tables do not say how the SAN is designed, where replicas sit, what restore objectives are available or whether customer backups leave the same facility risk envelope.

The dedicated-server page is unusually concrete because it lists small quantities. Finite inventory can be a positive signal: the provider is not pretending that abstract capacity is unlimited. It can also be a repair watchpoint. If a listed class has only a few units, customers should ask what happens when one unit fails, whether there is spare chassis capacity, whether disks can be moved, whether an equivalent server is reserved and how long remote hands can take during a busy incident. Inventory is installed capacity only if it is powered, cabled, available, supportable and connected to enough network and storage headroom.

Facility evidence points to Hillsboro and Portland boundaries

PDXHosting's public site gives a Hillsboro, Oregon address, while the product catalogue includes wholesale dedicated internet access at 921 SW Washington in Portland. PeeringDB's PDXHosting network record lists Portland Internet Hosting LLC as the organization behind AS36791 and identifies interconnection facilities including Opus Interactive Hillsboro (HIO01) and Stack Infrastructure Portland PORO2. ColoMap's AS36791 facility summary similarly points to on-net facility presence at Opus Interactive Hillsboro and STACK Infrastructure POR02A, both associated with 8135 NE Evergreen Parkway in Hillsboro.

That is meaningful operating evidence, but it needs the right boundary. Public facility presence does not prove that Portland Internet Hosting owns a data-center building. It more likely indicates racks, network presence, customer deployments, cross-connects or other on-net infrastructure inside third-party environments. For customers, this distinction decides who controls which part of an incident. PDXHosting may control servers, switches, routing, customer support and account policy. Facility operators control building-level power, cooling, access rules, common infrastructure and many physical maintenance conditions.

A failure in either layer can become customer downtime.

The facility evidence also prevents an over-broad geographic claim. The category for the article is global because the service is internet-orderable and the directory uses a global service area. The physical evidence is not global. It is Oregon-centered, with Hillsboro and Portland references. The PeeringDB ASN page lists NWAX peering and facility presence in Oregon. BGP.tools lists the locations of operation as the United States. None of the public sources reviewed show a published London, Singapore, Frankfurt or Ashburn region for PDXHosting services.

This matters for data locality. A customer can reasonably treat PDXHosting as an Oregon or U.S. hosting choice based on the address, facility records and product pages. The customer should not infer a complete data-sovereignty framework. The company does not publish a detailed statement showing where backups live, where support access originates, where logs are stored, what subprocessors operate the customer platform or how customer data moves between service components. A colocated server may be physically in an Oregon facility; billing records, support tickets and control functions may follow different systems.

The 921 SW Washington wholesale-internet offer adds a second urban layer. The product page describes dedicated internet access at that address and says cross-connects are additional and are the customer's responsibility. That is classic wholesale-access wording: the provider may deliver a port, but the customer still needs building access, cross-connect ordering, compatible handoff and its own service design. The address is not the same thing as a broad Portland cloud region. It is a specific access point that can be useful for customers already present in the building or nearby interconnection environment.

The right customer question is therefore not "does PDXHosting have Portland?" but "which PDXHosting product is delivered in which physical place, under whose facility rules, with which power feeds and which network handoffs?" Public sources answer only part of that question. They locate the provider in the market; they do not expose rack maps, cabinet count, power diversity or service-by-service placement.

AS36791 is strong evidence of operation, but not a full resilience proof

Routing evidence is the strongest public signal for Portland Internet Hosting LLC. BGP.tools' AS36791 page identifies Portland Internet Hosting LLC, shows AS36791 as active, lists originated IPv4 and IPv6 prefixes, names upstreams including Hurricane Electric and Opus Interactive, and records a NWAX internet-exchange connection. IPinfo's AS36791 page also identifies PDXHosting and reports upstreams including Hurricane Electric and Opus Interactive. Hurricane Electric's AS36791 BGP page provides another independent route view.

The RIPE NCC statistics API adds time-bounded context. The AS overview endpoint shows AS36791 announced for the July 14, 2026 query window and names the holder as PDXHOSTING - Portland Internet Hosting LLC. The announced-prefixes endpoint showed nine announced IPv4 and IPv6 prefixes for the same window. Those figures are not a capacity guarantee, but they support the conclusion that the AS was active immediately before publication.

The prefix mix should be read with care. Some public route views describe certain originated prefixes with names other than Portland Internet Hosting LLC, including third-party-named IPv4 and IPv6 blocks. That can happen for customer announcements, leased address space, delegated routing, registry-description lag or other commercial arrangements. It should not be turned into a claim of ownership without registry confirmation.

It is, however, a reason for customers buying transit or address-sensitive hosting to ask how prefixes are authorized, how route-origin authorization is maintained, who controls reverse DNS, and what happens if a delegated route has to move.

The upstream list also needs a practical interpretation. Seeing Hurricane Electric and Opus Interactive as upstreams is better than seeing a network with no public upstream diversity. It does not prove that every product has independent physical paths, that both upstreams are present in every rack, that both support full IPv4 and IPv6 reachability under stress, or that there is enough router capacity to absorb a failure. Transit resilience depends on router hardware, cross-connects, route filters, facility cabling, prefix policy and staff response. A BGP table shows reachability; it does not show the full repair plan.

The same is true for peering. PeeringDB's NWAX record and bgp.tools' NWAX peer list show PDXHosting as a NWAX entity with IPv4 and IPv6 exchange addresses and a 1G connection. Hurricane Electric's NWAX exchange page independently lists Portland Internet Hosting LLC at NWAX. That is useful because local exchange participation can reduce transit cost, improve regional paths and give the provider more routing options. It does not mean every customer gets exchange-level redundancy or high-capacity peering.

The 1G exchange connection is an economic clue. For a small host, a 1G NWAX port can be appropriate and efficient. It also limits how much traffic can shift through that path during congestion or upstream trouble. A customer expecting large sustained throughput should not treat exchange presence as a substitute for contractually specified bandwidth, DDoS handling, port utilization history or upstream failover testing. Peering is part of the network surface, not the whole network.

The terms and policy pages are reliability documents

PDXHosting's Acceptable Use Policy is more operationally revealing than a typical marketing page. It states that CPU cores and disk I/O are shared in VPS environments and that disruptive load may result in reboot, shutdown or suspension. It says VDS CPU cores are dedicated but I/O and network ports are still shared. It says shared hosting is not a replacement for a content-delivery network and that excessive storage, bandwidth or abusive traffic may lead to reduction requests, upgrades or suspension. Those statements help customers understand which resources are contended.

The network section of the same policy also matters. It says PDXHosting can absorb and tolerate occasional DDoS attacks, but customers who have not purchased optional DDoS filtering and are targeted with frequent or disruptive attacks may be suspended or terminated. It states a stricter position on IPv6-targeted DDoS events, requiring affected customers to use IPv4 filtering for the related service or discontinue IPv6. That is not a hidden footnote. It is a core availability condition for any public-facing workload likely to attract abuse.

The Terms of Service add further customer-side risk. They emphasize bill payment, system updates, resource behavior, no refunds for abuse and the provider's right to cancel service. The terms also say IP addresses assigned by PDXHosting are not portable and remain the provider's property. For a customer building on PDXHosting's addresses, that affects exit planning. If the service must move to another provider, the customer should assume DNS change, renumbering, mail reputation work and firewall updates unless it brings its own portable address resources.

This is not unusual in the hosting market. Providers have to protect shared infrastructure from spam, abusive traffic, denial-of-service activity, malware and customers who consume more than their plan allows. But policy enforcement can become a failure path. A customer might experience an outage not because a router failed, but because the account was suspended after abuse, billing, security or traffic issues. That is a real infrastructure risk for small businesses that rely on one server and one email contact.

The terms also highlight the support boundary. PDXHosting publishes ticket and billing links in its site navigation, and ARIN records list support contacts. Public sources do not provide a current staffed support schedule, emergency escalation ladder, remote-hands response target or public incident archive. BGP.tools includes legacy ARIN comment text listing NOC hours, but buyers should not rely on that as current support coverage without direct confirmation. For any production workload, the support question should be asked before migration, not during a rack or abuse incident.

The practical advice is simple. Treat policies as part of the architecture. If a workload needs continuous reachability, ask how abuse complaints are triaged, how many warnings are given, whether DDoS filtering is included, how IPv6 filtering is handled, what resource thresholds trigger intervention, how billing suspension works, how many contacts can receive alerts and whether emergency tickets have a different queue. A cheap server with opaque policy enforcement can be more fragile than a more expensive server with clear escalation.

Hosting economics explain both the appeal and the limits

PDXHosting's value proposition is clear from its published pricing: low-cost virtual servers, inexpensive storage add-ons, modest physical server stock, basic web hosting, colocation units and wholesale-access ports. That model works because the provider aggregates facility space, upstream connectivity, address resources, hardware and operational knowledge, then sells them in smaller portions than a customer could economically buy alone. It is exactly the layer that makes infrastructure usable for small organizations.

The same economics impose constraints. If a KVM instance costs only a few dollars a month, it cannot carry the same unused reserve, multi-site replication, individual support engineering and enterprise reporting as a larger managed platform. If a physical server page lists a handful of available units, repair may depend on the specific part and staff availability. If SAN storage is sold as an add-on, the customer should ask whether that storage is designed for convenience, redundancy, backup, performance or all of those. The product name alone does not answer the question.

For many customers, the answer may still be good enough. A monitoring node, staging system, small website, offsite backup target, VPN endpoint or hobby project can be well served by a provider like PDXHosting if the customer keeps a copy elsewhere. The risk grows when customers quietly promote a low-cost server into a critical production role. At that point, the missing public details become operational questions: backup export, restore time, disk failure handling, snapshot location, single-node concentration, support response, account suspension thresholds and migration cost.

The colocation product has a different economic trade. A customer can avoid building a data-center relationship and place equipment in a provider-managed environment. In exchange, it accepts a shared operational boundary. PDXHosting can provide space, network and remote coordination, but the customer still owns hardware condition, operating-system configuration, remote management, license recovery and backup design. If the customer's server fails, PDXHosting may be able to power-cycle or assist, but it cannot magically replace customer-owned architecture.

Wholesale internet access at 921 SW Washington has yet another model. Here the customer may already be in a building and needs connectivity. The product page says cross-connects are additional and the customer's responsibility. That means the customer has to understand building management, cabling, handoff media, port availability and the cost of getting from its rack to the PDXHosting handoff. A 100 Mbps or 1,000 Mbps offer is not operational until the physical path, IP assignment, routing policy and support contacts are all established.

The economics therefore create a layered dependency map: facility operator, PDXHosting, upstream carriers, exchange fabric, hardware vendors, storage design, customer configuration, account policy and user traffic. That map is not a reason to avoid the provider. It is the map customers need in order to decide which workloads belong there and which need a different design.

Data locality is real enough for placement, not enough for regulated assurance

The evidence supports a U.S. Oregon locality story. ARIN lists the organization in Hillsboro. PDXHosting publishes a Hillsboro address. PeeringDB and facility databases show AS36791 in Hillsboro facilities. The product catalogue names Portland wholesale access. Customers with Pacific Northwest latency needs or a desire to place workloads in Oregon can use those facts in a first-stage placement decision.

The evidence does not support stronger sovereignty language. PDXHosting does not publish a full data-residency statement, a backup-region map, a subprocessors page, a customer-data flow diagram, a formal certification list or a service-by-service data-location matrix. If a customer has health, finance, government, export-control or contractual data-location requirements, the public site is not enough. The customer would need written answers and probably contractual commitments.

Even a simple Oregon placement can have hidden paths. A server may sit in a Hillsboro data center, but DNS, billing, email, support tickets, customer backups, monitoring logs and abuse handling may touch other systems. Traffic may leave Oregon because BGP follows upstream and destination policy, not state borders. Public exchange participation can keep some traffic local, but it does not guarantee local routing for every destination. A buyer concerned with locality should test traceroutes from important user networks and ask which upstreams serve the specific product.

There is also a facility-operator boundary. If a customer relies on Opus or STACK facility characteristics, it should remember that PDXHosting is the customer-facing provider, not necessarily the facility owner. Opus Interactive's data-center page describes its Hillsboro facility scale and power capacity, while STACK's public materials describe Portland-market infrastructure. Those are facility-market facts. They do not automatically become PDXHosting service guarantees. The provider's contract, cabinet design and purchased services decide what the end customer actually receives.

The most defensible position is modest. Portland Internet Hosting LLC can be described as selling globally reachable hosting services from an Oregon-centered infrastructure footprint. It should not be described, on current public evidence, as a sovereign cloud, a multi-region platform or a provider with disclosed regulated-data architecture.

Failure paths start with racks, circuits and shared systems

The first failure path is rack or facility exposure. Public facility records place PDXHosting in third-party environments, but they do not show how many racks, cabinets, power circuits or switches support each product. A single-corded server, a small group of host nodes, a PDU problem or a maintenance window can dominate customer experience. Customers should ask whether their service is single-rack, multi-rack or facility-diverse, and whether any published redundancy applies to their plan rather than to the facility in general.

The second path is upstream and exchange dependency. AS36791 has visible upstreams and a NWAX connection, but a customer still needs to know whether the service is dual-homed in practice, whether both IPv4 and IPv6 are protected, how route filters are maintained, whether BGP sessions terminate on separate routers and how the provider handles a partial route leak or upstream impairment. Public route views prove reachability, not full fault isolation.

The third path is storage. KVM, VDS and physical-server products can use local storage or optional SAN storage depending on plan and configuration. Shared storage can improve flexibility, but it becomes its own dependency. Customers should ask where snapshots reside, whether backups are independent of primary storage, whether storage transport is redundant all the way to the host, and what restore support looks like after controller or node failure.

The fourth path is hardware stock. The physical-server page's finite quantities are useful evidence, but a customer should distinguish sales inventory from repair inventory. A provider might have a few servers for sale and still have no exact spare for a failed production host. Conversely, it may have parts not visible publicly. The only reliable answer is a direct statement about replacement process, part availability and remote-hands timing.

The fifth path is abuse and resource enforcement. The acceptable-use policy makes clear that disruptive VPS load, DDoS exposure, spam, port scanning, proxy activity and other prohibited uses can lead to shutdown, suspension or termination. For a well-run provider, that enforcement protects other customers. For an underprepared customer, it can become a surprise outage. Workloads exposed to attack or user-generated content need DDoS, abuse and logging plans before they go live.

The sixth path is billing and account control. The terms emphasize payment, cancellation and customer contact information. A failed card, stale email address or unmanaged invoice can create avoidable downtime. Production use should have multiple contacts, invoice monitoring and a tested path to reach support. This is mundane, but mundane failures take real services offline.

The seventh path is migration. The terms say IP addresses are not portable. That means exit planning should not depend on keeping the same provider-assigned addresses. Customers should keep DNS under their own account, avoid hard-coding provider addresses in too many places, maintain off-provider backups and know how to rebuild. A server that is cheap to buy can be expensive to leave if the customer has not planned address and data portability.

Who is exposed when PDXHosting has a bad day

The lowest-risk affected group is the hobbyist or developer using a small KVM or LXC instance. The likely impact of an outage is inconvenience, a down test environment or a lost non-critical service. The mitigation is straightforward: keep code and data elsewhere, monitor externally and assume the server can be rebuilt.

Small businesses using a VPS, VDS or physical server for production face more serious exposure. A resource issue, failed disk, abuse complaint, DDoS event or support delay can affect customers directly. These buyers should not outsource their entire continuity plan to the host. They need external backups, restore tests, independent DNS, alerting from outside the provider and written notes for how to rebuild on another platform.

Colocation customers face a split responsibility. PDXHosting may provide space, power, network and assistance, but the customer owns its equipment choices and configuration. A colocated firewall or router can become a single point of failure even if the provider's network remains healthy. These customers need remote management, spare parts, labelled cabling, clear access authorization and a plan for moving to another provider if the colocation relationship ends.

Wholesale-internet customers face routing exposure. If they depend on PDXHosting for a building connection or route path, an upstream fault, exchange issue or provider policy change can affect their own users. They should monitor BGP, understand handoff details, keep out-of-band contact paths and consider a second transit option when uptime matters.

Shared-hosting and web customers face a different dependency: they rely heavily on provider administration, account policy and platform hygiene. A shared platform can be inexpensive and convenient, but it is not a content-delivery network, a dedicated server or a bespoke managed environment. The acceptable-use policy says as much. Customers with heavy media, high traffic or unusual processes should choose a product that matches the workload rather than stretching a shared plan.

The broader internet is unlikely to experience systemic harm from a PDXHosting incident. Public evidence does not place the company at hyperscale. The risk is concentrated in the customers and downstream users who depend on its Oregon-hosted services, AS36791 reachability, colocation space or wholesale access. Local criticality is still real. A small provider can be mission-critical to the small organizations that rely on it.

What would strengthen the evidence grade

PDXHosting could materially improve public confidence with a facility-by-service page. It would not need to reveal sensitive cabinet details. It could state which product families are available in Hillsboro, which depend on 921 SW Washington, whether products are single-rack or multi-rack, whether A/B power is available, which services have remote-hands coverage and what support channels apply during facility work.

A public network page would also help. It could describe AS36791 routing policy, upstreams by location, NWAX participation, route-security practices, DDoS filtering options, blackhole communities, prefix limits and customer BGP requirements. Much of the network is already visible in BGP.tools, PeeringDB, IPinfo and Hurricane Electric. A provider-owned explanation would reduce ambiguity and show operational intent.

Backup and restore documentation would be especially useful. Customers need to know whether snapshots are included, whether backups leave the primary host or facility, how restores are requested, how long large restores can take, and how data can be exported during cancellation. Small-host customers often underestimate backup responsibility until the first hardware incident. Clear documentation would reduce that risk.

An incident and maintenance history would improve the operating picture. Public route databases show whether the AS is visible, but they do not show customer impact, repair time or root cause. A status archive with planned maintenance, unplanned outages, affected services, start and end times and corrective action would be more valuable than generic availability claims.

Support transparency would also upgrade the grade. The public record includes support contacts and ticket links, but not a current emergency coverage statement. Customers need to know whether urgent tickets are monitored around the clock, whether remote hands are available after hours, how abuse issues are escalated and whether billing issues can be resolved before suspension.

Finally, a concise data-locality statement would help customers match workloads to the service. It should separate server location, backup location, support access, billing data and third-party service dependencies. That would not turn PDXHosting into a regulated sovereign cloud. It would let buyers make cleaner placement decisions.

Bottom line

Portland Internet Hosting LLC should be treated as an operating, Oregon-centered hosting and network provider with visible public evidence: AS36791, ARIN records, PDXHosting product pages, NWAX participation, PeeringDB facility entries and a service catalogue that spans virtual servers, physical servers, storage, colocation, wholesale internet access and web hosting. That evidence is enough to move the company out of the dormant-record category.

It is not enough to assume enterprise resilience. The public record does not prove owned facilities, multi-site failover, rack diversity, deep spare inventory, audited uptime, support staffing depth, backup independence or service-specific data residency. Customers should therefore buy PDXHosting the way they should buy any small infrastructure provider: with respect for its useful local role, but with their own backups, monitoring, DNS control, abuse planning, billing hygiene and migration path.

The company sells capacity that can be valuable precisely because it packages physical infrastructure into affordable units. The operational truth is that those units still depend on racks, circuits, transit, storage, staff and repair windows. The safest customers will be the ones who make those dependencies visible before they need them.

For a prospective buyer, the decision should therefore be workload-specific rather than brand-wide. A low-risk service can use PDXHosting for affordable Oregon placement and treat any outage as recoverable from an external copy. A revenue-facing service should test support, backups, address portability, DDoS handling, account alerts and route reachability before moving real users. A colocation or wholesale-access buyer should confirm facility, handoff, power and remote-assistance details in writing.

The same company can be a sensible supplier for one workload and the wrong single point of dependence for another; the public evidence is strong enough to make that evaluation possible, but not strong enough to do the evaluation for the customer.