Sprecho ships as ordinary signed installers, so it deploys through whatever you already use — Microsoft Intune, Jamf, Group Policy, Munki, Ansible or a link in an email. There is no Sprecho-side MDM connector to configure, and none is needed.
The one thing to plan for is that device enrolment happens at sign-in, not at install time. That shapes the rollout.
Where to get the installers
Open the Enterprise console at enterprise.sprecho.ai and go to Downloads. The page is visible to team owners and admins and offers:
| Platform | Package | Notes |
|---|---|---|
| Windows | .msi |
Labelled "MSI (for IT deployment)". This is the one to push |
| Windows | .exe |
The consumer installer from the public download page |
| macOS | .dmg |
Separate Apple Silicon and Intel builds, signed with a Developer ID certificate |
| Linux | .deb |
For Debian and Ubuntu fleets |
The MSI is a standard Windows Installer package, so it behaves like any other MSI in your tooling — package it as a Win32 or line-of-business app in Intune, or as a policy in Group Policy, and use your usual silent-install options.
macOS ships as a DMG, not a PKG. Jamf can deploy a DMG-delivered app, but if your workflow assumes a PKG you will need to repackage. Tell us if that is a blocker for your rollout — write to support@sprecho.ai.
Terminal Server and multi-session Windows environments have their own agent MSI on the same page. See use Sprecho over remote desktop and terminal server.
How a device joins your team
- Your management tool installs Sprecho. Nothing is configured at this point, and the app does not contact your team.
- The person launches Sprecho and signs in — ideally through SSO, so there is no password to distribute.
- The app enrols itself into the team the account belongs to. From that moment it receives your device policy and appears in the console's device list.
That is the entire flow. There is no configuration profile, no .mobileconfig
and no per-device enrolment token to place on the machine beforehand — the
account is what carries the team identity.
The practical consequence is that a device you have imaged but nobody has signed in on yet will not appear in the console. Do the SSO configuration before the mass install, so the first launch already has somewhere to sign in to.
Controlling updates centrally
Managed fleets usually want update control, and the device policy provides it:
- Automatic updates off — the in-app updater is skipped entirely. Devices then only move version when you push a new package, which is exactly what a change-controlled environment needs.
- Update channel — stable, beta, or a specific pinned version.
- Forced update grace period — how long someone may keep working after a forced update is requested, 24 hours by default.
These sit alongside the rest of the policy — allowed languages, allowed hours, what may be locked — in manage enrolled devices.
A rollout that goes smoothly
- Buy enough seats first. A member without an available licence cannot sign in through SSO at all.
- Configure and test SSO, including domain verification, before the install wave.
- Set the device policy you want, so the first heartbeat already applies it rather than changing behaviour on people a week later.
- Push the package to a pilot group of five to ten people and watch them appear in the console.
- Roll out to the rest, and use the device list to spot machines where nobody ever signed in.
On macOS, remind people that the app needs the microphone and accessibility permissions on first launch. Those are per-user macOS prompts and cannot be answered by an installer. See grant microphone and accessibility permissions.