What could you put online with Fly.io?
Fly.io can run the code for a web app, such as a booking page that needs to check open times and save requests. It runs that code on a virtual computer called a Fly Machine.
You supply the app and its start instructions. A website address gives visitors a way in. Saving bookings still requires a place to keep the records, such as a database.
How do you get one page to load?
Start with a working copy of your app, a Fly.io account and its command-line tool. A terminal is the window where you type these commands.
- Choose a disposable project and check that it connects only to test services. Review the planned location, Machine size and optional services. Use fly launch --no-deploy if you want to inspect the app setup before deploying it.
- Check the generated start and build settings. A build prepares your code to run. For supported projects, Fly Launch can prepare the file that tells it how to build the app. Check which connection point the app listens on so Fly.io can route visitors to it.
- Deploy with fly deploy and open the address Fly.io shows for the web app. Start by checking that one intended page loads.
How do you try a change away from the live app?
Use a separate staging app for regular testing, or set up Fly.io’s GitHub review-app workflow to create temporary versions for code changes. Fly.io also documents putting staging and production in separate organizations for an extra network boundary.
Before running an automatic preview or sharing its address, check which people can reach it and where it sends its data. Use a test database, test sign-in and a test inbox if your app uses those services. Confirm that one made-up booking goes into the test records.
Apps in the same Fly.io organization generally share a private network. Network access and which customer can read a particular booking are separate checks.
Can you try it without keeping a paid app running?
The current trial gives a new account US$1 in usage credit for seven days or until the credit runs out. It starts without a card, and trial Machines stop after five minutes of running.
When the trial credit runs out or expires, you need to add a card to restart Machines or create resources. Fly.io may remove trial resources. Use disposable records or take a separate copy before relying on that trial for a demo.
What makes a Fly.io bill grow?
New organizations pay for the resources they use. A running Machine is billed by the second based on its processing power, temporary working memory and location. Check the number of Machines as well as the size.
| What you use | Published unit and example |
|---|---|
| A running web Machine | One shared Machine with 1 GB of memory in Ashburn, Virginia is US$6.70 for 30 days continuously on. Other regions and sizes can differ. |
| A stopped Machine | US$0.15 per GB for 30 days for the disk that holds its installed files. |
| Attached storage and backups | Volumes cost US$0.15 per GB of reserved space per month. Snapshots, which are saved copies, cost US$0.08 per GB-month of stored snapshot data after the first 10 GB each month. |
| Data sent out | US$0.02 per GB sent to the public internet from North America or Europe. Other regions and private traffic between regions have their own rates. |
| Managed Postgres | The separate Basic database plan is US$38 per month. Current clusters add US$0.28 per GB used for a 30-day month, measured hourly. Older v1 clusters charge for reserved database space. |
Where should bookings and uploaded files stay?
A Machine’s ordinary disk is temporary. Choose a separate database for structured records or an attached Fly Volume when your app needs files on disk to survive a restart.
A volume stays on one server and attaches to one Machine. Fly.io does not automatically copy its contents to other volumes. Fly.io takes daily volume snapshots by default, but advises keeping a separate backup for important data.
Fly.io Managed Postgres is an optional service for database records. It includes automated backups and can switch to a working copy if one fails. It stays on the organization’s private network. You still decide which users can see or change their records.
How can you undo a bad release or move the app?
Check that the earlier code can work with your current records and settings before switching back. Fly.io can redeploy an earlier retained package of your app. That operation uses the current settings and leaves saved data in place.
Keep your app code and build recipe in your own repository, the saved project where you track code changes. Keep a copy of the exact working app package if you need a long-lived recovery option. Fly.io may remove old packages from its storage.
Plan data recovery separately. For PostgreSQL, make a database export and try restoring it to a compatible database before moving. Keep uploaded files separately and recreate private settings, connections and the public address at the new host.
What if a report should finish after the visitor leaves?
Fly.io can run the web app and a separate worker in the same project. The worker is a program that handles tasks without taking a visitor’s web request.
For example, the web page can accept a request for a large export and a worker can prepare it later. Check how the worker starts, what happens if a task fails and which Machines run while the website is quiet. Include the worker’s running time in your estimate.