Show HN: IndigoStack – a new native macOS app for local web development | Hacker News Reader

Show HN: IndigoStack – a new native macOS app for local web development

indigostack.app

187 pointsJeffMarmalade69 comments

Hi HN,

I'm opening up the beta for IndigoStack. It's a native macOS app which provides a fresh take on how to run all the services you need for local web development. I've been building it for myself as a Laravel & Drupal developer and I'm now looking to get some beta testers on board!

Check it out, and don't forget to sign up to the forums to give us your feedback!

https://indigostack.app

My motivation:

Like many developers I've developed a love-hate relationship with the existing options for local development on a Mac. If they're virtualised, you'll often get...

* high CPU usage * high RAM usage * poor filesystem performance / syncing * command line and configuration complexity

And existing native solutions tend to be either too simplistic, or command line-based or both.

So I've built IndigoStack with everything I liked and wanted, running everything natively on your Mac:

* services are all native & fast * services are standalone; macOS updates won't ruin your setup * able to run multiple services (eg PHPs) simultaneously * easily build / start / stop / rebuild your stacks in the GUI * run multiple projects which don't interfere with each other * config-in-code; quickly and easily share stacks within a team

Open articleView on HN

Anyone who thinks that Docker isn't a problem is obviously on Linux and not on a Mac. While I agree with the concept of Docker being fantastic, the practical reality is that it's painfully slow on MacOS even with the new virtiofs. I have been beta testing Indigo for the past week with Drupal sites and I can confidently say this is an order of magnitude faster at everything but especially things that you do repetitively all day, every day: clearing cache, config import, `drush uli`. There's no syncing issues to deal with so you're never left wondering if you saved some incorrect css or if it just hasn't synced into the container yet. I'm still yet to come across a configuration I couldn't replicate based on a fair number of Pantheon, Platform.sh and Acquia hosted sites.

I like making websites, I don't like tinkering with servers.

~Have you tried the recent update?~

Edit, missed the line mentioned in the child comment.

https://www.docker.com/blog/speed-boost-achievement-unlocked...

> it's painfully slow on MacOS even with the new virtiofs

They said it here

The little mini rack design is so cute!!! This type of playfulness is what I loved about the Mac experience 15 years ago.

I love the art here! Could OP point to where they get them / what the style is called?!

skuemorphism

> Could OP point to where they get them

Their partner made them: https://news.ycombinator.com/item?id=31488625

Absolutely agree. Sometimes I miss the skeuomorphism of the old days, even if I do spend most of my time in the terminal.

What's it actually do? "Run all the same services as your production stack, isolated but directly on your Mac. No Docker, no virtual machines, no hassles" is vague AF.

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!

I think we get that, the question is how do you isolate everything without a VM or docker?

via docker and a VM.

It doesn't use docker or a VM

"isolation" most likely done by the automagick configuration using different ports...

Different Ports != Isolation..

But hey, marketing.

Interesting that you assumed it's just using different ports, and then judged the author based on your assumption.

There are other ways to achieve process isolation in a Unix environment without relying on Docker or virtualization.

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.

Exactly. From the web page it seems that "isolation" here is basically just installing separate copies of services/libs (php, nginx, etc) under an IndigoStack controlled folder and then running them on a port not already taken by another service. One of the benefits of Docker is explicitly that it does a change root and thus provides an isolated file system in which to run your code. It also creates separate network interfaces for the process to isolate it from your host network.

This has a number of benefits including protecting sensitive files/info in your home folder from rogue dependencies and allowing you to easily toss the dev environment into a black hole once it's no longer needed. If IndigoStack somehow implements isolation using chroot or other MacOS/Darwin equivalents it should be explained on the web page. Otherwise I think the marketing text is misleading:

> Bare metal. With the best of virtualized.

Edit:

