TillaTheHun0
commented
2 years ago Vercel makes it a bit cumbersome to run remix apps locally, without using different adapters. This is even what the vercel example does. We don't want to encourage users to diverge their development and production environments like this.
We could use the Vercel CLI and vercel dev option, but that requires a lot of extra auth and linking to vercel, which I am not keen on forcing users to go through. And vercel dev does not work with cloud dev environments like Gitpod and Github Workspaces.
The Remix community seems to be rallying around Fly.io, which is a similar PaaS like Vercel, but accepts docker images to run on Firecracker microVMs (sweet!). Instead of Vercel, I think I will integrate Fly.io into the Alternative Stack, as it will achieve the same goal of not requiring users to setup an AWS account, if they don't want to, while also using the same adapter for development and production.
Thank you for helping to improve the Alternative Stack!
If you have a feature idea for hyper, drop on into our Slack!
Is your feature request related to a problem?
Many user's are trying to avoid AWS or working with a Cloud provider. Part of hyper's mantra is to make working with Cloud services, easier. Many folks just need to deploy their application to a scalable platform, then consume their hyper services from there, not ever needing an AWS account. Vercel integration would be great for this.
Describe the solution you'd like
On stack initialization, allow the user to choose Vercel or AWS as their deployment target, and set up the project accordingly.
Additional context
The stack should default to Vercel, since it requires the least amount of setup.