Hosting for vibe coding 2026

AI tools build a working app in minutes – the question is where it runs permanently afterwards. Free plans are enough for prototypes. As soon as real users come along, one thing above all decides: usage-based billing with a spending cap or a fixed server price.

Prices: entry-level plans according to the providers' websites, as of 30 October 2026. Euro prices incl. VAT except Hetzner (net), dollar prices excl. VAT. Usage-based plans can be considerably higher depending on traffic.

Apps built with Lovable, Bolt, v0, Replit, Cursor or Claude Code have a few recurring quirks. They are almost always based on Next.js, Vite or React, access Supabase or Postgres and contain API keys that can accidentally end up in the frontend.

Then there is the typical usage pattern: lots of prototypes, most of which never see any traffic, and occasionally one that suddenly goes viral. Hosting that costs nothing at zero traffic and grows automatically under load fits this better than a fixed server plan – as long as you set the spending limit.

Usage-based platforms bill by CPU seconds, bandwidth and function invocations. An infinite loop in the generated code or a bot calling an API route millions of times can turn €0 into a three-figure bill overnight.

So before the first deploy: activate the spending limit in the provider dashboard (Vercel "Spend Management", Railway "Usage Limits", Render "Spending Limits"), set up a notification at 50% and build in rate limiting for public API routes. If you don't want that, you will have a calmer time with a fixed-price VPS – there the bill is predictable; at worst the site is simply slow.

PaaS (Vercel, Netlify, Railway, Render): connect the repository, done. No server knowledge needed, HTTPS and domain set up automatically, rollback in one click. The right choice for your first projects and anything that needs to go online quickly.

VPS (Hetzner, IONOS, Vultr) with Coolify or Dokploy: one server for around €5 to €6/month on which any number of apps can run. Coolify is a free, self-hosted interface that handles Git deploys, TLS certificates and databases almost as conveniently as Vercel. From the third or fourth long-running project, this saves a considerable amount of money.

In practice it often ends up as a mix: prototypes on the free PaaS plan, projects with real users on your own server.

• Check API keys – keys belong in server environment variables, never in code with the NEXT_PUBLIC_ prefix or in the frontend bundle.
• Enable Row Level Security – with Supabase, RLS is the only real access control. Without it, anyone with the public key can read the entire table.
• Private repository – generated code surprisingly often still contains sample credentials.
• Rate limiting – every public API route needs a limit, otherwise you pay for other people's traffic.
• Validate input – AI code often only checks user input in the frontend. Add server-side validation.
• Update dependencies – generated package.json files frequently contain outdated versions.
• Legal notice & privacy policy – as soon as the app is publicly accessible, the usual obligations apply in Germany.

A thought experiment with freely chosen figures, not a provider's price list: a small app runs on the free plan of a platform with usage-based billing. Over a weekend a bot calls an unprotected API route a million times. If each call is charged a fraction of a cent, that adds up to double-digit or triple-digit amounts that go unnoticed without a spending limit.

By comparison, a VPS at a fixed price of around €5 to €6 a month: the cost is fixed for the year even if a bot generates load. The site then gets slower or goes down, but the bill stays the same. For projects with real business risk you should safeguard against both, because rate limiting and a spending limit at the provider belong together.

AI-generated apps, too, are best taken through a fixed sequence that makes errors visible early. The first time it takes a few hours, and afterwards only minutes.

• Export the code to a private Git repository and remove example credentials.
• Create environment variables at the host and never store them in the code.
• Deploy a preview version and test it with real input.
• Connect your own domain and check HTTPS.
• Set up a spending limit, notifications and monitoring.
• Enable database backups and restore one as a test.

Take your time over the last two steps. A backup that has never been tested only becomes a backup once you have restored it successfully. When moving from a platform plan to your own server, this sequence stays the same; only the deployment tool changes.

As soon as your app is publicly accessible and not purely private, the usual obligations apply: a legal notice (Impressum) under section 5 DDG and a privacy policy that describes exactly which services process data. These include hosts, database providers such as Supabase, analytics tools and the AI interface if user input is sent to it. With each of these service providers you need a data processing agreement under Art. 28 GDPR.

If you build a chatbot or other AI features for end users, the EU AI Act (Regulation (EU) 2024/1689) provides for transparency obligations: users should be able to recognise that they are talking to an AI system. Also check the AI provider's terms of use to see whether you may use outputs in commercial products, and keep records of this.