I do like the idea of something like IndigoStack though. Being able to describe a dev environment programatically/declaratively and then having something take care of setting that up is nice. If you're a pure MacOS shop then something platform specific like this is probably an okay solution.

Why would you run Docker in a development environment? I know that people do this, but I just can't fathom why. Docker images should be built using a build server and deployed to staging and production. If you have a sane development environment - whether it's a virtualenv in Python or maven based in Java, it's pretty predictable.

I run databases however in Docker on my Mac.

The idea is to have the same build pipeline that works locally or in prod. In the end it keeps being an holy grail because dev requirements usually differ from prod requirements (i.e. code hot-reload as fast as possible with interpreted languages in dev vs slimmest possible image in prod).

You can just have multiple stages in the same Dockerfile, one for dev and another for prod, and have your docker compose yml file target the dev one.

Yes, I did exactly this at $DAYJOB, the holy grail for me would be to have the exact same build process without any "if $environment". But anyway I agree it is good enough.

Because as a developer you can simply run `docker-compose up` and have your development environment working immediately without having to ensure you have all the necessary dependencies installed locally.

And even if you think setting up a "sane development environment" is simple, it gets much more complicated as you add additional languages and versions of those languages, and their underlying frameworks, etc. For example if you look at NodeJS alone: we have things like nvm to switch between Node release versions because you'll often have different projects relying on different versions of Node. Or you could just use Docker and it's baked in, basically.

Just because you have a particular workflow doesn't mean other people don't have a different one.

What if someone's dev environment requires a running Redis server, PostgreSQL, and MinIO? And what if you need to keep those instances free of cruft from other projects? Hey, you know what works for that? Docker!

Or what if you need to mock several AWS services locally, because you don't want to be paying for actual AWS or polluting other environments while working on something? Hey, you know what works for that? Docker!

It's easy

So it's just fork-execing services that are compiled natively for Mac? In what way is that "isolated" or "the same as production"?

The attention to detail in this app is impressive, especially for a beta app. Keep up the good work!

My $0.02 suggestion after 5 minutes with the app: Instead of a dialog asking "Are you sure you want to delete this?", how about an "Undo delete" instead? Just a thought.

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

This is amazing and something I’ve been dreaming of for a long time.

I kept nodding to myself and saying “OMG, yes!” in my head to every topic in your site. You hit the nail in the head and I hope you add Node, Rails, Python, etc someday.

However, my perception is that this won’t be open source, right? If so, I understand that money needs to be made but I don’t see myself relying on another closed source tool, unfortunately. Maybe there can be an open source business model? Just my random 2 cents.

Congratulations on identifying a pain point so precisely and executing so well.

You'll gain massive adoption if you promote this as "Local development for Serverless".

</sarcasm>

Lol, love it :D

So to be clear this only supports PHP.

Any hopes for other stacks, I'd love this for Node.

I find `nvm.sh` pretty invaluable for juggling node versions - https://github.com/nvm-sh/nvm#intro

I think my ideal Indigo approach would provide similar functionality to nvm-sh but:

* allow running more than one version at a time (for working on/running multiple projects at differing stages), and

* save you having to install, learn & remember the command line syntax for it; many people find a GUI more productive, despite them often being fully capable of using the command line

You may want to look at asdf, which has plugins for a LOT of language toolchains.

Also. Many version managers allow me to have a .node-version or similar file in my project folder, and will automatically switch to that version for any commands run in that directory.

Finally, have you considered supporting a config file similar to docker-compose? GUIs are great, but being able t have the config committed to version control is better!

I used to be an nvm guy until I found volta. Never going back. https://volta.sh/

Absolutely. The current PHP focus was a handy place to start, but my plan is to incorporate whichever services people find most useful. If you can start a topic in the forums I'm interested to discuss with you how best to cater for node.

I like the drawings instead of generic icons or pictures on the website. Did you draw them yourself?

Thanks for your kind feedback. I'm lucky enough to be married to an awesome designer/illustrator who drew them by hand :)

