Security

Vela is built on AWS Sydney, owned and operated by Starboard Solutions Pty Ltd. Every customer’s data lives in its own logical partition, encrypted at rest. Every integration uses standard OAuth 2.0 — we never store your Microsoft, Xero, or Google passwords. Cross-tenant data access is blocked at the cloud-provider level, not just in our application code.

This page is honest about how the system is built. If you’re evaluating Vela for a security-conscious team, the points below should answer most questions. If they don’t, get in touch and we’ll respond directly.

All customer data is stored in AWS Sydney (ap-southeast-2). It does not leave Australia. Backups, replicas, logs, and telemetry all stay within the same region.

The exceptions are documented third-party processors — Stripe (billing), Microsoft Graph (your inbox, by your authorisation), Xero (your accounting, by your authorisation), PostHog and Sentry (product analytics and error tracking). These operate under their own published privacy and data-handling commitments; see our Privacy Policy for the full list.

Every row of customer data in our database is keyed by a tenant identifier (TENANT#<your-tenant-id>). Application code is responsible for setting that key correctly — but we don’t rely on application code alone.

Lambda functions that act on behalf of a single tenant assume a per-request IAM role that is session-tagged with the caller’s tenant ID. The IAM policy on that role uses an AWS condition that requires every DynamoDB action’s leading key to match the session tag. In plain English:

The same role has an explicit Deny on dynamodb:Scan and on table-level control-plane actions (delete, restore, export). A full-table read or a destructive table operation cannot be performed from this role at all.

We request the minimum scopes needed to deliver the features you turn on. Specifically:

• Microsoft Graph (Inbox): read your inbox and draft replies for your approval, read your calendar. Delegated permissions only — Vela acts on your behalf, never as an application-level identity that could send mail without your consent.
• Microsoft Graph (what we never request): Mail.Send as application permission, Files.ReadWrite.All, or any tenant-wide admin scopes.
• Xero: read invoices and contacts, create/update invoices and payment reminders for the organisation you connect. Scoped to the single Xero org you authorise; never the wider practice or partner data.

You can review the exact scopes Vela has requested at any time in Microsoft Entra (Enterprise applications → Vela) or in Xero (My Xero → Connected apps), and revoke them yourself.

• Infrastructure as code. Every piece of cloud infrastructure is defined in AWS CDK and version-controlled. There are no “click-ops” resources — drift between code and reality is detected on every deploy.
• Least-privilege roles. Each Lambda function has its own execution role with the narrowest set of permissions it needs. Functions that handle one tenant’s data hold a different (more restrictive) role than functions that intentionally span tenants (e.g. the Stripe webhook handler).
• Point-in-time recovery. The primary database has continuous point-in-time backups enabled and a RETAIN deletion policy on production tables — accidental stack deletion cannot drop the table.
• Alerting. CloudWatch alarms publish to SNS for production errors, IAM policy changes, and abnormal billing patterns. The on-call inbox is monitored daily.
• Audit trail. Authentication failures, cross-tenant access attempts, and admin actions are written to an immutable audit log keyed by tenant. This log is queryable for incident response.

Vela uses a small set of well-known sub-processors to deliver the service. The current list:

• Amazon Web Services — hosting, database, identity, secret storage (Sydney, AU)
• Vercel — marketing site and web app delivery (global edge)
• Stripe — subscription billing and payment processing
• Microsoft — Graph API for inbox and calendar (your authorisation)
• Xero — accounting API (your authorisation)
• PostHog — product analytics
• Sentry — error and performance monitoring
• Anthropic — large-language-model inference for drafting and classification

Material changes to this list are notified to customers in advance via the in-product change log and (where the change affects data handling) by email.

Vela is built to be compliant with the Privacy Act 1988 (Cth)and the Australian Privacy Principles. We rely on AWS’s certifications (ISO 27001, SOC 2, IRAP) for the underlying infrastructure. We have not yet pursued our own SOC 2 audit — we’ll publish the report here when we do.

Security is a shared responsibility. We secure the platform; you secure your accounts. We recommend MFA on every Vela login, MFA on the Microsoft and Xero accounts you connect, and prompt removal of authorised users who leave your team.

If you believe you’ve found a security issue in Vela, please tell us before you tell the world. We will respond within one business day and work with you to verify, fix, and (with your permission) credit you for the discovery.