Security

How your code runs

Submitted code never runs in the web application. It is sent to a separate execution service reachable only over an internal token.

Each run gets a throwaway container with no network access, a memory cap, a single CPU, a process limit, dropped capabilities and a read-only root filesystem. A ten-second wall clock applies, and the container is destroyed after the run.

SQL answers run against a database created for that run and dropped immediately afterwards, under a statement timeout.

Accounts

Passwords are hashed with bcrypt and never stored or logged in the clear. Sign-in, sign-up and password-reset endpoints are rate limited.

Reset links are single-use, expire after an hour, and only a hash of the token is stored.

Payments

Stripe handles card data; we never see it. Webhooks are signature-verified and processed idempotently, so a replayed event cannot grant a second entitlement.

Reporting a problem

Email security@buildstep.org with enough detail to reproduce the issue. We aim to acknowledge within two working days.

Please do not run automated scanners against production, and do not access or modify data that is not yours. Good-faith research reported this way will not be met with legal action.