[tsergiu]

In my opinion the syntax of layerci is relatively simple as someone coming from docker, and does basically boil down to "give us the commands you use to deploy"

However they also have the advantage that they can run deployments on arbitrary runtimes. It looks like reploy only works if my app fits in the runtimes that were preconfigured by you. Because of that, I can run not just my dev deployment, but something very close to my prod deployment as well (we've had multiple bugs that only show up in prod due to our build process).

And finally, their aggressive docker-like layer caching allows very substantial speedups in not only builds, but tests as well. The speedups are typically in the triple digits compared to a reasonably well-optimized build.

I think the differences are major enough that I wouldn't exactly characterize the end results as similar.

Full disclosure: I know the founder

[podoman]

Hi!

> In my opinion the syntax of layerci is relatively simple

That's awesome! They've definitely built a nice product for some use cases, can't disagree with that.

> Reploy only works if my app fits in the runtimes that were preconfigured by you

Reploy actually supports any arbitrary runtime. Checkout our docs: https://docs.getreploy.com

> their aggressive docker-like layer caching allows very substantial speedups in not only builds, but tests as well

Makes sense; Reploy actually won't run your tests (or any other CI-esque things to that note). We're very much focused on only spinning up environments!

Overall, there is definitely overlap here. I'd argue that if someone wants to spin up a frontend, backend, db, etc., it makes a lot more sense to enumerate your `services` rather than try and serve them all in a single runtime (I think this is called a Layerfile?). I'm not sure how a use case like this would work with Layer, but that would be my hesitance in trying to set things up.

Layer seems like a great option for running long jobs to really take care of that speed up.