Remote deployment

By default the whole of Mosael runs on your own machine. But the backend can move to a server with the desktop app pointed at it — several people sharing one media library, one set of workflows, one publishing queue.

Think this through first: your data now lives on that server. Access still requires authentication and workspace membership. Ask the administrator to configure members and registration policy.

Point the desktop app at a remote backend#

Change Server address in settings to the backend's address. It decides where this desktop app sends its requests; locally that defaults to http://127.0.0.1:8800.

The backend has to allow the origin#

Browsers block cross-origin requests, and the error they produce looks like "the backend is broken". So on the server, list the allowed origins one by one in MOSAEL_CORS_ORIGINS (comma-separated):

MOSAEL_CORS_ORIGINS="https://studio.example.com,https://studio2.example.com"

The desktop app's own origins (Electron's file:// and friends) are always allowed; setting this does not displace them.

Wildcards are not supported, deliberately. /api/auth is open by nature: on a fresh, empty database, registration succeeds for anyone who can reach the port. Under a wildcard, any web page the user happens to open could register an account on your backend and read the token back. So domains get listed one at a time.

While you are at it: the first thing to do after exposing a deployment is turn open registration off (registration policy in Admin).

Workers have to cross the network too#

Publishing and browser automation go over the worker channel. It carries no user session; it authenticates with a shared key. Locally the backend writes that key into its own data directory and the worker reads the file — but when the backend is on another machine, that file is either stale or absent. The symptom is publishing, browser automation and externally-executed jobs all returning 401 at once, which looks like three separate things breaking.

Set the same MOSAEL_WORKER_KEY on both sides:

# The same value on the server and on the machine running the worker
MOSAEL_WORKER_KEY="a long random string"

Why not "trade a user session for a worker token": this channel is deployment-wide — claiming a pending publish task claims anyone's task. Hanging it off a user session would let any logged-in user's worker on a shared server claim everyone's tasks, which is an escalation. Whoever holds this key is this deployment's worker.

Publishing still needs a desktop#

Publishing is not an HTTP call — it drives a real browser on your behalf: sign-in state, captchas and platform redesigns all need an actual browser window. So the backend only enqueues, and the work is done by the publisher inside Electron. The web interface does not include a desktop publishing worker.

A backend on a server plus the desktop app on your own machine works fine: the desktop connects out, and publish tasks run on your machine.

More than one publisher#

Supported. Each worker has a stable identity of its own (generated on first run; override with MOSAEL_WORKER_ID — container data directories are often ephemeral).

The identity is required. Reclaiming a stuck task uses the test "this account is not in the set I am currently running", and that sentence only means anything coming from the worker that claimed it. Without identities, two workers mark each other's in-flight tasks as failed.

A given platform account is only ever driven by one worker at a time — there is one sign-in state and one upload queue.