Agents · Updated 10 November 2026 · 9 min read

How to take a vibe-coded app to production safely in 2026

A launch checklist for apps written by an AI agent: keys, database access rules, dependencies, payments, email limits, backups, logs and a way back when a deploy breaks.

View as Markdown

An app that works in the preview isn't ready for strangers until you've checked the parts an AI agent tends to get wrong: secret keys that reach the browser, database tables anyone can read, outdated packages and unsigned payment webhooks. Fix those first, then add the things a prototype never needs: backups you've restored once, logs you can read, a spending limit and a way to roll back. The host matters less than the checklist, though it should give you secrets, logs and rollbacks out of the box.

If you still need to pick where the app runs, where to host apps built with AI coding tools compares the options. This page is about what to do before you send the link to real users.

The launch checklist at a glance

Area	What often goes wrong in generated code	What to do before launch
Secret keys	A private key sits in a `VITE_` or `NEXT_PUBLIC_` variable and ships to every visitor	Move it to server code and the host's secret store, then rotate it
Database access	Tables without row-level security, or policies that let everyone through	Turn RLS on for every exposed table and test allow and deny per role
Dependencies	Packages with known vulnerabilities	Run `npm audit` and turn on Dependabot alerts
Payments	Webhooks accepted without checking who sent them	Verify the Stripe signature on the raw request body
Sign-up email	The built-in mail sender allows 2 auth emails an hour	Connect your own SMTP provider
Backups	Nobody has tried a restore	Take a backup, restore it somewhere else, write down the steps
Deploys	A bad push takes the site down with no way back	Use a host that keeps earlier deployments and can switch back
Costs	A traffic spike or a loop turns into a large bill	Know what happens at your plan's limit before you launch

Why AI-written apps need their own pass

The OWASP Top 10 for 2025 puts broken access control first, followed by security misconfiguration and software supply chain failures. Those three map closely to what an agent produces when you ask for features and never ask for rules: screens that show the right data to the right person in the demo, but a database that would hand any row to anyone who calls it directly.

Some builders now help. Lovable runs a Quick scan automatically each time you publish, covering tables without row-level security, access rules that let everyone through, known vulnerabilities in npm packages and MCP servers exposed without authentication. Its Deep scan reads the whole codebase for logic and permission problems. Lovable says the scans can't guarantee complete security and suggests a professional review for apps that handle sensitive data. The Quick scan also belongs to Lovable's publish step, so it doesn't run when another host deploys your code.

1. Get secret keys out of the browser

Frameworks decide what reaches the browser by the variable name. Vite exposes every variable starting with VITE_ in client code after bundling and warns not to put sensitive values there. Next.js does the same with NEXT_PUBLIC_: anything else stays on the server. An agent asked to make a feature work can rename a key with one of those prefixes just to clear an error.

Search the repository and the built files for every VITE_, NEXT_PUBLIC_ and PUBLIC_ name and ask of each one whether a stranger may see it.
Move private keys, such as a Stripe secret key or a Supabase secret key, into server code and the host's secret store.
Rotate any key that was ever public or committed. Deleting it from the code doesn't remove it from Git history.
On GitHub, secret scanning runs for free on public repositories and checks every branch and the full history. Push protection for your user account is on by default and stops pushes of secrets to public repositories.

The article on environment variables and secrets explains build-time versus runtime values in more depth.

2. Lock down the database

If your app talks to Supabase from the browser, its row-level security policies are your access control. Supabase's own guidance is direct: a table in an exposed schema without RLS can be read and written by any role that has a grant on it, so enable RLS on every such table. Adding policies doesn't remove default grants, so revoke the ones the app doesn't need.

Write one policy per operation: select, insert, update and delete.
Test both sides. Supabase suggests SQL tests that check what anon and authenticated may and may not do.
Keep the secret key, which bypasses RLS, in server code only.
Add indexes for the queries the app runs most, and run a load test, preferably on a staging copy, before a big launch, as Supabase's production checklist recommends.

3. Update and audit dependencies

