Schedule C — Cloud

C.1 Service Scope

Sanya Cloud comprises three independently purchasable services:

• Cloud VPS — a Linux/Windows virtual machine with dedicated vCPU, RAM, and NVMe SSD storage as specified in the plan you ordered (Starter, Growth, Scale, Power, or a custom configuration).
• Storage Box — managed off-site storage accessible by SFTP, FTPS, SAMBA, BorgBackup, rsync, or WebDAV. Sized as ordered (1 TB, 5 TB, 10 TB, 20 TB, or larger by quote).
• Object Storage — S3-compatible bucket storage accessible at s3.cloud.sanya.tz via standard AWS-style access keys and any S3 client (AWS CLI, MinIO, rclone, application SDKs).

Each service may be ordered independently — there is no requirement to bundle them.

C.2 Shared-Responsibility Model

Sanya Cloud follows the industry-standard shared-responsibility model. The line between "ours" and "yours" is sharp:

C.2.1 We Cannot Read Inside Your VPS

Once your VPS is provisioned, we have no operational access to its operating system, files, memory, or running processes. We do not install monitoring agents. We do not have your root password. Our control plane operates one level above the VPS — at the hypervisor — and can:

• Power the VPS on, off, or restart it.
• Take a snapshot of the disk image.
• Resize CPU, RAM, or disk (with your authorisation).
• Suspend network access.
• Delete the VPS.

It cannot read or modify the content of your disk in flight. To inspect or recover data inside the VPS, you must use the console (initial root credentials are emailed at provisioning; we recommend you change them immediately) or SSH in with your own keys.

C.2.2 Implications for Data Processing

Because we cannot access data inside your VPS, our role under Tanzania's PDPA Act 2022 differs from our role for Sanya Business or Kanisa MS. For Cloud VPS we are an infrastructure provider, not a processor of your application's personal data. Your data-controller obligations therefore extend to choosing, configuring, and securing the VPS appropriately for whatever data you put on it. If you require a formal Data Processing Agreement that covers this allocation, see /legal/dpa.php.

C.2.3 What Triggers Us Looking

We may inspect metadata about your VPS (CPU load, network throughput, IP-level packet headers) if we are investigating an abuse complaint, network attack from your IP, or compliance with a Tanzanian regulator's order. We will not access the contents of your disk except under a Tanzanian court order, in which case we will notify you unless legally prohibited.

C.3 Hardware, Region, and Underlying Infrastructure

C.3.1 Specifications

Each plan ships with the vCPU, RAM, NVMe disk, and bandwidth allocation stated at purchase. These are minimum guarantees — bursts above the allocation are best-effort and not guaranteed.

C.3.2 Region

You choose a region at order time. Currently supported: Tier-3 European data centres (Germany or Finland). Johannesburg and Nairobi regions are available on request for latency-sensitive workloads. Once provisioned, region changes require destroying and re-provisioning the VPS at the new region — your responsibility to migrate data.

C.3.3 Underlying Sub-Processor

The specific infrastructure operator we use to deliver Sanya Cloud is named in DPA Annex B.1. We may change sub-processors with at least 30 days' notice. Any change will preserve at least the same level of security and compliance.

C.3.4 Hardware Refresh

We may migrate your VPS to newer underlying hardware at any time, with reasonable notice. Such a migration is transparent (a snapshot + restore at the new host, with ~60 seconds of network downtime).

C.4 Uptime SLA

We target 99.9% monthly uptime for VPS, Storage Box, and Object Storage (≤ 43.8 minutes of unplanned downtime per month). General SLA exclusions from Master §8 apply. Service credits for missed SLA:

• 10% of that month's fee for the affected service if uptime is between 99.0% and 99.9%.
• 25% if between 95.0% and 99.0%.
• 50% if below 95.0%.

Credits apply to your next invoice. Credit requests must be filed within 30 days of the affected month at billing@sanya.tz with the VPS ID and approximate downtime windows. Downtime caused by you (e.g., misconfigured firewall, your own SSH lockout, your app crash) does not count toward SLA.

