Arino Link and the Command Inbox: how the platform connection works
Arino Link is the pull-based, signed connection between your Arino One instance and the Arino control plane, and the Command Inbox at Settings → Platform → Commands is where every message that connection delivers waits for an administrator's explicit approval before anything happens. Until you pair, the instance sits behind a zero-traffic gate and makes essentially no outbound calls to Arino at all.
What Arino Link actually is
Arino Link is not a live tunnel and it does not let Arino reach into your instance. It is a periodic pull: your instance calls out to the control plane on a heartbeat (every 15 minutes once paired) and the control plane's response may include pending commands. Your instance never accepts inbound connections from Arino, and the control plane cannot initiate anything outside that heartbeat cycle.
Pairing happens once, from Settings → Platform, and works like this:
- A Super Admin enters the owner email already on file and requests pairing.
- The control plane sends a six-digit one-time code to that email address.
- The Super Admin enters the code to complete verification.
- Your instance receives and stores a management token, and pins the control plane's public signing key for future signature checks.
Declining at this stage, or clicking Disconnect later, permanently stops all outbound traffic — including the anonymous install beacon — until you opt back in through the same flow.
The zero-traffic gate
Before pairing, a function called the zero-traffic gate refuses every outbound call except two narrowly scoped, low-sensitivity ones: a one-off anonymous install beacon on first boot (disableable via an environment flag) and, if you created a Super Admin account, a one-time owner registration notice. No heartbeats, no telemetry events, and no command traffic of any kind reach Arino from an unpaired instance. This is enforced in code, not just policy, and is covered by an automated test that fails the build if it's ever bypassed.
The signed, pull-based command queue
Once paired, your instance's heartbeat may return commands from the control plane. Each one is:
- Signed with ECDSA-P256 by the control plane's private key, and checked against the public key your instance pinned at pairing. A missing pin, or any signature that doesn't verify, causes an immediate rejection — the command is discarded before it is ever shown to anyone.
- Bound to your instance — a command addressed to a different instance UUID is rejected.
- Checked against an allowlist. Every instance accepts, at minimum,
update_offer(a new release notice) andsupport_session_request(a time-limited support access grant). Additional command types, such as syncing a narrow set of non-sensitive configuration flags, are only accepted if your control-plane pairing explicitly granted that scope. - Stored, never executed. A command that passes every check above is inserted with status
awaiting_approval. Nothing runs at this point.
Admin approval in the Command Inbox
The Command Inbox at Settings → Platform → Commands lists every command your instance has received, in whatever state it's in: awaiting approval, approved, executed, rejected, or failed. Each card shows what type of command it is, a human-readable description of what approving it will actually do, and — for update offers — the release notes in full.
Nothing executes without an administrator clicking Approve & execute. You can also Reject, with an optional free-text reason, and the command is closed out permanently. There is no "auto-approve" setting and no way for a command to bypass this screen. If the instance isn't paired, the Command Inbox shows a simple "Not connected" state with a link back to Settings → Platform instead of any command data.
Command types are deliberately narrow in what they can do:
| Command type | What approval does |
|---|---|
update_offer | Records the available version number so you can see it's outstanding; surfaces release notes and a suggested Lovable prompt. Applies nothing to your code — you paste the prompt into your own Lovable project yourself. |
support_session_request | Grants a time-limited support access window (a duration and a specific set of scopes), which auto-expires and can be revoked early from Platform settings. |
config_sync (scope-gated) | Writes a narrow, explicit allowlist of non-sensitive settings — things like quiet hours, opt-in keywords, or AI toggles. Secrets, roles, pairing state, and anything in the messaging core are never syncable this way. |
module_sync (scope-gated) | Enables or disables optional modules that aren't core to messaging; core modules can never be remotely disabled. |
Any command type your instance doesn't recognise is parked as unsupported rather than executed or ignored silently, which keeps older instances safe against future command types they've never heard of.
The three privacy tiers of outbound traffic
Everything your instance ever sends to Arino falls into one of three tiers, each with its own trigger, fields and lawful basis, documented in full in the public privacy policy.
| Tier | Trigger | What's sent | Gated by |
|---|---|---|---|
| 1 — Install beacon | Once, on first boot | Instance UUID, version numbers, deployment kind | ARINO_TELEMETRY=off |
| 2 — Owner report | Once, on Super Admin creation | Instance UUID, owner name and email, version numbers | Fires once regardless of later pairing decision |
| 3 — Paired connection | Every 15 minutes, only after OTP pairing | Heartbeat health and capability flags, command results, opt-in product events | Pairing status; stops immediately on Disconnect |
Across every tier, message content, contacts, media, business data, and any credential or API key are never transmitted — a rule enforced by an automated test in the codebase, not just a policy statement.
Practical guidance
- Pair only once you're ready to receive support and update notices; there's no downside to waiting, since the instance is fully functional unpaired.
- Review the Command Inbox periodically even when it's empty — it's the place any future support session grant or config sync will surface, and stale unreviewed commands are worth investigating.
- Treat a support session grant like any other elevated access: check the scopes and duration before approving, and revoke early if the work finishes sooner than expected.
- If you disconnect, understand that this is immediate and local — no further notice reaches Arino beyond the heartbeats simply stopping.
Frequently asked
What is Arino Link?
Arino Link is the pull-based pairing connection between your instance and the Arino One control plane. It is established once, at Settings → Platform, with a one-time code sent to your registered owner email, and it is what lets Arino send you signed update offers and support requests without ever pushing code or configuration directly.
Does anything run automatically once I'm paired?
No. Every command a paired instance receives lands in the Command Inbox with status "awaiting approval". Nothing executes, and no setting changes, until an administrator explicitly clicks Approve & execute. You can reject any command, optionally with a reason, and it will never run.
What happens if my instance is never paired?
The instance is fully functional but sits behind the zero-traffic gate: it makes no outbound calls to Arino at all beyond the one-off anonymous install beacon (unless disabled) and, if a Super Admin account was created, a one-time owner registration email. No heartbeats, no commands, no support telemetry leave the instance.
Can Arino push code changes to my instance remotely?
No. Update-offer commands only record an available version and surface release notes and a suggested prompt for you to apply yourself, in your own Lovable project. No command type in the current allowlist can execute arbitrary code or modify the messaging core.
How are commands authenticated?
Every command is signed with ECDSA-P256 by the control plane's private key. Your instance pins the corresponding public key the first time it pairs and verifies every subsequent signature against it before the command is even stored. A missing pin or a bad signature causes an immediate, silent rejection — the command is never shown to an administrator.
How do I disconnect from Arino Link?
Click Disconnect on Settings → Platform. This deletes the local management token, clears pairing state, and heartbeats simply stop on their next scheduled tick — no further outbound call is needed to notify Arino, since the absence of heartbeats is itself the signal.
Apply this to your own deployment
This guide describes decisions we make on live instances. Tell us your channels, systems and region and we will map it to an architecture outline, a provisioning plan and an indicative commercial model — usually within one business day.