What ADI knows about you.

From the software used free of charge, little, and most of that is a property of how it is built rather than a promise about how it is run. Free use needs no account, so there is no profile to hold. Your machines are yours, the data on them never travels through us, and the app on your phone talks to them directly. What we do receive from free use comes from two places, both described below: a fixed list of usage events that the desktop app sends unless you switch them off, and page views and a few clicks on this website. Both go to a collector we run ourselves.

Buying an Enterprise licence, or selling ADI as one of our partners, is different: a named business is involved, and we hold what that takes. That has its own section, Customers, partners and the partner portal.

This page covers ADI, which runs on your own machines, and adi Fleet, the iPhone and iPad app that reaches them, and then this website, and last Enterprise licences and the partner portal. It says what each one stores, what leaves the device, and what our own infrastructure can see. Where something is checkable, the way to check it is written down.

Free use has no account

When you use ADI and adi Fleet free of charge, nothing asks for a name, an email address or a password. There is no sign-up, no login, no profile and no server of ours holding your data, because free use involves no server of ours at all — ADI runs on your machine and adi Fleet runs on your phone. We do not know who our free users are. We can count the installs that send usage events, and we know each of those only by a random install id.

This holds for free use only. An Enterprise licence is issued to a named business, and the partner portal has accounts with names, email addresses and passwords; both are described under Customers, partners and the partner portal.

What adi Fleet keeps on your phone

All of it stays on the device. None of it is sent to us, because there is nowhere to send it.

• An identity. The app generates an Ed25519 keypair on the device the first time it runs. It is stored in the iOS Keychain, marked this device only, so it does not sync to iCloud and does not follow your Apple Account onto another device. It is the only name your machines know you by.
• The list of machines you have paired and whatever you have chosen to call them. A local file in the app's own container.
• One password per machine, in the Keychain, minted during pairing. The machine keeps only a salted verifier of it, so neither side stores a password anybody could read back.

Deleting the app deletes all three. There is nothing to ask us to erase, because we never had a copy.

The two permissions the app asks for

Camera, and only to read a pairing code. A pairing token is over nine hundred characters, so a machine draws it as a QR and the phone reads it. The system decoder hands the app the text of the code and nothing else — no photograph is taken, stored, or transmitted, and the camera is switched off the moment the scanner closes. If you refuse the permission, the app falls back to a field you can paste the token into and everything still works.

Local network, so the app can find a machine on the same Wi-Fi and connect to it directly instead of going the long way round. Refusing it costs you speed, not function.

What our relays can and cannot see

Two machines usually reach each other directly. When a network will not allow that — a strict firewall on one side, mobile data on the other — the connection falls back to a relay we run, and that is the one part of this where our infrastructure is in the path at all.

A relay cannot read what it carries. The connection is encrypted end to end between the two devices, which authenticate each other by key; the relay forwards ciphertext between two parties it cannot impersonate and cannot decrypt. Whatever a dashboard of yours shows, a relay of ours sees as noise.

What a relay unavoidably handles is the network address a connection arrives from, for as long as the connection lasts. It does not write that down. Our relays run with no access log: nothing records that a particular address connected, when, or to whom. The only thing they write is failures — a rejected TLS handshake, a malformed request — which exist to tell us a relay is broken, are bounded in size rather than kept deliberately, and describe connections that never got started.

The update check

ADI checks for updates. It asks GitHub for the release manifest at github.com/adi-family/mono/releases, which means GitHub — not us — sees a request from your address, exactly as if you had opened that page in a browser. It carries no identifier, nothing about your machine, and no account. Turn it off with adi-mono update disable.

Usage events

Starting with the version after 1.30.0, the desktop app also sends a fixed list of usage events. They are on unless you switch them off. They go to relay.withadi.dev, the collector this website uses too (see below), which we run ourselves and which refuses any event or field that is not on its list.

Every event carries the ADI version, your operating system and its architecture, and an install id: a random id the app creates on your machine and keeps in ~/.adi/mono/analytics. It is not derived from your hardware or from anything about you. Beyond those, each event carries only the fields named here.