C.5 Billing & Renewal

Sanya Cloud is billed in advance per Master §4, in one of three cycles:

• Monthly — default; full plan price; renews monthly.
• Quarterly — 3 months prepaid; ~5% discount vs monthly.
• Annual — 12 months for the price of 11 (~8% discount).

Renewal is automatic; a reminder + invoice is sent 14 days before due. Mid-cycle plan upgrades are pro-rated; downgrades take effect at next renewal. Storage Box and Object Storage follow the same cycles as the VPS they are linked to (or stand alone with the same options).

C.6 Refunds — Not Available

Sanya Cloud payments are non-refundable. Because billing is in advance and the underlying infrastructure cost accrues continuously regardless of whether you actively use the VPS, we cannot refund prepaid time. Specifically:

• No money-back guarantee. Test the service with a single monthly cycle if you're unsure.
• No pro-rated refund on cancellation. Cancelling mid-cycle ends auto-renewal; your service continues to the end of the paid period.
• Service credits are the sole remedy for missed SLA (§C.4).
• Exception: if Sanya Cloud is unable to provision a VPS at all due to capacity issues on our side, the prepaid fee is refunded in full.

Full refund policy in /legal/refunds.php.

C.7 Suspension & Deletion Clock

If a renewal invoice remains unpaid past its due date, the following timeline applies (consistent with Refund Policy §8.2):

Why the difference: our upstream infrastructure costs accrue continuously and do not pause when your invoice does. Shorter billing cycles get shorter retention windows because the loss on our side scales with how long we hold an unpaid VPS. Annual customers paid up front so we can hold the door open longer.

Before the deletion deadline you may restart the service by paying the overdue invoice — your data is intact, your IP is the same, and you regain SSH / console access to copy data out yourself. After the deletion deadline the disk image is wiped at the infrastructure level and cannot be recovered.

We do not extract data from a suspended VPS on your behalf. If you want a final disk image, the path is: (1) pay the overdue invoice, (2) the VPS comes back online with all data intact, (3) you SSH in or use the customer portal to take your own snapshot / disk image, (4) cancel. The same principle that applies to Sanya Host (Schedule A §A.11) applies here: the underlying suspension reason must be resolved before data access is possible.

If the suspension was caused by an AUP violation, regulatory order, or imminent security threat (Master §5.2) — in which case there may be no payment route to lift it — the VPS remains inaccessible and proceeds toward deletion on the standard clock. Keep your own off-site backups (Storage Box, external rsync target) for this scenario.

C.8 Snapshots & Backups — Your Responsibility

Sanya Cloud does not back up your VPS. There are no automatic snapshots, no scheduled backups, and no managed off-site backup service. Backing up everything inside your VPS — files, databases, configuration — is entirely your responsibility, on your own schedule, to your own destination.

C.8.1 Snapshots are manual, and are NOT a backup

Snapshots are not taken automatically. You create them yourself from the customer portal — typically before a risky change (an OS update, a configuration change, a global fix) so that if the change breaks something you can roll back to that exact point.

• A snapshot lives on the same hypervisor as your VPS. If that hardware or its storage fails, the snapshot is lost together with the VPS.
• A snapshot is a short-term "undo" point for changes you make — not a data-protection plan, and not something to rely on for routine data restore.
• Restoring a snapshot is an last-resort action, appropriate only for catastrophic situations (e.g., complete data loss on the server) when you have no better option.

C.8.2 No off-site backups from us

We do not copy your VPS to another location. If you need disaster recovery, you must configure it yourself — for example a nightly database dump and file sync to a Sanya Cloud Storage Box (§C.11) or to an external target (S3, another provider, your premises). You choose the tool, the schedule, and the retention.

C.8.3 Your own backups are the only thing protecting your data

Because we do not back up your VPS, your own application-level backups are the only thing standing between you and permanent data loss. We strongly recommend automated, off-site, application-consistent backups (a coordinated database dump rather than a raw file copy of a database under load). Do not depend on snapshots for this — they are neither off-site nor guaranteed application-consistent.

