The panel¶

The panel is where your team runs LokaDB Cloud: it connects your database, moves organizations, watches the runner and your customers' agents, and holds your account's keys, team and alerts. Everything it does goes through the same API your backend calls.

Signing in¶

Email link. Enter your email, accept the Terms of Service and the Privacy Policy, and press "Email me a sign-in link". The link works for 15 minutes, in the same browser.
Google or GitHub. "Continue with Google" or "Continue with GitHub", after the same consent.
New versions of the terms. When the Terms, the Privacy Policy or the Data Processing Agreement change, the panel asks you to accept the new versions ("Accept and continue") before anything else.
Invitations. An invitation link asks you to sign in, then adds you to the account with the role it was sent with.

The first time, "Create your account" asks for your company's name. A new account is pending: you can connect your database and run the check while we activate it; moves wait for activation. A suspended account is read-only, and organizations already moved keep working.

The top bar¶

"Organizations", "Moves", "Agents", "Statistics" and "Setup" ("Setup" stands out until LokaDB is enabled). Beside them: your plan and how many of its organizations are in use (a link to the plan page), the account switcher if you belong to several accounts, "Account", the theme and "Sign out".

Setup¶

Six steps, each unlocked by the previous one:

LokaDB in front of your database. What must already run in your network: the LokaDB proxy in front of your database (its config with control_plane and credentials_key), a relay your customers' agents reach, the spec of the tables to move, and a machine with Docker for the runner. The panel cannot see your network: it ticks this step once the runner has connected and reported your database. Install on your database, steps 1 to 8, gives all of it (step 7, enable, may be left to step 4 here).
Install the runner. "Set up the runner" makes a one-time registration and a form for the runner's config: the API address (filled in), a name, the owner role, the paths of the spec, the proxy config and the relay CA, and the relay's addresses. It writes runner.json (the database's DSN is env:LOKADB_DB, set on the runner's machine; no password goes into the panel) and the docker run command that fits it, with a -v for every file outside /etc/lokadb. On the runner's machine: save the file, set LOKADB_DB, run the command. The page shows "Connected" once the runner registers, then your database once it reports it. Later, "Register another runner" adds a standby runner. See The runner.
Run check. lokadb check on your database, with its log live. It changes nothing.
Review the report. The verdict is "Ready", "Needs review", "Not supported yet", "Blocked" or "Invalid spec". For "Needs review", tick "I have read the changes and warnings and accept them" to go on. A blocking verdict lists what to fix; then run the check again.
Enable LokaDB. The account's owner types the database's name and presses "Enable LokaDB". Members see that an owner runs it. While no organization is moved, lokadb disable undoes it.
First organization. The form of a new move.

Organizations¶

Every organization of your database: "All", "In the cloud", "Own database", "In progress" and "Needs attention", each with its count, and a search by number, name, tenant or your reference. The table shows where each organization is, its move, its agent (online or offline), its profile and since when. An organization in the cloud has a "Move" button.

An organization's page shows where it is, its profile, its agent (version, last contact) and its database; what needs attention; the extensions in its database (with the command its administrator runs to add a missing one); your name and reference for it; the latency to its database over the last 24 hours; and the history of its moves.

"Extensions" lists, per extension your tables need, which organizations at customers have it and which miss it, with the command to copy. A banner on the organizations page warns when one is missing somewhere: look before you deploy a migration that needs it.

Moves¶

"All", "Active", "Finished" and "Failed": the organization, the kind (move or move back), the state, the progress, when it changed and who started it (a member, an API key or the customer).

A new move ("+ Move an organization"): the organization (its number or tenant uuid), your external reference, the customer's email (optional: it gets the alerts about their side only, such as their agent gone or their database unreachable), "Wait for my approval after check" (on by default) and "The customer may move back from their cabinet". "Create the move" shows the one-time install command and the customer's cabinet link: pass both to the customer's administrator. When the plan's organizations are all in use, the form says so before you create.

A move's page: the steps ("Agent connected", "Check", "Copy rows", "Switch", "Direct profile"), the agent, the customer's database, the check's verdict, the install command's expiry, the live log and the full check report. The buttons appear only where the move's state allows them:

Button
"Approve the move"	A checked move that waits for your approval.
"Run check again"	After a fix, on a checked, blocked or failed move.
"Retry"	A failed step again.
"Move back to the cloud"	Type the organization's number to confirm.
"New install command"	The old command stops working.
"Cancel"	Before the move switches; the agent is revoked.
"Customer cabinet link"	A new link for the customer (the old one stops working).

The state names are those of the integration guide: "Waiting for agent", "Checking", "Ready to move", "Waiting for approval", "Blocked by check", "Moving", "Moved", "Moving back", "Back in the cloud", "Failed", "Cancelled".

Agents and runner¶

Runners: each runner's status (active, standby or offline), version (with the release to update to when it is behind), host, last contact and key fingerprint; the owner can remove one.
Last status: whether the runner reaches your database, the control plane, your relays and proxies.
Customer agents: how many are online, offline or outdated, and per organization its status, version, latency, last contact and certificate renewal.

Statistics¶

For the last hour, 24 hours, 7 or 30 days: organizations in their own databases, queries through the proxy, the share of errors, how often the customers' databases were reachable, the latency to the five slowest, and a table per organization. The numbers come from your runner's and agents' reports; no row of data is in them.

Account¶

Members. Who is in the account and their role. The owner invites by email with a role, changes roles and removes members. A member can leave; the last owner cannot.
Plan & usage. The plan, how many organizations are moved or moving out of how many, and the billable organizations of the last 30 days. To change the plan, the owner writes to us from this page.
API keys. The owner makes a key with a name, read-only or not; it is shown once. Each key shows when it was made and last used, and "Revoke" ends it.
Alerts & webhook. Email alerts per rule, with a threshold where the rule has one (Growth and Enterprise plans), and the account's webhook receiver: its URL and events. The signing secret is shown once, when it is made.

Who may do what¶

	Owner	Member	API key	Read-only key
Read everything	yes	yes	yes	yes
Moves and their actions, check, runner registration, names, alerts and webhook	yes	yes	yes	no
Enable LokaDB, remove a runner	yes	no	no	no
Members, invitations, API keys, closing the account	yes	no	no	no

A pending account can read everything, register its runner and run the check; other changes answer account_pending.