Built with security as a first principle.
Isolated build containers, signature-verified authentication, and encryption at rest for your secrets and deployment data. Below is what is actually in place — and, at the bottom, what is not.
What protects your account and your code.
Isolated build containers
Every build runs in its own container and is torn down afterwards. One project's build never shares a filesystem, process space or environment with another's.
Least-privilege build credentials
The credentials a build runs with can write published output and do nothing else. They carry no read access to other customers' output, no database access, and no access to our secrets store — so a hostile build has nothing to read.
Encryption at rest
Environment variables, secrets, build output and database records are stored with AES-256 server-side encryption. Traffic to and from the platform is served over HTTPS.
Signature-verified sessions
Every authenticated request re-verifies the token's signature, issuer, audience and application client against the identity provider. There is no path that assumes a session when verification cannot be performed — it fails closed.
Secrets never live in source
Credentials flow from the deployment pipeline's secret store into the runtime environment at deploy time. None are committed to the repository, and none have a hardcoded fallback value that would let a missing variable quietly half-work.
Cryptographic randomness
Anything that acts as a credential or a proof — session material, domain-verification tokens — is generated with a cryptographic random source, never a general-purpose random number generator.
Rate limiting on every entry point
Sign-in, sign-up, password reset, one-time codes and the general API each have their own budget, so pressure on one does not consume another's. Exhausting a budget returns a refusal, not a slower success.
Bot protection that fails loudly
Sign-up and sign-in are checked for automated abuse. If that check is not configured, the platform records that no check ran — it never reports an unverified request as verified.
Browser hardening headers
Responses set framing, MIME-sniffing, referrer and permissions policies, so the dashboard cannot be embedded in a hostile page or coaxed into leaking a URL to a third party.
Continuous backups
Point-in-time recovery is enabled on the databases holding account, project and billing records, so a table can be restored to any second within the retention window.
Storage closed by default
Our storage buckets have public access blocked at all four AWS settings. Published sites are served through the application, not by exposing a bucket to the internet.
Coordinated disclosure
We publish an RFC 9116 security.txt. Reports go straight to the maintainer and get a human reply. There is no bug bounty — there is no reward to claim, only a fix.
Gaps we would rather you read here.
Every platform has them. Ours are listed because you will find out eventually, and finding out later is worse.
No two-factor authentication
Accounts are protected by a password and email verification. TOTP is not implemented, and the security settings page says so rather than showing a toggle that does nothing.
No third-party audit or certification
We hold no SOC 2 or ISO 27001 attestation and no external assessor has reviewed us. The controls above are verifiable by using the product — not signed off by an auditor.
One region, no failover
Everything runs in Mumbai. That is good for latency and for data residency, and it means a regional outage is an outage for us too. There is no cross-region standby, and our Terms carry no uptime SLA.
Found something?
Please tell us before you tell anyone else. Include steps to reproduce and we will confirm receipt, tell you what we found, and let you know when it is fixed. Reports are read by the maintainer directly — not triaged by a vendor.