# The console on your node

The console is the browser interface: the overview, the approvals inbox, jobs, connections, policies, members, the audit record. On a deployment inside your network it is served by your own node, from your own address, and it is downloaded with the product rather than fetched from us.

## Where it comes from

The console bundle ships inside the node. Your gateway serves it on its own origin, which means the browser and the API are the same origin: no cross-origin configuration, no cookie domain to get right, and in the common case no address for anyone to type, because the console's origin already is your node.

Point `-console-url` at that same address so the links in the emails the node sends lead back to it.

An address screen and a key-entry fallback exist inside that shipped bundle, and they exist for two narrow cases: a fresh node that has not been claimed yet, and a bundle running detached from its node during development. Neither is a normal way in.

## What is not on our origins

`enterprise.atmon.ai/console` is the console for enterprises running on our cloud, and its door is email sign-in only: an email, then whichever sign-in methods that address supports. There is no key entry and no address entry on it, and there never will be, because a browser URL on our domain implies our backend. The same is true of the consumer console at `atmon.ai`.

So there is exactly one console that asks where the server is, and it is the one your node serves. If a person on your team is looking at a screen on an atmon.ai address asking for your node's endpoint, they are on the wrong page.

## Sign-in email

The console signs people in with links and codes sent by email. A node whose mail driver is still `log` prints those links into its own log rather than sending them, which works for one person on a laptop and fails for everybody else. Configure a real driver before you invite a second person.

## Who may create an account

`-signup` decides it: `open` for anybody, `invite` for people you invited, `closed` for nobody. The console renders the door to match, so a closed node shows a sign-in page and no signup form rather than a form that fails after it is filled in.

A node reachable from a wide network with open signup is a node anybody who reaches it can create a project on. The default is `closed`, and changing it is a decision with a reason behind it.

## If you serve the console from a second host

Two settings have to agree, and both fail closed rather than quietly.

`-browser-origins` names the origins allowed to call the API from a browser. Name exactly the origins you mean. A wildcard on a credentialed API is a hole rather than a setting.

`-console-cookie-domain` decides where the session cookie is set. Leave it empty when the node serves its own console, which keeps the cookie to that one host. Set it only when the console and the API sit on two hosts under one domain, and set it to the parent of both.

Serving the console from the node itself avoids both settings, which is the reason to prefer it.