Privacy Policy

01Who we are and what this covers

Termite is a native SSH and terminal client. This policy explains what the Termite apps and the Termite backend do with your data. It covers the apps for iPhone, iPad, Mac and Android, and the versions for other desktop platforms as they ship. We have written it platform-neutrally; where a platform genuinely differs, the difference is called out in section 15.

In this policy, "we" and "us" means Sentryline Labs, the developer of Termite and the publisher named on the app's store listings. Contact details are in section 17. For people in the UK, EU and EEA, we are the data controller for the data described here.

Some things this policy describes only happen if you use the optional features that need them. The terminal itself works without an account, and the SSH side of the app never involves our backend: connections, keys and terminal traffic do not touch it whether you are signed in or not. One thing does happen without you asking: the app registers the device itself with our backend when it starts, before any sign-in, so that notifications can be addressed to it later. On Android that first-launch registration also carries a push token. It is described in section 2.

02What we collect, and why

Account

If you sign in, you get an account on our backend. Depending on the platform, you sign in with Sign in with Apple, Sign in with Google, or an email one-time code. We receive and store your email address, a display name if the provider supplies one, and the provider's subject identifier (the anonymous id that ties your sign-in to your account). We use this to authenticate you and to attach your subscription to you. We never receive your password with any of these methods.

Your sign-in session (access and refresh tokens) is stored on your device only, encrypted under a non-exportable key held by the platform secure hardware. Signing out deletes it, including when you are offline.

Device and push

To wake you when something on your server needs you, the app registers the device with our backend and stores:

• A device identifier we generate ourselves. On iPhone and iPad this is the App Attest key id, which is bound to that device's secure hardware. On Android it is a random 128-bit install identifier generated on first run. We deliberately do not use the advertising identifier, the Android ID, the IMEI or the device serial number. The app never reads them.
• A push token from Apple Push Notification service or Firebase Cloud Messaging, so a notification can reach that device.
• Your notification preferences: whether you want "command finished" and "agent waiting" alerts, your quiet-hours window, and your time-zone offset. We need the offset to apply quiet hours server-side, since the phone may be locked when the alert fires. Note that a time-zone offset plus a sleep window is a coarse hint about where you are and when you sleep; that is the cost of quiet hours working while your phone is asleep.
• A last-seen timestamp and a short log of push events (which host label, which event type, when) used to rate-limit and de-duplicate notifications.

Purchases

Termite is a paid app. Purchases are made through the storefront for your platform (today that is the App Store or Google Play), so we never see your card details. We use RevenueCat to validate receipts and tell us whether your subscription is active. RevenueCat identifies you by your Termite account id, not your email. Our backend stores your entitlement state (tier, product id, store, expiry) and, for auditability, the purchase events RevenueCat sends us. Those events contain store and transaction identifiers, product id, price, currency, environment and store country.

Abuse prevention and device attestation

On iPhone and iPad the app performs an Apple App Attest attestation, which shows that it is running on a genuine, unmodified Apple device. The attestation is verified on our own server against Apple's certificate chain; we do not send anything to Apple to do it, and we store the resulting key id and public key with the device record. We would rather be precise about what it does today than imply more: attestation is recorded but not yet enforced. While we finish rolling it out, a device that cannot produce a valid attestation is still allowed to register its push token and receive a Remote-awareness session credential. One thing it does gate unconditionally, on both platforms and regardless of that setting: linking a device to your account requires cryptographic proof of possession, so a device record can never be attached to an account without it. Enforcement for the rest is a change we intend to make before general availability. The equivalent Android check (Play Integrity) is planned and is not in the shipped Android app today.

If you use the natural-language command feature, our server records the IP address of the request and a timestamp so that we can enforce quotas and stop abuse.

Optional features that transmit content

Two features send content from your session off your device. Both are opt-in and described in full in section 6: Remote awareness (notifications about long-running commands and waiting agents) and natural-language command generation.

03What we don't collect

This list is not aspirational. Each item was checked against the code of every Termite app and of the backend. Where there is an exception, it is the one in section 6, and it is named there rather than hidden here.

