VPS Reviews

VPS Reviews & Impressions

First-hand reviews of VPS providers I've actually used for self-hosting, development, and networking experiments. The good, the bad, and occasionally the spectacularly broken.

Last updated: October 19, 2026

Affiliate disclosure: Some links on this page are affiliate links. I may earn a commission if you purchase through them, at no additional cost to you. Affiliate relationships do not guarantee favorable reviews.
GreenCloud · Current budget pricing $25/year

GreenCloud's Budget KVM sale plans currently start at $25 per year in several locations. At the time of writing, some $25/year plans include around 4 GB RAM, 2 CPU cores, 35 GB SSD or NVMe storage, one IPv4 address, IPv6, and several TB of transfer. Exact hardware, bandwidth, IPv6 allocation, location, and availability vary by plan.

View current Budget KVM plans →

My experience with GreenCloud

I currently use GreenCloud VPS for multiple public Linux VPS nodes, including Clanker and ScopeCreep.

These are not idle test machines. I use them for Docker services, monitoring, web applications, DN42 routing, WireGuard, DNS, small Internet-protocol servers, and networking experiments.

GreenCloud has been a good fit for the kind of inexpensive Linux infrastructure I run: enough resources to do useful work, cheap enough that keeping multiple locations online is practical, and support that has responded quickly when I have hit provider-side network problems.

What I run on them

  • Docker and Docker Compose workloads
  • ASP.NET Core / .NET applications
  • Mission Control monitoring and telemetry
  • Random Steam Game and Random GitHub
  • Gopher, Gemini, QOTD, Finger, and other small services
  • WireGuard tunnels
  • BIRD and DN42 BGP routing
  • IPv4 and IPv6 networking experiments
  • Authoritative DNS and HTTPS services

Support experience

I have had a couple of network problems worth mentioning. I think those incidents are more useful in a review than pretending nothing has ever gone wrong, because they show what support does when the infrastructure is actually broken.

August 2026

IPv6 provisioning issue

After enabling IPv6 on one VPS, Neighbor Discovery to the supplied gateway worked and outbound packets left the VM, but nothing came back. Packet captures indicated that the problem was upstream of the guest.

I opened a ticket at 07:30. Support replied at 07:32, investigated the VPS, and at 07:48 asked me to retry after making a change. I confirmed IPv6 was working at 07:54.

About 24 minutes from opening the ticket to confirmed working IPv6.

September 2026

Unsolicited IPv6 multicast traffic

On another VPS I noticed inbound bandwidth increasing even though my applications were not receiving that amount of traffic.

A packet capture showed unsolicited ICMPv6 / MLDv2 multicast listener reports from another device on the provider-side network. During a 300-second capture I measured roughly 72,007 frames, about 107 MB, or approximately 2.85 Mbps of sustained inbound traffic from that conversation.

I opened a support ticket at 01:16. GreenCloud replied at 01:19 and began investigating the provider-side source.

The unwanted multicast traffic stopped after they investigated the issue, so the underlying problem was fixed. The bandwidth that had already been recorded in the control panel was not removed afterward.

The initial technical response came in roughly three minutes, and the unwanted traffic was subsequently stopped.

What I like and what to know

What I like

  • Cheap enough for hobby and small-service infrastructure
  • KVM VPSes work well for normal Linux workloads
  • IPv6 is available
  • Multiple locations make multi-node experiments practical
  • Support has responded quickly when I have reported problems
  • No special platform required for normal Docker and networking work

Things to know

  • I have encountered provider-side IPv6/networking issues
  • These are inexpensive VPSes, not managed enterprise infrastructure
  • I monitor CPU, memory, bandwidth, and service health myself
  • I still keep backups and plan around the possibility of a VPS failing
  • Plans, locations, and pricing can change

Who I think GreenCloud fits

GreenCloud makes the most sense to me if you are comfortable administering your own Linux server and want inexpensive compute for small applications, personal infrastructure, Docker workloads, networking experiments, or geographically separate nodes.

Want the VPS without doing all the server work?

If you need help setting up or operating the server, I also do deployment and self-hosting work: Linux VPS setup, Docker, HTTPS, monitoring, backups, application deployment, and related infrastructure.

Development & deployment help

The GreenCloud VPS buttons are affiliate links. I may earn a commission if you purchase through them.

Not recommended · Updated October 19, 2026

Servitro — Frankfurt, Germany

I purchased a VPS from Servitro to diversify my hosting across multiple providers. Unfortunately, it has become one of the worst VPS experiences I've had.

I brought up a Frankfurt VPS named Wurstcase for DN42, Yggdrasil, WireGuard, and other networking experiments. Initial network latency from Pennsylvania to Frankfurt was genuinely good: my first IPv6 tests were around 90–95 ms, with no packet loss in the small samples I ran.

Unfortunately, the actual VPS performance later became severely degraded by persistent CPU steal time. Repeated mpstat 1 10 samples collected across the evening, overnight, and the following morning showed sustained %steal averages around 14–24%, with individual one-second samples reaching as high as 74%.

