Security at Infralyst
Infralyst is read-only first, conservative about changes, and transparent about how we handle your data.
Our security principles
Read-only by design
Infralyst connects to your AWS accounts and GitHub repos with the minimum access needed to analyze infrastructure and open pull requests. Apart from creating branches and PRs, everything we do is read-only.
Least privilege, scoped access
Access to your cloud accounts is granted via a Terraform-created IAM role with tightly scoped permissions. The GitHub App is limited to the repositories you select. You stay in control and can revoke access at any time.
Changes as code, not clicks
All changes land as small, reviewable Terraform PRs in your own repos. Infralyst never deploys directly to your infrastructure. Your team reviews, tests, and merges every change.
Simple, modern stack
We run on a modern Linux-based stack managed as code. Operating systems, libraries, and dependencies are kept up to date with security patches, and services run in hardened, private networks.
AWS, GitHub, and Slack access
AWS access
- •You add the Infralyst Terraform module to your infra repo.
- •The module creates a read-only IAM role so Infralyst can see your AWS resources and utilization.
- •We use that role to fetch the metadata and metrics needed for rightsizing. We don't need or request access to your application data.
GitHub & Terraform
- •You install the Infralyst GitHub App in your GitHub organization and choose which infrastructure repositories it can see.
- •Infralyst opens pull requests in those repos only, on dedicated branches.
- •We never push directly to main or merge changes on your behalf.
Slack
- •If you connect Slack, we use it only to send notifications and trigger PR generation from your channels.
- •We do not read or store the contents of your wider Slack workspace.
- •You can disconnect Slack at any time from your workspace settings.
Data we store (and don't store)
We store
- Account details you give us (like name, email, and workspace info).
- Infrastructure metadata and utilization needed to generate rightsizing recommendations.
- Configuration for your integrations (AWS role ARN, GitHub repo mappings, etc.).
- Product analytics that help us understand feature usage and improve Infralyst.
We don't store
- Your AWS access keys or secret keys – access is via role assumption, not long-lived credentials.
- Your application payloads or customer data.
- Database rows, S3 object contents, or logs from your production systems.
- Payment card details are handled by Stripe; our servers never see your full card number.
- Any secrets you don't explicitly configure in Infralyst.
Infralyst focuses on infrastructure metadata and usage patterns, not your application data. We never sell your data or use it for advertising. You can delete your workspace and its associated data at any time.
Encryption and infrastructure
Encryption in transit and at rest
All traffic between your browser, our API, and our integrations is protected with TLS. Sensitive data in our databases is encrypted at rest.
Our own infrastructure and models
We run our own infrastructure and host our own open-source AI models for analysis. We don't send your infrastructure data to third-party LLM APIs.
Limited employee access
Access to production systems is limited to essential personnel and requires multi-factor authentication. We follow least-privilege principles internally.
Keeping software up to date
We regularly update operating systems, libraries, and dependencies to pick up security patches. New code is reviewed before it's deployed.
Security questions & responsible disclosure
If you've found a potential security or privacy issue, or have a question about how Infralyst handles data, please contact our security team.
When you email us, please include as much detail as you can, along with steps to reproduce if applicable.
Once we receive your report, we will:
- 1.Acknowledge your message and confirm that we're looking into it.
- 2.Investigate the issue and assess impact and severity.
- 3.Resolve the problem where needed and, when appropriate, share what we changed.
We ask that you follow responsible disclosure and give us a chance to fix issues before sharing them publicly.