Settings & lifecycle

The settings area for each workspace is split into tabs (Profile, Members, Security, and more), and each field is gated by the role required: most are owner-only, with a handful that admins can also edit. A self-signup workspace starts active on the Free plan; after that, the limit preset and status are managed by Loha staff. See Workspace activation.

What's editable

Field	Who can edit	Notes
Display name	Owner, admin	Cosmetic. Shown in dashboards and emails. On the Profile tab.
Logo	Owner, admin	Square image. Used in the workspace picker and emails. On the Profile tab.
Slug	Nobody	Permanent. Pick wisely on creation.
Limit preset	Loha staff, via account manager	New workspaces start on Free; paid presets are applied by the Loha team, so contact us to change yours. Changing the preset changes seat limits, build minutes, and quotas. See Workspace activation.
Default trigger settings	Owner, admin	Affects newly connected repositories only.
Notification recipients	Owner, admin	Where build alerts go.

Renaming a workspace

The display name can be changed at any time and propagates immediately. The slug cannot be changed: it's burned into URLs and audit-log entries, and it identifies the workspace's isolation boundary. If you really need a new slug, the practical path is "create a new workspace, migrate, archive the old one." There is no in-place rename.

Ownership

A workspace has exactly one owner, set at creation. There is no self-serve ownership transfer. If ownership needs to move, contact your account manager.

Owner is the only role that can delete the workspace or change the 2FA mandate. See Members & roles for the full matrix.

Deleting a workspace

Owner-only, from Settings → Danger, and gated behind a typed confirmation plus a step-up re-authentication.

Deletion is a two-stage process:

Stage 1: immediately on request. A 30-day grace window opens. The workspace is suspended: it stops accepting work and members can no longer use it. Two things happen at once and are not reversible:

• API keys for the workspace are revoked: CI integrations using them stop working now, not in 30 days.
• In-flight builds are cancelled.

Stage 2: when the grace window expires. Erasure runs: repositories are disconnected (the upstream git repo is never touched), and secrets, build logs, and pipeline runs are deleted. Compute and storage are deprovisioned.

The audit log is retained past erasure, scoped to a tombstone organization id. The trail outlives the workspace.

You can cancel, but not undo the revocations

The owner can cancel a pending deletion at any point inside the 30-day window, and the workspace is restored to its previous status. But the revoked API keys and the cancelled builds do not come back. Reissue the keys and re-run the builds.

After the window closes, erasure is irreversible. Export anything you need before then.

Limit-preset changes and seat limits

Limit-preset changes are applied by the Loha team: contact us to request a change (see Workspace activation). Once applied, the new seat cap takes effect immediately. If the change is a downgrade to a preset with fewer seats than you currently have used:

• No members are kicked out. Existing members keep their access.
• New invites are blocked until you're back under the new cap (by removing members or revoking pending invitations).
• The Members page banner shows you the discrepancy and what to do.

Upgrading is the reverse: the new cap takes effect immediately and the next invite goes through.

Removed-member access revocation

When a member is removed (for any reason: explicit removal, workspace deletion, plan downgrade-driven cleanup), Loha takes three steps within the same request:

1. The member row is deleted.
2. All of that user's sessions are invalidated. Any open tab or live build view will fail on the next request and force re-auth.
3. All workspace-scoped API keys for that user are revoked. CI integrations using those keys stop working immediately.

The audit-log entry for the removal records how many sessions and API keys were revoked. See Members & roles for the full picture and what isn't revoked (already-cloned git repos, downloaded artifacts).

Two-factor authentication

The Security settings tab lets a workspace owner require two-factor authentication (2FA) for the workspace, and shows each member's current 2FA status (on/off) at a glance.

• Only the owner can toggle the mandate. Admins and members see the Security tab but the require-2FA switch is owner-only. Flipping it on sets a workspace-level requirement that members must have 2FA enabled on their account.
• The mandate doesn't enrol anyone. Enrolling in 2FA (a TOTP authenticator app) is an account-level action each person takes in their own Account → Security: it's tied to your Loha account, not to one workspace. The workspace mandate requires 2FA; it can't turn it on for you.
• How a member complies. A member who doesn't yet have 2FA enables it from Account → Security by scanning the TOTP QR code with an authenticator app and confirming a code. Once enabled, their row on the workspace Security tab flips to "on".

Requiring 2FA strengthens access control for the whole workspace: every person who can reach your builds, secrets, and pipelines is protected by a second factor, not a password alone. See Members & roles for what each role can do.

Audit-log retention

Each workspace's audit log keeps privileged actions: member changes, secret access, limit-preset changes, super-admin operations on the workspace. Owners and admins can view and export it from Settings → Audit.

Retention is governed by your workspace's effective retention policy, visible read-only under Settings → Retention and clamped by your limit preset. See Audit log for the window that applies to you.

See the Audit log page for the complete event catalog, retention policy, export workflow, and how the log maps to PDPA Article 30 compliance.

Super-admin activity

Loha staff (super-admins) can access any workspace for support and incident response. Every super-admin action on a workspace they aren't a regular member of is recorded, and owners and admins can review that activity from the Security settings tab.

PDPA Article 30

Recording super-admin reads and writes is our transparency commitment under PDPA Article 30: customers retain an independent verification path that Loha staff actions on their data are accountable. The same Article 30 obligation drives the broader Audit log retention policy.