Generated projects pull in many packages, sometimes at versions that are no longer current. npm audit asks your registry for known vulnerabilities in the project's dependencies, and npm audit fix installs patched versions where the version range allows; fixes that need a major upgrade require --force, so review those by hand. Dependabot alerts on GitHub watch the default branch and tell you when a new advisory affects a package you use, with the fixed version when one exists.

4. Payments and email

If the app takes payments, check that the webhook handler verifies the Stripe-Signature header with the endpoint's signing secret before trusting the event. Stripe needs the raw request body for that check, and code that parses the body as JSON first makes verification fail. Answer with a 2xx quickly and do slow work afterwards.

Email is the other quiet launch blocker. With Supabase's built-in sender, the endpoints that send sign-up and password-reset email are limited to 2 emails per hour across the project. Connect your own SMTP provider before launch; even then the default for auth emails is 30 new users per hour, which you can raise in the project's rate limit settings.

5. Backups, logs and a way back

Backups. Supabase doesn't offer backup downloads on its Free plan, and Free projects with low activity over 7 days may be paused. Upgrade or keep your own export, and restore it once into a fresh project so you know it works. Backups and the right to erasure covers how long to keep them.
Logs and alerts. Make sure server errors land somewhere you read, and add an uptime check from outside, see EU uptime monitoring and error tracking in Europe.
Rollbacks. Pick a host that keeps earlier deployments, so you can undo a broken push from the dashboard instead of debugging it at night. Zero-downtime deploys and rollbacks explains the mechanics.
Spending. Read what your host does when traffic or usage passes the plan. Hosting with spend caps compares the approaches.

6. Personal data

If people sign up, you hold personal data. Know which companies process it, sign their data processing agreements and list them in your privacy notice. For the full list of steps, read the GDPR hosting checklist.

Where Eurobase fits

Eurobase is a host for the deploy and run part of this list, not a security scanner. It builds your repository and runs it on European infrastructure run by Scaleway, a French provider; the company is registered in Warsaw, Poland. Every value you save as a variable or secret is stored encrypted, and a secret can't be read back after you save it. The Logs page keeps deployment, request, container, function and Worker logs for up to 30 days, and a rollback serves an earlier successful deployment again without rebuilding. If you keep working with an agent, it can deploy through the Eurobase MCP server or CLI, while secret values stay in the dashboard and never pass through the agent.

Best for: an AI-built app already in Git that should run in Europe at a fixed monthly price.
Price: a Free plan, then Starter at €10 and Pro at €20 a month + VAT. There are no usage charges today: work over a limit is refused, apps on V8 isolates and Functions stop until the monthly reset, and containers and static sites keep serving.
What it lacks: preview deployments, Dockerfile builds and a managed Postgres, MySQL or Redis, so your data stays with a database provider such as Supabase. ISO 27001 and SOC 2 certifications are being worked on, not yet held.

Setup: getting started, secrets, rollbacks, Eurobase + Supabase and AI agents.

Frequently asked questions

Is a vibe-coded app safe to launch?

It can be, once someone has checked it. The code an agent writes isn't less safe by nature, but nobody asked it for access rules, key handling or abuse limits, so those are usually missing. Go through the checklist above, and get a professional review if the app handles payments, health data or other sensitive records.

What's the most common security hole in AI-generated apps?

Broken access control, which OWASP ranks first among web app risks in its 2025 list. In apps backed by Supabase it usually shows up as a table without row-level security or a policy that allows every request. Check next for a private key exposed through a VITE_ or NEXT_PUBLIC_ variable.

Do I need to rewrite the app before production?

Usually not. Most fixes are configuration and small changes: moving keys to the server, adding RLS policies, verifying webhooks and updating packages. Rewrite only the parts a review shows you can't secure.

Do I need a staging environment?

It helps. A second database and a second deployment let you test migrations and sign-up flows without touching real users. If your host has no preview deployments, a separate project on a branch does the same job.

Can I keep using the AI agent after launch?

Yes, but keep it away from production secrets and review what it changes. Approve deploys yourself, and keep rollbacks within reach.