• app_first_launch — the first time the app starts with usage events on. fresh: whether this is a new install or an existing one being upgraded.
• onboarding_completed — the first time you save your main agent during setup. backend: which agent backend you chose.
• agent_run_started — an agent run starts, in your first seven days only. launched_by: you, an agent or an automation; backend.
• agent_run_finished — that run ends, in your first seven days only. is_error: whether it ended in an error; terminal_reason: a short code for how it ended, such as completed; launched_by.
• app_daily_active — once for each day the app runs. runs_human, runs_agent, runs_automation: how many runs started that day, counted by who started them.
• dashboard_created — you create or import a dashboard. from: blank or import.
• store_item_installed — you install something from the Store. kind: agent, tool, dashboard or service; slug: its name in the public Store, sent only for public Store items.
• fleet_invite_created — you create a fleet invite. Nothing else.

No event contains your prompts, the text of a task, what a run produced, your files or their paths, your secrets, or what a run cost.

The collector is ours, run on Amazon Web Services in Frankfurt (eu-central-1), and With ADI, Inc. is responsible for what it holds (see below). It sees your IP address with each request, as any server does, and uses it only to limit request rates, in memory.

Switch usage events off in Settings → Usage events, with adi-mono analytics disable, or by setting DO_NOT_TRACK=1 in the environment. Off, the app sends none, not even one saying it was switched off. adi-mono analytics forget deletes the install id from your machine. On free use, with the update check and usage events both off, the software makes no outbound request of its own. An Enterprise installation also checks its licence with us, as described below.

The app's Getting started link opens this website's welcome page with the install id in the address. If you have accepted this site's cookie in that browser, the page links your visits to that install. If you have not, or you declined, it sends nothing that carries the id.

This website

Everything above is about the software. This section is about withadi.dev, the site you are reading, and nothing in it changes what ADI or adi Fleet send.

This site records page views and two kinds of click: the download links, and the links that open an email to sales@withadi.dev. They are sent to relay.withadi.dev, a collector we run ourselves, whose source is public at github.com/adi-family/analytics. It refuses any event or field that is not on its list. Despite the name, it is not one of the relays above: those carry connections between your devices, and this one only receives what this site sends it.

For a page view it keeps the page's path, the domain of the site that sent you, and any campaign tag in the link. For a click it keeps which download or which email link it was, and the page it was on. With each it keeps the browser family, the operating system family and the device type, without version numbers, and the time. It does not keep your IP address: it sees it, as any server does, and uses it only to limit request rates, in memory. It does not keep the full address of the page you came from, anything you type, or a location. There is no autocapture, no session recording and no heatmap, and the site sends none of this to anyone else.

Until you choose, nothing is stored on your device and no identifier is sent, so your page views cannot be linked to each other. If you choose Decline, the only thing stored is that answer, and still no identifier is sent. If you choose Accept, the site sets a first-party cookie, adi_id, holding a random id for one year, so that your visits can be linked to each other. Safari removes it after seven days. Your answer is kept in your browser's local storage, under adi.consent, so the banner does not ask again. If you have accepted and then open the Getting started link from the ADI app, a second cookie, adi_link, holds that install's id for one year, and your visits are linked to that install. Decline deletes both cookies. If your browser sends Global Privacy Control or Do Not Track, the site sends nothing at all, and does not ask.

Change your answer

The collector runs on Amazon Web Services, which hosts it for us, in its Frankfurt region (eu-central-1). The raw events are kept there for 395 days. We read them in our own ADI, which copies them from there.

The site is served by Cloudflare, which handles the request in order to deliver the page and keeps its own operational logs as any host does. There is no form to submit and no newsletter. You can check what a page loads rather than take it on trust: your browser's network panel shows the page's own files from withadi.dev, relay.withadi.dev/web.js, and the requests to relay.withadi.dev. The Store's pages also ask app.adi, a name that reaches only your own machine and only if ADI runs on it, whether to show Install.

Customers, partners and the partner portal

Everything above is about ADI and adi Fleet used free of charge, and about this website. An Enterprise licence, and selling ADI as one of our partners, involve a named business, and this section says what we hold for each.

Enterprise licences

We issue each Enterprise licence to a named customer business, and keep the licence's code, the company's name, the licence's status and its dates.

An Enterprise installation checks its licence with our licence service at licence.withadi.dev when it starts and then every six hours. Each check carries the licence code; a deployment id, a random id the installation creates once and keeps in its own state store, not derived from your hardware; a one-time random value and the time it was sent; and the installation's ADI version, operating system, architecture, and how many machines and users it has. That is the whole request. It carries no names, no email addresses, and nothing your users do in ADI.

