Last updated: 14 July 2026.
Security is central to BastionTrail's design. This page summarizes how we protect the data you entrust to us. Questions or vulnerability reports: support@bastiontrail.com.
BastionTrail uses an outbound (push) model: your Git server sends webhooks to us. We never require inbound access to your network, no agent runs on your servers, and no firewall port is opened.
Every call from Jira is authenticated by validating the Forge Invocation Token (RS256) against Atlassian's published keys, with issuer, audience and expiry checked and enforced in production. Every inbound webhook is verified against a per-installation secret using constant-time comparison. Events are de-duplicated by a deterministic content hash.
All traffic is encrypted in transit with TLS. Data at rest is stored in a managed PostgreSQL database with full-disk encryption at rest.
Each installation's data is scoped to that installation. We store only the metadata needed to link events and build the audit trail (commit, branch, merge-request and deployment references and URLs, Jira issue keys, commit author name, timestamps). We do not store source code, passwords, or payment data.
When a customer uninstalls the app, an uninstall trigger automatically erases all of that installation's data from our backend — events, synced project keys and health state. Deletion or export can also be requested at any time.
Atlassian (Forge runtime and Invocation Token), Railway (backend and PostgreSQL) and Cloudflare (DNS and TLS). See the Privacy Policy and Data Processing Addendum.
Please report suspected vulnerabilities to support@bastiontrail.com. We aim to acknowledge within two business days and will keep you informed of remediation.