Ask HN: Best way to simultaneously run multiple projects locally?

Woah, so much overcomplication in the comments!

If you want to run multiple applications, how about ... just running them? It sounds like you already do that, so what is the real problem that you are trying to solve?

If it's annoying to start them by hand one by one, you could use Foreman or Overmind to start them with a single command, and interleave their output in a terminal.

What a bunch of over engineered solutions.

I run multiple side projects on my linux desktop using both postgresql and mysql, and using host entries work well enough.

For HTTP, using entries in hosts file locally allows the clients to all connect to port 80 on the local machine all using different domain names, and nginx can proxy the connection to whatever port the backend is running on.

Everybody loves their random port numbers these days, but I still prefer custom hostnames.

Just chuck an entry into your hosts file and tell your web server to sniff for it and you’re done. Run your stuff on port 80 like nature intended and never have to teach either end of your app how to deal with colons and numbers in domain names.

And you get to skip the six paragraphs of pain the other commenters are describing, orchestrating their kubernetes and whatnot.

e.g.: http://dev.whatever/

Different ports.

Don't add unnecessary complexity unless it's strictly necessary.

Using Kubernetes can be good for your resume.

What I usually do is to use different ports on my workstation. So I can get the fastest iteration, by keeping things simple. Be careful to keep the ports straight, though.

You can put the port numbers and other installation-specific files in a `.env` file, application-specific config file, or a supplemental build system config file, that aren't checked into Git.

One way I did this was to have a very powerful `Makefile` that could not only build a complicated system and perform many administrative functions, of a tricky deployment, but also work in both development and production. That `Makefile` pulled in `Makefile-options`, which had all the installation-specific variables, including ports. Other development config files, including HTTPS certificates, were generated automatically based on that. Change `Makefile-options` and everything depending on any of those was rebuilt. When you ran `make` without a `Makefile-options` file, it generated one, with a template of the variables you could set.

Today I'd consider using Kubernetes for that last example, but we were crazy-productive without it, and production worked fine.

Containers.

I’ll also recommend commercial OrbStack for Mac, because it simplifies some configuration and is performant.

That was my focus over the last couple months (and right now with customer solution I’m running tens of isolated clusters of heterogenous services and custom network configurations).

I’ve tried nix, local Caddy/Haproxy, Direnvs, Devenvs, dozens of task file runners, DAG runners etc.

Kubernetes is fine but it’s a domain in its own and you’ll end up troubleshooting plenty of things instead of doing work itself.

The simplest solution I would recommend is a task runner (Justfile/Taskfile) with containers (either built or with volumes attached - this prevents secrets leakage). Pay special attention to artifact leakage and clone volumes instead of mutating them.

I don’t recommend Docker Compose because it has low entry and a high ceiling and it takes long time to back out.

For simple clusters (5-8 containers) it’s working well. If you need to level up my personal recommendation would be:

- Go for pure programmatic experience (I’ve tested bunch of API clients and IMO it’s less time learning Go than troubleshooting/backfilling missing control flow features) - there’s also Magefile for simplified flows

- Full Kubernetes with templating language (avoid YAMLs like a plague)

- Cuelang if you want to go for full reliability (but it’s difficult to understand and documentation is one of the worst I ever read through).

https://ddev.com/ has become standard in the circles I run in (most are web devs working in agencies touching multiple projects each week). You don't have to use DDEV specifically, but it works like a dream and may provide some inspiration.

Each project gets its own Docker Compose file. These allow you to set up whatever project specific services and configuration you need.

None of your projects need to expose a port. Instead each project gets a unique name like `fooproject` and `barproject` and the container listening to port 80 is named {project-name}-web.

It all gets tied together by a single global NGINX/Traefik/Caddy container (you choose) that exposes port 80 and 443 and reverse proxies to each project's web container using Docker's internal hostnames. In pseudo-code:

  https://fooproject.example.site 
  {
    reverse_proxy fooproject- web:80
  }

  https://barproject.example.site 
  {
    reverse_proxy barproject-web:80
  }

  127.0.0.1 *.ddev.site

It may seem overcomplicated (and it is complicated). But since it's a de-facto standard and well-maintained, that maintenance burden is amortized over all the users and projects. (To the naysayers, consider: PopOS/Ubuntu are quite complicated, but they're far easier to use for most people than a simpler hand-rolled OS with only the essentials.)

I prefer setting up services that bind to port 0 ("get me an unprivileged port"), report that back, and use that to auto-configure dependent services.

This allows local development and debugging for fast iterations and quick feedback loop. But, it also allows for multiple branches of the same project to be tested locally at the same time!

Yeah, git does not make that seamless, so I'd have multiple shallow clones to allow me to review a branch without stopping work on my own branch(es).

Before there was Docker and Kubernetes I used to run hundreds of web sites on a single server by being disciplined about where files go, how database connections are configured, etc. I still do.

I would say docker-compose with traefik is definitely the easiest! You can even set dependencies between services to ensure that they load in the right order, do networking, etc.

If you're interested in running locally, a solution like kubernetes seems slightly overkill, but it can be fun to mess with for sure!

Kube slows down iteration cycle. I use bash script that encodes the port information. No big deal if you repeat this boilerplate code. LLM can apply a change to all of it simultaneously.

Simple `bin/restart`

K3s is good. Kube is also good. But for local development you want to isolate to code and have rapid cycle time on features. Use `mise` with simple run script. If deploying to k3s use Docker (with Orbstack if Mac) and simple run script.

LLMs bad at auto debugging environment means you are spending even more time on low leverage task. Avoid that at all costs. Small problem => small solution.

We use the following steps:

- Each service listens on a different, fixed port (as others have recommended).

- Have a single command (incrementally) build and then run each service, completely equivalent to running it from your IDE. In our case, `dotnet run` does this out of the box.

- The above step is much easier if services load their configuration from files, as opposed to environment variables. The main configuration files are in source control; they never contain secrets, instead they contain secret identifiers that are used to load secrets from a secret store. In our case, those are `appsettings.json` files and the secret store is Azure KeyVault.

- An additional optional configuration file for each application is outside source control, in a standard location that is the same on every development machine (such as /etc/companyname/). This lets us have "personal" configuration that applies regardless of whether the service is launched from the IDE or the command-line. In particular, when services need to communicate with each other, it lets us configure whether service A should use a localhost address for service B, or a testing cluster address, or a production cluster address.

- We have a simple GUI application that lists all services. For each service it has a "Run" button that launches it with the command-line script, and a checkbox that means "other local services should expect this one to be running on localhost". This makes it very simple to, say, check three boxes, run two of them from the GUI, and run the third service from the IDE (to have debugging enabled).