> ## 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. # Asymptote Managed > Forward Beacon endpoint events to Asymptote's managed ingest service and see them on the Asymptote dashboard. ## Forwarding overview Asymptote Managed is the forwarding path that lands Beacon endpoint events on the Asymptote dashboard without any customer-run infrastructure. Beacon stays the local JSONL producer. A Vector forwarder on the endpoint tails the [runtime JSONL log](/concepts/core-concepts#runtime-jsonl-log) and the inventory log and POSTs gzip-compressed NDJSON batches over HTTPS to Asymptote's ingest service, authenticated with a key issued to that one device. This is the only Beacon destination that sends telemetry to an Asymptote-run endpoint, and it is opt-in. Beacon's default remains local-only; nothing is forwarded until a member of your Asymptote organization approves the device in the browser and the forwarder is started with the resulting key. Revoking the device from the dashboard's Beacon Endpoints page stops ingestion within about a minute. Generate the pack with [`beacon endpoint asymptote`](/cli/asymptote). `beacon endpoint connect` performs enrollment and runs the forwarder as a service; the pack is for running or inspecting the same forwarder by hand. ## What leaves the machine Every line written to `runtime.jsonl` after the forwarder starts, and every line of `inventory_state.jsonl`, exactly as Beacon wrote them locally. Beacon's [retention and redaction](/security/retention-redaction) settings apply before a line is written, so they apply to what is forwarded. The ingest service adds a `tenant` block (organization, device, approving user, receive time) to every event server-side and ignores any tenant fields sent by the client. Nothing else is sent. The forwarder does not read prompts, files, environment variables, or shell history beyond what the events already contain. ## How identity works Each enrolled machine gets its own key. Enrollment is a browser flow: the CLI registers the machine's hostname, operating system, and Beacon version, opens the dashboard, and a signed-in member of the organization chooses the organization and clicks Approve. The key is minted only after that click and is shown to the CLI once. It is stored in a `0600` secrets file that Vector reads through its secret backend, so the key is in neither `vector.toml` nor the environment of the Vector process. The ingest service checks three things on every request: the key is known and not revoked or expired, the user who approved the device is still a member of the organization, and the organization is enabled for managed ingest. Those checks are cached for one minute, which is the longest a revoked device can keep sending. ## Wire contract * `POST /v1/ingest/runtime` and `POST /v1/ingest/inventory` with `Authorization: Bearer `, `Content-Type: application/x-ndjson`, and `Content-Encoding: gzip`. HTTPS only; the CLI and pack refuse other schemes. * Each line must be a Beacon endpoint event: `vendor=beacon`, `product=endpoint-agent`, `schema_version`, a parseable `timestamp`, and `event.kind` and `event.action`. Malformed lines are counted and reported; a batch fails only if every line is bad. * Limits per request: 8 MiB compressed, 10,000 lines, 1 MiB per line. The pack batches at 5 MB or 5,000 events or 60 seconds, whichever comes first. * Responses: `200` with accepted and rejected counts and the object written; `401` for an unknown, revoked, or expired key, or an approver who left the organization; `403` when the organization is not enabled; `413` when a limit is exceeded; `429` and `5xx` are retried by Vector with backoff. Other `4xx` responses are dropped, which is the intended behavior for a revoked key. * `GET /v1/ingest/health` (or `HEAD`) with the bearer key returns `200` or `401` and is the credential check the forwarder's startup healthcheck and the smoke-test script use. ## Offline behavior Vector keeps reading into a disk buffer (512 MiB for runtime, 256 MiB for inventory) while the network is unavailable and drains it when connectivity returns. The service accepts events with old timestamps, so a laptop that was asleep or on a flight catches up without loss, up to the buffer size. A batch whose acknowledgement was lost is re-sent; the dashboard's storage collapses duplicates on Beacon's deterministic event id. ## Install the pack ```bash title="Generate the Asymptote pack for a system-mode deployment" theme={null} sudo /opt/beacon/bin/beacon endpoint asymptote install-pack \ --system \ --output ./beacon-asymptote-pack ``` The pack includes `README.md`, `vector.toml`, `asymptote-ingest-smoke-test.sh`, and `sample-event.jsonl`. Run Vector by hand with the environment described in [`beacon endpoint asymptote print-config`](/cli/asymptote#beacon-endpoint-asymptote-print-config). ## Validation 1. Run `sh ./beacon-asymptote-pack/asymptote-ingest-smoke-test.sh` with `BEACON_ASYMPTOTE_INGEST_URL` and `BEACON_ASYMPTOTE_SECRETS_FILE` set. It checks the key (`200` valid, `401` revoked) and posts the log tail once. 2. With Vector running, write a validation event: `beacon endpoint asymptote validate`. 3. Within a minute or two, search the dashboard telemetry page for `Beacon endpoint Asymptote validation event`. ## Revocation Revoke a device, or every device a person approved, from the dashboard's Beacon Endpoints page. The ingest service rejects the key within about a minute, Vector logs `401` responses and drops those batches, and the forwarder needs a new enrollment to resume. Removing a user from the organization has the same effect on every device they approved. ## Related Generate the pack, print the config, and write validation events. Where this channel sits among Beacon's trust boundaries. Controls applied before events are written or forwarded. Every other destination Beacon supports.