Monorepo Support

I don&#x27;t get the case against monorepos, and why it&#x27;s so polarizing.<p>You can share code without having to stand up infrastructure to host packages and whatnot.<p>You can separate concerns without introducing the infinite complexity of network io, queues etc. This is kind of a dig at microservices I guess, which have their place functionally (decoupled infrastructure, scaled independent of other services).<p>You can still deploy to separate targets, a code repository is not 1:1 with a deploy target, that is a fake constraint that never even existed.<p>Manyrepos ALWAYS end up being second class citizens. Test setup isn&#x27;t as good as in the monorepo because that means duplicating it N times, and that is obviously wrong.<p>Common patterns are The Same But Different everywhere and&#x2F;or there is crazy complexity in sharing code between repositories to alleviate this (often having its own problems)<p>It&#x27;s just... all of that goes away with one&#x2F;fewer code repositories. So... why? I&#x27;m not even anti micro-service, monorepo actually makes MORE sense with microservices IMO. Why do we do this?<p>Before someone points it out, I do recognize that a monorepo can still be poorly architected. We can all rest assured knowing that poor architecture is poor architecture whether it be monorepo, manyrepo, monolithic, microservice, PHP, Rust, blah blah.

Hey folks. I do devrel here at Render and it&#x27;s nice to see this floating by on Hacker News--our new monorepo support does a lot to improve the ergonomics of running multiple services out of a single repo.<p>One note: in Render parlance, &quot;services&quot; includes static websites, so even for systems that wouldn&#x27;t always be considered a monorepo in other contexts, this is useful to launch a static website alongside your code and, in so doing, more clearly communicate what you&#x27;re doing to the next person to touch it. (Including six-months-from-now you.)

Render is one of those companies you don&#x27;t see a lot on HN, but you talk to developers who use it and they have a lot of love for it. Stuff just works like you&#x27;d expect it to. We&#x27;ve been a happy user of monorepo support since it was in beta and it&#x27;s worked great for us.

This is great! I’ve been using Render to host all my projects ranging from static sites to full blown web apps ever since moving away from Heroku. Their free tier is also pretty good for prototyping.<p>Recommend it to anyone moving away from Heroku or looking for a cheap place to start.

This is patching symptoms.<p>If you need some hosting&#x2F;deployment tool to support the way you structure your code repos, there is a bigger problem.<p>Your own tooling for your repo should decide what gets triggered. It&#x27;s not even as simple as this article makes it out to be. If I edit a readme.md, should this redeploy because it&#x27;s in the same directory?<p>Of course not. Structure your code how you want. Then make good tools to trigger other tools. don&#x27;t restrict yourself to every downstream job type and tool integrating vertically with your specific structures.

Many-repo is better at places that can’t fund a large infrastructure team, mono-repo is better at places that can.<p>The natural state of a mono-repo is Twitter-like paralysis, it requires concentrated work to avoid that but that work can make them better than many-repo.

Tried it for a couple of years, and as many already said, its more that its different than that its a lot better or worse than the altrrnative.