docs: add Kosli Capture Managed Service page

[mintlify]

Adds a new "Kosli Capture Managed Service" page to the Getting started section, based on a customer-facing overview drafted by Graham.

• New page: getting_started/kosli_capture.md (sidebar label: "Kosli Capture")
• Content adapted to docs style: second-person voice, sentence-case headings, setup steps in a Steps component
• Added to the Getting started group in navigation, after Environments

---

Generated by Mintlify Agent.

Requested by: graham@kosli.com via Slack
Mintlify session: slack_1782915660.508229_D0AM66349C1

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
kosli	🟢 Ready	View Preview	Sep 2, 2026, 12:08 PM

[claude]

Claude finished @gsavage's task in 1m 39s —— View job

---

Doc review

• Read the diff at current branch head
• Check navigation, links, and redirects
• Cross-file consistency checks
• Post findings

Both internal links (/administration/kosli_capture, /getting_started/environments) resolve to existing files, the new page is in config/navigation.json:73, and no page was moved, so no redirect is needed. The three empty stub pages flagged on the previous push are gone from the diff.

---

Improvement

getting_started/environments.md:58 — the new sentence lands directly after the list of eight supported environment types (Kubernetes, Docker, server paths, S3, Lambda, ECS, Azure, Cloud Run). "Kosli can also report these snapshots for you" reads as covering all eight, but administration/kosli_capture.md:18 says Kosli Capture supports only ECS and Lambda today. A reader on a Kubernetes or Cloud Run environment will follow the link expecting a managed option that does not exist for them.

Qualify it in place:

…or on certain events. For supported AWS resources, Kosli can also report these snapshots for you, using the Kosli Capture Managed Service.

Fix this →

administration/managing_environments/overview.md:67-69 — the H3 nests correctly under "Managing physical environments", but three smaller things are off:

• Line 13 tells the reader "This page covers managing environments via Terraform. For creating environments via the CLI or UI, see Getting started: Environments." Kosli Capture is none of those three, so the section reads as out of scope unless it says so.
• The two sibling H3s are imperative verb phrases — "Create a physical environment" (line 23), "Import an existing physical environment" (line 35). A gerund heading breaks the pattern.
• "will automatically snapshot" / "will create" describes a capability that exists today.

### Create physical environments automatically

The [Kosli Capture Managed Service](/administration/kosli_capture) creates physical environments for you, without Terraform. It snapshots your infrastructure according to rules you define, creating environments as needed.

Fix this →

Suggestion

administration/kosli_capture.md:38, 42 — environment auto-creation is claimed twice, and the second one is circular. Line 38 ends "Kosli Capture will create physical environments for you"; line 42 then says "Because Kosli Capture creates physical environments as needed, when your infrastructure changes, Kosli will keep up" — which restates the claim as its own reason. The genuinely new information in that paragraph is that evolving infrastructure needs no reconfiguration.

Drop the trailing sentence from line 38 and fold the capability into line 42:

As your cloud environment evolves, such as the addition of new ECS clusters or the retirement of existing Lambdas, Kosli Capture automatically detects the changes and creates any new physical environments needed. No changes to the configuration created during the initial setup are required.

config/navigation.json:73 — the page is a flat entry after administration/managing_tags, while administration/managing_environments/overview sits in a Managing Environments group (lines 61–65) that currently holds exactly one page. A reader asking "how do my environments get populated?" will look in that group first. Moving administration/kosli_capture into it collocates the two environment pages and clears the single-child-group signal that scripts/audit_navigation.py reports.

---

2 Improvements, 2 Suggestions, 0 Critical. Nothing here blocks the merge — the ECS/Lambda scoping qualifier on getting_started/environments.md is the one worth doing before it ships.
· branch mintlify/2dca75a3

[claude]

Improvement — this page claims something the Kosli Capture page doesn't. "Kosli Capture will create physical environments as needed" is a real capability claim, but administration/kosli_capture.md never mentions creating environments — it only says tags "determine which Kosli environment should hold the snapshots", which reads as routing into environments that already exist. A reader who follows the link won't find the auto-creation behaviour confirmed. Worth adding a sentence to the "Finding resources" section of the Kosli Capture page, since auto-creation is arguably its biggest selling point over Terraform-managed environments.

Two smaller points on the same block:

• Heading level. This is an H2, so it sits as a sibling of "Managing physical environments" and "Managing logical environments" — but it is about physical environments, and it's wedged between the two. ### Automatically creating physical environments, appended to the physical-environments section, nests correctly. It also sidesteps the mild scope clash with line 13 ("This page covers managing environments via Terraform"), since Kosli Capture isn't a Terraform mechanism.
• Tense. "will automatically snapshot" / "will create" → present tense reads better for a capability that exists today.

