Uninstall & reset
Permaura is easy to take out again, and worth knowing how to before you put it in. Work top-down: revoking access takes effect immediately, whereas deleting files does not revoke anything on its own.
Deleting the gateway's files does not revoke an agent's session or unpair a device — those records live on your account. Do the console steps first, then remove the software.
Cut off access right now
If you need everything to stop this second, you don't have to uninstall anything.
- One integration — open the connection and hit its kill switch. Every call through it is refused instantly, across every agent and grant.
- Everything — stop the gateway. A gateway that isn't running can't act, whatever any grant says. (There's also a global pause on the gateway itself, reachable from the REST API —
POST /v1/broker/pause— which halts every call without taking the process down.) - One agent — remove it on the Agents page. Its sessions are revoked immediately, and grants that named only that agent are deleted with it, so it can't quietly return with access you thought you'd taken away.
Stop the gateway
Running from the terminal
Ctrl-C in the window it's running in. To find and stop one you've lost track of:
pkill -f permaura
Running under the desktop app
Quit the app. It supervises the gateway and stops it on the way out.
Remove the gateway and its data
Everything the gateway installs and stores lives in one directory: ~/.permaura (or wherever you pointed PERMAURA_HOME). Inside it are bin/permaura and gateway.db.
First take the permaura command off your PATH, while the binary is still there to do it:
permaura unlink
The installer and the desktop app put a symlink on your PATH pointing into ~/.permaura/bin. Like the boot service below, it lives outside the directory you are about to delete, so removing the directory first leaves a permaura on your PATH that points at nothing — and unlink needs the binary in order to run, so afterwards it cannot clean up after itself. It only ever removes a link Permaura created, and says so when it leaves anything else alone.
Then remove the directory:
rm -rf ~/.permaura
That removes the binary, the local store, and the sealed vault it holds.
Nothing is broken, but a dead permaura is still on your PATH. Find and remove it by hand:
ls -l "$(command -v permaura)" && rm "$(command -v permaura)"
Check where it points before you delete it. If it resolves somewhere other than ~/.permaura/bin or Permaura.app, it belongs to something else.
If you installed it with the one-liner, remove the boot service too
The curl installer registers the gateway to start on its own — a systemd unit on Linux by default, and a login agent on macOS if you asked for one with --service. That registration lives outside ~/.permaura, so deleting the directory leaves it enabled and pointing at a binary that is gone.
# Linux, whichever of the two you have
sudo systemctl disable --now permaura && sudo rm /etc/systemd/system/permaura.service
systemctl --user disable --now permaura && rm ~/.config/systemd/user/permaura.service
# macOS, only if you installed a login agent
launchctl bootout gui/$(id -u)/com.permaura.gateway
rm ~/Library/LaunchAgents/com.permaura.gateway.plist
Credentials are sealed on the gateway and cannot be read back, so there is no copy of them anywhere else. Once gateway.db is gone, every connection's credential has to be entered again, and the local audit chain goes with it. If you might want the audit trail, read it out first — the console's Audit log page, or permaura audit.
Your account on permaura.com is untouched by this. Connections, policies, and grants defined there stay as they are — you can pair a fresh gateway and set the credentials again.
Remove the desktop app
Quit the app, then drag Permaura from Applications to the Trash. Its own preferences live under ~/Library/Application Support/com.permaura.desktop; remove that too for a clean slate. Deleting the app does not delete ~/.permaura, so do both if you want the gateway gone as well.
Turn off remote access
Flip the Remote access switch off under Settings → Gateway. Permaura tears the tunnel down and the public URL stops answering. With the desktop app your gateway is relaunched local-only; running headless, stop cloudflared and restart the gateway without PERMAURA_PUBLIC_URL.
The public hostname is stable and reserved for you — turn remote access on again later and you get the same URL back, so anything already pointed at it keeps working.
Unpair an approval device
Open Workspace → Devices and revoke the device. Its signing key is no longer trusted and it stops receiving approval pushes.
On a hosted gateway there is one exception: revoking your last usable device asks you to prove it's you again first, with your password or a two-step code. Emptying the keyring returns the worker to trusting the next device on first use, so it is the one revocation that loosens rather than tightens. Every other revocation, on every gateway, asks for nothing.
From the moment a device is paired, the gateway stops accepting unsigned approvals — and revoking that device does not lift the requirement. That's deliberate: otherwise anyone holding your account session could clear the bar by removing a device.
Pair a replacement, or lower the floor. Where you can lower it from depends on the gateway: on a local or tunnelled one, only from the machine running it; on a hosted one, from the console under Workspace → Devices after a fresh sign-in, and while a working device is still trusted that device has to sign the change as well. See Approvals, and Playbooks for a hosted gateway whose last device is gone.
On a hosted gateway, a second approval device is normally held until a device you already paired confirms it. Revoke every device first and that requirement drops, so a replacement enrols on your re-authenticated account alone. It's the recovery path, and it's the reason to revoke before you pair rather than after.
That is precisely why taking out the last device needs a sign-in of its own: it is what re-opens the first-use door. Doing the whole recovery therefore means signing in twice, once to revoke and once to pair, and neither proof can be spent as the other.
Reset a workspace without starting over
To hand a workspace a clean slate while keeping your account and plan:
- Remove every agent (revokes their sessions).
- Delete the grants, then the policies, then the connections — in that order, since each is referenced by the one before it.
- Stop the gateway and delete
~/.permaura/gateway.db, then pair a fresh gateway.
Cancel a paid plan
Settings → Billing → Cancel. You keep the plan's features until the period you've already paid for ends, then drop to Free. Cancelling never destroys your setup: the local loop — connections, policies, grants, audit — keeps working, and you only lose the paid reach features. Hosted workers are paused during a grace period rather than torn down, so paying again picks up where you left off.
Close your account
Settings → Account → Delete account (/settings/account/delete), or Delete account on the phone app, which opens the same page. It takes two confirmations:
- Enter your password on that page. Permaura emails you a confirmation link, good for 24 hours. Nothing has been deleted at this point.
- Open the link and confirm once more. That's the point of no return.
The page tells you up front exactly what will go, so you're never sent into a flow that fails at the end:
- Organisations you own alone are deleted with you, and their workspaces, gateways, connections and audit rows go with them.
- Organisations you're only a member of are untouched. You lose your access; nobody else is affected.
Two things you have to resolve first
Deletion is blocked, with the reason shown on the page, until each is cleared:
- A live subscription. Cancel it first. Cancelling someone's billing as a side effect of a deletion isn't ours to do quietly, and leaving it running would keep charging someone who believes they're gone. A plan you've already cancelled but are still inside the paid period for does not block you.
- An organisation with other members. Hand it over to another owner, or delete the organisation, first. Paying for a seat never gives you the power to delete somebody else's account, so those members survive either way.
There is no restore, no grace period after the second confirmation, and no copy of your sealed credentials anywhere. Read out anything you want from the audit log before you start.
Deleting your account doesn't touch the software on your machine. Stop and remove the gateway separately, as above.