Looks interesting.

I’ve been using MAMP Pro.

Docker works fine, but I’m not really a backend developer. I work on the server, maybe once every three months (or less often). I usually just end up using BBEdit and Forklift, as it’s a short job, and I want to get back to Swift.

I usually need to set up Docker all over again, since I didn’t keep it up, and MAMP is an overcomplex mess. The latest release did something to PHP 8, which I haven’t been able to pin down, but it’s made it worthless as a testbed, until I get that fixed.

Sounds like you're having some of the kinds of pain I've had in the past. Give Indigo a spin... I'm hoping it will make your life a little better! :)

Thanks for sharing this! Will this help me (or someone like me) manage something like 1 database server (with multiple databases in it) shared between all my projects and then let me swap out the PHP version on a per-project basis? ...basically my qualm with something like XAMPP is that it's hard to swap out the PHP version, and I end up having multiple XAMPP installs for all my different PHP versions I have to work with.

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.

I understand the desire here to get more performance out of macOS for web development. The problem is that even if you have the right stack installed writing and executing code in macOS is not the same as doing it in the same OS and stack that the code is deployed on. You will still run into situation where it “works on my machine” but fails when deployed.

A common set of issues has to do with the file system.

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.

> I quickly realised that trying to accurately replicate my production environments locally was not going to be a happening thing

Your production environment should be easily reproducible via some sort of infrastructure as code system, or it could be built in containers/docker itself. In that case you absolutely can replicate your production environment locally incredibly closely. Usually the main differences are around scale and performance. I see this as good though as it is much easier to stumble upon performance issues on a local dev machine than it is on a blazing fast prod instance.

> 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.

Staging is for sharing and reviewing your work with other stakeholders before deploying to production. I prefer to not have asinine platform related bugs to show up when I am demoing my work around the company or with clients. Also in my experience staging is not a spare pi (which is also ARM!) or a local docker instance.

> 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.

It is still the same OS and is miles ahead of just simply being POSIX compliant. I would be interested in specific differences and issues you've seen in ARM linux vs. x86 linux, especially when it comes to the layers PHP operates within.

> Re file system issues, you're absolutely right; this colossal thread

Have you tried the VirtioFS experimental feature in docker desktop? With it enabled I can write hundreds of GB per day from docker to my macOS file system with no sweat.

In any case, I was referring to differences between executing code on a macOS file system vs. a linux file system that matches production. macOS handles permissions and case sensitivity differently which can cause problems, especially for junior devs.

Anyway, good luck with this endeavor. I am sure many will find it sufficient!

Hope you don't mind me continuing the conversation, I like having my thinking challenged/stretched :)

> I quickly realised that trying to accurately replicate my production environments locally was not going to be a happening thing

Sorry I wasn't clear; my production environments are docker and as such yes, trivial to get running locally. My experience was that this was far less useful than expected. The moment I started turning on things like Xdebug and implementing mechanisms to deal with non-production .envs etc etc it became less and less useful for me. I'm guessing there are workarounds for all these kinds of issues (or you wouldn't be a proponent), but I do suspect that if you're developing locally in a 95+% clone of a production docker environment, you are one of very few who have managed it and enjoyed it enough to keep doing it. Which is to say you're a legend :D

> staging

Perhaps I used poor terminology; call it "Test". And the Pi was a poor example also, sorry! I don't run Pi's, and my personal dev circumstances are fairly atypical. However, I do feel it's solid advice to suggest that people:

a) run whatever development environment is most productive for you on a daily basis locally, so long as it closely replicates the production environment at the level your job requires. So as a front-end / back-end developer that means the same PHP/MySQL/Nginx versions etc.

b) run a clone of your production environment on a separate machine (local VM / local tiny PC / second VPS, whatever) for testing

> specific differences and issues you've seen in ARM linux vs. x86 linux

