Built to be trusted with production
Alaf Server is explicit about where your data lives, who can touch it, and how self-hosted instances talk to the cloud. Here's the short version — the docs go deeper.
Data ownership
Local and server projects live only in your instance's database. Cloud projects are canonical on Alaf Server Cloud. A resource is either fully local or fully cloud — never split.
Permission model
Every request passes one permission plane — role + resource grants. Denied access returns 404, never confirming a resource you can't see.
Local ↔ cloud boundary
One gateway, one owner identity. Proxied requests forward no local cookies or org ids, and there are no hybrids — a local bug can't reach cloud-owned data.
Credential custody
The GitHub App key lives only on Alaf Server Cloud; self-hosted instances mint tokens through it. Cloud sessions and secrets are encrypted at rest and never exposed to the browser.
Self-host or cloud
Run AlafServer entirely on your own infrastructure with no data leaving your network, or connect Alaf Server Cloud when you want managed compute. Your choice, per project.
Compliance & responsible disclosure
For the strictest requirements, self-hosting keeps all project data and network traffic inside your own infrastructure. We're actively working toward formal certifications; this page reflects the platform's current, factual security posture.
Found a vulnerability? Please report it privately at security@mtntasci.com.