For each deployment, the service keeps when it was first and last seen and the latest version, operating system, architecture and counts it reported. It also keeps a record of every check: when it arrived, the licence code and deployment id, the answer it got, the version, and the IP address it came from. The licence service runs on Cloudflare, which hosts it for us. You can check what is sent rather than take it on trust: the check is one HTTPS request from your installation to licence.withadi.dev, and a proxy or firewall log on your side shows it.

The partner portal

Our partners sell ADI through the partner portal at partners.withadi.dev. For each person a partner adds, the portal holds their name, their email address and a hash of their password, made with argon2id; it does not keep the password itself. Signing in sets one cookie, a session cookie that is strictly necessary for the portal to work. It is HttpOnly, so the page's scripts cannot read it, and it lasts 30 days.

The portal also holds each partner's business country, and the payment links its people create, with the customer's company name and email address, the number of instances, and any note the partner adds. Where the portal asks a partner to confirm a statement, it keeps who confirmed it and when.

We host the portal ourselves on Amazon Web Services in Frankfurt (eu-central-1). Its database is backed up every night, the backups are encrypted, and each one is deleted after 30 days.

Stripe

When a partner connects its Stripe account, Stripe runs its own onboarding and identity checks. We receive the account's id and its status, not the documents the partner gives Stripe.

A customer buying through a partner pays on Stripe Checkout, on the partner's own Stripe account, and enters card details on Stripe's page, not ours. We receive the payment and subscription ids, the amounts, the status and the customer's email address.

Stripe is an independent controller of what it processes for its own purposes. Its privacy policy is at stripe.com/privacy.

Why we hold this

To perform our contract with the customer or the partner: issuing and checking licences, running the portal, and processing payments. To meet our legal, tax and accounting obligations. And for our legitimate interests in keeping the service secure and preventing fraud.

How long we keep it

A customer's or a partner's account data is kept while the relationship lasts, and after it ends for as long as we need it for legal, tax and accounting records. The portal's backups are deleted after 30 days, as above.

Your rights

Depending on where you are, you may have the right to see the data we hold about you, to correct it, to have it deleted, to restrict or object to how we use it, and to receive it in a portable form. To use any of them, write to info@withadi.dev. You can also complain to a data protection supervisory authority, such as the one where you live or work.

Who else is involved

• Amazon Web Services hosts the partner portal and our event collector, in Frankfurt.
• Cloudflare delivers this website and runs its DNS, and hosts the licence service.
• Stripe processes payments, as described above.
• GitHub serves the release manifest the update check reads.

Where the data is

With ADI, Inc. is a company in the United States. The partner portal and our event collector are hosted in the European Union, in Frankfurt. The service providers above may process data in other countries, including the United States, under their own terms.

What we never do

We do not sell your data, share it with advertisers, or hand it to data brokers. There is no advertising SDK, no analytics SDK, and no third-party SDK of any kind in adi Fleet. None of this is a policy we could quietly change on a server, because the collection would have to be built first, shipped in an update, and declared to Apple before the App Store would take it.

The desktop app's usage events and this website's page views and clicks go only to our own collector. The desktop app carries no third-party analytics or advertising SDK, and the site no third-party analytics or advertising script.

Children

ADI is a tool for administering computers you own, and it is not directed at children. We do not knowingly collect anything from children. The usage events and what this website records are tied to random ids, not to a name.

Who is responsible

With ADI, Inc., a Delaware corporation, is responsible for the data described on this page. In the language of data protection law, it is the data controller. You can reach it at security@withadi.dev.

Changes, and asking us something

If any of this stops being true, this page changes before the thing that made it untrue ships. There is no mailing list to announce that on, so the page carries its own date.

Questions, or a correction to something above, to security@withadi.dev. It is the same mailbox as the security page and it reaches the person who wrote the code.

To see or delete what this website recorded about you, write to the same address with the value of the adi_id cookie in your browser, and we will find what is tied to it and delete it on request. Without that id, if you never accepted the cookie, your page views carry nothing we could find you by. About the usage events from an install, write with its install id, which adi-mono analytics id prints and Settings → Usage events shows. About adi Fleet, the honest answer is that we hold nothing to give you. About an Enterprise licence or the partner portal, write to info@withadi.dev, as Your rights says.

Last updated 24 October 2026.