NULLRUNControls that protect
your data.
The controls we apply to the execution paths that run through NullRun, grouped by what each one defends.
Data protection
Encryption in transit and at rest, and how it is backed up.
AES-256 encryption at rest for sensitive columns
TLS 1.3 at the edge, with a TLS 1.2 fallback for older clients
Hash-chained, append-only audit log with cryptographic tamper detection
Strict transport-security headers on every public response (HSTS, CSP, X-Frame-Options, Referrer-Policy, Permissions-Policy)
Daily database snapshots (pg_dump + gzip) on the production host, integrity-checked by an automated restore test on every run
Restore drill cadence formalised against the daily snapshot
Operational security
How the platform resists abuse, outages, and cross-tenant contamination.
Fail-closed budget enforcement: missing or unreachable spend data means reject, never silently allow
Server-minted per-execution tokens bound to the issuing key. Replays and cross-org reuse are rejected.
Idempotency on the two billing endpoints. A retried /gate or /track cannot double-bill, because the dedupe key is persisted with a unique constraint rather than held in memory
Two-phase API key rotation with an in-flight drain window. Revoking does not lose in-progress reservations.
Outbox + dead-letter queue for SDK event ingestion, with hourly reconciliation against the audit log
Edge geo-block (MaxMind GeoIP): hard-block sanctioned jurisdictions, divert high-risk traffic to a waitlist
IP-level sanctions defence at signup: every signup is screened against the comprehensive-sanctions jurisdiction list before account creation; designated persons whose travel or residency places them in an eligible jurisdiction are caught by the IP-level check and by operator review
Per-tenant scoping enforced on every data access path, with database-level access controls backing application-layer checks
Layered name-and-email sanctions screening on signup against the OFAC SDN, EU CFSP, UK HM Treasury, and UN consolidated lists with weekly refresh
Identity and access
Authentication, authorization, and secrets.
Per-org RBAC with role separation between owner, admin, member, and viewer seats
Two-factor authentication for admin and owner roles (TOTP, with recovery codes)
Cryptographically signed SDK requests — unsigned or stale-timestamp calls are rejected before policy evaluation
Per-connection encryption keys injected from environment configuration; never logged, never returned by the API
Secrets scrubbed from logs before emission — a deny-list of secret-shaped field names plus a match on `KEY=VALUE` secret patterns
Hosted secret manager (KMS / HSM-backed) for production keys
Compliance and monitoring
Audits, alerting, and the disclosure posture you can hold us to.
Continuous monitoring and alerting via Prometheus + Alertmanager, with Slack as the primary notification channel
Centralized audit log retention aligned with the windows in our Privacy Policy §5
SOC 2 Type II
Independent external security review and penetration test by a third-party firm
Public status page with historical uptime and incident postmortems
Compliance evidence export — automated evidence collection aligned with SOC 2 trust criteria, refreshed on every change to the control matrix
Vulnerability disclosure
We commit to a coordinated response for any report sent to the address below.
Found a security issue? Email support@nullrun.io with [security] on the subject line, plus a reproduction, impact summary, and any technical context you can share. The prefix routes the message to the security rotation rather than general support. We acknowledge within 2 business days, triage within 5 business days, and credit reporters in the post-fix advisory unless you ask to remain anonymous.
In-scope: any NullRun-controlled domain (*.nullrun.io) and the public API at api.nullrun.io. We do not permit testing that degrades service for other tenants; please stop and contact us if you find a flaw that does.
For non-security issues, write to support@nullrun.io without the [security] prefix.
Infrastructure and sub-processors
Where your data lives and which third parties we rely on.
Primary region: Frankfurt, Germany (DigitalOcean FRA1). Data at rest stays in that region, and the daily backup snapshot is written to that same region, on the production host.
Who can reach the service. The edge geo-block is a sanctions control, and it is stricter than a sanctions list. Sanctioned jurisdictions are refused outright. EU, EEA, UK, Switzerland, China and India are treated as high-risk, no service: the marketing pages divert to a waitlist and the API is refused. The check runs at the edge on every request and fails closed if the GeoIP database cannot be read. We host in Germany and publish this page, our Privacy Policy and our DPA, so you can see where the service runs and which terms cover it.
Sub-processors as of this page version:
- DigitalOcean Holdings, Inc — hosting (Frankfurt, Germany — DigitalOcean FRA1)
- S3-compatible object storage (AWS S3 in prod, MinIO-compatible in dev) — available as a backup target for a second copy of the snapshot. It is not part of the daily run today, so no data reaches it. The Postgres snapshot itself is compressed, not client-side encrypted; configuration backups are encrypted before upload. See Privacy Policy §5.
- Slack Technologies, LLC — outbound alerting and on-call notifications (alert bodies may contain redacted decision summaries; alert channel configuration is per-org)
The edge geo-block resolves the requesting IP to a country with the MaxMind GeoLite2-Country database, loaded locally at the edge. The lookup result is never transmitted to MaxMind and no data is sent to them, so MaxMind is not a sub-processor; its only role is deciding whether an IP belongs to a sanctioned or otherwise high-risk jurisdiction.
This is the operational sub-processor subset. The full sub-processor list, including transactional email, payment, and OAuth identity providers, lives at /privacy §6. Material changes are announced in the changelog.
Recovery objectives
Targets we measure restores against, not contractual commitments.
RPO = 24 hours. Worst-case data loss between the last successful daily backup and a regional outage.
RTO target = 4 hours. Time to restore service from a cold secondary region after a primary-region failure.
Track record so far comes from manual restore drills; a fixed cadence is being formalised (see Data protection above).
Disclaimer. RPO and RTO figures are operational targets we measure against; they are not a service-level commitment and do not give rise to credits, refunds, or breach claims. For customers who need contractual recovery guarantees, those are negotiated on a per-customer basis under Terms §11 (per-customer amendment).