podoman

16 ms·

121.
by podoman 6y ago
Yeah this is definitely interesting. We built this because there's so much room for innovation. Sure, there are a few people that offer staging envs, but just looking at the diversity on this thread, there's clearly not a single p
122.
by podoman 6y ago
True that! At Reploy, we spin up Reployments, not Deployments! :)
123.
by podoman 6y ago
Hi! Very interesting points: addressed them below. 1. For the most part, with Reploy, users either a) Use a staging db b) Seed their environments with fixtures or test data. c) Do a db dump of a common db Each of them have their own tradeof
124.
by podoman 6y ago
This is pretty neat! Does pr-merger handle the deployment itself? From reading the docs, it seems like the tool merges a bunch of PRs into a single branch, correct? I'm curious what the whole workflow looks like.
125.
by podoman 6y ago
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 tha
126.
by podoman 6y ago
Thanks @anurag, we should get connected at some point, just shot you a message :) .
127.
by podoman 6y ago
Definitely understand where tommy is coming from. From a timeline perspective, we are "copying release", but better put: we're working on the same thing :).
128.
by podoman 6y ago
Hello! I'm slightly confused here, but I do agree with your statements. Are you implying that Reploy should also support production Deployments? If that's the case, then yes! We're also thinking in that vain more long term. I
129.
by podoman 6y ago
Agreed! Woot!
130.
by podoman 6y ago
At the moment, we're generating manifests via the kubernetes API. This may change though! Take a look: https://github.com/kubernetes/client-go
131.
by podoman 6y ago
The end result is ~similar, but their configuration is a little more involved and isn't as simple as "give us the commands in your dev environment". That being said, it seems like they're focused on speed, as they suppor
132.
by podoman 6y ago
Sorry if my assumptions were incorrect in the above post; and likewise, big fans of Render's offerings :) .
133.
by podoman 6y ago
Thanks for chiming in. We're also looking to offer more than Heroku does w/ their Review apps feature :). I actually learned that the Procfile was a semi-standard on this thread, so maybe a move from Heroku isn't too difficul
134.
by podoman 6y ago
Hi there, yes this was discussed in a couple threads! Happy to answer any other questions you have :) .
135.
by podoman 6y ago
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
136.
by podoman 6y ago
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 pul
137.
by podoman 6y ago
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 scheduli
138.
by podoman 6y ago
The infra is scheduled on k8s. Happy to answer other specifics!
139.
by podoman 6y ago
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 deploymen
140.
by podoman 6y ago
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 co
141.
by podoman 6y ago
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 lo
142.
by podoman 6y ago
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 Rea
143.
by podoman 6y ago
We know of another company in a previous batch that does have a similar offering. This is definitely a growing space!
144.
by podoman 6y ago
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 comm
145.
by podoman 6y ago
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.
146.
by podoman 6y ago
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.
147.
by podoman 6y ago
Appreciate the tip! We actually have a domain with reploy__.com, but aren't using it. We'll set that up!
148.
by podoman 6y ago
Working on a fix; thanks for the heads up!
149.
by podoman 6y ago
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
150.
by podoman 6y ago
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

More ›