I have a Phoenix app I’m building in my free time that I’d like to test in a production-ish environment before deploying it to my personal server and fly.io seemed like a decent place to try that out. However, the app deals with image and video uploads and I’d rather not go over any usage limits so I’m wondering if there’s a way to destroy and recreate the environment on a schedule — every hour, for example — or when a disk usage limit is hit?
I couldn’t find anything like this in the official documentation. I know I could do this manually, but I’d rather have this happen automatically without any intervention on my part, if possible.
The closest thing I’ve found is scheduled machines, but that seems more like something you spin up to run a single job instead of a web app that should be live, but reset every hour or so.
Might be more simpler than that. We don’t bill for machines stopped so if your app just exits with code 0 the machine will stop you’ll get zero costs unless you have another resource attached to it that is billed constantly such as volumes.
Chris McCord wrote a bit onto how to do this in a way that Phoenix only stops when there’s no active connections:
Or you can rely on our Fly proxy to do this for you without code changes:
We do that by default when you fly launch an app nowadays.
If those are not what you’re looking for I’m happy to help more.
Does the auto-stop/start provided by Fly recreate the root volume for the VM? In other words, will a SQLite3 database on the root volume be deleted when a volume is stopped like that? To be clear: in this case that’s what I’d want to happen.
And on that note, is it possible to run a script on startup that’s not defined in code? I’m wondering if it’d be possible to run a command that generates a demo user for the app without adding in the code for that to the app itself.
I’m not so sure I’d like shutting down the Phoenix app when it’s idle . I don’t yet know if that’s something I want for the real thing, and I’d prefer to keep the production and “demo” codebases the same.
That’s correct. Often people mount their databases outside their volumes and lose this data but I think it’s cool you’re using this as a feature
No code changes but generating an user
if the goal is not having something committed to your original repo I can think of a few approaches you can try:
If you can afford committing your fly.toml inside your repo you could tweak cmd, entrypoint or exec to see if you can do something like app --generate-user admin in case that’s an option for your app.
If you app supports generating users by environment variables use the [env] section on your fly.toml
Create another repo that will contain fly stuff such as fly.toml and add your other repo as a submodule (or just paste it inside there) and make sure whatever you do for build like Dockerfiles not that path. This would make it possible for you to have code specific for your demo
Deploy with your base sqlite DB with all mocked data. That sounds bonkers but since you’re mounting this to root and this will be resetted each restart it could be very interesting.
Awesome, thank you for the help @lubien! I’ll try a couple things and report back here what worked best, just in case someone else comes here with similar questions
. I don’t yet know if that’s something I want for the real thing, and I’d prefer to keep the production and “demo” codebases the same.
