Hacker Newsnew | past | comments | ask | show | jobs | submit | evanphx's commentslogin

The honest answer to your question about where the line is: it's when you start writing your own health checks, restart logic, and deployment orchestration on top of compose. That's the tipping point where you're maintaining infrastructure instead of just running apps.

We built Miren for exactly this middle ground. Push to the cluster, it handles image building, TLS, and deployment on any Linux server. No Dockerfile, no compose, no Kubernetes. Autoscaling is on by default. It's not that Kubernetes is wrong, it's that there should be something between compose scripts and a full cluster.

We're actively working on ways of deploying already ready services in docker files to the cluster, which would probably be what you're looking for initially unless the cluster you're doing a lot of development on the cluster.


Why did you use AI to write this?

EDIT: Only moderate snark intended.


If you're open, love to get your thoughts on https://miren.dev. We've doing similar things, but leaning into the small team aspects of these systems, along with giving folks an optional cloud tie in to help with auth, etc.


How is it monetized? I read something about open core and paying for additional services I think. What are those and where can I find them?


Are you doing that across a fleet of machines or just one?


We have 4 servers we run containers on. Calling that a fleet feels too generous. Not much rhyme or reason as to what containers run on which server


Totally, it's all about the primitives. I'm curious where exe.dev is gonna build on the the base, or just leave it up to folks to add all their own bespoke stuff to do containers, logs, etc.

The last 20 years has given us a lot of great primitives for folks to plug in, I think that lots of people don't want to wrangle those primitives, they just want to use them.


Agree and so I went looking and here is the reason: https://github.com/InitWare/InitWare/commit/3ee721035525dbb1....

They started with a specific version of systemd and have been mutating it since then, so the whole this is "tainted" with LGPL now.


Upon hearing this (and seeing the software that you've got listed on the website) I went and bought one. Looks great!


Hi, Evan Phoenix, Rubinius creator here. I just wanted to stop in and say thank you for this comment. It means a lot to me, even after all these years that Rubinius helped you out.

I mentioned this on twitter as well (https://twitter.com/evanphx/status/1458912013011152898?s=21) but wanted to reach out here and let you know personally too.

Thank you.


Hi Evan, I'm happy you found this comment heartwarming. Your work on Rubinius (and even more - Puma!) was really amazing, it had a big influence on my career


Templar does not do SSL termination because it does not terminate requests for your api. It's designed to mediate connections between you and any APIs that you use, protecting you against those APIs being unreliable.


Yup! That's on the todo list. Auto-caching, as I'm calling it, would figure out a how long to cache something for and then be able to later on use HEAD to check if the url in question has changed.

That cache time could be as long as 5 seconds, so that Templar is checking pretty often if the upstream has changed.


Thanks Veejay!


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: