Show HN: IndigoStack – a new native macOS app for local web development (indigostack.app)
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!
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
72 comments
[ 5.3 ms ] story [ 155 ms ] threadAny hopes for other stacks, I'd love this for Node.
* 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
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!
A common set of issues has to do with the file system.
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.
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!
> 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.
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.
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.
All the PHP development frameworks these days have moved to Docker or VMs but nothing beats native. Indigo looks promising.
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.
* 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.
</sarcasm>
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.
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.
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 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.
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.
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?
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 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.
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?
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
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!
Different Ports != Isolation..
But hey, marketing.
There are other ways to achieve process isolation in a Unix environment without relying on Docker or virtualization.
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.
I run databases however in Docker on my Mac.
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.
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!
'Support' is more commonly used as a verb, so it's creating expectation of an action by the user or the site.
Well.. except for web3..
Their partner made them: https://news.ycombinator.com/item?id=31488625
I like making websites, I don't like tinkering with servers.
Edit, missed the line mentioned in the child comment.
https://www.docker.com/blog/speed-boost-achievement-unlocked...
They said it here
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.
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