Privacy policy

SERVER SIDEKICK LLC ("we", "us") makes the Server Sidekick app (the "app") and runs https://www.serversidekick.app (the "website").

The short version

The sections below give the detail.

What the app stores, and where

What you put into the app is stored on your device: saved hosts and groups (including addresses, MAC addresses and startup commands), usernames, passwords, SSH keys, SSH certificates, host keys you have accepted, snippets, saved runbooks, saved port forwards, the commands you run, a log of the app's activity, background jobs, a diagnostics log of the errors and warnings the app has run into (with host names, addresses, usernames, commands and secrets removed), metrics it has sampled from your servers, snapshots of servers you've turned Drift on for (their system details, installed packages, services, users and groups, open ports, and the text of any config files you chose to watch), which stay on this device, stored encrypted, and are not synced or included in the app's backups, alert rules, the alert history read back from your servers, favorites and settings. Depending on what you set up, it also stores:

• A server's BMC (its management controller): the BMC's address, the fingerprint of a certificate you chose to trust for it, and the BMC's username and password.
• Web pages on your servers that you open inside the app (see "Connections the app makes"): for each certificate you chose to trust for one, which saved host and port it is for, the certificate's fingerprint and name, and when you trusted it.
• Alert destinations: where your servers send alerts (an ntfy server and topic, an access token, a webhook address and its headers, or a Healthchecks ping address), and a record of what the app last installed on each server (see "Alerts").
• Backup repositories: the restic or Borg repositories you add for a server (where each one is, and how the server finds its password), and any repository password you choose to save.
• X11 forwarding (on a computer): whether it is on for a host, and the last few X applications you started.
• The AI assistant: the address of the AI service, the model name, whether the assistant is on, and your API key for that service.
• Sync: the sync server's address, your username there, the fingerprint of a certificate you chose to trust for it, the server password or app password, sync's encryption keys, sync's own bookkeeping (the names of your other syncing devices and when each last synced), whether this device syncs passwords and keys, whether it syncs preferences, and any code this device has shown to add another device, until it is used or expires.
• The purchase: whether this device has Unlimited Hosts, which store said so, and when (see "Purchases").

Passwords and keys are stored encrypted. Your saved passwords and SSH keys, and your alert destinations and Drift snapshots, are encrypted by the app, with a key held in your device's secure storage (the Keychain on Apple platforms, the Keystore on Android). BMC usernames and passwords, the assistant's API key, saved backup repository passwords, and sync's server password and encryption keys are kept in that secure storage directly. The rest is not encrypted by the app. Where it is kept depends on the device:

• iPhone, iPad and Android: in the app's private storage, which the operating system keeps other apps out of.
• Mac: in your Documents folder, as files named after what they hold (such as hosts.hive), where other apps you run can read them. If your Mac syncs Documents with iCloud Drive, those files are synced too, under Apple's privacy policy. Passwords and keys stay encrypted either way. On the Mac the app also uses your own ~/.ssh/known_hosts file, as ssh does, and can import host keys from it when you ask. Sync never reads or changes that file; it works only with the app's own list of host keys. A key from your file that the app has copied into its own list, because you imported it or because you connected to that host, is in that list and syncs (see "Sync").

iPhone and iPad backup. If you back up your iPhone or iPad to iCloud or to a computer, iOS includes the app's data in that backup, under Apple's privacy policy. Passwords, keys and the other items in secure storage stay encrypted in it.

