Shared responsibility
This content is not available in your language yet.
TebibHost runs the cloud; you run what’s in it. Where the line sits:
| Area | TebibHost | You |
|---|---|---|
| Data centre, hardware, power, network uplinks | Yes | |
| Virtualization, storage cluster, platform network | Yes, including patching | |
| Isolation between customers (VMs, VPCs, accounts) | Yes | |
| The console, API and their availability | Yes | |
| OS images when a VM is created (current, with the guest agent) | Yes | |
| The operating system inside your VMs after creation: updates, hardening, users | Yes | |
| Your applications, their configuration and their secrets | Yes | |
| Security groups and which ports are open | Safe defaults (inbound closed) | Yes |
| Who in your organization can do what (IAM), MFA, access keys | Tools and safe defaults | Yes |
| Backups of your data, and copies outside the region | Yes | |
| Disk replication inside the region | Yes | |
| Abuse sent from your resources | Detection and blocking | Yes |
In practice
Section titled “In practice”- Patch your VMs. Turn on automatic security updates (
unattended-upgradeson Ubuntu and Debian,dnf-automaticon Rocky and AlmaLinux). - Keep inbound closed except what must be public; open SSH to your own networks only.
- Use MFA and least privilege for people; expiring, network-restricted keys for programs.
- Back up. Snapshots roll a VM back, but they live on the same storage as the VM. Keep copies of important data somewhere else too.
What TebibHost does about abuse
Section titled “What TebibHost does about abuse”TebibHost blocks outbound SMTP (port 25) and caps new outbound connections for everyone. A VM found sending attacks or spam can be stopped and held for review; its page then shows why, and it can’t be started until the hold is lifted. Reports and questions go to abuse@tebibhost.com. See the acceptable use policy.