• Your SSH private keys, passphrases and host passwords. They are held in the platform secure hardware, gated on your biometric or passcode, and there is no export path in the app. Our backend has no table, field or code path that could receive one.
• Your terminal scrollback and command output. Scrollback lives in memory in the app and is never written to a server. (The bounded exception is the short pane extract described in section 6.)
• Your keystrokes. What you type goes down the SSH connection to your own server. On Apple platforms the terminal also disables autocorrect and predictive text, so what you type in the terminal cannot enter the system keyboard dictionary. (The bounded exception is the same one: with Remote awareness on for a host, the text of a command that ran for at least 30 seconds is sent when it finishes. See section 6.)
• Your server addresses, ports and usernames. Your saved hosts live only on your device. There is no server-side host table, and the address, port and username of a host are never transmitted to us. What does travel with a notification event, and only for hosts you have opted in, is the display label you gave the host, the host's internal id (a random identifier meaningful only to your own app) and the tmux session name.
• The contents of files you transfer. SFTP streams directly between your device and your server.
• Your known-hosts records and host-key fingerprints. Stored locally for trust-on-first-use verification, never transmitted.
• Your port forwards and tunnel targets. Local only.
• Analytics, crash reports, advertising and attribution. No Termite app contains an analytics, crash-reporting, ad or attribution SDK, and our backend runs no analytics. There is no IDFA/ATT prompt on Apple platforms and no advertising-id permission on Android; the apps never read an advertising identifier. Two honest qualifications. Our Android purchase dependency pulls in an unused Google advertising-id library that we never call and that adds no permission to the app, but a store scanner may still see it. And the SDKs we do depend on report their own metadata to their own companies: Google's push SDK sends device model, operating-system version, SDK versions and app version to Google as part of registration, and our payment processor's SDK reports device type, operating-system version, locale and country with the receipt data. We do not choose or control what those SDKs send; some of it (country, device type) is visible to us in the processor's own dashboard. The store privacy labels record these flows as "Diagnostics".
• Location, contacts, microphone, photos library, phone identifiers. The apps request only the permissions they use: notifications, camera (for scanning a connection QR code, at the moment you tap it), and biometrics. Camera frames are decoded in memory and never stored or uploaded.
• Anything sent to a server we do not control. Apart from the processors listed in section 8, the apps talk to exactly one first-party hostname: our Supabase project.

04The SSH reality

This is the part people most want to know, so it gets its own section.

Your SSH connections go straight from your device to your servers. There is no Termite relay, proxy, bastion or "cloud terminal". We could not read your session if we wanted to, because the traffic never reaches us. Authentication happens between your device and your host using a key held in your device's secure hardware.

The same is true of the actions you take from a notification. When you tap Approve, Reject or Stop on your lock screen, the keystroke is delivered over the app's own SSH connection to your host. Our backend does not execute anything on your machines and holds no credential that would let it.

Two related honesty notes. First, a notification tells the app which saved host it refers to by id; the app resolves that against hosts already saved on your device, so a bad message cannot point the app at a server you never configured. Second, if you enable Remote awareness, the app writes a session credential onto your own server so the shell hook there can post events to us. See the next section.

05Where your data lives

Most of what Termite knows about you lives on your device: your hosts, identities, keys, known-hosts records, snippets, tunnels, recent connections and preferences. That data is in the app's private storage, and secrets are in the platform secure hardware.

The account data described in section 2 lives in our backend, which is hosted on Supabase (managed Postgres and serverless functions). Supabase processes this data on our instructions as our hosting provider. Payment processing sits with Apple or Google, and receipt validation with RevenueCat.

Every table holding user data has row-level security enabled with an explicit deny-all policy for client roles; only our server-side functions, using a privileged role, can read or write it. The only table any client can read directly is a static configuration table used to recognise AI agents in terminal output. It contains no user data.

06Remote awareness and AI-agent features

These are the features where content from your session leaves your device. They are optional, off by default, and worth understanding before you switch them on.

Remote awareness (per-host, default off)

Turning on Remote awareness for a host lets Termite install a small shell hook on that server, and gives that hook a session credential so it can post events to our backend. From then on, for that host:

