I want to share something that happened today with xCloud, because it reminded me why I personally appreciate the Enhance philosophy of running your own infrastructure on your own terms.
I opened a support ticket in xCloud and intentionally did not allow SSH access. Despite that, a support engineer created a sudo user and logged into my server without my authorization. I understand they were probably trying to help, but accessing a production server without explicit consent is a serious security concern. For me, it is the equivalent of someone entering your house even though you said the door should remain closed.
To make things more worrying, the IP used for the connection is listed on AbuseIPDB for botnet and malicious activity, which raised even more questions about access controls and internal policies.
Now, I want to be very clear: I am not here to bash xCloud. I respect the team, I value how they respond to feedback, and I truly admire how far the product has come. In 2023 it was honestly a mess, and today it is a completely different platform. I am even listed in their Hall of Fame for contributing security feedback, and I am proud of that. I want them to succeed.
The only reason I dig so deeply into these things is because my mission is education. I run Webnestify, and I am also launching a non profit initiative, Webnestify Education, to help people understand digital safety and server security. When I find something concerning, I talk about it because someone out there might learn something important from it.
This experience simply reinforced how much I appreciate Enhance. With Enhance, nothing happens behind my back. I own the servers, I control the access, I enforce the security, and I can be confident that no one is logging in unless I decide so. That kind of transparency and control is priceless when you manage production environments for real businesses.
xCloud’s Response
They explained that their internal permission system mistakenly flagged my ticket as if I had already approved both Magic Login and SSH access. Because the site was down and the issue involved database credentials, their support agent acted quickly, assuming access was already granted. In similar cases, clients often forget to enable SSH access when a site is down, so their workflow sometimes requires rapid action to recover production environments.
They also clarified that:
Only a very small group of senior engineers has elevated access
All staff actions are logged with unique IDs for audit
Their devices and network are secured and monitored internally
This behavior is not common, and they acknowledged the confusion
They are improving the SSH approval system so this cannot happen again
OTP-based one-time SSH access sharing is already planned
They apologized and assured me this was a one-off incident caused by a workflow issue in their fairly new ticket system.
My Thoughts
I appreciate the transparency and the apology. But I also want to be honest:
Yes, mistakes can happen. But what if I didn’t notice this? What if I wasn’t auditing my server?
Security is not about trusting that people always do the right thing. It is about ensuring the system does not allow the wrong thing to happen in the first place.
This is why Enhance continues to stand out for me. With Enhance:
I own the servers
I control who logs in
Nothing happens behind the scenes
No support engineer gains access unless I explicitly grant it
The entire stack is transparent and based on open, predictable components
Enhance gives me the confidence that my infrastructure operates on my terms, with my security policies, and without unexpected hands touching production machines.
I am sharing this because I believe in open conversation, transparency, and learning. Not to shame xCloud, but to remind all of us why control and self-hosted architecture matter so much.
