5 ms·

I skipped over fly.io because I don't want to run a command to deploy an update to an app. I much prefer Render.com and DigitalOcean's setup where you select a

I skipped over fly.io because I don't want to run a command to deploy an update to an app. I much prefer Render.com and DigitalOcean's setup where you select a repo and then it takes care of the rest with auto update on git push. This seems like a trivial thing to add. If I wanted to use a domain specific configuration file then that's always an option, later.

seth123456 4y ago
Fly did send an email linking to one of their articles on how to set it up for github maybe a few hours after the initial setup. I think it took me like 5 minutes to setup deploy on git push to main (or your deploy branch)
benhoyt 4y ago
They don't really need to add anything, because you can just use a GitHub Action that run "flyctl deploy". Here is Fly.io's guide to the 15 lines of YAML you can use to do that: https://fly.io/docs/app-guides/continuous-deployment-with-github-actions/ https://fly.io/docs/app-guides/continuous-deployment-with-gi...
- MarkSweep 4y ago
  If any Fly.io people are reading: this page has Git merge conflicts in it currently. Search for <<< on the page.
- yencabulator 4y ago
  What's really needed for this to be good is API tokens scoped to something significantly less than "anything my account can do". Fly devs have confirmed this is in the works, think macaroons. The only defense here is that Fly isn't the only party being incredibly sloppy with their API keys. Cloudflare is just as bad.
mtlynch 4y ago
>I much prefer Render.com and DigitalOcean's setup where you select a repo and then it takes care of the rest with auto update on git push. Doesn't that force you to use your hosting provider as your CI provider? I've always avoided the automatic "deploy on git push" solutions because I want to keep my CI provider uncoupled from my hosting provider. That way, I can switch hosts without having to rewrite all my CI code.
- tuukkah 4y ago
  To keep CI and hosting decoupled, your CI can push fresh images to a docker registry, and your deployment can poll for updated images. An easy way to achieve this is to add the Watchtower container to your compose files: https://containrrr.dev/watchtower/running-multiple-instances/ https://containrrr.dev/watchtower/running-multiple-instances...
  - mtlynch 4y ago
    I don't think that's a good solution in general unless you're confident that all of your deployments will use Docker Compose. About 1/3 of my deployments are just static sites, and the rest all fit into a single Docker container, so integrating Compose would be a big increase in complexity.
    - tuukkah 4y ago
      I'd say Compose simplifies even your single-container deployments, as the compose file is the single place to set your env variables, port forwards etc. That being said, you can use Watchtower without Compose. It's enough to run docker run -d -v /var/run/docker.sock:/var/run/docker.sock containrrr/watchtower

seth123456 4y ago

Fly did send an email linking to one of their articles on how to set it up for github maybe a few hours after the initial setup. I think it took me like 5 minutes to setup deploy on git push to main (or your deploy branch)

benhoyt 4y ago

They don't really need to add anything, because you can just use a GitHub Action that run "flyctl deploy". Here is Fly.io's guide to the 15 lines of YAML you can use to do that: https://fly.io/docs/app-guides/continuous-deployment-with-github-actions/ https://fly.io/docs/app-guides/continuous-deployment-with-gi...

MarkSweep 4y ago
If any Fly.io people are reading: this page has Git merge conflicts in it currently. Search for <<< on the page.
yencabulator 4y ago
What's really needed for this to be good is API tokens scoped to something significantly less than "anything my account can do". Fly devs have confirmed this is in the works, think macaroons. The only defense here is that Fly isn't the only party being incredibly sloppy with their API keys. Cloudflare is just as bad.

mtlynch 4y ago

>I much prefer Render.com and DigitalOcean's setup where you select a repo and then it takes care of the rest with auto update on git push. Doesn't that force you to use your hosting provider as your CI provider? I've always avoided the automatic "deploy on git push" solutions because I want to keep my CI provider uncoupled from my hosting provider. That way, I can switch hosts without having to rewrite all my CI code.

tuukkah 4y ago
To keep CI and hosting decoupled, your CI can push fresh images to a docker registry, and your deployment can poll for updated images. An easy way to achieve this is to add the Watchtower container to your compose files: https://containrrr.dev/watchtower/running-multiple-instances/ https://containrrr.dev/watchtower/running-multiple-instances...
- mtlynch 4y ago
  I don't think that's a good solution in general unless you're confident that all of your deployments will use Docker Compose. About 1/3 of my deployments are just static sites, and the rest all fit into a single Docker container, so integrating Compose would be a big increase in complexity.
  - tuukkah 4y ago
    I'd say Compose simplifies even your single-container deployments, as the compose file is the single place to set your env variables, port forwards etc. That being said, you can use Watchtower without Compose. It's enough to run docker run -d -v /var/run/docker.sock:/var/run/docker.sock containrrr/watchtower