How to vibe code securely in 2026

Vibe coding securely means more than prompting an AI to write safer code. Some of the most overlooked security gaps open up at deployment, and most guides do not cover that layer.

AI tools like Lovable, Bolt, Cursor, and Claude generate working applications from natural language. They optimise for code that runs. Security constraints have to be specified explicitly or enforced at the deployment layer.

The result is that vibe-coded apps frequently reach production with hardcoded API keys, admin database access, no environment separation, and no controls on what executes at runtime. This article covers where those risks live, what controls close them, and how to deploy a vibe-coded app securely using Northflank.

Vibe coding compresses the time between idea and deployment. That compression is valuable, but it also compresses the time available for the security decisions that normally happen between writing code and shipping it.

AI tools generate code that satisfies the prompt. They do not enforce security constraints unless those constraints are explicitly requested. The generated output frequently includes credentials inline, connects to databases with whatever access level is easiest to configure, and assumes a deployment environment that may not exist. The deployment environment provides the security layer that code generators do not enforce by default.

The table below shows where the most common vibe coding security failures occur.

Most guides focus entirely on the code layer. In vibe-coded apps specifically, the deployment layer is where gaps most frequently go unaddressed, and it is the layer that a secure deployment platform can close by default.

Securing a vibe-coded app is not about rewriting everything an AI generates. It is about applying controls at the right layer: secrets management, sandboxed execution, scoped database access, environment isolation, and a basic pre-ship review. The sections below cover each one.

AI tools regularly include API keys, database passwords, and access tokens directly in generated code. This is one of the most common and highest-impact failure modes in vibe-coded apps. When that code is pushed to a repository, those credentials are exposed to anyone with access, and often to public search indexes if the repository is public.

The fix is to apply a few straightforward rules before pushing any generated code:

• Store credentials as environment variables and inject them at runtime rather than writing them into source code
• Never commit a .env file to a repository. Add it to .gitignore from the start
• Use a secrets manager to store and inject credentials centrally, especially across multiple services or teammates

On Northflank, secret groups store credentials centrally and inject them into services at build time or runtime depending on the variable type. Northflank masks secrets in build logs and does not expose them in the platform UI or API responses. When your app connects to a managed database on Northflank, the connection string is injected through the same mechanism. For the full deployment walkthrough, see How to deploy vibe-coded apps.

This is the security layer that almost no vibe coding guide covers in depth. Most guides say "use containers." For apps that execute AI-generated or user-submitted code at runtime, standard container isolation is not sufficient.

Docker containers share the host kernel. A bug or exploit in a containerised workload can affect the host system and other containers running on the same host. For vibe-coded apps that include AI coding assistant features, code interpreter functionality, or any feature that runs user-submitted input as code, this is a practical risk with documented precedent.

MicroVM isolation changes the containment model. Instead of sharing the host kernel, each workload runs inside a lightweight virtual machine with its own kernel. A compromised workload is significantly contained and substantially limits what it can reach on the host or across tenants. The three isolation technologies relevant here are:

• Firecracker: A microVM monitor developed by AWS. Runs workloads inside lightweight VMs with minimal overhead. Used in production by AWS for serverless workloads. See What is AWS Firecracker and Firecracker vs gVisor.
• gVisor: Runs a guest kernel called the Sentry in user space that handles system calls from the application, preventing them from reaching the host kernel directly. Provides strong isolation without a full VM. See What is gVisor.
• Kata Containers: Combines container tooling with VM-level isolation using lightweight VMs. Compatible with Kubernetes. See What are Kata Containers and Kata Containers vs Firecracker vs gVisor.

Northflank uses Kata Containers, Firecracker, and gVisor depending on the workload type, giving vibe-coded apps microVM-level isolation without requiring you to configure any of it. Sandboxes spin up in 1-2 seconds. Both ephemeral and persistent execution are supported: ephemeral sandboxes are short-lived and torn down after execution completes, while persistent sandboxes maintain state between sessions for apps that require it.

For more on sandbox infrastructure for AI-generated code, see How to sandbox AI agents, Best code execution sandbox for AI agents, and How to run AI-generated code.

AI tools default to whatever database access is easiest to configure during code generation, which is typically admin access. An app running with admin credentials can read, write, and delete far more than it requires. A bug in that app carries a much larger potential impact: a read query can expose a full table, a write operation can modify unintended records.

Least-privilege database access means each service connects with only the permissions it requires for its specific function. A read-only reporting tool gets read-only credentials. A service that writes to one table does not get access to every table.

Northflank managed databases (PostgreSQL, MySQL, MongoDB, Redis) provision with scoped credentials that are injected through secret groups. You do not configure this separately; it is how the platform handles database connections by default.

Vibe coding encourages rapid iteration. That speed creates a specific risk: changes tested against a live production database, or updates deployed directly to a URL that real users are hitting. Environment isolation reduces the risk of a bad iteration reaching production.

The minimum required separation is a dev environment and a production environment with no shared state between them. A staging environment between the two gives an additional buffer for testing before anything reaches users.

Preview environments go one step further. Every pull request gets its own isolated copy of the app, spun up and torn down on merge. For vibe coders iterating quickly with a Git-based workflow, this means every change is testable in isolation before it reaches the live URL. If you are not yet using pull requests, environment separation between dev and production still applies regardless of workflow.

See How to auto-create preview environments on every PR, What are ephemeral environments, and Ephemeral sandbox environments.

The four controls above are primarily deployment-layer concerns. This one operates at the code layer and requires manual attention.

AI-generated code should be treated as untrusted until reviewed. A useful prompt pattern for improving the security baseline of generated output is to request it explicitly: "Generate this with input validation, parameterised queries, least-privilege access, secure secret handling, and no hardcoded credentials." The output will not be perfect, but the baseline improves.