• When a command that ran for at least 30 seconds finishes, the hook sends us the text of the command line, its exit code, your host label, the host id and the tmux session name. We do not store the command text (it is used to build the notification and then dropped), but it does travel to Apple's or Google's push service as the notification body, which means those companies can read it.
• When an AI agent in your session pauses for input, the app sends us the last eight rendered lines of that terminal pane. Our server reduces them to a short question of at most 160 characters before use, and we do not store either the capture or the extract, but the full eight lines cross the network to us, and the extract goes on to Apple or Google as the notification body.

We store, per event, only the host label and the event type with a timestamp, so we can rate-limit and collapse duplicate notifications. The address, port and username of that host are never sent.

Turning Remote awareness off stops new events. The session credential already written to that server remains there until it is rotated or you remove the hook. It is a credential that only allows posting events for that session, and it grants no access to your account or your other data.

Natural-language command generation

On supported platforms, you can describe what you want in English and have Termite propose a shell command. When you do, we send your prompt (up to 2,000 characters) and the shell context you have allowed to our backend, which forwards it to a third-party AI model provider to generate the command. The context fields are individually controllable: your working directory and git branch are included by default, and your recent shell commands (up to ten) are excluded by default, because a command you typed with a token or password inline would otherwise go with it. The app says this in the settings screen too.

Nothing is executed automatically. The proposed command is shown to you and runs only when you send it. Our backend caches the model's response keyed by a hash of the request, so repeating the same prompt does not re-bill the model, and it records the request's IP address and a timestamp for quota enforcement.

07What appears on your lock screen

Notifications are the one place Termite renders remote content outside the app, including on a locked device. A wake notification can show:

• the host label you chose, as the subtitle;
• the command line that finished (first ~120 characters), or the short extract of what the agent is asking (up to 160 characters) as the body;
• on Apple platforms, a Live Activity on the lock screen and in the Dynamic Island showing the host, the agent name, the phase and elapsed time, plus the same short prompt.

A Live Activity has to be addressable while it is running, so registering one stores on our servers its own push token together with the host it belongs to. That registration is deleted when the activity ends or when Apple tells us the token is dead.

These only appear if you turned Remote awareness on for that host. There is currently no setting to keep the Live Activity while hiding the prompt text, and no "hide notification content on the lock screen" option inside Termite. Your operating system's own lock-screen preview settings are the control that works today. Quiet hours suppress alerts server-side during the window you set.

08Third parties who process data for us

We do not sell your data, we do not share it for advertising, and we do not use it to build profiles. These are the only companies that receive anything, and each receives only what its job requires.

Scroll the table sideways for all four columns →

Each of these third parties is engaged under a written agreement that requires them to provide the same or an equal level of protection for your data as this policy states, to process it only on our instructions and only for the purpose described above, and not to use it for their own advertising or profiling. The same requirement applies to any parent, subsidiary or other related entity that would have access to user data. We do not work with data brokers.

We may also disclose data if we are legally required to, or where necessary to investigate abuse of the service. If Termite is ever sold or merged, we will tell you before your data moves to a new controller.

09How long we keep things

Honestly stated, because this is where a lot of policies get vague:

• Written to no database table: the command text and the pane extract sent by Remote awareness. They are held in memory only long enough to build a notification. They do still pass through our hosting provider's platform as ordinary request bodies, and its function logs can retain diagnostic fragments. In particular, if the AI model provider returns an error, part of that request can appear in a server log.
• Deleted when you sign out: your sign-in session on that device, and nothing else. Signing out is not an erasure. See the note in section 10.
• Kept on your device until you delete it or uninstall the app: hosts, keys, known hosts, recent connections, preferences, the device identifier, and any Remote-awareness session credential.
• Kept on our servers until you ask us to delete it: your account record, device records and push tokens, notification preferences, the Remote-awareness session credentials issued to your devices, Live Activity registrations (a push token plus the host it belongs to), the push-event log (host label, event type, timestamp), and entitlement and purchase-event records. We do not currently run automated expiry on these. A push token is cleared automatically when Apple or Google tells us it is dead, and a Live Activity registration is removed when the activity ends.
• Kept indefinitely, and not linked to your account: the request-quota rows created by the natural-language command feature, which hold an IP address and a timestamp with no account column, and the generated-command cache, whose entries are keyed by a one-way hash of the request. Because nothing ties either to your account id, we cannot find them from a deletion request; they are also the two records with no automatic expiry today. We are fixing both: a scheduled purge is the right answer here, and it is not yet in place.
• Held by others on their own schedules: Apple, Google, RevenueCat and Supabase retain what they retain under their own policies.

