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.