Hosted Site Adapters vs Local Runtime: Choosing the Right iatlas-browser Path

Why This Search Exists

People often want a simple rule for adapter execution. In practice, the rule is about state. If an adapter only needs public data and read-only requests, it can often run as a hosted subset. If it needs your browser context, it belongs on the local runtime.

Without that boundary, teams either overcomplicate the hosted layer or underuse the local runtime, and both paths lead to brittle integrations.

Recommended Approach

The hosted subset at `miaoda.vip` is intentionally narrow. It includes public, read-only, server-safe adapters that can run without personal tabs, cookies, or user-specific browser state.

The full local adapter model is broader. It can take advantage of your live browser session, extension bridge, and page state, which is why it remains the center of the product.

Key Takeaways

• Hosted adapters are for public, read-only, remote-safe tasks.
• Local adapters are for session-aware tasks tied to your real browser context.
• The adapter catalog should describe execution mode clearly.
• A good architecture uses both layers without pretending they are the same.

Fast Start

1. Browse the adapter catalog at `/sites/` to understand available commands.
2. Check `GET /v1/sites/hosted` for the hosted subset that can run remotely.
3. Use `POST /v1/sites/run` for hosted read-only adapters.
4. Use `iatlas-browser site ...` locally whenever the command depends on your actual browser state.