> ## Documentation Index
> Fetch the complete documentation index at: https://docs.asymptotelabs.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Quickstart

> Choose the right Asymptote path for a local, managed, or private rollout

Start here if you are deciding how to introduce Asymptote across a team. Asymptote can begin as open-source Agent Beacon telemetry across supported local, CI, and cloud surfaces, move into managed visibility and governance, or run in a private deployment for stricter infrastructure requirements.

## Choose a deployment path

| Hosting Option | Use it when | Next step |
| - | - | - |
| Asymptote Open Source | You want open-source telemetry across supported agent surfaces, local JSONL where applicable, and customer-managed forwarding into your SIEM or observability stack. | Start with the [Security & IT quickstart](/get-started/quickstart-security-it) or [developer quickstart](/get-started/quickstart-developers). |
| Asymptote Managed | You need centralized ingest, fleet-wide visibility, policy controls, investigations, SSO/RBAC, audit trails, and rollout support. | Review [Asymptote Managed](/deployment/managed) or [contact us](https://asymptotelabs.ai/contact). |
| Asymptote Private Deployment | You want managed capabilities with dedicated infrastructure, stricter data boundaries, or residency requirements. | [Contact us](https://asymptotelabs.ai/contact) to discuss deployment requirements. |

See [Hosting Options](/deployment/hosting-options) for the full comparison.

## Open source rollout strategy

For most Security and IT teams, the safest open-source path is staged. Local endpoint collection is usually the first evaluation path, then teams can add CI and cloud-agent surfaces where those agents run:

1. **Evaluate locally** with a small pilot group using supported [agent harnesses](/runtimes).
2. **Validate health and visibility** with endpoint status, runtime log freshness, and expected event coverage.
3. **Add CI or cloud surfaces** with the relevant Beacon setup paths when agent activity also runs in build jobs or hosted sandboxes.
4. **Decide where events should live**: local JSONL only, Wazuh localfile, a supported SIEM/log destination, object storage, or a customer-managed pipeline.
5. **Expand through MDM** once install coverage, collector health, and forwarding checks are stable.

The open-source path can remain local-only by choosing **Local only** in the first-run install wizard or by using unattended/package deployment paths. The endpoint agent does not require a hosted account, remote policy fetch, or external network dependency during normal local collection.

## Managed or private path

Move to Managed when a small pilot becomes an operating program: multiple teams, centralized search, governance, investigations, access control, and rollout support.

Connecting an endpoint is one command once your organization is provisioned: `beacon endpoint connect` enrolls the device and starts the forwarder. The first interactive `beacon endpoint install` offers the same step, with Standard and Metadata-only privacy choices and a confirmation before forwarding begins. See [`beacon endpoint connect`](/cli/endpoint-connect).

Private Deployment is the path for regulated teams that need managed capabilities with dedicated infrastructure, stronger isolation, custom retention, or residency requirements.

[Contact us](https://asymptotelabs.ai/contact) to discuss Managed or Private Deployment.

## Pick your quickstart

<Columns cols={2}>
  <Card title="For Security & IT Teams" icon="building-shield" href="/get-started/quickstart-security-it">
    Plan an open-source pilot, validate endpoint telemetry, and decide when to centralize or move to Managed.
  </Card>

  <Card title="For Individual Developers" icon="user" href="/get-started/quickstart-developers">
    Install Beacon locally, confirm collection health, and inspect agent activity on your machine.
  </Card>
</Columns>

### Then pick your platform

Both paths install the endpoint agent locally, and that part differs by operating system. The
package, the service manager, and how a fleet is deployed are not the same on each:

<Columns cols={2}>
  <Card title="macOS" icon="apple" href="/platforms/macos">
    Homebrew for one machine, or the signed `.pkg` with Jamf, Fleet, or Rippling for a fleet. launchd.
  </Card>

  <Card title="Linux" icon="linux" href="/platforms/linux">
    A `.deb` or `.rpm` that installs and starts the endpoint for you. systemd.
  </Card>

  <Card title="Windows" icon="windows" href="/platforms/windows">
    An MSI that installs and starts the endpoint for you. Windows Service Control Manager.
  </Card>
</Columns>

Capturing from CI jobs, cloud agents, or your own applications through the SDK needs none of this.
See [agent harness integrations](/runtimes).

## Deeper guides

<Columns cols={2}>
  <Card title="Asymptote Open Source" icon="download" href="/deployment/open-source">
    Install Beacon and configure the open-source telemetry path.
  </Card>

  <Card title="Security & IT Rollout Guide" icon="building-shield" href="/security">
    Expand from pilot to managed endpoint rollout, validation, and forwarding.
  </Card>

  <Card title="Asymptote Managed" icon="key" href="/deployment/managed">
    Review managed visibility, policy controls, investigations, and rollout support.
  </Card>

  <Card title="Agent harness integrations" icon="list-check" href="/runtimes">
    See supported runtimes, deployment modes, destinations, and boundaries.
  </Card>
</Columns>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.