Reverting from Indigo v2 to v1

We hope you won’t need this page — but if Indigo v2 hasn’t worked out on your Mac, you’re not stuck with it. Indigo v2 plans for this from the moment it first runs.

How the escape hatch works#

The first time Indigo v2 launches on a Mac that ran v1, it takes a snapshot of your v1 configuration and state before upgrading anything — your ~/.indigo configuration files, Indigo’s Application Support folder, and each of your stacks’ .indigostack configuration files. The snapshot lives in a dated folder in your home directory (for example ~/.indigo.v1-snapshot-2026-08-19), and it’s small: your service data — databases and the like — isn’t part of it, because reverting never touches your data.

Bundled inside Indigo v2 is a script that restores that snapshot and gets you back to a working v1.

What reverting does — and doesn’t do — honestly#

It restores Indigo to the moment before v2 first launched. Your stacks’ configuration files, Indigo’s settings and its state files all go back to how they were. Anything you changed inside v2 after that — stacks added or reconfigured, preferences, licence sign-ins — is lost from Indigo’s configuration. v2’s copy of each stack’s configuration is kept beside the restored one, as config.json.v2, in case you want to refer to it.

Your databases stay on disk. The revert never touches a service’s data directory. MySQL 8 and MySQL 5.7 databases open again in v1 just as they were. One exception: MySQL 9. v2 ships a newer MySQL 9 than v1 did, and MySQL upgrades its data files in place the first time the newer version starts — the older version can’t read them afterwards. If you have MySQL 9 databases you care about, export them from v2 before you revert, and import them once v1 is running. The revert script lists every database that has been started under v2, so you’ll know which ones to think about.

Services v1 doesn’t have. Indigo v1 has no MariaDB or PostgreSQL. If you added either in v2 — including a MySQL 5.7 → MariaDB migration — that data stays on disk, but v1 can’t open it and the service won’t appear in the stack. Export anything you need from v2 first.

Redis and Mailpit start empty. Both keep their files inside the service’s compiled folder, which the revert rebuilds — the same thing that happens on any rebuild.

Compiled services are rebuilt. The revert resets each stack’s compiled service directories, so v1 rebuilds its services from its own copies the first time each stack starts — the same thing it does for any new stack. Expect the first start of each stack to take a little longer.

Reverting#

1. Open Terminal and run the script from inside the Indigo v2 app bundle:

   bash "/Applications/Indigo.app/Contents/Resources/revert-to-v1.sh"

2. Read what it tells you — it explains exactly what will happen, and nothing changes until you type revert to confirm. It will ask for your admin password once, to remove v2’s privileged helper tool so v1 can install its own.

3. When it finishes, delete Indigo v2 from your Applications folder.

4. Download Indigo v1 (the latest v1 release, 1.2.5):

   https://downloads.indigostack.app/file/indigo-downloads/Indigo.zip

5. Unzip it, move Indigo.app into Applications, and open it. v1 will offer to install its helper tool, and each stack rebuilds its services on first start.

softwareupdate --install-rosetta --agree-to-license

The snapshot folder is kept after a revert, so running the script again is safe. Once v1 is happily running, you can delete the snapshot — or keep it; it’s small.

If something’s not right#

• “No v1 state snapshot found” — either this Mac never ran v1 before v2 (there’s nothing to revert to), or v2 first ran here before it learnt to take snapshots. The script won’t guess; contact us at and we’ll work out the best path back.
• The script found more than one snapshot, or an unfinished one — it stops rather than restoring the wrong thing. Get in touch and we’ll sort it out.
• Anything else — contact us at . Reverting is something we test, and we’d rather help you through it than have you stuck.