Lock the portal
Turn on two-factor or a passkey under Account. Review signed-in sessions and revoke any you do not recognize. Two-factor and passkeys.
Every VPS is an isolated KVM guest. DDoS mitigation is always on. A firewall sits in front of the operating system. The portal that can destroy your servers takes a second factor.
The guest is yours. Neighbors do not share your kernel. Public IPs sit behind always-on DDoS mitigation, and you can filter traffic before it reaches the operating system.
Each VPS is a full virtual machine with its own kernel and virtual disks. Other customers cannot read your filesystem or attach to your processes.
Layer 3/4 mitigation is always on for every public IPv4. No attack surcharge, and no checkbox to flip after the box is already falling over.
Allow or deny traffic from the service page after deploy. Rules sit in front of the guest OS, so a missed iptables line is not the whole story. You still run a host firewall inside the VM.
Put backends on an isolated LAN. Members talk to each other. Traffic in or out of the VNet is blocked. No platform NAT.
Treat the client account like production access. A second factor, sessions you can revoke, and root passwords that are stored encrypted and shown only to you.
Sign-in is email and password. Add an authenticator app or a passkey as a second step. Save the recovery codes. Anyone who can sign in can read root passwords, spend credit, and destroy servers.
The initial root password is stored encrypted and shown only while you are signed in. Change it after first login and switch to SSH keys. Do not paste it into a ticket.
We isolate the guest and mitigate the IP. SSH keys, package updates, and which ports are open are still your work. Do these before you install anything that matters.
Turn on two-factor or a passkey under Account. Review signed-in sessions and revoke any you do not recognize. Two-factor and passkeys.
Put your key on the server, confirm a second session, then turn password login off. The browser console still works if SSH goes wrong. Harden a new server.
Set the hypervisor firewall to what the workload needs. Run a host firewall inside the guest too. Databases and caches belong on localhost or a private network, not 0.0.0.0.
Copy anything you cannot replace off the server before an upgrade, a firewall edit, or a panel install. The platform does not take snapshots. If the server is already compromised, isolate it and rebuild. Do not try to clean a rooted box in place.
Isolation, DDoS, the portal, and what you still have to lock down yourself.
No. Each VPS is a KVM virtual machine with its own kernel and virtual disks. Neighbors cannot read your filesystem or attach to your processes.
Yes. Layer 3/4 mitigation is always on for every public IPv4, on every plan, with no per-attack fee.
Not as a matter of course. We do not browse your disk to see what you installed. Abuse reports, legal process, and incidents that threaten the network are the exceptions, the same ones in the AUP.
Turn on an authenticator app or a passkey in the client portal, then review signed-in sessions and revoke any you do not recognize. Anyone who can sign in can read root passwords and destroy servers.
VPS disks live on Enterprise SAS SSD storage in our Tampa metro facility, unless a product page says otherwise.
Cut it off with the hypervisor firewall, copy off anything you still trust, and rebuild. Do not try to clean a rooted box in place. The docs cover hardening a new server and responding to a compromise.
Tampa is live. Pick a plan, pick an OS, and the server is online in under a minute.