Absolutely none (as you probably guessed); I've never run an ARM server, nor had any issues between native binaries on x86 or M1 and their identical counterparts in production. As you suggested, the issues I typically face (and many like me, I expect) are at a different abstraction level from this; most boiled down to a) service configuration differences eg PHP extensions or b) file system issues (eg permissions & case sensitivity).

Re VirtioFS no, when I still used D4M I ran docker-sync with various strategies. It kinda worked. I then ran VS Code's Remote Containers. It kinda sorta worked. Both were annoying on an almost-daily basis.

> I think there's a growing realisation that Docker is harming developer productivity.

It depends a lot on specifics, but as a trend I tend to agree. However, there's value in making the development environment consistent among engineers. I wonder if there's a middle ground for version-pinning things like PostgreSQL and Ruby that's not as extreme as containerization.

In theory yes. In practice I haven’t seen any of these issues in years. And the last time I did see issues was due to case-insensitive file system which is easily fixed by running local code on a case-sensitive partition.

And many of us have a staging environment for QA anyway, so if the odd issue did sneak through, it wouldn’t be a major problem as it wouldn’t make it to production.

I work on a PHP project that is installed an any number of environments - so exactly duplicating production is impossible. Of course we have a CI/Test system that tests various combinations of PHP version and DB engines, but we can't replicate every possible production environment. Using Docker to match production is therefore moot in our case.

All the PHP development frameworks these days have moved to Docker or VMs but nothing beats native. Indigo looks promising.

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).

1. "macOS updates won't ruin your setup" - How can this be guaranteed since shared libraries may change in OS updates?

2. Docker on mac is a memory hog (was a performance hog too until the virtioFS changes landed). But docker allows me to run the same setup in local as well CI and optionally in production.

Hence it doesn't appeal to me but it looks like a good alternative to MAMP. Good luck!

I suppose you can run your tests in docker and just do dev work in a "good enough" replica.

Exactly. I would argue this is the only way you can be sure your code will run properly in Production.

I found that when I tried developing inside a clone of my Production Docker environment, I started having to change more and more things over time eg installing Xdebug etc that meant it was not the reliable test environment I hoped it would be.

The binaries that ship with Indigo install their own shared libraries to /usr/local/Indigo. However there are a number of cases where they do still depend on macOS dylibs (stuff like libSystem, libiconv, libc++). In this case macOS updates won't ruin your setup, because Indigo will ship with binaries that specifically work with the new OS.

Re: 2) if that works for you that's great. However a lot of developers end up using Docker abstractions (for very good reasons) such as Lando or Laradock which specifically don't attempt to replicate a production environment any closer than Indigo does. So as @Chrischen says below, use something highly productive for development, and use a clone of your Production Docker stack for QA. Arguably that's the only way to truly be sure your tests pass in your Production environment.

Is Docker really a hassle?

In every project directory, I have a "run.sh" script that starts a docker container with the right stack and mounts the project dir into the container.

Been doing this for years now. It feels completely seamless, fast and logical to me. What am I missing?

I'm glad Docker works so well for you as the premise is awesome. You're on a Mac right? It's just that you having a bespoke run.sh, and "mounting directories" makes me think Linux, where yes, Docker would be excellent for development.

However, assuming you are on Mac, I'm curious what kind of development you do? It seems hard these days to avoid stuff like `composer update` or `npm update` or to compile SASS or to bundle JS and as soon as you do any of those things, with Docker you start to get a syncing feeling. Sorry, shouldn't try to be funny this late in the day... :)

Oh also, when I run Docker for Mac I often get random 100% CPU usage for no reason at all, with no containers running, causing all my fans to spin up to full. I also periodically find I've run out of SSD space because docker has used it all up with qcows or something. And anytime I had to make a config change in one of my images I had to jump through flaming hoops to get it to take effect in the container. Not because of Docker per-se but because I wanted to write PHP or Javascript, not learn how to sysadmin Docker.

