Secure your Fly.io surface
Org-wide secret scope, publicly exposed services, and machines running images long out of date. We don’t connect to Fly.io to collect evidence for its own sake — we connect to secure it, and the compliance artefacts follow from that work.
Book a Demo[01] What This Surface Exposes
Where Fly.io goes wrong
Fly.io goes wrong through secret scope: secrets set at organisation level are readable by every app in that organisation.
- Secrets scoped more broadly than the app that needs them
- Services published publicly with no network restriction in front of them
- Machines running images well behind the current build
- Deploy tokens shared across CI pipelines with no per-app scoping
- Volumes holding regulated data with no classification or backup position
[02] What We Secure
What we watch, catch and fix on Fly.io
On Fly.io we review secret scope per app against actual need, and inventory which services are genuinely meant to be internet-facing.
- Secret scope reviewed per app against actual need
- Public service inventory checked against what is meant to be internet-facing
- Image currency tracked for running machines rather than for the repository
- Token scope and rotation tracked per pipeline
- Volume inventory captured as assets with classification
[03] Where It Lands
Where Fly.io lands in your registers
Every cloud resource we discover becomes an entry in your asset register with an owner, a criticality rating, and its data classification. Access reviews cover the IAM principals attached to it, and the risk register carries the mapping between the asset and the risks it actually carries — so a public bucket is a named risk against a named asset, not a line item in a scan report.
[04] How We Engage
On Fly.io specifically
On Fly.io, we re-scope secrets and tokens and drive image refreshes. Introducing network restrictions in front of public services we plan with your team to avoid breaking traffic.
Platform licence
Everything you need to find and fix it yourself, with no ceiling on the depth of the answer.
- Every connected tool monitored for misconfiguration and drift, with findings mapped to the assets and risks they affect
- Remediation guidance that tells you what is wrong and exactly how to fix it — however deep or awkward the issue is. We are engineers running a security company, so the answer is the real one, not a link to vendor documentation
- Assets, access reviews, and risk register populated from the tools themselves rather than from spreadsheets
- Unlimited integrations and unlimited users, with anything missing built within two weeks
Managed service
Every tool you connect through Konfirmity comes under our care, with our team doing the work.
- Continuous misconfiguration and drift monitoring across every connected tool, watched by our analysts rather than by a dashboard waiting for you
- Incident response led by us, with containment coordinated with your team
- Remediation performed directly wherever you have granted us the authority to act — and where we cannot act, we project-manage the fix to completion rather than handing you a ticket
- Decision support on the tools themselves: where something is failing you on capability or costing more than it returns, we will tell you, and help you replace it
[05] Fly.io FAQs
What Fly.io access does Konfirmity need?
Konfirmity needs a read-scoped API token for the organisations you connect, sufficient to list apps, machines, volumes and secret names. We read secret names and scopes, never values. Deploy tokens are separate and we neither need nor request them for assessment.
Do you track image freshness on running machines?
Yes, and specifically for machines rather than repositories. A patched image in your registry does nothing while an old one is still running. Konfirmity tracks what each machine is actually running so stale deployments surface as findings.
Amazon Web Services
Google Cloud Platform
Microsoft Azure
Kubernetes
Terraform