Android device backup. If you have Android's backup turned on, Android includes the app's list of hosts and groups (names, addresses, ports, MAC addresses, startup commands, jump hosts, Proxmox details, a BMC's address, and per-host choices such as the terminal multiplexer and whether X11 or SSH agent forwarding is on) in your Google account backup and in device-to-device transfers, so they come back when you set up a new phone. Saved credentials (usernames, passwords and SSH keys), BMC logins, alert destinations and everything else are left out. This backup is made by Android under Google's privacy policy, not by us, and you can turn it off in Android's settings.

If you turn on app lock, the app asks your device to verify you with Face ID, Touch ID, your fingerprint or your passcode. Your device does the check. The app learns only whether it passed and never receives your biometric data. While app lock is on, the app also hides its contents from the app switcher on iPhone, iPad and Android, and on Android it blocks screenshots and screen recording of the app.

Connections the app makes

The app connects only where you tell it to:

• Your servers, over SSH and SFTP. The commands you run and the files you transfer go between your device and those servers, not through us. SSH encrypts that traffic. Network tools such as ping, traceroute, DNS lookups and HTTP checks run on your server, not on your device. To show whether a saved host is up, the app checks from your device whether its SSH port answers. While the dashboard is on screen, the app keeps connections to your hosts open and reads their load, memory and disk every few seconds.
• Web pages on your servers, when you open a Jupyter or code-server notebook, or a web admin page found on one of your hosts (such as Proxmox's or Cockpit's) that the app reaches through an SSH tunnel. On iPhone, iPad, Android and Mac the page opens inside the app, in your device's own web view (WebKit on Apple devices, Android System WebView on Android), and travels inside SSH to that server only. A link on the page to another site opens in your browser instead. For a Jupyter server, the address the app opens carries the server's login token; the app never shows it or logs it, and hands it to nothing but the web view (and, on a Mac, your browser if you choose Open in browser). The web view keeps the cookies, cache and other site data those pages set on your device, as a browser does, so a page can remember that you signed in. That site data is not synced and not in the app's backups. A page whose certificate your device does not trust is refused. For a web admin page you can check that certificate (its fingerprint and name are shown) and trust it; after that only that exact certificate is accepted, and a different one is refused with a warning showing both.
• SSH agent forwarding, if you turn it on for a host. A server you are connected to can then ask the app to sign in to another server with that host's own saved key. The server learns the key's public part, its certificate if it has one, and the name you gave the credential. The app asks you before every signature, names the key and the server, and never sends the private key.
• An X server on your computer, if you turn on X11 forwarding (on a Mac or another computer, not on a phone or tablet). The app connects the server's X programs to the X server your computer's DISPLAY setting names, usually XQuartz on a Mac, and reads that X server's access cookie from xauth on your computer. Your server only ever sees a random stand-in cookie. If DISPLAY names another machine, the app connects to that machine.
• Services on your own network or accounts, such as a Proxmox host you have added. When you open a web app found on one of your hosts, the app may first check that its port answers.
• A server's BMC, if you add one. The app connects directly from your device to the BMC address you entered, over HTTPS, only when you open or use that server's BMC screen. It sends the BMC username and password with each request, to that address only. It refuses a certificate your device does not trust until you have checked and trusted that exact certificate. What the BMC reports is shown to you, not saved.
• Your sync server, if you turn on sync. See "Sync" below.
• The AI service you choose, if you set up the assistant. See "The AI assistant" below.
• The App Store or Google Play, on iPhone, iPad and Android, to show the price of the in-app purchase and to check whether you own it. See "Purchases" below.
• Your local network, when you ask the app to scan it. The scan looks for SSH servers, asks the network's devices to announce themselves (through Bonjour/mDNS and UPnP/SSDP) and looks up their names, so it can list devices such as printers or media players by name. Wake-on-LAN, when you use it, sends a wake-up packet on your local network. The results stay on your device. On iOS this is why the app asks for Local Network access.
• Links you tap, such as the website or a help page, which open in your browser. Those sites have their own privacy policies.

Alerts add no connection from your device: your servers send them (see "Alerts").

When you switch away on iPhone or iPad. iOS suspends an app soon after you leave it, and the app's connections drop. So that a quick switch to another app and back, or a quick lock and unlock, doesn't cut you off, the app asks iOS for a little more time while a terminal session or a tunnel is open: usually about 30 seconds, as iOS decides. In that time the connections already open stay open, to your own servers only. The app makes no new connection to your servers, uses no saved password or key, and reconnects nothing until you are back in the app (and past app lock, if it is on). The extra time ends when you come back, when the last session and tunnel have closed, or when iOS ends it. Then the app stops its tunnels and iOS suspends it. The one other thing that can happen in that time is a sync round falling due, which goes only to your sync server, as it would with the app in front. The app has no background refresh: once it is suspended or closed, nothing in it connects anywhere until you open it again.

Google's barcode scanner on Android. When you scan a QR code on Android, the app uses Google's ML Kit barcode scanner, which runs on your device. The image is not sent anywhere, but ML Kit may send Google information about the scanner's use: the device's manufacturer, model and OS version, the app's package name and version, a per-installation identifier and performance measurements such as how long a scan took. Google uses it for diagnostics and usage analytics. See Google's ML Kit data disclosure. On iPhone, iPad and Mac, QR codes are read by Apple's or the app's own on-device code, and nothing is sent.

The servers and services you connect to are run by you or by third parties. We have no access to what they collect, and their own policies apply.

Sync

Sync is optional and off until you set it up in Settings → Sync. It keeps your hosts and related items the same on your devices through a WebDAV server you choose, such as your own Nextcloud, ownCloud or NAS. We do not run a sync server and never receive your synced data.

• What syncs. If you turn on sync, the app stores your hosts, groups, port forwards, alert rules, snippets, runbooks, which servers you watch with Drift and which of their config files and favorites on the WebDAV server you chose, encrypted on your device with a key protected by a sync passphrase you choose. A host includes its name, address, port, MAC address, startup command, jump host, Proxmox details, a BMC's address and trusted certificate, the backup repositories you added for it (where each one is, and how the server finds its password), and choices such as its terminal multiplexer and whether X11 or SSH agent forwarding is on. The server can't read your synced data: it sees only encrypted files, a file holding the encrypted key, their sizes and when they change (see "What the server can see").
• Passwords and keys. Passwords, SSH keys and alert destinations are included only on devices where you also turn on "Sync passwords and keys", and never a credential you mark "Keep on this device only". With it on, a device sends your saved credentials (their names, usernames, passwords, SSH keys and key passphrases, and any SSH certificates), which credential each host and group uses, and your alert destinations (including ntfy tokens and webhook addresses). It also sends BMC usernames and passwords, backup repository passwords you chose to remember and the assistant's API key. It is off by default on each device, and turning it on asks for your sync passphrase. Turning it off stops this device sending and receiving them; it deletes nothing, here or on your other devices.
• Preferences. "Sync preferences" is on unless you turn it off on a device. With it on, your theme, temperature unit, the assistant's service address and model, and the terminal's colors, font, key row and what leaving a host's terminal does with sessions still running sync too. The terminal's text size, whether the key row shows, and whether the assistant is on stay on each device. Turning it off stops this device sending and receiving preferences; it deletes nothing.
• Host keys. The host keys your app has accepted sync too, whether or not "Sync passwords and keys" is on: there is no separate switch for them. For each key that is the host's name or address and port, the key's type and fingerprint (not the key itself), when you accepted it, and whether it came from a line your known_hosts file marks @revoked, a key to refuse. A key you accept the first time you connect, a changed key you accept, a host key you forget, and keys you import (including revoked ones) reach your other devices, so they trust or refuse the same keys without asking again. That also means a changed key you accept on one device is accepted on all of them. The Known Hosts screen shows which of your devices each key came from. When you add a device that already trusts a different key for a host than your synced data does, the app shows both and uses the synced key unless you choose to keep that device's. Host keys are encrypted like everything else that syncs, and the server sees only the encrypted file. If you import a known_hosts file, everything the import added syncs as well, including host keys for servers that are not in your host list, so your sync folder's encrypted data can name servers you have never added to the app. Entries that file hashes stay hashed: the app keeps and syncs the hash and its salt as written, and never learns the name behind it. Your own ~/.ssh/known_hosts file on a Mac is not read or changed by sync (see "What the app stores, and where").
• Web page certificates. A certificate you trust for a web page on one of your servers (see "Connections the app makes") syncs like a host key, whether or not "Sync passwords and keys" is on: which saved host and port it is for, the certificate's fingerprint and name, and when you trusted it. Trusting a certificate on one device trusts it on all of them, and trusting a changed one replaces it on all of them; the app says so when it asks. Deleting a host forgets its certificates on every device. When you add a device that already trusts a different certificate for a page, the app uses the synced one unless you choose to keep that device's. The pages' cookies, cache and other site data never sync.
• What does not sync. The purchase, your logs and history (including alert history and metrics), Drift snapshots, the web view's site data, the demo host, sync's own settings and the rest of this device's settings (such as app lock and the layout) do not sync.
• End-to-end encrypted. Everything that syncs is encrypted on your device before it is sent, with a key protected by your sync passphrase. The app never sends the passphrase anywhere and does not store it, so neither the server nor we can read your synced data. Anyone who has the synced files and learns your sync passphrase can read what they hold. We never receive the passphrase or the files, and cannot recover them. How sync's encryption works.
• What the server can see. It stores one encrypted file per device, named with a random ID, and an unencrypted file holding the encrypted key and the settings used to derive it from your passphrase. From these it can tell how many devices sync, roughly how much data each holds and when each last synced. It also receives your username and password for it, and your device's IP address, as any server you connect to does. Each device's name in the sync list (its model, such as "iPhone 17 Pro", or a name you give it) is inside the encrypted file.
• Adding a device with a code. "Add a device" on a device that already syncs shows a code, as a QR code or as text, for 10 minutes. The code holds your sync folder's address, your username there, the fingerprint of a certificate you trusted for it, and a one-time secret. It does not hold your passphrase or your server password. While the code is open, the server also holds one more encrypted file, which opens only with that secret; it is deleted when the code is used, withdrawn or expires. The new device still needs its own sign-in to the server. Anyone who has the code and can sign in to your sync server before it expires can read your synced data, so show it only to your own devices.
• Signing in. You can enter the server's address, a username and a password or app password, or sign in to Nextcloud in your browser, which then gives the app an app password. Use an https address: with http, which the app allows only for addresses on your own network, the password crosses your network unencrypted (your synced data is encrypted either way). Your device may offer to save the login or the passphrase in its password manager; that is your choice, and the password manager's policy applies.
• Turning it off. Turning sync off on a device deletes that device's file from the server and keeps everything on the device. Your data stays on the server while any other device still syncs. "Delete synced data everywhere" deletes the whole sync folder from the server. Sync runs only while the app is open (on iPhone and iPad, that includes the short time after you switch away described under "When you switch away on iPhone or iPad").
• The server's terms. The sync server is run by you or by a provider you choose, and its own terms and privacy policy apply.

Alerts

Alert rules are optional. There are two kinds.

• Checked by the app. A rule the app checks itself raises a notification on your device while that host's Metrics or Services screen is open. No push server is involved. On iPhone and iPad, an alert you mark urgent is delivered as Time Sensitive, so it can show during a Focus.
• Checked by your server. If you turn on server-side alerts for a server, the app installs, over SSH and SFTP and in the account it signs in as, a folder named .server-sidekick/alerts in that account's home folder. It holds a check script with your rules for that server, and a file only that account can read, holding the address of the destination you chose and any token for it. The app schedules the script with a cron entry or a systemd timer, every 5 minutes unless you choose another interval. Each run reads the server's own state (disk space, memory, load, services, containers, certificate expiry and, when it runs as root, disk health), and the script keeps its own history log in that folder. The top of the script says what it is and how to remove it by hand.
• Where alerts go. When a rule fires or clears, the server sends a message directly to the destination you chose: ntfy.sh, your own ntfy server, a webhook (such as Discord, Slack, Gotify or an Apprise API server), or a Healthchecks ping address. The message names the host and the rule and gives the reading. It does not pass through the app or through us. The service you choose, and the app that shows you its notifications (such as the ntfy app), have their own privacy policies. If you use ntfy.sh, its policy applies: it passes messages through Google Firebase Cloud Messaging to reach Android phones, and through Apple's push service to reach iPhones.
• Other connections your server makes. A certificate expiry rule makes the server connect to the address you entered to read its certificate. A "host unreachable" rule makes another of your servers check whether this one's SSH port answers.
• Back in the app. When you open a server's Alerts screen, the app reads that server's alert history and keeps a copy on your device. "Send test" runs on the server, not on your device.
• Sync and backups. Alert rules sync with your other items, and alert history does not. Alert destinations sync only where "Sync passwords and keys" is on. Alert destinations are included in the app's encrypted backups; rules and history are not.
• Removing them. Remove in the app's Alerts screen deletes the script, its folder and its schedule from the server. Deleting the app, or Delete all data, does not reach your servers: the script keeps running and sending until you remove it, in the app or by hand.

The AI assistant

The app has an optional assistant that can help you with a host. It is off until you set it up and turn it on in Settings, under AI Assistant. We do not provide an AI service: you enter the address of an OpenAI-compatible service you choose, a model and your own API key for that service. Before it is turned on, and before the first message of each conversation is sent, the app shows you what will be sent and where, and asks you to confirm.

• When it sends. Only from a host's Assistant screen: when you send a message or press Retry, and after you approve a command or file read the assistant proposed, so that it can continue with the result. The assistant cannot run anything itself: nothing it proposes runs on your server unless you approve it.
• What it sends. Your messages and the rest of the conversation; a short summary of the host (operating system and version, distribution, kernel, architecture, number of CPUs, package manager, init system, whether it is a physical or virtual machine, and whether the login can run elevated commands); command output you choose to attach, with the command that produced it and its exit status; whether you approved each command or file read it proposed; and the output of each one you approve. The summary leaves out the host's name and address and your username, but command output, files and your own messages can contain them.
• Secrets. Before anything is sent, the app takes out the passwords, SSH keys and passphrases of your saved credentials and of the current connection, saved BMC passwords and usernames (other than a factory default such as root), your API key, and any private key it finds. Apart from private keys it can only find exact copies, and it skips secrets shorter than four characters, so read what you attach before you send it.
• How it is sent. Over HTTPS, with your API key. Plain HTTP is allowed only to your own device, a .local name or a private network address, for a model you run yourself. That traffic, including the key, is then not encrypted.
• The service's terms. The service you choose receives what is sent, and its own terms and privacy policy apply to it, including whether it keeps your messages or uses them for training. We have no access to it.
• On your device. Conversations are not saved: one is kept in memory only while its Assistant screen is open. Commands and file reads you approve are recorded in the activity log, like other actions.
• Turning it off. Switch it off in the assistant's settings. Remove key deletes the API key, the service's address and the model from your device and turns the assistant off. With sync, it also deletes the key from your other devices where "Sync passwords and keys" is on, and clears the address and model on those where "Sync preferences" is on.

Purchases

On iPhone, iPad and Android the free version holds up to five hosts. Unlimited Hosts removes that limit with one purchase. It is not a subscription. Hosts you already have keep working whether or not you buy. On the Mac there is no limit and nothing to buy.

• The store handles the purchase. You buy through the App Store or Google Play, under Apple's or Google's terms and privacy policy. They take the payment and keep the purchase record. We never see your payment details or your store account, and the app has no account of its own.
• What the app learns. The app asks the store what Unlimited Hosts costs where you are, and whether your store account owns it. Restore Purchases asks the store again. The app keeps only the answer (yes or no, which store gave it and when) on your device, so the limit stays lifted when the store can't be reached. It sends that answer nowhere: it is not in backups, and sync does not carry it. No purchase service or server of ours is involved.
• What we receive from the stores. Apple and Google give us sales, refund and tax reports, and Google Play shows us each order. We use these only for accounting, tax, refunds and support.

What you can choose to send

The app only sends something out when you ask it to:

• Backups. You can export your hosts, groups, credentials (including SSH keys), saved port forwards, snippets and alert destinations to an encrypted file protected by a passphrase you choose. The passphrase never leaves your device, and we cannot recover a backup if you lose it. You decide where the file goes. If you save it to iCloud Drive, Google Drive or similar, that service's policy applies to it. A backup includes a host's BMC address and trusted certificate, but not its BMC login, and it does not include alert rules or history, runbooks, the assistant's settings or key, sync's settings, certificates you trusted for web pages or the purchase.
• Sharing hosts. You can share hosts with another device as a QR code or a file. A shared host contains its name, address, port, username, jump host and MAC address, never a password or key. The file is not encrypted, so send it only where you'd be happy for those details to be read.
• Sending credentials. You can put the credentials you select into a file encrypted with a passphrase you choose, and hand it to your device's share sheet. It goes wherever you choose there. The Share button in Settings shares only a link to the app.
• Files. When you upload a file to a server, the app reads only the files you pick with the system file picker or photo library.
• Diagnostics. Settings shows the diagnostics log. Nothing in it is sent automatically. Copy, Share and Email support move a copy only where you choose, and you can read the whole log before you send it.
• Contacting support. "Email support" opens a message to support@serversidekick.app in your own mail app. If you send it, we receive your email address and whatever you write or attach, and we use it to answer you and to improve the app.

Permissions the app asks for

The app does not ask for your location, contacts, microphone or advertising ID, and it does not use or store device identifiers. To name your device in sync's device list it uses only the device's model, never the name you gave the device, and it discards the other device details the system returns with the model. (Google's scanner on Android, above, uses its own per-installation identifier.)

Our website

The website is hosted on GitLab Pages. It sets no cookies, and it runs no analytics, advertising or third-party scripts: every file it loads comes from the website itself. GitLab processes technical information such as your IP address and browser type to deliver and secure the site, under GitLab's privacy statement. If you pick a light or dark theme on the website, your browser remembers the choice locally; it is never sent to us.

Keeping and deleting your data

The app keeps what it stores until you delete it. You can delete hosts, credentials and other items one by one, or everything at once:

• Delete all data (Settings) removes everything the app keeps on the device, including what it saved in your device's secure storage, and starts the app again as if it had just been installed. It changes nothing on your servers, and it does not delete a synced copy on your sync server: use "Delete synced data everywhere" in Settings → Sync first if you want that gone too. It also leaves alert scripts on your servers running: remove them in Alerts first. It does not clear the cookies, cache and other site data that pages you opened in the app's web view left on the device. On the Mac it empties the app's data files in your Documents folder, and leaves your Local Files folder and your own ~/.ssh files alone.
• Deleting the app deletes its data on iPhone, iPad and Android, apart from your device's backups above. On Apple devices the Keychain can keep an app's items after the app is deleted, so use Delete all data first to be sure they are gone. On the Mac, the data files stay in your Documents folder, and the web view's site data in your Library folder, until you delete them.
• Copies you made (backup files, shared files, synced copies, alert scripts on your servers, emails to support) are not reached by either; delete them where you put them.

We cannot recover any of it for you, because we never had it.

Your rights

Because the app sends us nothing, there is normally no data of yours for us to access, correct, delete or hand back. The exceptions are the emails you send to support and the sales records the stores give us.

For those, you can ask us to tell you what we hold, correct it, delete it, restrict how we use it or give you a copy in a common format. This applies wherever you live, including if you are in the European Economic Area, the United Kingdom or California. We answer within 30 days, and we may ask you to confirm who you are first. We keep store sales records for seven years, which covers US tax record-keeping, and support emails for two years after the conversation ends, unless you ask us to delete them sooner. You can also complain to your local data protection authority. We do not sell or share personal information as those terms are defined in California law.

Where the law requires a legal basis for the little we hold, it is our legitimate interest in answering your emails and running the app you used, or your consent, or a legal obligation.

Where data is processed

We are based in the United States. Any personal data we hold, such as support emails and store sales records, is processed there and by the providers named above. Support email is handled through GitLab's Service Desk.

Security

Your data stays on your device, protected by the platform's own security and the app's encryption, apart from the copies described above. No method of storage or transmission is perfectly secure, and we cannot guarantee it. To report a security problem, see Support.

Children

The app is not directed at anyone under 18, and we do not knowingly collect personal information from children. If you believe a child has sent us personal information, contact us and we will delete it.

Changes to this policy

We will post any change on this page and update the date at the top. Changes take effect when posted.

Contact

SERVER SIDEKICK LLC
support@serversidekick.app