Last updated: 2026-06-25.
Your stack runs on your cloud infrastructure. TryDirect's job is to provision it, deploy to it, and protect every credential, secret, and message in between. This page lists what we do today, the third-party scores that verify those claims, and what's on the security roadmap.
Independent verification
The fastest way to evaluate a hosting platform's security posture is to look at independent, publicly verifiable scans. These run on demand against try.direct and can be rerun by anyone.
Run your own scans:
- SSL Labs (Qualys) - current TLS configuration grade
- Mozilla Observatory - HTTP security headers score
- Hardenize - full domain hardening report
Transport encryption
- TLS 1.2 and TLS 1.3 only. Legacy TLS 1.0 / 1.1 and SSLv3 are disabled.
- Strong cipher suites only. No RC4, no CBC ciphers, no export-grade ciphers, no anonymous DH.
-
HSTS preload header:
max-age=31536000; includeSubDomains; preload. try.direct is in the Chrome HSTS preload list, so browsers refuse to load it over plain HTTP even before a redirect. - Let's Encrypt certificates auto-renew before expiry. Certificate transparency logs publish every issuance.
- Common TLS vulnerabilities (Heartbleed, POODLE, BEAST, CRIME) confirmed mitigated on the most recent scan.
Secrets management
Cloud credentials, API keys, SSH keys, database passwords, and OAuth tokens are stored in HashiCorp Vault. They never live in plain text in code, env files, container images, or backups.
- Each deployment gets its own scoped Vault token. Deployments cannot read each other's secrets.
- Vault is not exposed to the public internet. Service access is mediated by the platform's internal network only.
- Cloud credentials never reach the deployed stack. The provisioning step uses your cloud API token, then discards it. Your application containers do not hold DigitalOcean, Hetzner, AWS, or Linode credentials.
Account security
- OAuth2 sign-in with Google or GitHub - no password to phish.
- Two-factor authentication - TOTP (Google Authenticator, 1Password, Authy) and email one-time-passcode supported.
- Role-based access control - users, teams, and admin roles are isolated.
- OAuth2 access tokens are short-lived and rotated automatically.
Payments
- Card payments are processed by Stripe on Stripe-hosted checkout. Card data never touches TryDirect servers.
- PayPal payments are processed by PayPal on PayPal checkout pages, with the same isolation.
- Because card data never enters our environment, TryDirect qualifies for the simplest PCI DSS self-assessment level (SAQ-A). The formal attestation is in progress.
Deployment isolation
- Each customer's stack deploys to their cloud account, not to shared TryDirect infrastructure. There is no multi-tenant noisy-neighbour risk because there is no shared runtime to share.
- The on-server Status Panel agent uses HMAC-signed requests, replay protection, and an explicit command allowlist.
- SSH credentials for deployed servers are stored per-deployment in Vault, not on the TryDirect operator team's laptops.
Audit, monitoring, and error tracking
- Application errors are tracked in Sentry (frontend and backend). PII is filtered before transmission.
- Infrastructure uptime and host metrics are monitored by Zabbix.
- User-facing events (logins, password resets, deployments) are written to an immutable activity log per user.
- All third-party processors are listed publicly (see Data Processors below).
Privacy and data processing
- GDPR-aligned. We act as a data processor for customer-provided data and as a data controller for account data.
- EU customers can request a Data Processing Agreement (DPA) by emailing privacy@try.direct. A published, downloadable DPA is in preparation.
- Data subject requests (export, deletion) are handled within 30 days of receipt.
Sub-processors
Services that process customer data on TryDirect's behalf:
- Stripe - card payment processing
- PayPal - alternative payment processing
- Mailjet - transactional email delivery
- AWS SES - secondary email delivery
- Sentry - application error tracking
- Google Analytics 4 - anonymised traffic analytics
- Cloud providers - Hetzner, DigitalOcean, Linode, Vultr, Contabo, AWS, Oracle Cloud - only on customer instruction, deploying to the customer's own account
Reporting a security issue
If you find a vulnerability, please report it privately so we can fix it before it can be exploited.
- Email security@try.direct
- Acknowledgement within 48 hours
- Triage and fix plan within 7 days for confirmed high-severity issues
- Public credit on request after the fix ships
A
security.txt
file documents this contact in the format defined by RFC 9116.
Recent security work
- 2026 - self-administered penetration test completed against the public surface (information gathering and configuration review phases). Findings are tracked and being remediated on a published cadence.
- Anti-CSRF, anti-clickjacking, and content-type sniffing protections are enabled platform-wide.
- Backup files, .env files, .git directories, and dotfiles are not served by the web tier (verified by independent scan).
Roadmap
Honesty rather than aspiration: items below are in progress, not claims of current state.
-
Published DPA at
/legal/dpa- downloadable Standard Contractual Clauses template, countersignable by email. - PCI DSS SAQ-A self-attestation published.
- CSA STAR Level 1 - public Cloud Security Alliance self-assessment listing.
- Third-party penetration test with published summary.
- ISO 27001 certification - EU-focused information security management standard.
- SOC 2 Type II - US-focused operational controls audit.
- Public bug bounty program - recognition first, monetary rewards later.
Questions
Privacy / GDPR / DPA requests: privacy@try.direct
Vulnerability reports: security@try.direct
Compliance documentation requests (audit summaries, sub-processor agreements, security questionnaire responses): compliance@try.direct