Deploying Tiune in an organisation
What to allowlist, which permissions to expect, how it behaves offline, and what is not ready yet.
Written for whoever has to put Tiune on other people's machines. It says what is true today, including the parts that are awkward — an admin who finds those out during a rollout has a worse day than one who read about them here.
What you are actually deploying
| Platform | What it is | State |
|---|---|---|
| macOS 12+ | A signed, notarised app. Installs by drag-and-drop from a DMG. | Ready |
| Windows 10+ | An app with an Inno installer that upgrades in place. | Not code-signed yet — see below |
| Android 9+ | A keyboard with a dictation key, not a normal app. | Coming to Google Play; not listed yet |
Windows is not code-signed. SmartScreen will warn on first run, and that warning does not go away by itself — unsigned reputation resets with every release. If your fleet blocks unsigned executables, Tiune will not install on it today. This is the honest state of things and the reason we say "macOS today" when someone asks what to standardise on.
Network
Tiune does not need the network to dictate. On the free plan there is no network path in the dictation pipeline at all, and on paid plans a lost connection falls back to on-device transcription rather than failing. What the network is for is signing in, the cloud features, and updates.
| Host | What it carries | If you block it |
|---|---|---|
api.tiune.app | Sign-in checks, entitlements, cloud transcription (dictation and meeting notes), AI cleanup and meeting summaries, vocabulary and transformation sync | Paid features stop; local dictation continues |
tiune.app | The admin console at tiune.app/admin, for whoever manages seats | Admins can't manage the team; nobody's dictation is affected |
<project>.supabase.co | The sign-in exchange itself, in the system browser | Nobody can sign in, so nobody can dictate |
github.com and its release CDN | The updater feed and the download it fetches | The app never updates; nothing else breaks |
huggingface.co | Downloading an optional extra speech engine | The bundled engine still works offline |
us.i.posthog.com | Product analytics | Nothing breaks. See Privacy for what is sent and when |
Sign-in opens the user's system browser, not a window inside the app, so whatever proxy or SSO your browser goes through is the one that has to work.
A blocked host looks like a billing problem, not a network one
This is the trap worth knowing before you file a bug with us.
If a proxy answers a blocked request with 401 or 403 rather than dropping it, Tiune reads that as an answer from our servers rather than as interference. A 403 becomes "not included in your plan" and a 401 can end the session — so the symptom an admin gets told about is "it says I need to upgrade" or "it keeps signing me out", from a machine whose plan is perfectly fine.
If you see either symptom on a managed network and nowhere else, check the proxy before checking the subscription. Closing this gap properly — telling a proxy's denial apart from ours — is open work on our side, not a configuration you can fix on yours.
Permissions
On macOS Tiune asks for two, and it cannot work without them:
- Accessibility, which is how it types into the app you are using. Without it Tiune can hear you but has nowhere to put the words.
- Microphone, which is how it hears you.
Both are per-user TCC grants. There is currently no configuration profile or MDM payload from us that pre-grants them, so each user answers both prompts once on their own machine.
Meeting notes (Pro, macOS 14.4 or later) adds a third, System Audio Recording, asked the first time someone accepts an offer to take notes. It is audio only — not Screen Recording. Anyone who never takes meeting notes never sees it.
On Windows neither prompt exists; typing and audio need no special grant.
Working offline, and on disconnected machines
One sign-in is enough. After that, everything that runs on the machine keeps running indefinitely without a connection — dictation, the on-device engines, punctuation, vocabulary. A machine that is offline for a month does not get locked out of the free-plan behaviour it already had.
What stops offline is what needs a server by definition: cloud transcription, the AI cleanup pass, and sync. Those resume when the connection does.
What is not ready yet
Stated plainly, because a rollout plan built on any of these would be built on nothing:
- No per-machine installer. macOS is drag-and-drop per user; there is no
.pkgthat installs for every account on a machine. - No MDM profile for pre-granting macOS permissions.
- A small admin console. tiune.app/admin handles seats, members, invitations and 30-day usage counts. It cannot push settings to people's apps. See Teams & Enterprise.
- No Windows code signing, as above.
- No SAML or SCIM, and no joining by email domain. Sign-in is Google, Apple or Microsoft on a computer, and Google on Android. If your identity provider is Entra or Google Workspace you are already covered; anything else is a conversation.
- No managed settings. Nothing pushes a setting to everyone's app yet; each person sets their own.
- No SLA, SOC 2 or HIPAA commitments.
Data
What leaves a machine, on which plan, and who processes it is set out in full on the Privacy page rather than summarised here, so there is one description of it rather than two that can drift apart.
The short version for a security review: on the free plan nothing about a dictation is transmitted; on Plus the transcribed text and up to 256 characters of what was already in the field are sent for cleanup; on Pro the audio is sent for transcription. Each person can stop the field context and app category being sent with Send where you're writing in Settings → Privacy. Meeting notes, on Pro, sends meeting audio to Deepgram in an online transcription mode and the transcript text for its summary in every mode. An administrator on a Teams or Enterprise plan sees seat membership and usage counts, never content.
Who to talk to
Email support@tiune.app and say it is a deployment question — that reaches a person, not a queue, and deployment questions are answered by someone who can change the software rather than only describe it.
For a rollout of any size, say so before you start rather than after: how many seats, which platforms, and what your network does to unknown hosts. The proxy behaviour above is the single most common reason a pilot looks broken.