3 ms·
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 Herok
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 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?
- sergiomattei 6y ago> arguably easier than dealing with Procfiles This is quite a strong statement — I've never had an issue with procfiles, and prefer them considering how easy they make process management. They're also even semi-standard, considering that multiple services use them (Heroku, AWS EB, etc) - contrary to the reploy.yml file. What are the issues you've noticed with them?
- podoman 6y agoThis 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.
- josegonzalez 6y agoI believe a Procfile on Heroku is used for Dockerfile-based apps, though the `heroku.yml` takes precedence if that is available.