Where to host a web app? The question comes up as soon as the app leaves the tool that built it, or as soon as its bill starts to climb. Six kinds of hosting answer it, and each one hands you a different share of the work. This guide compares them on concrete criteria, then gives the answer that fits each situation.
By Simon Vasconcelos Lee
Published on 3 November 20268 minute read
A web app is code that answers requests, a database that keeps its state, and often background jobs. Each kind of hosting takes care of part of that.
lovable.app address, with a built-in backend (database, user sign-in, files), Bolt on a bolt.host address, Replit with four deployment types.The first table shows what stays on your plate, the second what you pay and where your data lives (prices and documentation published in October 2026).
| Kind | What you manage | Database | Background jobs, long-running processes |
|---|---|---|---|
| AI app builders | The app, within the tool | Built in (Lovable) or connected, such as Supabase | Depends on the tool (reserved VM and scheduled deployments at Replit) |
| Deployment platforms | The code and its configuration | At a third-party provider (Neon, Supabase, Upstash through the Vercel Marketplace) | Time-limited functions: at Vercel, 300 s by default, 800 s on Pro (1,800 s in beta); long-running processes in beta |
| PaaS | The code, the services, their size | Offered by the platform, billed separately | Workers and scheduled jobs, declared as services |
| Cloud | The whole architecture: network, machines, access | A managed service or a database on a machine | Anything, by assembling services |
| Unmanaged VPS | The server: system, security, backups, monitoring | On the server, tuned and backed up by you | As many as memory allows |
| Managed VPS | Your code; the host runs the server | On the server, backed up by the host | As many as memory allows, monitored by the host |
| Kind | Bill | Where the data lives | Portability |
|---|---|---|---|
| AI app builders | Subscription; at Lovable, the built-in backend consumes credits | With the platform and its providers | Code synced with GitHub (Lovable); the built-in backend migrates separately |
| Deployment platforms | Subscription, then usage: on Vercel Pro, USD 20 a month per deploying member, with USD 20 of usage included | Functions in one region (iad1 by default at Vercel), the database with its provider | Standard code; platform-specific services get replaced |
| PaaS | By resource: at Railway, USD 20 per vCPU and USD 10 per GB of memory, per month | One region of your choice (five at Render) | Simple with a Dockerfile |
| Cloud | Service by service; at AWS, outbound transfer billed beyond 100 GB free per month | The region of your choice | Depends on the services used |
| Unmanaged VPS | One price per size; transfer sometimes billed beyond an included volume (USD 0.01 per GiB at DigitalOcean) | The server’s data centre | Complete: standard software, root access |
| Managed VPS | One monthly price per size, operations included | The server’s data centre; backups kept off the machine | Complete: your code and your data remain yours |
On a platform billed by usage, the price of a month depends on what the app did that month. At Vercel, once the included credit is used up, function CPU time, function memory, page regenerations and image transformations are billed per unit; at Fly.io, machines are billed by the second. Ideal for starting small, this model calls for an eye on the dashboard as the app grows. On a VPS, a traffic spike uses the server’s resources and the bill stays the same: the question becomes choosing a size that handles your peaks, with headroom.
Job queue workers, sync bots, real-time connections, scheduled tasks: many apps have this second life. Deployment platforms are built around time-limited functions, and Vercel offers long-running processes in beta (Vercel Daemons). PaaS providers declare them as separate services, a background worker or a cron job at Render. On a server, they are processes like any other, started and restarted by the system.
At Vercel, functions run by default in the iad1 region (Washington, D.C.), and the documentation recommends placing the database in the same region: every round trip to a distant database is paid for in latency. On a VPS, the app and its database share the same machine, in an identified data centre, which business customers and contracts governing personal data often require.
| Your situation | The hosting that fits |
|---|---|
| A prototype, a demo, an idea to test | The builder’s own hosting, or a platform’s free plan (at Vercel, the Hobby plan is reserved for personal, non-commercial use) |
| An app with its first users | A managed VPS; a PaaS if your team builds and deploys on its own |
| A business application: customer data, a team that relies on it | A managed VPS: data in an identified location, backups, monitoring with intervention |
| The developer has left, or the app was built with AI | A managed VPS, with takeover and migration of the existing setup |
| A technical team that wants to stay in control | A VPS, with assistance for questions outside the day-to-day |
| A mostly static site, with highly variable global traffic | A deployment platform and its distribution network |
As long as the app is there to show an idea, the tool that built it publishes it in one click. Choosing hosting comes with the first users: data to protect, a bill to plan for.
As soon as the app has users and nobody on the team is meant to administer a server, the answer is a Managed VPS: the app runs on a server reserved for it, with its database, its background jobs and its resources, and the host runs that server for you. Proactive management also follows the app itself (errors, slowdowns, expensive queries, disk space) and recommends the fix, which you apply, yourself or through your AI assistant. Has the developer left? It takes over the existing setup as it is, migration included.
A team that does its own administration gets the most from a server it keeps control of: Simafri’s VPS Pro includes Full-Stack Assistance, a diagnosis that runs from the operating system down to the application code.
Today’s choice can be revisited tomorrow, as long as the app stays portable:
Next.js is a good example: its documentation states that a Node.js server started with next build then next start supports all of its features, on any host that runs Node.js.
With a Simafri Managed VPS, your app runs on an Intel Xeon server with ECC memory and mirrored NVMe SSDs, operated by our experts: updates, 24/7 monitoring with intervention before you even call, encrypted backups every night and restores included. We proactively monitor your app and recommend what will make it faster and more secure, before a problem ever surfaces. Migration is free, and we help you put online an app built with Lovable, Bolt, Cursor or another assistant.
For a demo, the tool’s own hosting is enough. Once the app has users, sync its code with GitHub and run it on a server reserved for it: a managed VPS takes care of that, from going live to monitoring, and the tool remains your workshop for building what comes next.
A PaaS runs your services in its containers and bills the resources they use. A VPS is a server of your own, with root access, at a price set by its size: you administer it, or you hand its operation to the host with a managed VPS.
On a platform, count the subscription, then usage: compute, memory, data transfer, team members. On a VPS, the price is that of a server size, known in advance. To compare, start from three months of real traffic and add the time your team spends on hosting.
Yes, and all the more easily when the code is in git, the configuration in environment variables and the database in a standard format. The switchover happens without downtime: copy, test, lower the TTL, then change the DNS records.
Simafri
Let's talk about your project
Tell us what you need in a few words: we will get back to you quickly.
Thank you! Your request has been sent. We'll get back to you shortly.
Prefer email? Write to us at support@simafri.com.