Suggested change

	The [Kosli Capture Managed Service](/administration/kosli_capture) will automatically snapshot your infrastructure according to rules you define. Kosli Capture will create physical environments as needed.
	### Automatically creating physical environments
	The [Kosli Capture Managed Service](/administration/kosli_capture) automatically snapshots your infrastructure according to rules you define, creating physical environments as needed.

(Note the suggestion changes the heading to H3 — if you take it, move the block above ## Managing logical environments stays as-is, it's already in the right position.)

Fix this →

[claude]

Improvement — environment auto-creation is now stated twice. Line 38 ends with "Kosli Capture will create physical environments for you", and this sentence repeats it four lines later ("Because Kosli Capture creates physical environments as needed..."). The claim only needs to land once; here the useful new information is that evolving infrastructure is handled without reconfiguration.

Suggested change

	As your cloud environment evolves, such as the addition of new ECS clusters or the retirement of existing Lambdas, Kosli Capture automatically detects the changes. Because Kosli Capture creates physical environments as needed, when your infrastructure changes, Kosli will keep up. No changes to the configuration created during the initial setup are required.
	As your cloud environment evolves, such as the addition of new ECS clusters or the retirement of existing Lambdas, Kosli Capture automatically detects the changes and creates any new physical environments needed. No changes to the configuration created during the initial setup are required.

If you take this, drop the trailing sentence on line 38 ("Kosli Capture will create physical environments for you.") so the claim appears once, in the paragraph that explains why it matters.

[claude]

Suggestion — "Amazon's AWS API" is redundant (AWS is already Amazon's).

Suggested change

	Kosli Capture currently supports ECS and Lambda running within AWS. Support for S3 snapshots and for other cloud providers is in active development. A limitation in Amazon's AWS API currently prevents Kosli Capture from snapshotting EKS clusters; support for Kubernetes running on other cloud providers (e.g. Azure) will be added shortly.
	Kosli Capture currently supports ECS and Lambda running within AWS. Support for S3 snapshots and for other cloud providers is in active development. A limitation in the AWS API currently prevents Kosli Capture from snapshotting EKS clusters; support for Kubernetes running on other cloud providers (e.g. Azure) will be added shortly.

[claude]

Improvement — the new section sits outside this page's stated scope. The H3 nesting under "Managing physical environments" is right, but line 13 tells the reader "This page covers managing environments via Terraform. For creating environments via the CLI or UI, see [Getting started: Environments]" — and Kosli Capture is neither Terraform, CLI, nor UI. A reader who took that <Info> at its word won't expect to find this here.

Simplest fix: say explicitly that this is the exception, so the section justifies its own presence.

Suggested change

	The [Kosli Capture Managed Service](/administration/kosli_capture) will automatically snapshot your infrastructure according to rules you define. Kosli Capture will create physical environments as needed.
	The [Kosli Capture Managed Service](/administration/kosli_capture) creates physical environments for you, without Terraform. It snapshots your infrastructure according to rules you define, creating environments as needed.

(Also switches "will automatically snapshot" / "will create" to present tense — it's a capability that exists today, not a future one.)

[claude]

Critical — this page is empty but is wired into navigation, so it will publish as a blank page.

config/navigation.json:51 lists administration/authentication/single_sign_on and :52 lists administration/authentication/magic_link; :60 lists administration/managing_users/automated_user_provisioning. All three files contain only a title. Since deployment is automatic on merge to main, merging this PR puts three empty pages into the live Administration sidebar.

Three separate problems in each of the three files:

1. No body content. Either write the pages before merging, or drop the three nav entries and keep the stubs off main.
2. Missing description. CLAUDE.md makes it a required front matter field, and every sibling page has one (api_key_rotation.md, service_accounts.md, roles_in_kosli.md).
3. Title Case titles. CLAUDE.md asks for sentence case; the siblings follow it — "API key rotation", "Service accounts", "Mapping users to roles". So: "Magic link", "Single sign-on", "Automated user provisioning".

These are also outside the stated scope of this PR (the description covers only the Kosli Capture page) — a separate PR for the auth/provisioning pages, once they have content, would keep this one reviewable.

Suggested change

	---
	title: Magic link
	description: <one sentence describing the page purpose>
	---

Fix this →

[claude]

Improvement — environment auto-creation is still stated twice. Line 38 ends with "Kosli Capture will create physical environments for you", and line 42 repeats it ("Because Kosli Capture creates physical environments as needed, when your infrastructure changes, Kosli will keep up"). The second sentence in line 42 is also circular — it restates the claim as the reason for itself.

Fold the capability into the paragraph that explains why it matters, and drop it from line 38:

Suggested change

	Kosli Capture finds all supported resources within your AWS accounts, and examines the tags on those resources to determine which Kosli environment should hold the snapshots. Kosli Capture will create physical environments for you.
	Kosli Capture can filter out resources based on your tags.
	As your cloud environment evolves, such as the addition of new ECS clusters or the retirement of existing Lambdas, Kosli Capture automatically detects the changes. Because Kosli Capture creates physical environments as needed, when your infrastructure changes, Kosli will keep up. No changes to the configuration created during the initial setup are required.
	Kosli Capture finds all supported resources within your AWS accounts, and examines the tags on those resources to determine which Kosli environment should hold the snapshots.
	Kosli Capture can filter out resources based on your tags.
	As your cloud environment evolves, such as the addition of new ECS clusters or the retirement of existing Lambdas, Kosli Capture automatically detects the changes and creates any new physical environments needed. No changes to the configuration created during the initial setup are required.

[claude]

Suggestion — "Amazon's AWS API" is redundant (AWS is already Amazon's). Punctuation is fixed now; this is the last thing left in the sentence.

Suggested change

	Kosli Capture currently supports ECS and Lambda running within AWS. Support for S3 snapshots and for other cloud providers is in active development. A limitation in Amazon's AWS API currently prevents Kosli Capture from snapshotting EKS clusters; support for Kubernetes running on other cloud providers (e.g. Azure) will be added shortly.
	Kosli Capture currently supports ECS and Lambda running within AWS. Support for S3 snapshots and for other cloud providers is in active development. A limitation in the AWS API currently prevents Kosli Capture from snapshotting EKS clusters; support for Kubernetes running on other cloud providers (e.g. Azure) will be added shortly.

[claude]

Improvement — environment auto-creation is still claimed twice, and the second one is circular.

Line 38 ends with "Kosli Capture will create physical environments for you", then line 42 says "Because Kosli Capture creates physical environments as needed, when your infrastructure changes, Kosli will keep up" — which restates the claim as the reason for itself. The genuinely new information in that paragraph is that evolving infrastructure needs no reconfiguration; folding the auto-creation into it lands the claim once, in the place where it matters.

Suggested change

	Kosli Capture finds all supported resources within your AWS accounts, and examines the tags on those resources to determine which Kosli environment should hold the snapshots. Kosli Capture will create physical environments for you.
	Kosli Capture can filter out resources based on your tags.
	As your cloud environment evolves, such as the addition of new ECS clusters or the retirement of existing Lambdas, Kosli Capture automatically detects the changes. Because Kosli Capture creates physical environments as needed, when your infrastructure changes, Kosli will keep up. No changes to the configuration created during the initial setup are required.
	Kosli Capture finds all supported resources within your AWS accounts, and examines the tags on those resources to determine which Kosli environment should hold the snapshots.
	Kosli Capture can filter out resources based on your tags.
	As your cloud environment evolves, such as the addition of new ECS clusters or the retirement of existing Lambdas, Kosli Capture automatically detects the changes and creates any new physical environments needed. No changes to the configuration created during the initial setup are required.

[claude]

Suggestion — "Amazon's AWS API" is redundant (AWS is already Amazon's). Everything else in this sentence is resolved; this is the last bit.

Suggested change

	Kosli Capture currently supports ECS and Lambda running within AWS. Support for S3 snapshots and for other cloud providers is in active development. A limitation in Amazon's AWS API currently prevents Kosli Capture from snapshotting EKS clusters; support for Kubernetes running on other cloud providers (e.g. Azure) will be added shortly.
	Kosli Capture currently supports ECS and Lambda running within AWS. Support for S3 snapshots and for other cloud providers is in active development. A limitation in the AWS API currently prevents Kosli Capture from snapshotting EKS clusters; support for Kubernetes running on other cloud providers (e.g. Azure) will be added shortly.

[claude]

Improvement — heading style breaks with its siblings, and the tense reads as unreleased.

The H3 nesting under "Managing physical environments" is right, but the two sibling H3s on this page are imperative verb phrases — "Create a physical environment" (line 23), "Import an existing physical environment" (line 35) — so a gerund heading stands out. And "will automatically snapshot" / "will create" describes a capability that exists today.

One more thing worth a sentence: line 13 tells the reader "This page covers managing environments via Terraform", and Kosli Capture is not Terraform. Saying so explicitly stops the section reading as out of place.

Suggested change

	### Automatically creating physical environments
	The [Kosli Capture Managed Service](/administration/kosli_capture) will automatically snapshot your infrastructure according to rules you define. Kosli Capture will create physical environments as needed.
	### Create physical environments automatically
	The [Kosli Capture Managed Service](/administration/kosli_capture) creates physical environments for you, without Terraform. It snapshots your infrastructure according to rules you define, creating environments as needed.