Roman Milyushkevich, HasData's co-founder and CTO, spent most of his career extracting data from websites. At every new job, he built tools to handle similar workloads. Browsers had to run by the hundreds, and the parsers that turned pages into data broke every time a site changed its layout. "I built HasData based on my own experience, to solve my own problems, and it appears others have the same problems," he says.
HasData now has more than 1,300 customers, and the largest group of them is building AI agents. An agent that needs fresh information from the web has to search for it and turn the results into data its software can use. HasData provides that information through its APIs.
Outside of AI agents, HasData’s customers use its APIs for a variety of other purposes. Some use the company and contact data they retrieve through HasData to add more information to records in their own sales tools. Other customers use the data in SEO rank trackers and real estate investment software. Some customers use HasData’s APIs to track how brands show up inside AI answers.
Every one of them trusts HasData to deliver the data they need, when they need it. That means HasData needs a cloud environment it can rely on.
"I built HasData based on my own experience, to solve my own problems, and it appears others have the same problems."
Co-founder and CTO, HasData
The challenge
HasData initially used another cloud provider's virtual machines for its infrastructure. They were cheap and good for the price, but the company outgrew them as request volume climbed. HasData needed more CPU and more private network bandwidth, and the provider's outages were frequent. Growth exposed other problems, too.
First, latency began spiking on the network in ways the team could not trace to its own code. Roman suspected some of the cloud provider’s other customers were causing the problem. Their virtual machines shared the same hardware and could take CPU time away from HasData's parsers.
Then Google began blocking the cloud provider's IP addresses based on reputation, meaning the addresses had carried enough bad traffic in the past that Google treated any request from them as suspect. The blocking broke HasData's own calls to critical services like Google Cloud Storage and Firebase. To restore access to those services, the team had to route that traffic through other providers.
Then, the cluster setup created another challenge. HasData ran its own Kubernetes cluster on the cloud provider. But its nodes could only communicate through a VPN over the public internet.
The most obvious solution to the problem was working with a hyperscaler. Roman spent a couple of days comparing prices from AWS and Google Cloud. "I just opened their pricing calculators and it was a very fast decision that we were not going to use them," he says. A mid-tier cloud provider cost less, but was still too expensive at HasData's scale. The company was handling roughly half a billion requests per month.
Since HasData was already running its own Kubernetes cluster, the decision shifted from price to what kind of servers the cluster should run on. "If we were hosting our own Kubernetes cluster on [our previous provider], why are we looking for a managed solution?"
The solution
Bare metal was the answer, and Servers.com by Nexcess was where HasData found it. The company migrated in November 2025.
Servers.com bare metal gave the Kubernetes cluster two things the virtual machines could not. The first was dedicated servers. No other customers share the CPUs, so nothing else takes processor time from the parsers. That removed the factor Roman believed was causing the latency spikes. Parsing latency dropped by roughly 30% after HasData moved the cluster to bare metal.
The second was a global private network. Every node in the cluster now talks to every other one over a private path, eliminating the problematic VPN setup. Before committing, Roman ordered two servers for a test. Confirming they could communicate without a VPN and seeing the network speeds settled it for him. Evidence showed the Kubernetes cluster would perform far better on Servers.com infrastructure.
Moving to Servers.com also eliminated the IP address reputation issues. Since the move, HasData's calls to Google Cloud Storage and Firebase have not been blocked.
Most importantly, HasData did not have to change how it operates. The team has kept its own Kubernetes cluster, managed with Rancher, and deploys to it the way it always has. Standing that cluster up on bare metal was the one real effort in the move, and HasData chose to hire a DevOps engineer to handle it. He still maintains the environment, but developers can deploy new pipelines themselves, with the DevOps engineer reviewing their work.
The economics reinforce the decision. "What we are paying for servers plus his salary is less than the AWS bill would be for us at our scale," Roman says.
The environment has run without an incident since the move. Support is also more direct. "We have a channel on Telegram where we can ask any questions at any time," Roman says. "I have direct contact with Travis [King, HasData’s account executive at Servers.com]. He replies within minutes. And most importantly, we don't have any problems."
Nearly a year in, Roman's report on the Servers.com environment is short and sweet. "It just works. We set everything up at once, and now we're just updating some stuff regularly." HasData was running 9 servers at first. It now runs 14, plus 3 cloud instances and 2 load balancers. It adds a server about every two months, and request volume has reached roughly half a billion a month. The environment has kept up without a major change in how the team runs it.
For the engineering story behind this partnership, including how a CPU-bound workload behaves once it stops sharing hardware, read the technical companion.
To learn how Servers.com by Nexcess builds bare metal cloud for workloads like HasData's, contact the team.
Thanks to Roman Milyushkevich and Nikita Naumov for sharing the HasData x Servers.com story.