C.9 Customer Obligations

In addition to Master §3 and the AUP, on Sanya Cloud you specifically agree to:

• Maintain operating-system security. Apply patches promptly. Outdated kernels and unpatched services are the #1 cause of VPS compromise. We do not auto-patch your VPS.
• Manage credentials securely. Rotate the initial root password we emailed at provisioning. Use SSH keys, not passwords, for SSH. Use a 2FA-protected non-root account for daily work.
• Configure a firewall. Don't expose database ports or admin interfaces to the public internet. ufw, iptables, or firewalld are pre-installed depending on the image.
• Respond to abuse / security notices within 24 hours. If we detect outbound network abuse (DDoS attack from your IP, spam egress, malware C2 traffic), we will email you and may suspend if not remediated.
• Use the VPS for lawful purposes only. See the AUP. Sanya Cloud is not exempt from Tanzanian law just because you have root.
• Not impersonate Sanya or other customers. Do not configure reverse DNS to spoof another organisation's domain.

C.10 DDoS & Network Abuse Handling

Inbound DDoS: L3/L4 mitigation (volumetric, SYN flood, UDP amplification) is included free at the network edge. L7 (HTTP-level) protection is the customer's responsibility — we offer it as a paid add-on or it can be done with Cloudflare / your own WAF.

Outbound abuse: if your VPS is identified as the source of an attack (compromised, intentional, or via a misconfigured open-relay), we will suspend network access pending investigation. The shared-responsibility model means the compromise is yours to remediate; we will help with diagnosis but not with cleanup of your application code.

Sustained attack on your VPS: if your VPS becomes the target of an attack that we cannot mitigate at our edge (e.g., very large L7 flood directed at your application), we may temporarily null-route the VPS's IP to protect the rest of our network. We will restore the IP after the attack subsides.

C.11 Storage Box (Specific Rules)

• Purpose: off-site storage target for backups, photo libraries, NVR footage, file shares. Not designed as a public-download CDN.
• Access: SFTP, FTPS, SAMBA, BorgBackup, rsync, WebDAV. Each Storage Box gets isolated credentials.
• Retention: data remains as long as your subscription is active. On cancellation, deletion clock matches §C.7 for the original billing cycle.
• No execution: Storage Boxes do not execute code. They are storage targets only.
• Throughput: best-effort. Storage Boxes are bandwidth-shared with other Storage Box tenants on the same hardware.

C.12 Object Storage (Specific Rules)

• Endpoint: s3.cloud.sanya.tz. AWS-style signature v4 authentication. Buckets are private by default; you may set public ACLs at your own risk.
• Bundled allocation: 1 TB included free with every active VPS. Standalone Object Storage subscriptions are also available.
• Egress: first 1 TB/month outbound free. Beyond that, charged per TB at the rate published on /cloud.php.
• Object operations: PUT, GET, LIST, DELETE — unmetered (no per-request charges).
• Object lifecycle: standard S3 lifecycle rules supported (auto-delete after N days, auto-transition to cheaper tier). You configure these.
• Versioning: object versioning is opt-in per bucket. Use it for accidental-delete protection.
• Deletion: a DELETE request is immediate and (unless versioning is on) irrecoverable. Treat aws s3 rm the way you treat rm -rf.

C.13 Data Egress & Portability

You may export your data at any time. We will not charge an "exit egress fee" — our network egress allowances cover normal data movement out. Where we can practically help with a bulk transfer (e.g., to AWS S3 via rclone, or to your premises via a one-time disk image download), we will, at our cost for the first 1 TB.

For a VPS you may at any time:

• Download a full disk image (qcow2 / raw) via the customer portal — one free image per VPS per month.
• SSH in and copy data out by any means (rsync, scp, tar over SSH).
• Mount Object Storage as an S3 client and copy buckets directly.

C.14 Cloud Fees Schedule

Standard plan pricing is published at /cloud.php. Ancillary fees:

All fees are quoted in TZS, exclusive of VAT, and added to your next invoice unless paid upfront.