Remote access

Your Cronable daemon binds to 127.0.0.1 and never opens an inbound port. Remote access lets you reach that daemon’s dashboard from any browser anyway — you sign in at remotecontrol.cronable.ai, pick the machine, and drive its full UI over a tunnel the daemon opens outbound. Nothing is exposed on the machine running your jobs.

It’s the same trust model as the webhook relay: the connection is opened by your server, brokered by Cronable’s hosted relay, and bound to your license — no ports, no tokens on disk, no other customer able to reach your daemon.

How it works

Your daemon holds an outbound connection to Cronable’s relay (the same one it uses for inbound webhooks). To serve remote access it also stands up a remote-control responder on that connection.
You open remotecontrol.cronable.ai and sign in with your Cronable account (the same account you manage your subscription with).
The dashboard shows your fleet — every daemon on your account currently reachable. You pick one.
The relay’s browser edge (rc.cronable.ai) authorizes the request against your license and tunnels it to that daemon’s responder, which answers with the real UI. Your browser drives the daemon as if it were local.

At no point does the daemon accept an inbound connection, and at no point does a request reach a daemon that isn’t on your account and entitled.

Requirements

A Team or Business license. Remote access is gated on the license’s features.remoteControl entitlement, which those plans carry; Solo does not.
Remote access enabled on the daemon (off by default — see below).
A reachable relay URL configured on the daemon (the hosted default is Cronable’s relay).

Enabling it on a daemon

In the daemon’s Settings (or .cronable/settings.json):

remoteAccessEnabled — false by default. Set it true to let the daemon answer remote-control requests. While it’s off, the daemon still connects to the relay for webhooks but refuses every remote-control request.
remoteAccessLabel — an optional human name for this machine, shown in the picker (e.g. "prod-box" or "home server"). Helpful once you have more than one.
relayUrl — the relay the daemon connects to. Leave it at the hosted default unless you run your own relay.

Enabling it is enforced twice: the daemon only answers when remoteAccessEnabled is true, a remote-control responder is running, and the current lease actually entitles remote control. A Solo license (or a missing entitlement) is refused even if the toggle is on.

Using the dashboard

Go to remotecontrol.cronable.ai and sign in with your Cronable account.
Choose a machine from the picker (labelled by remoteAccessLabel where set).
You get the daemon’s full dashboard — the DAG, Inspector, Executions, logs, Settings — driven live through the tunnel.

Security model

Outbound only. The daemon opens the connection; nothing listens for inbound traffic on the machine running your jobs. There is no port to scan, firewall, or expose.
License-bound. The relay authorizes every remote-control request against your license before it tunnels anything; a request can only ever reach a daemon on your own account.
Entitlement-gated. Remote control requires the features.remoteControl entitlement (Team / Business) and the per-daemon remoteAccessEnabled toggle — both, on every request.
No standing credentials on disk. Like git sync and the webhook relay, remote access uses the connection your daemon already holds; there is no long-lived token stored on the box for it.

Remote access is a hosted add-on to the self-hosted product: your jobs, secrets, and data stay on your machine — the relay only brokers the encrypted tunnel between your browser and your daemon.

Webhook relay — the same outbound-connection model, for inbound events.
Security — the daemon’s trust boundary and loopback binding.
Operations & scaling — running the daemon as a long-lived service.

Webhook relay Failure handling