Security

Effective: 21 August 2026

How Sahabti is built and operated. We are in beta, so some of what a mature provider offers is not here yet — this page says where.

Infrastructure

Sahabti runs on Proxmox VE clusters on hardware we own and operate — not resold capacity from another cloud. Tenant workloads run as containers on that cluster. We will name the data-centre facility and region on request at [email protected].

Public web traffic reaches us through Cloudflare. The origin has no inbound ports open to the internet: the connector dials out, so there is no public address to scan or attack directly. That also gives us Cloudflare's DDoS mitigation in front of every console and API.

Encryption in transit

• TLS 1.2 minimum on the public edge, with TLS 1.3 enabled.
• Every plain HTTP request is redirected to HTTPS with a permanent redirect.
• HSTS is sent on every response with a two-year max-age covering all subdomains, so a browser that has reached us once will not try HTTP again.
• Automatic HTTPS rewrites are on, and email is sent over STARTTLS or implicit TLS.

Traffic to a tenant's own database instance is a direct TCP path you control; whether it is encrypted depends on how you configure that engine.

Encryption at rest

Passwords are stored as salted, memory-hard hashes (scrypt). API tokens are stored hashed — the value is shown once at creation and cannot be recovered from us. SSH keys are stored as public keys only.

Whole-disk encryption of the cluster storage pool is not currently in place. We do not claim it, and if it is a requirement for you, ask us before you build on the platform.

Tenant isolation

• Every workspace gets its own SDN network. A tenant's instances cannot reach another tenant's private network — the isolation is in the network fabric, not in an application check that could be bypassed.
• Outbound traffic leaves through a per-tenant NAT router rather than straight onto a shared segment.
• Every instance NIC is bandwidth-capped from its plan, and shared ingress carries a flat org-wide aggregate cap. One tenant cannot starve the uplink for everyone else.
• Quotas per plan bound how much a single account can provision at all.

Account security

• Email verification is required before an account can be used — a sign-up cannot provision anything until a one-time code sent to that address is entered.
• Passwords must be at least 12 characters with upper case, lower case and a digit.
• Sign-in, sign-up, password reset and one-time-code endpoints are rate-limited per IP, with the counters held in the database rather than in memory — so limits survive a restart and are shared across replicas instead of being multiplied by them.
• Sessions are listed in account settings with their device and last use, and can be revoked individually.
• Optional sign-in with GitHub or Google. Passwords for those providers never reach us.
• Workspace API tokens are scoped to the workspace, capped at the permissions of the person who created them, and independently rate-limited so a leaked token has a bounded blast radius.

Staff access

Operator access to production runs over a private, zero-trust network path; there is no publicly exposed administration interface, and access is limited to the people who operate the platform. Actions taken from the operator console are written to an append-only internal audit trail recording who acted, on what, and when.

We reach a customer instance only to resolve a support request you raised, to act on an abuse report, or to restore service during an incident. If we sign into your account to help you, that session is recorded in our internal audit trail; you can ask us for a record of staff access to your account at [email protected].

Abuse controls on public tenant endpoints

Customer-deployed web applications are served from sahabti.app, each on its own subdomain. That is a different domain from sahabti.com, on purpose: customer code never shares a cookie scope with our console, API or identity service, and each customer's site is isolated from every other's. Anything you reach on *.sahabti.app is a customer's site, not ours. Public database instances are not named at all — they are reached at an address and port allocated to them, and nothing customer-controlled is published under sahabti.com.

To report abuse on a *.sahabti.app site — phishing, malware, spam, attack traffic, illegal content — email [email protected] with Abuse at the start of the subject line and the full hostname. Reports of active phishing, malware or attack traffic are handled first; we aim to respond to every abuse report within 2 business days.

What stops a tenant workload from being used against other people:

• No anonymous provisioning. An account cannot create anything until its email address is verified with a one-time code.
• No direct public exposure by default. Instances egress through a NAT router. A dedicated public IP is not available on the free plan — free-tier workloads share ingress, so the cheapest path for an abuser is also the least useful one.
• Bandwidth caps per plan, on both the instance NIC and the public leg of the NAT router, which bounds outbound flood and amplification traffic.
• Quotas per plan on how much can be provisioned.
• Published acceptable-use rules with immediate suspension for active phishing, malware, attack traffic or CSAM — see the acceptable-use and suspension sections of the Terms of Service.
• A monitored abuse channel, [email protected]. We aim to respond within 2 business days, and we treat active phishing, malware and attack traffic as our highest priority.
• Ownership records. Every instance is tied to the workspace and account that created it, so a suspension is scoped to the responsible account rather than to a shared address.

What we do not do: pre-screen customer workloads, or inspect the contents of customer instances looking for policy violations. We act on reports and on platform-level signals.

Monitoring and incident response

Services emit structured request logs with a request id, and platform health is published at status, which reads the control plane live. We are a small team and do not staff a dedicated on-call rotation; during an incident we post what we know to the status page as soon as we can.

For a personal data breach, our notification commitment is in the DPA.

Backups

You can take instance snapshots and backups from the console. We do not currently run automatic scheduled backups on your behalf, and we do not offer a recovery-time guarantee. Keep independent copies of anything you cannot lose.

Compliance

Sahabti holds no third-party security certification today. We are not SOC 2 audited and not ISO 27001 certified, and we will not imply otherwise. We will say so plainly here when that changes.

We will answer a security questionnaire as best we can, and the DPA sets out the assurance and audit rights that come with a customer relationship.

Reporting a vulnerability

Send it to [email protected]. Include enough detail to reproduce it: affected URL or endpoint, steps, and what you were able to access. Our disclosure contact is also published at /.well-known/security.txt.

What to expect. We are a small team without a dedicated security function, so we do not promise a fixed response clock. We aim to acknowledge a report within 5 business days, we will tell you what we intend to do once we have assessed it, and we will credit you in the changelog when a fix ships if you would like us to.

Rules of engagement. Test only against your own account and your own instances. No denial of service, no traffic that degrades other tenants, no social engineering of our staff or customers, and no accessing or exfiltrating another customer's data — if you find a path to someone else's data, stop and report it. Research conducted within these rules is welcome and we will not pursue legal action over it.

We do not currently run a paid bug bounty.

Contact

[email protected] for everything. Start the subject line with Security, Abuse or Privacy — those three jump the support queue.