CPU steal samples

  • 19.01% average steal
  • 18.65% average steal
  • 18.64% average steal
  • 18.86% average steal
  • 22.93% average steal
  • 23.67% average steal
  • 20.26% average steal
  • 19.66% average steal

Guest CPU usage itself remained relatively low, and %iowait was effectively zero in the samples I collected. The combination of low guest workload and high CPU steal strongly indicated host-side CPU contention rather than a workload problem inside my VM.

I opened support ticket #FHO-567811 on October 14, 2026 at 22:54, including multiple mpstat captures demonstrating the problem.

I followed up on October 15 after the issue persisted for more than twelve hours, providing additional measurements showing average CPU steal around 20–24% and individual spikes reaching 74%. I requested an investigation of the host node and migration if necessary.

By October 16 at 14:25, the ticket had been open for approximately 39 hours and 31 minutes. In the ticket history I reviewed, every visible message during that period was one of my own updates. I had not received a visible response from support.

During that time, performance deteriorated enough that establishing an SSH session became difficult. I requested either migration to a healthy host or cancellation with an appropriate refund or credit.

October 19, 2026 · Incident update

Update: It keeps getting worse

Following the original CPU steal complaints, Servitro migrated my VPS to another host node. CPU steal appeared to improve substantially after the migration. Unfortunately, the migration introduced new problems.

First, SSH access failed following the migration, requiring troubleshooting through the VNC console. After restoring access, I discovered that public IPv6 connectivity was completely broken.

I investigated and captured network traffic showing that the configured IPv6 gateway was not responding to Neighbor Discovery requests. IPv4 was still working at that point, so I restored an affected DN42 BGP peering session by switching its WireGuard transport to IPv4.

I reported the IPv6 failure to Servitro support.

Then the situation got substantially worse.

Later on October 19, the VPS stopped responding over public IPv4 as well. The VNC console also stopped connecting, leaving me unable to access the server through either the network or the provider's console.

The control panel reported 0% CPU utilization, unavailable memory information, and zero network traffic. Although the service continued to be listed as Active, I could not determine whether the virtual machine was running.

At 12:10 PM on October 19, I attempted to start the VPS using the control panel's Boot function. The operation was cancelled after approximately 20 seconds with this message:

The system failed to respond to the action request. Further attempts are likely to be cancelled until the system is responding normally. Try again in five minutes.

This suggests a possible problem with the host or VPS management infrastructure. I cannot independently confirm the cause without access to the hypervisor.

I escalated the complete outage through support. As of this update, the VPS remains inaccessible, and I have not received an explanation or estimated restoration time.

I originally purchased this VPS to diversify my infrastructure across independent hosting providers and improve redundancy. Instead, I have spent days troubleshooting a service that was supposed to provide an additional reliable network location.

October 2026 · Ticket #FHO-567811

My conclusion

Cheap VPS hosting inevitably involves shared resources, and a single overloaded host would not by itself make me write off a provider. Infrastructure problems happen.

What changed my opinion was the combination of severe, persistent host contention, inadequate communication, and further failures following the host migration. What started as a performance issue progressed to broken IPv6 connectivity and eventually a completely inaccessible VPS.

I have encountered provider-side networking problems with other inexpensive VPS providers where support acknowledged the issue within minutes and began investigating. Problems are inevitable; how a provider responds is a major part of the service.

I understand that budget VPS hosting does not include enterprise-level support. However, expecting timely acknowledgment of an unusable service and meaningful updates during a complete outage is not unreasonable.

I will not be renewing my service with Servitro. The low price simply is not worth the instability, repeated troubleshooting, and lack of timely communication.

Based on this experience, I do not recommend Servitro for workloads where predictable performance, availability, or timely support matters.

Incident timeline

  • October 14, 22:54: Opened support ticket #FHO-567811 with CPU steal measurements.
  • October 15, 15:16: Followed up with sustained steal averages around 20–24% and spikes reaching 74%.
  • October 16, 14:23: Reported that SSH access had become unreliable because of severe performance problems.
  • October 16, 14:25: Requested migration or cancellation with an appropriate refund or credit.
  • October 19: Following migration, discovered that the IPv6 gateway did not respond to Neighbor Discovery.
  • October 19, later: Public IPv4 became unreachable, and the VNC console stopped connecting.
  • October 19, 12:10 PM: The panel cancelled a boot attempt because the system failed to respond.

Still want to try Servitro?

I cannot recommend Servitro based on the problems documented above. But if you decide to try the provider anyway, you can use my affiliate link.

Affiliate disclosure: I may receive a commission if you sign up through this link, at no additional cost to you. This does not change my negative assessment.

This review documents my experience with one Servitro VPS and its associated support incidents. It does not imply every customer or host node has the same experience. I will update this review if Servitro provides additional information or resolves the outage.

For VPS Providers

Want me to review your VPS?

I'm open to reviewing other VPS providers, especially inexpensive KVM VPSes, IPv6 deployments, unusual locations, interesting network configurations, and services aimed at self-hosters or developers.

Providing free or discounted service does not guarantee a positive review. If a provider supplies the service being reviewed, I will disclose that.

Contact me