OcaltQL Client

Overview

The OcaltQL Client is a native application that lets you connect and orchestrate commands across all your devices. It turns any machine into a full participant in your Ocalt infrastructure: an execution target, a Fabric agent, an Ocaltio drive, a local development server that is not a simulation.

Install it from client.ocalt.com. Configure it at http://localhost:12345. Register a name. From that moment the rest of the stack can see it.

What it is

A small local agent plus a configuration UI. It holds your Ocalt credentials, a machine alias, and the root folder it may serve. It dials out. Nothing inbound is required.

Local development with the client is not a second runtime. The file is on your disk; the execution is on Ocalt against your real namespace. There is nothing to drift out of step, and nothing to install but the agent.

What it does

• Registers the machine under a name Fabric and OcaltQL can address (DIRECTIVE REGISTER).
• Executes commands you send with DIRECTIVE "name" EXEC "…".
• Serves a project folder off your disk while scripts execute for real.
• Exposes local storage to Ocaltio as a drive.
• Reports position when asked (DIRECTIVE STATUS), which is what logistics and geofence scripts use.
• Runs on a mini PC, an old laptop, a phone, an industrial box — anything that can keep an outbound connection.

How it works

The client maintains a secure outbound connection to your Ocalt account and exposes the local machine's capabilities under your control and permissions. Commands travel down the connection; results travel back. Files the rest of the stack reads from this machine are read from the folder you allowed, not from the whole disk.

A machine you no longer control simply stops answering. Unregister the name when you are done with it.

Getting started

1. Download and install from client.ocalt.com.
2. Open http://localhost:12345. Sign in with the Ocalt account that should own the machine. Set a machine alias you will recognise at 3am. Set the root folder it may serve.
3. In the console, run DIRECTIVE REGISTER "edge-01" using the same alias.
4. Prove it: DIRECTIVE "edge-01" EXEC "uname -a" (or the Windows / Android equivalent).
5. Only then write a WATCH, a tunnel, or a hosting target on top of it.

DIRECTIVE REGISTER "greenhouse" SET ?reg
AFTER DIRECTIVE "greenhouse" EXEC "cat /sys/soil/moisture" SET ?m
AFTER EMIT ?m("stdout")

Local development

Point the client's root at your project folder, set a port, and open it. An .oql file is a page. The visitor's request — here, you — reaches the script with method, query, body and cookies, because it is production execution against a local file.

SUBDOMAIN ADD is the step that makes the same file reachable as name.ocalt.site for everyone else. Local is for the loop; the subdomain is for the URL you send.

IoT and on-site hardware

Sit the client on a machine near the hardware. That machine becomes the gateway. Your scripts address it with DIRECTIVE; it speaks to the hardware in whatever the hardware understands: HTTP, MQTT, Modbus, a vendor SDK, GPIO, Home Assistant.

A WATCH polls a value and fires only when it changes. That is the whole automation model — no rules engine, no vendor cloud deciding what counts as an event.

Who it is for

Anyone who wants their laptop, desktop, server, phone or edge device to be a first-class part of their Ocalt environment rather than an external afterthought. Operators putting a gateway on a farm, a depot, a lab bench, a vehicle.

Related products

FAQ

Does the client work without the internet?

The agent has to dial out to be addressable. Local files remain on disk either way. Automation that must run while a site is partitioned should be written to tolerate a missed poll, not to assume a private island runtime.

Can two people share one client?

Register the machine to a business namespace. Members with the machines grant can address it without holding the SSH password. That is the point.