JeffMarmalade

Thanks for giving me the chance to hide under the marketing rock :) But you're right and I will have a good think about what I'm implying by describing it as isolated. "Isolated" means things to me in this context, but it legitimately implies other stuff as raised in this thread, which Indigo does not attempt to do. I don't want to mislead anyone, marketing jargon or not.

Interesting! I hope Indigo may be really helpful for you. If I'm understanding your use-case correctly, you could create a stack with both MySQL versions, and another stack containing a site per PHP version, all pointing at the same codebase in your filesystem, but each configured to use a different PHP. Then you can run them all simultaneously if you want, with each in their own browser window eg project-72.test, project-73.test, project-74.test, project-80.test etc (one per PHP).

Nooo not a crash! Thanks for the heads-up. I wonder if it's when there are no stacks other than the system; I'll have a play in my VM. It would be great to follow this up in the forums, so thanks for trying and sorry it's caused you troubles! You don't happen to use Hotmail perchance? I've seen some issues with their blocklists. Anyway, feel free to contact me directly at hello at indigostack.app and I will do my best to get things sorted for you.

Yes absolutely. I'd suggest creating a "Shared services" stack, and put a MySQL service in that rack. Give it a static port (eg 3306).

Then create a second stack with Nginx or Apache (or both), and your choice of PHPs, as many as you need. All the sites will have access to MySQL from the first stack, on the port you configured (eg 3306).

Alternatively, do the "shared services" stack then add one stack per project. Just depends how you like to organise it.

lol sorry about that. It's kinda hard finding the right line in the website promo text between technical detail and something friendly enough to catch visitors' attention.

The premise of running Docker for Mac or other VMs as a development environment is usually so you can run the exact same set of services in development as you run in production. Isolated meaning you can delete the stack, rebuild it, start it up on another machine without any fear of it being affected by macOS updates. With D4M or VMs this is at the expense of not running it directly on your Mac natively, but rather inside the VM.

So to answer your question ("What's it actually do?"), it runs the same services as you might run in docker, with similar upsides (separated from the OS, rebuildable, shareable etc) but without the downsides.

Many developers have experienced first-hand the hassles involved in running D4M or a VM for development. However, those solutions really seem to work for some, so if that's you, Indigo is probably not of interest :)

Anyhow, thanks for the feedback, and if you can suggest anything I could/should say on the site specifically, please do!

Ah, "Undo"... good thinking, it's the Mac way :) I'll put it on my list.

My personal experience is that while it's an enticing concept — the idea that local development using Docker will reflect production issues — it just doesn't pan out. I quickly realised that trying to accurately replicate my production environments locally was not going to be a happening thing, and ended up migrating my development stack to docker-based environments such as https://lando.dev and https://laradock.io which make no pretence of being a reflection of production.

Further, if you have an m1 Mac your Docker environment will be running ARM versions of linux which almost certainly is not what you are running in production, so it starts becoming pretty clear that Docker on Mac is !== Docker in Production.

However, I do agree, there are issues you might find in production that you won't find when running your app in Indigo. I would argue that's what staging is for. Just create a literal clone of your production docker stack either on your Mac or a spare Pi and run your tests there before pushing to production.

I think there's a growing realisation that Docker is harming developer productivity. It certainly was for me.

Re file system issues, you're absolutely right; this colossal thread <https://github.com/docker/roadmap/issues/7> was in fact a motivating factor for me; the underlying file system issues seem pretty insurmountable. Fundamentally, Docker on Linux is awesome, and Docker on Mac (and Windows) just isn't, purely for this one reason.