Where should your app live?
Keep your current host if someone can use the published app and come back to the result. If the app only opens on your laptop, look for a host that can run the work behind the page. You can make that choice before you buy a domain.
Do you already have a place to publish?
In your app builder, look for the published address rather than the link you use to edit. Lovable and Bolt can both publish from inside the builder. Ask what your current plan can run and where it saves information before you pay for another service.
The address and the app version are separate decisions. You can first use the address your host gives you. A domain, such as example.com, is a name you can point at that host later. A deployment is a prepared version of your app placed on the host. Buying a domain does not deploy the app.
What does the host have to run?
A menu site can often serve files that were prepared ahead of time. A booking app needs code to run after someone picks a time. That code checks availability, saves the booking and tells the person what happened. It can run on the host or in a service the app calls.
Ask whoever builds the app to show you the framework, such as Next.js, and name the parts that run away from the visitor’s browser. The runtime is the environment that runs that code. Check that the host supports the features and packages those parts use. A working homepage on your laptop answers a different question from whether the booking can be saved on the host.
Compare tools
Scroll the table sideways to read every column.
| Tool | What runs hereThe kind of app code the host can run in addition to serving pages. | How to try a changeWhat a separate app version gives you and what you still need to isolate. | What you pay forThe main unit to watch as people use the app. | Where data livesWhat keeps records and files between releases. |
|---|---|---|---|---|
| Cloudflare | Workers serves prepared files and runs compatible code when a request needs it. Check your framework’s Workers setup. | A Workers Preview can use its own settings. A Version URL uses the selected version’s existing connections. Confirm the actual database and file store before trying a write. | Requests to Workers and the time code spends computing. Storage products have their own meters. | D1 can hold records, R2 can hold files, or you can connect a compatible service. A code rollback leaves the stored information in place. |
| Vercel | A documented path for Next.js and other supported frameworks, including code that runs when a visitor submits a request. | The first deployment of a new project uses Production settings, even if a preview was requested. Later Preview deployments can use their own test settings. | Plan and deploying team members, then usage such as app-code calls, active computing time and memory. Hobby is personal and non-commercial. | Blob can hold uploads and a compatible database can hold records. Restoring the app version does not restore either store. |
| Netlify | Serves prepared files and can run app functions. Use the setup guide for the framework your app already uses. | A Deploy Preview gets its own address. Netlify Database can give it a copy of live records, while site-wide Blobs stores remain shared. | Credit plans draw live releases, computing work, data transfer and web requests from a shared balance. | Use a database for records and Blobs or a compatible file service for files. Check whether your files belong to the whole site or one deployment. |
| Render | Choose a Static Site for prepared files or a Web Service for an app that starts its own server. Free Web Services can sleep between visits. | A Pro workspace or higher can create a preview environment from a Blueprint, a description of the app’s services. Preview databases and disks start without the original data. | Workspace plan and each running service are separate. Compute size and time running matter, as does outbound data. | Use a database or file service, or an eligible paid disk. Ordinary service files are temporary. Free Postgres expires after 30 days. |
| Fly.io | Run a web process and separate background work on virtual computers called Machines. Choose their size and where they run. | Use a separate staging app or a temporary GitHub review app. Apps in the same Fly.io organization share a private network by default. | Machine size, location and seconds running. A stopped Machine can still cost for its disk. Volumes, snapshots and outgoing data have separate charges. | A volume lives on one server and attaches to one Machine at a time. Keep a separate backup. The optional managed Postgres service has its own backups. |
| Heroku | Run your app in a dyno, a place for one part of the app to run. A web dyno handles visits and a worker can prepare a report later. | Review Apps use GitHub and a group of apps called a pipeline. Check test services before creating a review app by hand or automatically. | Eco shares hours across a personal account. After 30 minutes without visits its web dyno and associated Eco worker sleep. Basic bills for enabled time. Added services are separate. | Files written inside a dyno disappear when it stops or restarts. Keep records in a database and uploads in lasting storage. Check which recovery and export options your database plan supports. |
| Railway | Run a website, database and background work as separate services in one project. Give the website its own public address. | A manual copy of an environment waits for review before deploying. Automatic GitHub previews can start when you open a change. Check the test connections before either path runs. | On paid plans for ordinary app services, the fee counts toward measured usage. Processor use, working memory, volume storage and outgoing transfer use separate units. | The Postgres template starts with one database server. You choose when to enable backups and a standby copy. A volume backup restores in the same project and environment. |
What should work before you share the address?
Start with one complete task on the address you plan to share. Before making a test booking, confirm that the app uses a test calendar and test records and that confirmation messages can only go to a destination you control. If you cannot verify those connections, stop and arrange an isolated test copy first.
- Open the actual addressGo straight to the booking page from a fresh browser window. Check that the address shows the version you meant to share. Keep service credentials in the host’s private settings, away from the code sent to the visitor’s browser.
- Save a booking and find it againBook a time using a test account. Refresh and find the same booking. Switch to a second test account. Try to open or change the first booking through the app, including pasting its exact page address. Switch back and check that the saved booking is unchanged.
- Try an unavailable timeChoose a slot you know is taken. Check that the page helps the person choose another time and that the calendar still shows the original booking only. Run the successful and unavailable paths on a phone-sized screen too.
- Follow a sign-in link if you use oneRequest a link for a test account using the inbox you control. Open it and make sure it returns you to the intended address and signs in the right account.
How do you try a change without touching live data?
A preview is a version you can open separately from the live app. Before you build it or try a task that writes anything, check where it will get records, put files, send email and take payments. A separate address can still use live connections.
Check access as well as data. Before sharing a preview meant for a few people, open it in a signed-out browser. If you can see it, someone with the link may be able to see it too. If a preview starts with a copy of live records, use an access-restricted setup or put disposable examples in a separate store instead.
If a release breaks the app, a rollback sends visitors back to an earlier app version. First check that the older version can still read any records the release changed. Switching versions usually leaves those records and files in place. Keep a recoverable copy before changing stored data and check whether automatic publishing will replace the version you restore.
What should you budget before inviting users?
Price the work the app will do. One booking can load a page, call the app’s code, write a database record and send an email. The host may charge for some of those steps and separate services may charge for the rest.
Write down the host’s base price, the unit it charges for and the service that holds the data. Then check what happens at the limit. Cloudflare Workers has a daily request allowance on Free. Netlify credit plans can pause a whole team’s web projects if one project exhausts the balance. On Render, changing the workspace plan does not change the plan for each running service.
Check whether the plan permits what you are building. Vercel Hobby is for personal, non-commercial work. A spending email and an automatic pause do different things. Vercel’s optional pause can arrive after the threshold and retained storage can still incur charges. The individual profiles give the current units and plan boundaries.
When does a bigger job change the hosting choice?
If an ordinary page works but generating a report takes a long time, check where the report runs. It may need its own background task so a visitor can leave the page and return when the file is ready.
Ask for the limits on time, working memory and upload size for the actual service you intend to use. Decide what the app shows if a task fails halfway through, where it keeps its result and whether a retry could repeat a charge or another action.
If you need to move later, treat the app code, web address, customer records, files and private settings as separate items. Check that the replacement can open a copied record and its uploaded file before pointing your domain at it.