4 ms·

After I have experienced several fly.io render railway northflank platforms, I think the problem with fly.io is that the web console is not fully functional, to

After I have experienced several fly.io render railway northflank platforms, I think the problem with fly.io is that the web console is not fully functional, too dependent on CLI and the response time of the application is unstable. The problem with render is that it is too slow to build, north is similar to railway, and the experience is good. But although the north console is very comprehensive, it is too complicated and dazzling. By contrast, the interface of railway is very simple and comprehensive, and UX is great. (found by wappalyzer analysis that it is based on nextjs,very nice)

eschatology 4y ago
I tried railway and northflank. Really like the UI northflank has; I think anyone familiar with Kubernetes should feel right at home. I also agree with the sentiment that railway ui is simpler.
fyzix 4y ago
I get up to 20secs of downtime when redeploying on railway... I was using the sample golang repo from fly : https://github.com/fly-apps/go-example https://github.com/fly-apps/go-example That's just unacceptible imo.
- fyzix 4y ago
  More context: The UI shows that the service is available but when I visit the live url, I get a 404. What I think is happening is that the UI shows the status of the underlying container and there is some fault with the reverse proxy they are using to expose the container to the internet. Fly.io doesn't have this issue but I am leery of all the complaints here.
- ndneighbor 4y ago
  Hey there fyzix! Angelo here, Support Engineer from Railway. I was here procrastinating from work when I saw this comment. The downtime you see is our proxy taking time to cutover- however, we have https://docs.railway.app/deploy/healthchecks https://docs.railway.app/deploy/healthchecks that will only cutover once we have a 200 from your API. This way we can keep your old deploy live and serving requests if and only if it's live. Theres more we can do to make it magical, but this should help in the meantime.
  - fyzix 4y ago
    Thanks for the reply, Issue resolved:) This could be done automatically by pinging the root and searching for a header set by railway's default page. If it doesn't exist then the service is live.
    - ndneighbor 4y ago
      We used to do that by default, but it led to issues with load on our proxy. (Imagine n * m pings against your host for a shit-tonne (official measurement) of builds + deploys a day.) We are hiring Network Engineers for exactly this reason :')
anurag 4y ago
>The problem with render is that it is too slow to build This is only true for the free tier, and (hopefully) won't be true for much longer.
- butterfly771 4y ago
  Yes, but I think the difference between free layer and paid users should be distinguished in terms of capacity and scalability. This crude entry experience may lead to a reduction in user conversion.

eschatology 4y ago

I tried railway and northflank. Really like the UI northflank has; I think anyone familiar with Kubernetes should feel right at home. I also agree with the sentiment that railway ui is simpler.

fyzix 4y ago

I get up to 20secs of downtime when redeploying on railway... I was using the sample golang repo from fly : https://github.com/fly-apps/go-example https://github.com/fly-apps/go-example That's just unacceptible imo.

fyzix 4y ago
More context: The UI shows that the service is available but when I visit the live url, I get a 404. What I think is happening is that the UI shows the status of the underlying container and there is some fault with the reverse proxy they are using to expose the container to the internet. Fly.io doesn't have this issue but I am leery of all the complaints here.
ndneighbor 4y ago
Hey there fyzix! Angelo here, Support Engineer from Railway. I was here procrastinating from work when I saw this comment. The downtime you see is our proxy taking time to cutover- however, we have https://docs.railway.app/deploy/healthchecks https://docs.railway.app/deploy/healthchecks that will only cutover once we have a 200 from your API. This way we can keep your old deploy live and serving requests if and only if it's live. Theres more we can do to make it magical, but this should help in the meantime.
- fyzix 4y ago
  Thanks for the reply, Issue resolved:) This could be done automatically by pinging the root and searching for a header set by railway's default page. If it doesn't exist then the service is live.
  - ndneighbor 4y ago
    We used to do that by default, but it led to issues with load on our proxy. (Imagine n * m pings against your host for a shit-tonne (official measurement) of builds + deploys a day.) We are hiring Network Engineers for exactly this reason :')

anurag 4y ago

>The problem with render is that it is too slow to build This is only true for the free tier, and (hopefully) won't be true for much longer.

butterfly771 4y ago
Yes, but I think the difference between free layer and paid users should be distinguished in terms of capacity and scalability. This crude entry experience may lead to a reduction in user conversion.