Vibe-coded apps have a characteristic that's worth understanding before anything goes live.

AI coding tools are optimised to make things work. They respond to prompts with code that satisfies the request — correctly, usually, for the specific scenario described. What they're not optimised for is the scenarios you didn't describe: edge cases, unexpected inputs, concurrent users, security attack patterns, and the thousand ways real users interact with software that no prompt anticipated.

This doesn't mean your app is broken. It means it's been tested for the happy path — the sequence of actions you intended — and not much else. Deploying it means exposing it to everything outside that path.

That's fine if you're deploying for personal use, a small group of trusted users, or a tightly controlled pilot. It's worth thinking harder about if real users, real data, or real money are involved.

For most vibe-coded web apps, the realistic options are:

Vercel — the simplest deployment experience for Next.js, React, and frontend-heavy apps. Connect your GitHub repository, configure environment variables, press deploy. If your app was built with a frontend framework and uses serverless API routes, Vercel is the path of least resistance.

Railway — handles full-stack apps with separate frontend, backend, and database services more naturally than Vercel. If your app has a Node.js or Python backend running separately from the frontend, Railway is where most vibe-coded apps with a real backend end up.

Render — similar territory to Railway, with a slightly different developer experience. Worth comparing on your specific stack.

Fly.io — for containerised apps with a Dockerfile. More configuration required, more control in exchange.

For most vibe-coded apps at the prototype or early-product stage, Vercel or Railway is the right answer. Both have free tiers for personal projects and modest paid plans for anything production-facing.

This is the part worth slowing down for.

‍

Environment variables and secrets

This is the most urgent thing to check, and the most commonly missed.

During development, AI tools frequently embed configuration values — API keys, database connection strings, authentication secrets — directly in the code or in a local .env file. In development, this is fine. In a public repository or a deployed environment without proper secrets management, it's a meaningful security problem.

Before deployment: search the codebase for anything that looks like a credential. Database URLs, API keys for Stripe, SendGrid, Twilio, or any other service, authentication secret keys, OAuth credentials. Move every one of them to environment variables on your deployment platform — Vercel, Railway, and Render all provide a UI for this — and ensure they're not committed to your repository.

If credentials have already been committed to a public repository: rotate them. Assume they've been seen.

What a developer would tell you: secrets that have been exposed even briefly should be treated as compromised. The automated scanners that hunt for exposed credentials in public repositories are fast, thorough, and not selective about whose repository they find.

Authentication and user data

If your app has user accounts — login, registration, sessions — the AI-generated authentication implementation deserves specific attention.

Common issues in vibe-coded authentication: session secrets set to obvious default values, passwords stored without proper hashing, cookies without the secure flag that restricts them to HTTPS connections, missing rate limiting on login endpoints that makes brute-force attacks straightforward.

None of these require deep security expertise to check. Search for where user passwords are handled and verify that something like bcrypt or argon2 is involved. Check that your session secret is a long, random string stored as an environment variable, not a placeholder from the development phase. These are ten-minute checks that prevent the most common authentication vulnerabilities.

What a developer would tell you: authentication is the part of an application where implementation quality matters most and where AI tools most frequently produce code that works in normal use but has weaknesses that only appear under deliberate attack.

Database configuration

Your development database runs on your local machine. That database does not exist anywhere a deployed server can reach.

You need a hosted database. Supabase for PostgreSQL, PlanetScale or Railway's built-in MySQL, MongoDB Atlas — the options are well-documented and mostly accessible with free tiers. The process: create the hosted database, run your migrations to create the schema, update your connection string environment variable, and verify the connection from the deployed app.

Do not copy your local data to production without understanding what you're doing. If you have test data locally and you're starting clean in production, you only need the schema, not the data.

What the AI didn't know about production

This one is subtle.

AI coding tools generate code for the scenario they're given. Production environments have characteristics that development environments don't: real traffic, concurrent users, database connections that need to be pooled rather than opened fresh for every request, memory limits, and error conditions that only appear under load.

A vibe-coded app that runs perfectly when one person is testing it can behave unexpectedly when twenty people use it simultaneously. Not catastrophically — but in ways that are worth knowing about before users encounter them rather than after.

What a developer would tell you: a brief load test before public launch — even running a simple script that simulates a handful of concurrent users — will surface the most obvious production-readiness issues before users become your test environment.

With the pre-deployment checklist done:

1. Get the code into a repository. GitHub is the standard. Vercel, Railway, and Render all connect to it directly.

2. Set up your hosting platform. Create an account, start a new project, connect the repository.

3. Configure environment variables. Every secret identified above goes here. Every platform has a section for this in their project settings.

4. Set up your database. Create the hosted database, run migrations, update the connection string in your environment variables.

5. Deploy. The first deployment will produce build logs. Read them when something fails — they are usually specific about the cause. Most first-deployment failures are missing environment variables or database connection issues.

6. Set up your domain. Add a custom domain in the platform settings. SSL is handled automatically by all major platforms.

7. Soft launch before public launch. Share the URL with a small group first. Watch what they do. Fix what breaks. Then open it up.

Once live, the app will occasionally have problems. The question is whether you find out from users or from your own monitoring.

Error tracking: Sentry has a generous free tier and integrates with most frameworks in minutes. It catches runtime errors, records what the user was doing when it happened, and notifies you. For anything with real users, this is worth the fifteen minutes to set up.

Uptime monitoring: UptimeRobot pings your app every five minutes and notifies you if it stops responding. Free, five minutes to configure, and means you find out about downtime before users email you about it.

Here's the thing a developer would ask you before you deploy:

Who is going to use this, and what are they trusting it with?

If the answer is "just me, for personal use, no sensitive data" — deploy it. The deployment steps above are sufficient. The security considerations are worth knowing but don't represent urgent risk at that scale.

If the answer is "real users, real personal data, possibly payment information, people who will trust this app with something that matters to them" — then the conversation is different. The conversation is now about fixing vibe code.

Not because deployment is impossible. It isn't. But because the gap between "works in development" and "safe and reliable in production for real users" is real, and in a vibe-coded codebase that gap is wider than it would be in a professionally built one. The security issues that AI tools routinely introduce — the ones listed above and others — are not hypothetical problems. They're consistent, documented findings in AI-generated code that security reviews catch and address.

The choice isn't binary. You can deploy, gather early users, validate the idea, and invest in a proper code review and remediation alongside that process rather than before it. Many vibe-coded products follow exactly this path — launch fast, then make it solid — and it's a legitimate approach if the risk profile matches.

What's worth avoiding is deploying something to real users with real data without being aware that the codebase may have vulnerabilities, and assuming that because the AI built it correctly in the functional sense, it built it correctly in the security sense too. Those are different things, and only one of them was in the prompt.

If you've deployed your vibe-coded app and you want a developer's honest assessment of what it looks like under the surface — what the security posture is, what needs attention before growth, and what a properly built version of it would look like — that's exactly the kind of conversation we have.

‍

Octogle Technologies reviews, remediates, and properly deploys vibe-coded applications — so what you built fast can also be trusted. Tell us what you've built and we'll tell you what it needs.