I'm using Linux as the host. No problems with Docker being slow. I can't say if there is a difference to running stuff directly on the host. If there is, it must be such a small difference that I can't notice it.

I would have thought Docker runs nice on all the big OSes, Linux, Mac and Windows. Isn't everyone doing everything in Docker these days? I would have thought there is an uproar if it is wonky on some platform.

When I do a config change in a Docker image, I just execute "docker build" and thats it. I have never experienced it not "taking effect in the container". Maybe because I don't keep containers around? The run.sh does "docker run --rm -it" so the container is gone when I stop the application.

Yeah, it's pretty amazing how mediocre Docker (and many other container implementations) can be outside of Linux after one is used to how good it is on Linux. Even though virtualization has improved greatly, it still has a significant overhead.

Man, that makes me happy I have chosen Linux as my OS and stayed with it.

I couldn't live without Docker anymore. It is just so convenient and logical.

Juggling a mix of environments on my host seems insane to me.

And without Docker, how do you deal with security? How do you work on a project without isolation? Do you trust every project and every piece of code so much that you let it run on your host?

Mac Docker brings its own set of issues. For me it's been a constant battle to deal with Mac For Docker for filesystem performance. Especially everything in JSLand. Loads of file checking, Docker's out of the box file system stuff for Mac has been very rough despite two attempts at resolving it, and just generally awful performance issues.

In theory stuff that is solvable, but it's not like on Linux (which is, after all, just the cgroups + chroot dance). The Mac stuff is painful and slow. And the ways to make some of it fast involve really bad tradeoffs at the other end.

I'm convinced that Docker setups on Mac have cut down on dev hours world wide by at least 10% from this kind of stuff, even with all the wins you get (at least in theory). It's still a bit shocking to me that we haven't figured out a better way to deal with this problem for web development given so many people are on Macs

How does this differ from MAMP, other than the fact that MAMP is quite old at this point?

Not so much that MAMP is old as that it's too simple for a lot of work. Essentially:

* MAMP offers a subset of the services Indigo provides (eg MAMP provides two PHPs, Indigo provides seven)

* with Indigo you can run any combination of services all at once if you like (that's a stack in Indigo)

* then in Indigo you can have multiple stacks all running together if you want

* you can share your Indigo stack with a team and have them all running the same stack with one click

So for example, if you maintain a really old Drupal site you might want a stack with PHP 7.2 (or even 5.6) and Apache, and perhaps you're migrating that old site to Laravel, so you'll create a stack with PHP 8.2 and nginx. You can give both their own domain names (eg oldsite.test and newsite.test) and run them both simultaneously. That's super easy to set up in Indigo.

Very cool and very useful!

Is there some issue with forum sign up emails? Have tried resending twice now, still nothing (in Spam or otherwise, a test email to myself from another domain was delivered instantly).

I have a consistent crash that wanted to report on the forum, but can't as yet.

With the "System" selected click the + (add stack) button -> crash.

Without the System selected no problem clicking that + button to add a new stack.

MacBook Pro (16-inch, 2019) / 11.6.5 (20G527) / 2.6 GHz 6-Core Intel Core i7 / 16 GB 2667 MHz DDR4

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.

Maybe it is just me, after skimming through the website, I thought "support" is to support the developer only to find out it is a documentation page.

Thanks for your feedback. I'm eager for it to actually support the developer, as you'd thought it would. Can you describe more what you'd hoped to see there?

Call it documentation. As well as that being a common term, it's a noun, and by clicking there noun-like documentation can be found.

'Support' is more commonly used as a verb, so it's creating expectation of an action by the user or the site.

Love your rationale :) It is done. You may have to empty your browser cache if you want to see the change.

This is great! This is one more step towards a world free of JavaScript! The obvious root of all evil. In no time will be back to server side render static html pages!

Well.. except for web3..

Reply on news.ycombinator.com