We would rather publish that list than a vaguer one. Automatic expiry for the transient records above (quota rows, cached generations, push-event logs) is work we have not finished; until it ships, the deletion route in section 11 is the mechanism that clears everything it can reach.

10Your controls in the app

• Remote awareness is per host, in the host editor, and off unless you turn it on.
• Notification preferences (which events alert you, and quiet hours) are in Settings. The operating system's notification permission is the master switch.
• Command-generation context (working directory, git branch, recent commands) is toggled field by field. A field you switch off is not sent at all, rather than sent blank.
• Host-key strictness can be tightened in Settings. On Android there are two modes, trust-on-first-use or strict, and a trusted host key can be revoked ("forget host") at any time. On Apple platforms there is a third mode, Off, which accepts any host without prompting; we do not recommend it, and there is no revoke control on Apple platforms today, so removing a trusted key means resetting that setting rather than forgetting a single host.
• Keys and identities can be deleted; deleting one destroys the key material, not just the record.
• Configuration export is available on Apple platforms: a JSON file of hosts, snippets and tunnels. By design it contains no keys and no passwords.
• Signing out deletes your session from the device.

11Account and data deletion

There is not yet an in-app button to delete your account. We would rather say that plainly than imply otherwise. We are building one; until it ships, deletion works by request:

• Email us from the address you signed in with, asking for account deletion. If you signed in with Apple's private relay, include enough detail for us to identify the account.
• We will delete every record we can locate from your account: your account record, your device records and push tokens, your notification preferences, the Remote-awareness session credentials issued to your devices, your Live Activity registrations, your push-event log (including the host labels in it), and your entitlement and purchase-event records. This is done by hand today (there is no automated cascade behind it), so we will confirm when it is finished, normally within 30 days.
• Two things a deletion request cannot reach, and we would rather say so: the request-quota rows created by the natural-language command feature hold only an IP address and a timestamp with no account column, and the generated-command cache is keyed by a one-way hash of the request. Neither is linked to your account id, so neither can be found from it. They are not used to identify you, and we are adding scheduled expiry for both.
• You can also ask for a copy of what we hold, and we will send it in a machine-readable form.
• Deleting your account does not cancel a subscription. Subscriptions are managed by the storefront you bought through (today the App Store or Google Play), and you cancel them there. It also does not touch anything on your own servers, or the data on your device: delete the app for that.
• We may keep a minimal record of a purchase where tax or accounting law requires it.

12How we protect data

• Secure hardware for secrets. On Apple platforms, keys are Keychain items marked this-device-only and non-syncable, every use is gated on Face ID / Touch ID / passcode, and generated P-256 keys are created inside the Secure Enclave. On Android, generated keys are non-exportable Keystore entries requiring user authentication, and imported keys and saved passwords are AES-256-GCM encrypted under a hardware-backed key that also requires authentication for each use. There is no code path in any Termite app that stores an SSH secret without that gate.
• Encryption in transit. All traffic between the app and our backend is HTTPS/TLS, with no exceptions to Apple's App Transport Security on Apple platforms and no cleartext traffic permitted in release builds on Android. Push delivery to Apple and Google is over TLS. Your SSH traffic is protected by SSH itself, with host-key verification on by default on every platform. The strength of that check differs, and section 10 has the detail: on Android a changed host key is an unconditional hard block and verification cannot be switched off; on Apple platforms a changed key raises a warning you have to accept, and an "Off" setting exists that accepts both new and changed keys silently.
• Least privilege on the server. Row-level security with deny-all policies for client roles; every user token is verified server-side before any data is touched; the only client-readable table holds static configuration.
• Device attestation. On iPhone and iPad the app performs an App Attest attestation and we verify it server-side, and proof of possession is required before a device can be linked to your account. As section 2 says plainly, attestation is not yet enforced as a condition of issuing push credentials; enforcing it is outstanding work. Play Integrity is planned for Android and is not present today.
• No secret logging. No Termite app logs credentials or terminal content; secret-bearing values are redacted in any diagnostic string. Server-side is a weaker guarantee. See the first bullet of section 9.

