Getting Started
Kora Actions and Approvals
Kora answers questions and reads your account instantly, but anything that changes your account stops and asks you to type a confirmation phrase back before it runs.
Two Kinds of Request
Every request you make of Kora falls into one of two categories, and they behave completely differently.
Reads happen immediately. Checking your plan, listing your sites, looking up a DNS record, fetching an invoice, reading site health. These change nothing, so there is no gate, no confirmation, and no credit cost.
Changes stop and ask. Anything that writes to your account, moves money, or destroys something goes through a typed confirmation gate before Kora will run it.
This is not a setting you can turn off. The confirmation model is enforced centrally for every channel Kora runs on, so a change cannot slip through because one surface forgot to check.
The Typed Confirmation
When Kora wants to make a change, its reply stops and shows three things:
- A plain summary of the exact action, naming the specific resource: the domain, the mailbox, the server, the backup date.
- A confirmation phrase, for example
yes restore backuporyes update wordpress. - The instruction: To confirm, type exactly: [phrase]. Or type anything else to cancel.
Type the phrase back and Kora runs the action. Type literally anything else, including "yes" on its own, and the action is cancelled.
Copy the phrase out of Kora's message rather than typing it from memory. It is shown in your Kora reply language, so in a language with macrons or diacritics an approximate retype will not match, and Kora will treat it as a cancellation.
What Always Confirms
The confirmation set is broad and deliberately so. In summary, Kora asks first before it:
- Deletes anything. A mailbox, a backup, a DNS record, a plugin, a theme, a WordPress user.
- Restores anything. A backup, a partial file restore, a server snapshot.
- Updates WordPress. Core, all plugins, a core rollback, a database repair, a search and replace, a database import, a security key rotation.
- Pushes or pulls between staging and production.
- Changes a plan or a subscription. Plan changes, billing-cycle switches, server resizes, cancellations, refund requests.
- Touches DNS. See the DNS rule below.
- Changes a domain's control. Nameservers, registrant email, transfer lock, auth code, transfer out.
- Changes email. Mailbox password resets, bulk mailbox creation, message archiving.
- Changes site security or delivery. Enabling or disabling the CDN, purging cache, geo-blocking, allowlist and denylist clears, SSL rotation.
- Powers or rebuilds a server. Power on, power off, reboot, hard reset, snapshot, snapshot restore, rescue mode, rebuild, on both cloud and dedicated servers.
- Runs a migration action. Cancelling, rolling back, importing a SQL dump, migrating from a backup.
- Installs software. WordPress or WooCommerce onto a site.
The DNS Rule, and Its One Exception
Every DNS mutation confirms. Creating, editing, deleting, bulk operations, zone file imports, applying a template, enabling or disabling DNSSEC: all of them stop and ask.
There is exactly one exemption. A plain verification TXT record, the kind a service gives you to prove you own a domain, is created instantly. It cannot affect traffic and it cannot affect mail, so gating it would be friction with no safety benefit.
The exemption is narrow on purpose. A TXT record that is actually a mail-authentication record, meaning SPF, DKIM or DMARC, whether detected by its content or by a reserved name like _dmarc or _domainkey, is not exempt and confirms like any other change.
If Kora is about to delete or edit a DNS record that Kapsule manages for your mail or your nameservers, the confirmation adds a caution saying so before you approve it. Read that line. Removing a managed MX or SPF record is the fastest way to stop your email arriving. See MX Records and SPF, DKIM and DMARC.
A Second Opinion Before You Confirm
For high-stakes changes, deletes, plan and billing changes, and most DNS work, a second and stronger reviewing model checks the proposed action before you see the confirmation. Its only job is to ask whether the action matches what you actually asked for and targets the right resource.
If it disagrees, its concern is added to the confirmation as a warning line. It never changes the action and it never approves on your behalf: the typed confirmation is still yours to give. If the review cannot run for any reason, the confirmation proceeds unchanged, so this can never block you.
One deliberate exclusion: the reviewer does not second-guess specific DNS record values such as MX hostnames or SPF includes. Those come from verified, current provider templates, and a language model's memory of a provider's DNS values is frequently out of date.
Who Is Allowed to Approve What
Kora enforces the same account roles as the rest of KPanel, centrally, for every action:
| Action type | Minimum role |
|---|---|
| Reads | Any account member, including Viewer |
| Changes and destructive actions | Owner or Admin |
| Billing actions: plan changes, cycle switches, resizes, cancellations, refunds | Owner, Admin or Billing |
If your role is not high enough, Kora says so plainly and tells you who on the account can do it. It does not silently fail or pretend to act.
Payments Need a Recognised Device
If a change involves a card charge and you are on a device the account cannot affirmatively recognise, Kora will not take the payment in chat. It hands you a direct link into the relevant KPanel page and says so explicitly: I will not charge it here. The panel then verifies you before the charge proceeds.
This fails closed by design. An unrecognised device, an expired session, or any uncertainty means the charge does not happen in the conversation.
What Kora Will Not Do At All
A small set of actions carries a real external cost and has no in-chat payment path yet. Kora refuses these outright rather than half-completing them:
- Renewing a domain, individually or in bulk
- Transferring a domain in
For these, Kora directs you to KPanel checkout, so the price you see is exactly what you pay, in your currency, with a proper invoice. Registering a new domain is available through Kora, because it routes through the real cart and you pay at checkout before anything is registered. See Domain Transfer In.
The Daily Action Limit
There is a cap of 200 Kora actions per account per day, counting actions that succeeded, are running, or are pending. It resets at midnight New Zealand time.
There is no limit on how many questions you can ask. The cap applies to changes only, and if you reach it Kora tells you the number and points you at KPanel, where nothing is capped.
Every Action Is Recorded
Each action Kora takes is written to an audit record with the action name, the parameters, Kora's stated reasoning, the outcome, and the request's IP address and browser. That record exists so the question "what changed, when, and who approved it" always has an answer.
Notably, the audit record is not erased when you erase Kora's memory. Conversation summaries can be forgotten; the record of what was done to your account cannot. See Reviewing and Erasing Kora's Memory.
What If It Fails
Kora says it made a change but nothing happened. If you never typed the confirmation phrase, the change never ran. Verify the real state in KPanel.
Your typed confirmation was not accepted. The match is exact. Copy the phrase from Kora's message. Some phrases include a value such as a domain or a date, and that part has to match too.
"That action needs admin permissions on this account." Your role does not permit it. Ask an Owner or Admin, or do it directly in KPanel.
"You have reached the daily limit of 200 Kora actions." Wait for the midnight reset or make the change in KPanel.
An action failed partway. Kora reports the failure and the audit record keeps the full detail. If the failure is not self-explanatory, open a support ticket and quote the date and time.