See every app you run

Enrol apps through device management, cloud identity, DNS or a vendor share, then list them, find shadow apps, export firewall rules, search SBOMs and read what is broken.

Planned for 1.3

Status Status is where the work is: Planned (in a milestone, not started), Building (tickets in progress), Preview (usable, may change), then the stability it ships at.

Stability The promise an interface ships with.

Stable Follows semantic versioning; breaking changes need a new major, 12 months of overlap and a codemod.
Beta Usable in production; may change before it becomes stable.
Experimental May change or go away; needs an explicit opt-in in main.yaml.

Stability levels

View as Markdown Open in Claude Edit

Updated 2026-10-28

You will enrol apps without touching their code, list everything Fleet knows, queue what nobody registered, export the attack surface as egress rules and find which apps run a vulnerable package. It takes about 20 minutes. Seeing is free for any verified organisation; acting is the paid plan.

You need

A verified organisation: add the TXT record Fleet shows you for your domain.
A tenant ID such as ten_01JC… and a Fleet state folder, .mainsdk/fleet by default (--state or MAINSDK_FLEET_DIR).

1. Enrol with proof

An app enrols through a channel you control, and a tenant ID alone never adds an app (MAIN-FLEET-0012):

Channel	Where you set it	Proof
Device management	AppConfig key `dev.mainsdk.tenant`	Your device-management signature
Cloud and Kubernetes	`MAINSDK_TENANT`	The platform's workload identity token (OIDC) from an issuer you registered
DNS	TXT `_mainsdk.acme.com` with `v=mainsdk1; tenant=ten_01JC…; region=eu`	Your verified domain; the app's host sits under it
Vendor	One consent from the vendor	The consent names your tenant; the apps show as third parties

A GitHub organisation scan adds every repository with a main.yaml with its project ID and SBOM. Enterprise-managed settings override an app's own: with network.allow of 10 hosts and a managed setting of 6, the app runs with the 6, and mainsdk explain config names the enterprise as the source. An app that ignores them loses its Main mark. A report whose hosts differ from the build provenance is flagged MAIN-FLEET-0014 and its mark shows as unverified.

2. List what you run

pnpm mainsdk fleet apps --tenant ten_01JC… --json

Each row has the owner, environment, version, Main mark and last release, and coverage shows as verified over total. Hosts seen in egress logs that serve no /.well-known/mainsdk.json are listed as unverified, so coverage is a number you can raise.

3. Export the attack surface

pnpm mainsdk fleet surface --tenant ten_01JC… --export k8s-networkpolicy > egress.yaml

Formats are k8s-networkpolicy, vercel-firewall and aws-sg; another name fails with MAIN-FLEET-0015. A NetworkPolicy allows addresses, so a host with no known address is named on stderr instead of being allowed. Check the file against a cluster with kubectl apply --dry-run=client -f egress.yaml.

4. Find where data goes

pnpm mainsdk fleet map --tenant ten_01JC… --label personal --region-outside in,eu --json

This lists each app that sends personal data to a provider outside India and the EU.

5. Find a package and what is broken

pnpm mainsdk fleet sbom find "lodash@4.17.20" --tenant ten_01JC… --json
pnpm mainsdk fleet vulns --tenant ten_01JC… --reachable --kev --json
pnpm mainsdk fleet broken --tenant ten_01JC… --json

sbom find answers from signed SBOMs and skips one whose signature does not verify. vulns leaves out an issue in code the app never calls (it gets a VEX "not affected" statement) and ranks the rest by the CISA KEV catalogue and EPSS. broken lists the apps failing an SLO right now with their owner.

History

The free view keeps 30 days of events and traces; a Fleet tenant keeps 13 months.

Specs fleet-enrolment, fleet-discover and fleet-observe.
Read your Fleet records to prove what was pushed.

Was this page helpful?