podoman

Hi there, yes this was discussed in a couple threads! Happy to answer any other questions you have :) .

Hi there, for sure! I'll put these companies in buckets:

https://render.com/ These folks are a production solution and have added support for review apps. All that happens is a new deploy of the production app on every PR. There's no support for spinning up arbitrary commits, caching, etc.. Further, its not free.

https://vercel.com/, https://www.netlify.com/ Only supports frontend (and maybe serverless?)

https://www.releaseapp.io/, https://getdockup.com/ These are both more direct competitors. Dockup is no longer around I believe. Wrt/ release we have different outlooks on pricing, as they charge a large initial fee. The product itself is similar, however.

And lastly, Heroku was discussed in threads below, but the general idea is that if you're already on Heroku, using review apps makes a lot of sense! With that being said, they don't support the features I mentioned above such as, restarting runs, comparing commits, caching, etc..

Let me know your thoughts, happy to keep the conversation going!

Sorry for the delay here. A list of runtimes is at the bottom of this doc (https://docs.getreploy.com/docs/fields), but notably, we support arbitrary docker images.

That is, if you specify `image: node`, we'll pull from the public node image on docker hub: https://hub.docker.com/_/node/

Ahh yes. We've spoken to some companies that have existing helm charts that they'd like to use with Reploy. Is this what you're referring to?

Regarding pricing, this is a good reason to use Reploy! Because all of the scheduling is happening behind the scenes, we have the flexibility to offer teams a more predictable pricing model.

The infra is scheduled on k8s. Happy to answer other specifics!

Most of our users are using Reploy for the concept of "Preview Environments". That is, being able to view the environment before a merge happens.

In fact, in many cases, it doesn't make sense to do a full production deployment on every PR (either from a time or cost perspective).

I do, however, understand your hesitancy regarding having a different deployment structure for these previews. The reality is that if you want fast builds an experience that makes it easy to compare different commits, etc.. there is a tradeoff.

Right now, we support branch-level commits as well. That is, you can add a specific branch that Reploy spins up environments on (in addition to open PRs). For any branch or PR that reploy is handling, you can "restart" previous commits to do comparisons.

The idea for supporting any commit on the whole repo is interesting (and honestly, not hard to implement), definitely see the benefit there!

Re: mobile. Yeah, maybe we could push arbitrary assets to a bucket somewhere so that you could serve an android build there. We're definitely focused on the web aspect, but this is exciting wrt/ making Reploy more encompassing.

And re: pricing. Got it. If you don't mind sharing more about your team's situation, we can probably figure something out (my email's in the post). The reason we charge per seat is because its a reasonable proxy for how many environments are being spun up, and frankly we're still learning how to metricize. It'd be cool to see what your team's workflows look like.

This is more of a subjective thought, but we use docker under the hood, so we support any arbitrary docker containers. Procfiles are limited in that sense.

But the argument that if you already have Procfiles in place, its easier, makes a lot of sense.

To your first points about the logic for spinning up these environments, we do exactly that :). Right now, we spin down environment after some time period, and GC everything when a PR is closed.

Re: mobile, we've considered serving React native apps on a URL, as there are already containers that support the whole ecosystem, but haven't actually considered android. If an android binary was generated, how would we serve it to end users?

Regarding the price per seat, that's an interesting outlook. For the most part, people haven't been worried about pricing, mainly because they're hesitant about spinning up too many environments. If this seems interesting to you all, we'd be happy to chat more about pricing (as we're still figuring things out :)).

We know of another company in a previous batch that does have a similar offering. This is definitely a growing space!

No worries, we like feedback!

So to touch on the Heroku argument, its easy for your team to set this up because your production environment is already on Heroku. For teams that deploy on AWS, however, setting up a `reploy.yml` file and committing it is arguably easier than dealing with Procfiles.

Re: Vercel, if a team only needs frontend apps, its definitely a good option. We offer the same service in this sense.

Overall, in your case, I do see a benefit in having both of these solutions combined. That is, being able to restart or compare a PR's state in one system probably adds value?

I think this might also have to do with timing. As in, this "per-PR" iteration model is now becoming popular. In our minds, after CI/CD, the next thing to automate are ~full deployments.

We do offer an on-prem solution if you're interested. You could simply spin up a kubernetes cluster on your infra and "helm apply". Feel free to reach out at my email above if you want more specifics.

Appreciate the tip! We actually have a domain with reploy__.com, but aren't using it. We'll set that up!

Working on a fix; thanks for the heads up!

These are actually things that our current customers have run into; our solution is reasonably generic. I've touched at your points below.

re: databases, one option is pointing your Reploy environment to a common database. The other is to actually spin up a database within Reploy, where you seed data or a do a dump (pgdump, mongodump, etc..)

re: logins, we generate deterministic URLs (checkout https://docs.getreploy.com/docs/links-discovery), so you can tell your auth provider what the links will look like. (Can talk more about this if you like).

Not in the near future. We've realized that the "staging" workflow is quite different than production, and companies like Render, Heroku, etc.. are missing a few key features that we wished were there; so we're doubling down on per-PR staging.

Ah, good question! We've spent some time at larger tech companies, and realized that when you have many distributed teams, you can actually run Reploy with smaller subsets of your stack, and treat external dependencies like you would for external providers.

For example, maybe your team contributes to a frontend/backend regularly; you'd just staticly point the Reploy environment to other service dependencies that don't change as often.

That being said, market-wise we're targeting <200 eng companies, but definitely a cool thing to think about.