Security
Last updated: 24 July 2026
Reporting a vulnerability
If you believe you have found a security issue, email hitliqiwei@gmail.com with details and steps to reproduce. Please give us a reasonable window to respond before public disclosure. We do not pursue good-faith researchers who follow responsible disclosure.
How raggate is built
- Never phones home. No scan content is ever sent to us. The default pipeline runs fully offline; if you configure a remote retrieval backend, only your infrastructure sees the queries. The local dashboard binds to loopback only.
- Signed licenses. Licenses are Ed25519-signed and verified offline; the private signing key lives only in the server environment, never in code or logs.
- Verified sessions & webhooks. Portal sessions are Clerk RS256 JWTs verified against a public key; Stripe and Clerk webhooks are signature-verified and fail closed.
- Secrets from the environment only. No secret is hardcoded, printed, or committed; this is enforced by automated tests in our CI.
- Least data on the wire. The paid checkpoint carries only your license token, an idempotency id, and a resource kind + credit amount (a count) — never your content.
Our honest threat model
The paid client ships as a compiled machine-code binary, which raises the bar against casual inspection and license tampering. We are candid that this is depth, not the wall. The durable enforcement is the server-side credit ledger, checked when a paid action runs. A tampered client still cannot spend credits it does not have.
Data & hosting
The portal runs on Render; authentication is via Clerk and payments via Stripe. See our Privacy Policy for what we collect and from whom.