Written for somebody who already has a problem and has already spent their patience. No article stubs, no “coming soon”, and nothing that ends by telling you to open a ticket. Search it, or read the lot — it is short enough.
Credentials appear in the client area the moment the build finishes. Nothing is emailed to you, because email is the least private channel either of us has.
01
Take the address from the client areaServices → your machine. The IPv4, the port and the initial root password are on that panel and nowhere else.
02
ConnectPort 22 unless you asked for another.
ssh root@203.0.113.10
03
Install your key and shut the door behind youPassword logins are the first thing scanned for. Put your key in place, then turn passwords off.
ssh-copy-id root@203.0.113.10
sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
systemctl restart ssh
04
Check you are not locked out before you close the sessionOpen a second terminal and log in again. Never close the first one until the second one works.
Locked yourself out anyway? Ask for a console from the client area — it is out-of-band and does not need SSH to be working.
A misconfigured firewall rule is the most common way to lose a machine, and it is entirely recoverable.
01
Request itServices → the machine → Open a console. An engineer sees the request immediately.
02
You get out-of-band accessThe same screen you would have standing in front of the rack, over an encrypted session. It works when the network stack is broken, when SSH is down and when the disk will not mount.
03
Fix what you brokeUsually one line in a firewall or sshd config. Reboot into single-user mode from the console if you need to.
A console session is never logged as a keystroke record. What you type on it is not retained by us in any form.
Running a Tor exit? Set a PTR that says so. It saves every operator who sees your traffic a research task, and it saves you the abuse reports that come from them guessing.
Closed by default on every new machine. Not to stop you sending mail — to stop an unattended machine acquiring a reputation the rest of the range then inherits.
01
Ask, and say what it is forOne sentence is enough. We are checking that a human is behind it, not auditing your business.
02
Set your PTR before you send anythingSee the reverse DNS entry above. Sending first and fixing DNS later means starting your reputation in a hole.
03
Publish SPF, DKIM and DMARCAll three. Two out of three is a deliverability problem you will spend a week diagnosing.
Bulk unsolicited mail is prohibited by the acceptable use policy and always will be. Transactional mail, newsletters people asked for and your own correspondence are not.
The order of these steps is the whole point. Allow SSH before you set the default policy, every single time.
01
Allow what you need firstSSH, then your services.
ufw allow 22/tcp
ufw allow 80,443/tcp
02
Only then set the defaultReversing these two lines is how people end up requesting a console.
ufw --force enable
03
Verify from somewhere elseFrom another machine, not from the session you already have open.
nmap -Pn -p 22,80,443 203.0.113.10
DDoS filtering happens at the border and is not affected by anything you do here. Your firewall handles what gets through to your ports; ours handles what never reaches them.
A snapshot is a point-in-time copy on the same storage as the machine. It is excellent against your own mistakes and useless against the storage failing.
01
Take one before anything irreversibleMajor upgrades, migrations, that one command you are not sure about.
02
Keep the ones that matter off the boxPull them to object storage or somewhere else entirely. A backup that shares a fate with the original is not a backup.
03
Restore-test onceAn untested backup is a hypothesis. Restore it somewhere harmless and confirm the data is actually there.
Snapshots are stored encrypted. We hold no key to the contents of a disk you encrypted yourself, which also means we cannot rescue it for you.
The strongest privacy guarantee on this platform is one we have no part in. Encrypt with a key we never see and the question of what we would hand over stops being a policy question.
01
Encrypt a data volume with LUKSSimplest on a second volume rather than the root filesystem.
cryptsetup luksFormat /dev/vdb
cryptsetup open /dev/vdb data
mkfs.ext4 /dev/mapper/data
02
Unlock it yourself at bootOver SSH after a reboot, or with a key file you keep elsewhere. Do not store the passphrase on the machine.
03
Accept the tradeA reboot needs you. That is the cost, and it is the reason the guarantee is real.
Full-disk encryption with remote unlock via an initramfs SSH server is possible too. Ask for a console during setup so a typo is recoverable.
Windows machines with 3389 open are found within minutes of being switched on. Three changes remove almost all of that exposure.
01
Require Network Level AuthenticationIt refuses the session before a login screen is ever drawn, which removes the brute-force surface entirely.
02
Restrict RDP to your own addressesWindows Firewall, scoped to the addresses you actually connect from. If they are dynamic, use a VPN endpoint on the same machine instead.
03
Rename Administrator and set a lockout policyBoth are two minutes of work in Local Security Policy and both are worth it.
DDoS filtering covers the network layer. It cannot tell a legitimate RDP login from a hostile one — that part is yours.
Your account holds a balance and can order services. It deserves more protection than the machines do.
01
Use a password nothing else usesThere is no identity document behind this account, which means no support agent can ever restore it for you. That is the trade you chose and it is worth respecting.
02
Turn on two-factor authenticationClient area → Account. Any TOTP application.
03
Keep the account key somewhere offlineIt is required to confirm a withdrawal if two-factor is not enabled, and it cannot be reissued by anybody.
We hold a hash of your password and nothing else. Losing both the password and the email address on the account is unrecoverable, by design.
Usually nothing, and that is the intended answer. Filtering is always on at the border and volumetric traffic never reaches your port.
01
Check whether it is actually reaching youIf your port is not saturated, the filtering is doing its job and the attack is somebody else's problem.
ss -s; vnstat -tr 10
02
Tell us if it is application-layerLayer 7 filtering has to understand what a normal request to your application looks like, so it is configured with you rather than guessed at.
03
Do not expect an invoiceMitigation is not metered here. An attack costs you the same as a quiet Tuesday.
We will never null-route you as a first response. If it ever came to that, an engineer would be talking to you before it happened.
Everything runs from one balance. You top it up, services draw from it, and there is no invoice to chase and no card to expire.
01
Choose an amount and an assetMinimum thirty dollars. Larger top-ups carry a bonus that is credited at the same moment as the payment.
02
Send exactly what the checkout showsThe address is yours alone and is not reused. Underpayments are credited for what arrived, not rejected.
03
The balance moves on confirmationBetween twenty seconds and twenty minutes depending on the chain. The table on the payments page has the figure per asset.
Balance never expires and is not withdrawn from you for inactivity.