8 ms·

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

187 points by JeffMarmalade 4y ago

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

deleted 4y ago
[deleted]
999900000999 4y ago
So to be clear this only supports PHP. Any hopes for other stacks, I'd love this for Node.
- beninsydney 4y ago
  I find `nvm.sh` pretty invaluable for juggling node versions - https://github.com/nvm-sh/nvm#intro https://github.com/nvm-sh/nvm#intro
  - IndigoStack 4y ago
    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
    - nicoburns 4y ago
      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!
  - jeffkeen 4y ago
    I used to be an nvm guy until I found volta. Never going back. https://volta.sh/ https://volta.sh/
- IndigoStack 4y ago
  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.
macinjosh 4y ago
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.
- deleted 4y ago
  [deleted]
- JeffMarmalade 4y ago
  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 https://lando.dev and https://laradock.io 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 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.
  - macinjosh 4y ago
    > 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!
jibbers 4y ago
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.
- JeffMarmalade 4y ago
  Ah, "Undo"... good thinking, it's the Mac way :) I'll put it on my list.
adepressedthrow 4y ago
How does this differ from MAMP, other than the fact that MAMP is quite old at this point?
- IndigoStack 4y ago
  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.
alberth 4y ago
You'll gain massive adoption if you promote this as "Local development for Serverless". </sarcasm>
- IndigoStack 4y ago
  Lol, love it :D
ChrisMarshallNY 4y ago
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.
- IndigoStack 4y ago
  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! :)
vimy 4y ago
I like the drawings instead of generic icons or pictures on the website. Did you draw them yourself?
- IndigoStack 4y ago
  Thanks for your kind feedback. I'm lucky enough to be married to an awesome designer/illustrator who drew them by hand :)
tambourine_man 4y ago
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.
dominucco 4y ago
boundlessdreamz 4y ago
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!
- chrischen 4y ago
  I suppose you can run your tests in docker and just do dev work in a "good enough" replica.
  - IndigoStack 4y ago
    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.
- IndigoStack 4y ago
  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.
TekMol 4y ago
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?
- IndigoStack 4y ago
  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.
  - TekMol 4y ago
    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.
    - 4y ago
Sophistifunk 4y ago
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.
- JeffMarmalade 4y ago
  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!
  - lukeholder 4y ago
    I think we get that, the question is how do you isolate everything without a VM or docker?
    - bongobingo1 4y ago
      via docker and a VM.
      - lukeholder 4y ago
        It doesn't use docker or a VM
    - 4y ago
a_c 4y ago
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.
- IndigoStack 4y ago
  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?
  - zhte415 4y ago
    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.
    - IndigoStack 4y ago
      Love your rationale :) It is done. You may have to empty your browser cache if you want to see the change.
dt2m 4y ago
The little mini rack design is so cute!!! This type of playfulness is what I loved about the Mac experience 15 years ago.
- barbieceo 4y ago
  I love the art here! Could OP point to where they get them / what the style is called?!
  - SSilver2k2 4y ago
    skuemorphism
  - latexr 4y ago
    > Could OP point to where they get them Their partner made them: https://news.ycombinator.com/item?id=31488625 https://news.ycombinator.com/item?id=31488625
- bovermyer 4y ago
  Absolutely agree. Sometimes I miss the skeuomorphism of the old days, even if I do spend most of my time in the terminal.
tiotempestade 4y ago
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..
soniktrooth 4y ago
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.
- dewey 4y ago
  ~Have you tried the recent update?~ Edit, missed the line mentioned in the child comment. https://www.docker.com/blog/speed-boost-achievement-unlocked-on-docker-desktop-4-6-for-mac/ https://www.docker.com/blog/speed-boost-achievement-unlocked...
  - chaychoong 4y ago
    > it's painfully slow on MacOS even with the new virtiofs They said it here
Deadpikle 4y ago
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.
- JeffMarmalade 4y ago
  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.
richrichardsson 4y ago
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
- JeffMarmalade 4y ago
  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.

187 points by JeffMarmalade 4y ago

deleted 4y ago

[deleted]

999900000999 4y ago

So to be clear this only supports PHP. Any hopes for other stacks, I'd love this for Node.

beninsydney 4y ago
I find `nvm.sh` pretty invaluable for juggling node versions - https://github.com/nvm-sh/nvm#intro https://github.com/nvm-sh/nvm#intro
- IndigoStack 4y ago
  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
  - nicoburns 4y ago
    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!
- jeffkeen 4y ago
  I used to be an nvm guy until I found volta. Never going back. https://volta.sh/ https://volta.sh/
IndigoStack 4y ago
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.

macinjosh 4y ago

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.

deleted 4y ago
[deleted]
JeffMarmalade 4y ago
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 https://lando.dev and https://laradock.io 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 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.
- macinjosh 4y ago
  > 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!

jibbers 4y ago

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.

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

adepressedthrow 4y ago

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

IndigoStack 4y ago
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.

alberth 4y ago

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

IndigoStack 4y ago
Lol, love it :D

ChrisMarshallNY 4y ago

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.

IndigoStack 4y ago
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! :)

vimy 4y ago

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

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

tambourine_man 4y ago

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.

dominucco 4y ago

boundlessdreamz 4y ago

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!

chrischen 4y ago
I suppose you can run your tests in docker and just do dev work in a "good enough" replica.
- IndigoStack 4y ago
  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.
IndigoStack 4y ago
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.

TekMol 4y ago

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?

IndigoStack 4y ago
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.
- TekMol 4y ago
  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.
  - 4y ago

Sophistifunk 4y ago

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.

JeffMarmalade 4y ago
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!
- lukeholder 4y ago
  I think we get that, the question is how do you isolate everything without a VM or docker?
  - bongobingo1 4y ago
    via docker and a VM.
    - lukeholder 4y ago
      It doesn't use docker or a VM
  - 4y ago

a_c 4y ago

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.

IndigoStack 4y ago
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?
- zhte415 4y ago
  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.
  - IndigoStack 4y ago
    Love your rationale :) It is done. You may have to empty your browser cache if you want to see the change.

dt2m 4y ago

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

barbieceo 4y ago
I love the art here! Could OP point to where they get them / what the style is called?!
- SSilver2k2 4y ago
  skuemorphism
- latexr 4y ago
  > Could OP point to where they get them Their partner made them: https://news.ycombinator.com/item?id=31488625 https://news.ycombinator.com/item?id=31488625
bovermyer 4y ago
Absolutely agree. Sometimes I miss the skeuomorphism of the old days, even if I do spend most of my time in the terminal.

tiotempestade 4y ago

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

soniktrooth 4y ago

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.

dewey 4y ago
~Have you tried the recent update?~ Edit, missed the line mentioned in the child comment. https://www.docker.com/blog/speed-boost-achievement-unlocked-on-docker-desktop-4-6-for-mac/ https://www.docker.com/blog/speed-boost-achievement-unlocked...
- chaychoong 4y ago
  > it's painfully slow on MacOS even with the new virtiofs They said it here

Deadpikle 4y ago

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.

JeffMarmalade 4y ago
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.

richrichardsson 4y ago

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

JeffMarmalade 4y ago
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.