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.
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.
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 helpThe 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.
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.
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