Security at AviateOps

Our security approach

We treat customer data the way we would want our own school’s data treated: stored only where it needs to be, encrypted in transit and at rest, isolated per tenant at the database layer, and accessible only to the people we explicitly grant access to. We use well-known managed providers for the parts of the stack that are easy to get wrong, and we layer defense-in-depth controls on top of them rather than relying on any single boundary.

Infrastructure

AviateOps runs on three managed providers, all operated from US regions:

• Vercel hosts the Next.js application (edge and serverless functions). We chose Vercel because their platform is SOC 2 Type II and ISO 27001 certified, secrets are encrypted at rest, and deploys are immutable and reviewable.
• Neon hosts our Postgres database in a US region. Neon is SOC 2 Type II certified, encrypts data at rest with AES-256, and supports point-in-time recovery and Row-Level Security — both of which we use.
• Cloudflare sits in front of every request for WAF, DDoS protection, bot scoring, and TLS termination. Cloudflare holds SOC 2 Type II, ISO 27001, and PCI DSS certifications.

We do not run our own servers, our own database, or our own edge — and we have no plans to.

Data encryption

• In transit: TLS 1.2 or higher on every connection between a browser, our edge, our application, and our database. HSTS is enabled with preload.
• At rest: All Postgres data is encrypted with AES-256 by Neon. Application secrets, build artifacts, and logs at rest on Vercel are encrypted by Vercel.
• Key management: Encryption keys are managed by our infrastructure providers (Neon, Vercel, Cloudflare) using their internal KMS. We do not handle raw key material, and no AviateOps employee has access to disk-level keys.

Authentication and access control

• Authentication is handled by Better Auth, an open-source library we self-host. Passwords, when used, are hashed with a modern algorithm (scrypt) — we never store plaintext passwords.
• Google SSOis supported and recommended: customers can sign in with their existing Google Workspace account and inherit their organization’s MFA and session policies.
• Sessions use HTTP-only, Secure, SameSite cookies with rolling expiry. CSRF protections are on by default for every state-changing request.
• Every person has their own account. We do not support shared logins, and we recommend customers do not share them either.
• Inside the app, role-based access control (owner, instructor, dispatcher, student) governs what each user can see and do. Permissions are enforced both at the application layer and at the database layer.

Network security

• Cloudflare WAF filters traffic before it reaches our origin and blocks common OWASP Top 10 attack patterns.
• DDoS protectionis provided by Cloudflare’s network at L3/4 and L7.
• Rate limiting is enforced on authentication and other sensitive endpoints to slow credential-stuffing and abuse.
• Admin endpoints (platform operations that touch more than one tenant) are IP-allow-listed and require an active session bound to a platform admin role.

Application security

• All database access goes through Drizzle ORM with parameterized queries. We do not concatenate user input into SQL.
• All inputs from the browser are validated on the server with typed schemas before they touch business logic.
• Postgres Row-Level Securityis enabled on every tenant-scoped table as a defense-in-depth layer — even if an application bug attempted to read another school’s data, the database would refuse.
• Dependabot watches our dependencies and opens pull requests for security updates. We review and merge those promptly.
• Every change goes through pull request review and CI (typecheck, lint, tests) before it can be deployed. Source lives in a private GitHub repository with branch protection on main.

Data isolation

AviateOps is multi-tenant. Each flight school is a separate tenant, and tenant data is segregated by Postgres Row-Level Security policies on every tenant-scoped table. Application queries always run as a database role bound to the active tenant, which prevents one school from reading or modifying another’s data even in the event of an application bug. A small number of platform operations (e.g. billing reconciliation) run under a separate elevated role that is not reachable from the customer surface.

Backups and disaster recovery

• Postgres backups are managed by Neon, with continuous WAL streaming.
• Point-in-time recovery is available for any moment within the preceding 7 days on our current plan.
• We can restore the entire database, or a single tenant’s data, from a recovery point.
• Vercel deployments are immutable — any previous version of the application can be rolled back in seconds.

Vulnerability management

• Dependency vulnerabilities are surfaced by Dependabot and the GitHub advisory database, and triaged on disclosure.
• Critical and high-severity issues are patched as soon as a fix is available — typically within days, faster if actively exploited.
• Lower-severity issues are batched into our regular release cadence.
• We follow coordinated disclosure for any vulnerability reported to us by a researcher (see “How to report a vulnerability” below).

Incident response

We have an internal runbook for security incidents. Confirmed or suspected incidents involving customer data trigger an on-call page to the engineering team, who assess scope and containment immediately. We commit to notifying affected customers in writing within 72 hours of confirming an incident that impacts their data, with the scope of impact, the remediation taken, and what we are doing to prevent a recurrence. After material incidents we run a blameless post-mortem and share a summary with affected customers.

Compliance posture

AviateOps is a pre-revenue company and we are not yet certified against SOC 2, ISO 27001, or any other third-party security framework. We are honest about that.

We have designed and operate our controls to be aligned with the SOC 2 Trust Services Criteria (security, availability, confidentiality), and we intend to pursue formal SOC 2 Type I and Type II reports once revenue and customer count justify the audit cost. When that work is underway we will publish progress on this page.

• PCI DSS: all card data is handled by Stripe. AviateOps never sees raw card numbers, and we rely on Stripe’s PCI DSS Level 1 certification. We are not in PCI scope beyond the integration tokens we hold.
• GDPR: see our Privacy Policy for how we handle data subject requests and the lawful bases on which we process personal data.
• HIPAA / FedRAMP: AviateOps is not designed for protected health information or US federal workloads and should not be used for either.

Subprocessors

We use the following subprocessors to operate AviateOps. We will notify customers in advance before adding a new subprocessor that processes customer data.

• Vercel, Inc. — application hosting, edge and serverless functions, CDN (United States).
• Neon, Inc. — managed Postgres database and backups (United States).
• Cloudflare, Inc. — WAF, DDoS protection, TLS termination (global edge; United States-headquartered).
• Stripe, Inc. — payment processing and card data handling (United States).
• Resend — transactional email delivery (United States).
• Google LLC — OAuth identity provider for customers who choose Google SSO (United States).
• GitHub, Inc. — source code hosting and CI (United States). GitHub does not store customer data.

How to report a vulnerability

If you believe you have found a security issue in AviateOps, please email hello@aviateops.com with the subject line “Security report”. Include reproduction steps, the affected URL or endpoint, and any proof-of-concept output. We will acknowledge your report within 2 business days.

We follow coordinated disclosure: please do not publicly disclose the issue until we have had a reasonable chance to investigate and ship a fix. We will credit you (with permission) once the fix is live.

In scope: the AviateOps web application and any subdomain we operate. Out of scope: findings against our subprocessors (please report those to the subprocessor directly), denial-of-service testing, social engineering of our team or our customers, and physical attacks.