Show HN: I got tired of managing dev environments, so I built ServBay

[Saltyfishh]

Hey HN,

For years, my local development setup has been a fragile mess of tools that never quite played nicely together. On my mac, it was a constant battle with Homebrew services starting (or not starting) on boot, conflicting PHP and Node versions managed by `asdf` or `nvm`, and a collection of `docker-compose.yml` files that I'd copy-paste and tweak for every single project. The cognitive load was just too high.

Setting up SSL was another chore involving `mkcert`. Sharing a quick demo with a colleague meant firing up ngrok. And if I wanted to run two projects that needed different versions of PostgreSQL? Good luck. I’d have to stop one service to start another.

I missed the simplicity of the MAMP/XAMPP era, but I needed something that could handle the diverse stack of a modern developer – not just PHP and MySQL, but Python, Go, Rust, Node.js, and various databases.

That’s why I (along with my small team) built ServBay. It's our attempt to bring back simplicity and speed to local development without sacrificing power. It's a native app for macOS and Windows, not a wrapper around Docker or VMs.

Here's what it does:

One-Click Stacks: You can install and run multiple, isolated versions of languages like Python, Node.js, Go, Java, Rust, Ruby, and .NET. No more path conflicts or environment variable hell.

Databases, Plural: This was a huge one for me. You can run multiple instances of MySQL, MariaDB, PostgreSQL, Redis, and MongoDB simultaneously. Project A can use Postgres 14 while Project B uses Postgres 16, both running at the same time on different ports.

Automatic SSL: Any host you create gets a valid SSL certificate out of the box. No more browser privacy warnings for `.test` or `.localhost` domains.

Built-in Tunneling: If you need to demo a feature or test a webhook, there's a one-click button to expose your local site to the internet via a secure tunnel.

One-Click Local AI: This is something we're really excited about. We've added a feature to easily download and run models like Llama 3 or Stable Diffusion locally through a simple UI, so you can experiment without worrying about API keys or costs.

Everything Else: It also handles one-click backups, has a clean, non-intrusive UI, and is designed to be as lightweight as possible.

I know what many of you are thinking: "Why not just use Docker?"

And that's a fair question. We use Docker for production and complex, multi-service architectures. But for quickly spinning up a single-service app, testing a new framework, or just general day-to-day development, the overhead of `Dockerfile`s, `docker-compose.yml`, slow file sync on macOS, and resource consumption often feels like overkill. ServBay is for those moments where you just want to get to the code.

The project is still young, and we have a long roadmap ahead. I'm here all day to answer any questions, listen to your (brutally honest) feedback, and hear about what your own development workflows look like.

You can check it out here: https://www.servbay.com

Thanks for reading.

[hansonkd]

Not sure if your testimonials are real or not. The few I looked at didn't appear in any google results and many have AI looking avatars one is even named "jaime freelancer"

[jonsully]

This post reads like you just finished building this (congrats!) and even says:

> The project is still young

But the website is stuffed with AI and yet "Trusted by over 100,000 developers worldwide"?

Doesn't pass the smell test for me.

[m90]

Congrats on building this. But, please do not auto translate your website content, English is fine. For my language the part about trust is really cringe, which is not really building trust, you know.

[whydoineedthis]

If there were a servbay.yaml file that a person could export & commit this would probably go down smoother from some folks.

If you added a feature to push/fetch and sync the local development database from an s3 (or like bucket) it would solve one of the real core problems of new developers getting started.

That nginx proxy probably works 99.999% of the time, but oh boy, is that .001% going to tick someone off. Proxy's always add a small layer of complexity that can fubar things in strange ways, i know from running many of proxies in production just fine until that tiny little app/proxy config change that borks it. I haven't dug in enough yet, but i hope it can be bypassed.

Ambitious project that I think has some legs. A lot of devs dislike docker and many teams struggle to use it well anyway (for instance, a good dev Dockerfile is usually not the same as a good production Dockerfile). You will need to make this more "IAC-like" if you want to beat it though, imho.

Keep going and good luck!

[Saltyfishh]

I'll think about it.

[gxonatano]

Those of us that use Nix don't have the problems you complain about. Just write (or vibe-code) a flake.nix for each project, and you can have arbitrary versions of whatever language (Node, PHP, whatever), arbitrary environment variables, port setups, and whatever else. Add in Direnv and you don't have to do anything but `cd` into your project directory. Then simply add an extra output to create a Docker image for your project.

The idea of paying double digits annually for a service that's basically a weaker version of Nix, and which lacks Linux support, is absurd.

[dangus]

These are my concerns watching this video:

1. In a team environment, this seems like it would cement bad long-term practices into your workflow. So much is happening outside of source control. I see there's a unified configuration feature but it seems like a GUI of various ways to make a big mess that your future DevOps team is going to facepalm about and untangle.

2.

> For years, my local development setup has been a fragile mess of tools that never quite played nicely together. On my mac, it was a constant battle with Homebrew services starting (or not starting) on boot, conflicting PHP and Node versions managed by `asdf` or `nvm`, and a collection of `docker-compose.yml` files that I'd copy-paste and tweak for every single project. The cognitive load was just too high.

This to me reads as "I don't know what I'm doing and I'm having a bad time." Me personally, I'm not copying and pasting docker-compose.yml files around manually, I'm using source control with a development team and using feature branches like a well-adjusted person. I'm not constantly battling with Homebrew, none of my development environments depend on Homebrew as that is not what the tool is for.

3. In the demo video, the use of AI imagery (of a particularly low quality) and the AI narrator seems very lazy and makes me think that I shouldn't use the app because it might be AI slop with lots of bugs and security issues. I'd rather see a demo given by someone who isn't the best speaker than hear a fake AI voice.

4. The "Why not just use Docker?" question has not been sufficiently countered.

[hk1337]

I feel like SSL certificates for local environments is a red herring. For 95% of the developers, I would imagine, absolutely do not need it and 4% that say they do are using http://127.0.0.1 instead of http://localhost and wondering why they're getting errors that the site isn't secure?

[linhns]

Not sure if it suits your goal but I would suggest using mise. https://mise.jdx.dev/

[unchar1]

This looks interesting.

One small feedback: It took me a while to figure out what it actually does. The homepage makes it look more like coolify or dokku.

[Saltyfishh]

thanks for your feedback. I'll try to modify it.

[pacifika]

Looks interesting enough to try out. i was looking if it explicitly supported django but it supports the underlying tech.

[Saltyfishh]

thanks for the feedback. I'm also considering whether to add frameworks.

[cr125rider]

> slow file sync on macOS

So at your core you’re trying to solve an Apple bug?

[dangus]

Notice there's no Linux version, maybe because nobody who uses Linux as a workstation would want this flavor of spaghetti.

The "why not use Docker?" question isn't really answered very well. If you're developing on Linux the obvious answer is that something based on containers is going to be a lot more robust and make more sense than this.

I could see this product being used by someone who is trying to untangle some legacy spaghetti, but to me it seems like if you introduced this to a new development workflow you'd be cementing some outdated and dangerous practices - a lot of stuff here happening outside of source control.

[Hendrikto]

This is the most astroturf AI comment I have ever seen on HN.

Reads like the fake testimonials from their website.

[Saltyfishh]

thank you