Your first hour
Lumaft is running and you are signed in as the bootstrap administrator. This page walks through the first hour: securing the account you just used, reading the readiness checklist, and learning what each page of the console is for.
First ten minutes
- Create your own account. Open Administration → Users & Access and create an
administrator account for yourself. Sign out, sign back in as yourself, and keep the
bootstrap
adminaccount as the recovery path rather than the account people use. - Retire the bootstrap file. Unset
LUMAFT_LOCAL_ADMIN_PASSWORD_FILEin your deployment, delete the password file, and restart. The file was read once; it does nothing now except sit there. - Check the backends. Open Administration → Backends. Every record should show a successful diagnostic. A failure here is isolated to that backend and does not affect the rest of the console; Troubleshooting has the fixes.
- Wait a minute. The first checkpoint cycle commits within about a minute of startup and populates Stacks. Update history follows on its five-minute cycle and populates Operations.
The first-run readiness checklist
On Backends, open First-run readiness. It reports seven checks; each is either something Lumaft can verify itself or something only you can.
| Check | Satisfied when | If it is not |
|---|---|---|
| Backend access | Every enabled backend's diagnostic succeeded | Fix the credential or policy; see Backend problems |
| Persistent storage | You have confirmed /data is on a volume that survives container replacement |
Lumaft cannot prove this from inside; a successful write today says nothing about tomorrow. Confirm the topology in Deployment and setup |
| Backup | You have taken and verified a cold backup | Do it now, before there is much to lose: Backup and disaster recovery |
| Evidence coverage | Update history has been observed for at least one backend | Wait for the first five-minute cycle, or check the backend diagnostic |
| Retention | A retention policy has been reviewed | New installations default to 90 days for both windows, adjustable up to 365 on Community; confirm it suits you under Data & Retention |
| Deployment security | TLS is in front of the container and LUMAFT_ALLOW_HTTP is unset |
Only you can verify this; the console cannot see the load balancer |
| Runner integration | Optional. Satisfied once runner evidence has arrived; Optional until then | Nothing required; see Runner integration when you want it |
Verify yourself is not a failure. It marks the checks where a green light from inside the container would be a false claim.
A tour of the console
The sidebar has two groups. Workspace is for everyone; Administration shows only the pages your role permits. The sidebar collapses to an icon rail; select the Lumaft icon at its top to expand it again. Appearance (under your account) offers a choice of light and dark themes and a UTC/local time preference, both saved with your account.
Overview
Observed Infrastructure: every configured backend with its project and stack counts, the latest recorded change, and observation freshness. It is the "is everything being watched" page. No backends configured yet means the backends file is empty or unset.
Stacks
The inventory, grouped by backend, project, and stack, with filters for backend, backend type, and a name search. Open a stack to reach the stack explorer:
- Resources — every resource in the current checkpoint, by URN, type, and name, with a search box.
- Outputs — the stack's exported values. Pulumi-marked secrets are redacted before they reach the browser. Unmarked plaintext is shown as Pulumi stored it.
- Operation history — the retained updates for this stack. Each row expands to a per-kind breakdown of created, updated, replaced, deleted, and unchanged resources when the evidence names them, and says plainly when it does not.
- Active locks — a Pulumi lock currently held on the stack, with its identity and when it was observed.
- Observation — when the current snapshot was taken and whether it is the latest or a last-successful view after a failed read.
A stack whose latest read failed keeps showing its last good snapshot, labelled Showing the last available inventory. Lumaft never shows a half-read state.
Operations
The cross-stack timeline. Every operation Lumaft has observed or been told about, newest first, with its outcome, its resource impact, and where the evidence came from. Filters live in the URL, so a view is a link. Reading the operation timeline explains every column and banner.
Reliability
Aggregate outcomes over an analysis window: success rate, operations per day, destructive resource actions, average and longest duration, and a daily trend. Each figure links back to the operations behind it. The window measures evidence first recorded in the window; imported history may have run earlier. Segmenting by backend, project, or stack requires Business.
Administration
| Page | What it is for | Requires |
|---|---|---|
| Backends | Backend records, diagnostics, and the first-run readiness checklist | backends:read, diagnostics permission |
| Users & Access | Accounts, roles, integration tokens, identity providers, stack scopes | accounts:manage, integrations:admin |
| Data & Retention | Retention windows, expiry health, purge, forget, legal holds, deletion history | operations:retention:manage, operations:purge |
| Notifications | Outbound notifications (Business) | Administrator |
| Licensing | Activate a connected license, read the installation ID, see effective entitlements | accounts:manage |
| Database | Storage provider status and the guided PostgreSQL adoption (Business) | Administrator |
A viewer sees none of these. That is the point of the viewer role.
What "normal" looks like
- Stacks populated within a minute; Operations within five.
- Backends show a last-observed time that advances every minute.
- Evidence coverage on Operations shows a collection start time per backend equal to when you started Lumaft. Everything before that is Before coverage began, forever.
- The expiry worker card on Data & Retention reads Succeeded after its first pass.
What to expect over the first day
- Update history from before Lumaft started appears as far back as the backend still holds it. Lumaft copies it into its own record, so from now on it survives the backend's pruning.
- Operations that Pulumi ran without a runner show a backend source and Changes not reported only where the backend record carried no counts; most updates carry them.
- If you wired up a runner, its first wrapped deployment appears as a runner row while it runs and a backend row after Lumaft observes the result. Two rows for one deployment is expected.
Next steps
- Add the rest of the team: Users and permissions.
- Take the first backup and write down the restore steps: Backup and disaster recovery.
- Decide on retention: Database integration.
- Know what the build cannot do before someone asks: Known limitations.