Two things we want you to know rather than discover: server-side, the small operational values we store (push tokens, the Remote-awareness session credential, event records) are held in our database without an additional application-level encryption layer on top of the provider's storage encryption; and no Termite app currently blurs the terminal in the app switcher, so live terminal content can appear in a system app-switcher thumbnail or a screenshot. No security is perfect, and we will not claim otherwise.

13Children

Termite is a developer tool. It is not directed at children, and we do not knowingly collect data from anyone under 13, or under 16 where local law sets that threshold. If you believe a child has created an account, write to us and we will delete it.

14International transfers, legal bases and your rights

Termite is used worldwide, and our providers (Supabase, Apple, Google, RevenueCat and the AI model provider) operate internationally. Your data may therefore be processed in a country other than your own, including the United States. Where we transfer personal data out of the UK, EU or EEA, we rely on the transfer mechanisms our providers make available, such as the European Commission's Standard Contractual Clauses.

If UK or EU data protection law applies to you, our legal bases are:

• Performance of a contract: running your account, delivering the app's features and honouring your subscription.
• Legitimate interests: keeping the service secure and available, preventing abuse, and enforcing usage quotas. We keep the data used for this to the minimum that works.
• Consent: for the optional features that transmit session content (Remote awareness and natural-language generation) and for notifications. You can withdraw it by turning the feature off or revoking the notification permission.
• Legal obligation: where we must keep records, for example for tax.

You have the right to access your data, to correct it, to delete it, to restrict or object to processing, to data portability, and to withdraw consent at any time. Use the contact address below; deletion and export are described in section 11. You also have the right to complain to your data protection authority. In the UK, that is the Information Commissioner's Office.

If you are in California: we do not sell or share your personal information as those terms are defined by the CCPA/CPRA, and we do not use it for cross-context behavioural advertising. You have the right to know, delete and correct, and we will not discriminate against you for exercising any of these rights. The categories we collect are the ones listed in section 2; the business purposes are the ones stated beside them.

15Platform specifics

• iPhone and iPad. The full feature set: Sign in with Apple, App Attest, APNs notifications, Live Activities and Dynamic Island, and natural-language command generation. Local app data (hosts, downloaded files, preferences) is included in your Apple device backup if you have backups enabled; keys are not, because they are stored as this-device-only Keychain items. Two differences worth naming: host-key verification has an Off mode here that Android does not offer, and there is no "forget host" control for revoking a single trusted key.
• Mac. A deliberately smaller surface: sandboxed with outbound network access only, and no device attestation, no push notifications and no Live Activities.
• Android. Sign in with Google or an email one-time code; FCM notifications; keys in the Android Keystore, StrongBox-backed where the device supports it. System backup is disabled entirely, so app data does not leave via Auto Backup or device transfer. Device attestation is not yet present. Firebase registers at first launch, as noted in section 2. Host-key verification cannot be switched off.
• Windows and Linux. Not shipped at the time of writing. When they arrive, this policy will be updated (before they are released) to describe how they store secrets, whether they participate in notifications, and which storefront or billing route they use, since neither the App Store nor Google Play covers a desktop build.

Where this policy says "on supported platforms", the feature exists on some platforms today and is planned for the rest as they reach parity. We will not quietly widen what a feature collects when it lands on a new platform; if that changes, section 16 applies.

16Changes to this policy

If we change this policy, we will update the effective date at the top and keep the current version at this address. If a change materially affects what we collect or who receives it (a new processor, a new category of data, a new default), we will tell you in the app, or by email, before it takes effect, and we will not apply it retroactively to data already collected.

17Contact

Privacy questions, access requests, deletion requests, or a mistake you have spotted in this document all go to the same place, and a person reads it.

Please put "privacy" or "delete my account" in the subject line so it is not missed.