Rethinking fly launch

[rubys]

My name is Sam Ruby and I work for fly.io. I'm planning on going to RemixConf 2023, and hope to start a discussion on:

• Replacing these manual deploy steps with fly launch.
• Having Fly and Remix converge on a single dockerfile generator
• Prepping for LiteFS

Background: I have a similar generator for Rails and contributed heavily to their docker template. For Rails, the generator is called during fly launch. I can do the same for Remix. The process can do anything a script can do, for example setting of session secrets.

[rubys]

Related discussions: fly community and remix github.

[MichaelDeBoey]

These are probably related as well & could probably be automatically fixed by the generator detecting certain situations:

• Fly Instance runs out of memory on deployment indie-stack#200
• No region defined in the fly deploy command, causes deployment to crash  indie-stack#213
• "fly apps create" not working correctly anymore blues-stack#138
• Deployment failing due to seed not working blues-stack#143
• Base Repo OOMs on Fly.io blues-stack#170

[rubys]

Over the next few days, I plan to make dockerfile-node the dockerfile generator for Node applications on fly.io. I will set things up so that it won't replace any Dockerfile you might have, I will be creating web pages showing how to use it to replace your Dockerfile to solve common problems (examples: running on windows, handle legacy peer dependencies, and running out of memory).

It is my hope to meet with people at RemixConf and use that time to make my case on replacing the Dockerfile templates that exist in Remix with this generator.

As to no region defined and fly apps create, fly.io recently made a rather significant runtime change. Some issues with the fly.toml created by remix:

• [experimental] section with a cmd =
• No primary_region
• [[services]] section rather than [http_service] with no auto_stop_machines or auto_start_machines

My recommendation will be that Remix stop creating a fly.toml, and update the deployment instructions to use fly launch instead. I'd like to talk through this and will either make the changes needed to fly launch to support this, or champion the need for changes within fly.io.

Finally, on the seed issue, if you want to be able to seed your production databases, you will need to make sure that all of the dependencies necessary to do so are present in the production environment.

[MichaelDeBoey]

Some extra related links:

• https://community.fly.io/t/my-postgres-database-is-down-for-no-reason/12664
• fix: add swapfile indie-stack#232
• fix(Dockerfile): update npm commands indie-stack#234
• Error connect database blues-stack#88
• Check if FLY_REGION is undefined blues-stack#101
• Fly.io -> Error: Can't reach database server  blues-stack#182
• use swap space for running migrations blues-stack#183
• fix(Dockerfile): update npm commands blues-stack#184

[rubys]

https://community.fly.io/t/my-postgres-database-is-down-for-no-reason/12664

this line is likely the culprit, this is something flycast should handle.

remix-run/indie-stack#232
remix-run/blues-stack#183

That's what fly scale and the --swap flag are for. If it is an app you care about, you want real memory. If it is a hobby app, virtual memory will do.

remix-run/blues-stack#101
remix-run/blues-stack#88

This seems related to the first issue above. I believe that process.env.PRIMARY_REGION is an apps V2 feature, so if the user has an older fly organization that hasn't been migrated, you will see undefined.

remix-run/blues-stack#184

This does several changes.

• install => ci ; this is a very good change, and dockerfile-node should be fixed to use this
• --production=false => --include=dev; this also is a good change, and dockerfile-node already does this
• --ignore-scripts -- I'm curious as to why that is needed. If it is not commonly needed, then I would be inclined to see it added as an option to dockerfile-node.

---

Meta comment: fly.io is still changing rapidly - and that's a good thing! But it keeps me busy - I've been focusing on Rails this past year or so and now am starting to expand to include Node frameworks. I have a high bandwidth communication with the product team and can react quickly to changes that are made to the platform. Each framework having fly specific code -- like remix currently does in its product -- leads to problems like these. It would be much better if that were factored out into dockerfile-node and fly launch which can be kept up to date with platform changes.

That's why I'm flying out to remix-conf this week and hope to have a high bandwidth conversation on the matter with @kentcdodds and anybody else interested in making this happen.

[MichaelDeBoey]

@rubys I appreciate all the work you're doing on the new dockerfile-node library 🙏
Just wanted to mention all the Fly-related issues/PRs I come across as they can potentially improve the lib (if things aren't implemented yet)

It would be much better if that were factored out into dockerfile-node and fly launch which can be kept up to date with platform changes.

It would indeed be better if we could just remove Dockerfile, fly.toml, ... from our repos and just call fly launch (maybe with some flags) without having to handle all the other stuff ourselves 👀

[rubys]

Adding, for completeness: remix-run/blues-stack#187

Also, the issues here also affect the newly announced epic stack.

[abetoots]

hi @rubys just wanted to check if there are any updates regarding the conversation with remix and @kentcdodds ?

[rubys]

@abetoots Not really. Epic stack is still not using fly launch for deployment. We've made a lot of improvements, and more are in the queue. I'd love for Remix to be able to take advantage of those improvements.

cc: @anniebabannie