[Concept] : FlyIO Deployment

[h0lybyte]

Core Concept/Theory
A clear and concise description of what the concept is. Ex. It would be cool if [...]

We could test out the deployment of the Rust API Profile and/or any additional dockerfiles directly through FlyIO.

Option 1 - Extend out the Dev branch CI/CD so that it would deploy the Dev build?
Option 2 - Create a microservice or two as a test case for the Fly deployment!

Having an additional endpoint or two running outside of our current provider is always an added benefit.

The Github action that we would use is probably their Superfly.
https://github.com/superfly/flyctl-actions

---

Alternative Ideas
Is there any other way this concept could be used?
Diversify our backend a bit outside of the main providers!

---

Alternative Examples/Sources
Are there any other references that you can provide?
No major examples as of right now! I can update this issue ticket when I do.

---

Additional information
Add any other context or examples of this concept here.

[h0lybyte]

Prepared the Chisel Docker Image -> https://hub.docker.com/r/kbve/rustprofilechisel

I will update the Fly deployment with this image then add it into the main pipeline.

[h0lybyte]

Reference to Fly.io [1] - https://coder.com/blog/remote-developer-environments-on-fly-io

[h0lybyte]

We could use the AWS free lamda storage and create a temporary 0bin replacement?

This would be a good project idea to test the fly deployment.

[h0lybyte]

Reference [2] - https://fly.io/docs/launch/continuous-deployment-with-github-actions/

[h0lybyte]

Secret Management -> https://fly.io/docs/apps/secrets/