Before merging any AI-generated code, a quick review should check whether:

• User input reaches a shell or SQL query without sanitisation
• Any credentials appear inline
• Auth checks exist on protected endpoints
• The dependency list includes packages that cannot be verified

Running static analysis in CI before every deploy adds a consistent check without manual effort on every diff.

Northflank is a full-stack cloud platform for deploying and running services, APIs, databases, workers, and background jobs, with CPU and GPU support. It applies the security controls described in this article by default: secrets management, microVM and sandbox isolation, scoped database credentials, and preview environments, without requiring infrastructure expertise.

The deployment flow below covers how to get a vibe-coded app running securely on Northflank.

1. Push your app to a GitHub repository. If you are using Lovable or Bolt, both sync to GitHub natively. See How to deploy vibe-coded Lovable apps to production for a step-by-step walkthrough.
2. Connect the repository to Northflank. Framework detection handles build configuration for React, Vite, Next.js, and most common stacks.
3. Add credentials to a secret group rather than as inline environment variables. Northflank injects them at build or runtime and masks them in logs and the platform UI.
4. If your app executes AI-generated or user-submitted code at runtime, configure sandbox isolation when creating or editing the service. Northflank provisions a microVM-backed execution environment using Kata Containers, Firecracker, or gVisor depending on the workload.
5. Set up preview environments so every pull request gets an isolated deployment before changes reach production.

The free tier covers two services, one database, and two cron jobs with always-on compute. For teams that need more, CPU costs $0.01667 per vCPU per hour and memory costs $0.00833 per GB per hour. Full pricing is on the Northflank pricing page with a cost calculator.

For a full comparison of deployment platforms for vibe coders, see Best deployment platforms for vibe coders and Best PaaS platforms for AI-generated and vibe-coded apps.

Use this checklist before deploying any vibe-coded app to a live URL.

• No API keys, database passwords, or access tokens appear in source code or committed files
• A .env file is listed in .gitignore and has not been pushed to the repository
• Database connections use scoped credentials with minimum required permissions, not admin accounts
• Environment variables are stored in a secrets manager and injected at runtime
• Dev and production environments are separated with no shared database or state
• If the app handles non-public data, the deployed URL requires authentication before that data is accessible
• Any feature that executes user-submitted or AI-generated code at runtime runs inside a microVM sandbox rather than a standard container.
• A preview environment or isolated staging environment was used to test changes before they reached production
• AI-generated dependencies have been verified: maintainer reputation, recent updates, no known CVEs
• Static analysis has run against the codebase and findings have been reviewed

Vibe coding is as secure as the deployment environment it runs in. AI tools generate code that works but do not enforce security controls by default. The generated output frequently includes hardcoded credentials, admin database access, and no environment isolation. These risks are addressable with the right deployment platform and a basic pre-ship review habit.

Hardcoded credentials are one of the most common and highest-impact risks. AI tools regularly include API keys and database passwords directly in generated code. When that code is pushed to a repository, those credentials are exposed. The second most common failure is deploying to a public URL with no authentication, which exposes internal data to anyone who finds the link. Hardcoded credentials originate as a code-layer oversight but surface as incidents at the deployment layer.

Not every vibe-coded app requires sandbox execution. If your app runs pre-written application logic and does not execute user-submitted or AI-generated code at runtime, standard deployment with environment isolation is sufficient. If your app includes any feature that executes code dynamically, including AI assistant features, code interpreter functionality, or agentic workflows, microVM isolation is strongly recommended. Standard container isolation shares the host kernel and provides weaker containment boundaries for untrusted code execution compared to microVM isolation.

Docker containers share the host kernel. A vulnerability or exploit in a containerised workload can affect the host system and other containers on the same host. A microVM sandbox runs each workload inside a lightweight virtual machine with its own kernel, significantly limiting the blast radius of a compromised workload. For AI-generated code that executes at runtime, microVM isolation is the more appropriate containment model. See Firecracker vs Docker and MicroVM vs gVisor for a detailed comparison.

Store API keys in a secrets manager, not in source code or .env files committed to a repository. On Northflank, secret groups store credentials and inject them into services at runtime without exposing them in build logs or the platform UI.

Yes. The security controls described in this article do not require infrastructure expertise when the deployment platform applies them by default. Northflank handles secrets injection, microVM sandbox isolation, database credential scoping, and environment separation as part of normal deployment. The pre-ship code review and dependency check are the parts that require manual attention, and neither requires a security background: the checklist above covers the most common failure modes for the majority of vibe-coded apps.

• How to deploy vibe-coded apps: Step-by-step walkthrough for taking a vibe-coded app from localhost to a live HTTPS URL on Northflank, including secrets, databases, and CI/CD.
• What is a microVM?: Explainer covering microVM architecture, how Firecracker and Kata Containers work, and when microVM isolation is required.
• How to deploy vibe-coded Lovable apps to production: Specific guide for Lovable apps covering GitHub sync, framework detection, environment variables, and custom domains.
• Kata Containers vs Firecracker vs gVisor: Side-by-side comparison of the three main microVM and container isolation technologies used in sandbox infrastructure.
• Enterprise vibe coding: how to deploy AI-generated apps safely: Covers RBAC, SSO, audit logging, and governance controls for enterprise teams deploying AI-generated apps at scale.
• How to sandbox AI agents: Deep dive into sandbox infrastructure for AI agents and code execution, covering isolation models and platform support.
• Best deployment platforms for vibe coders: Comparison of Northflank, Vercel, Render, Railway, and Fly.io on databases, secrets management, preview environments, and full-stack scope.
• How to auto-create preview environments on every PR: Step-by-step guide to setting up automatic preview environments on Northflank so every pull request gets its own isolated deployment.