How to Connect a Bolt.new
App to a Node.js Backend

The Correct Architecture: Frontend, API, Database, and Auth

The biggest mistake people make with AI-generated apps is treating the frontend as the whole product. A frontend is only the interface. A production app also needs a backend that decides what users are allowed to do, where data is stored, how payments or emails are triggered, and how errors are handled.

A clean Bolt.new-to-Node.js architecture usually looks like this:

• Bolt.new frontend: React, Vite, Next.js, or another JavaScript UI generated or edited inside Bolt.
• Node.js backend: Express or another Node framework that exposes REST APIs or GraphQL endpoints.
• Database: PostgreSQL, MongoDB, Supabase, Neon, PlanetScale, or another managed database depending on the app.
• Authentication: JWT, session cookies, OAuth, Supabase Auth, Clerk, Auth.js, or another identity layer.
• Deployment: Frontend on Vercel, Netlify, or Cloudflare Pages; backend on Render, Railway, Fly.io, AWS, DigitalOcean, or a VPS.

This separation helps you avoid spaghetti code. Your Bolt.new frontend should handle views, forms, and user interactions. Your Node.js backend should handle business logic, authorization, validation, database access, secrets, background jobs, and integration with third-party services.

Step 1: Create a Node.js Backend for Your Bolt.new App

Start by creating a separate backend folder. Keeping the backend separate makes deployment, environment variables, testing, and security easier to manage.

mkdir backend
cd backend
npm init -y
npm install express cors dotenv helmet zod
npm install --save-dev nodemon

Express remains a popular choice for simple Node.js APIs because it is lightweight, flexible, and has a strong middleware ecosystem. The official Express documentation also recommends security practices for production apps such as using TLS, validating input, securing cookies, and avoiding known vulnerable dependencies. Express security documentation is a useful reference before launching your backend.

Create a simple server.js file:

import express from "express";
import cors from "cors";
import helmet from "helmet";
import dotenv from "dotenv";

dotenv.config();

const app = express();
const PORT = process.env.PORT || 5000;

app.use(helmet());
app.use(express.json());

app.use(cors({
  origin: process.env.FRONTEND_URL,
  credentials: true
}));

app.get("/api/health", (req, res) => {
  res.json({ status: "ok", service: "bolt-node-backend" });
});

app.listen(PORT, () => {
  console.log(`Backend running on port ${PORT}`);
});

If your project uses CommonJS instead of ES modules, you can use require() syntax. If you use ES modules, add "type": "module" to your package.json.

Step 2: Create API Routes for the Frontend

Your Bolt.new app should not talk directly to the database from the browser. Instead, the browser should send requests to your Node.js API. The backend then validates the request, checks permissions, talks to the database, and returns a safe response.

For example, imagine your Bolt.new app includes a contact form or lead capture form. Create a route like this:

import { z } from "zod";

const leadSchema = z.object({
  name: z.string().min(2),
  email: z.string().email(),
  message: z.string().min(10)
});

app.post("/api/leads", async (req, res) => {
  const result = leadSchema.safeParse(req.body);

  if (!result.success) {
    return res.status(400).json({
      error: "Invalid form data",
      details: result.error.flatten()
    });
  }

  const lead = result.data;

  // TODO: Save lead to database
  // await db.lead.create({ data: lead });

  return res.status(201).json({
    message: "Lead received successfully",
    lead
  });
});

Validation is not optional. AI-generated forms often look complete, but a malicious user can bypass frontend validation and send bad requests directly to your API. Backend validation protects your database and reduces security risks.

Step 3: Connect the Bolt.new Frontend to Your Node.js API

Once your backend route is ready, connect the frontend using fetch or a client such as Axios. The best practice is to store your backend URL in a frontend environment variable instead of hardcoding it in multiple files.

VITE_API_URL=http://localhost:5000

Then call your API from the Bolt.new frontend:

const API_URL = import.meta.env.VITE_API_URL;

export async function createLead(formData) {
  const response = await fetch(`${API_URL}/api/leads`, {
    method: "POST",
    headers: {
      "Content-Type": "application/json"
    },
    body: JSON.stringify(formData)
  });

  if (!response.ok) {
    const error = await response.json();
    throw new Error(error.message || "Failed to submit lead");
  }

  return response.json();
}

This pattern keeps your UI clean. Components should call service functions such as createLead(), loginUser(), getProjects(), or updateProfile() instead of containing raw API logic everywhere.

Step 4: Configure CORS Correctly

CORS is one of the first issues developers face when connecting an AI-generated frontend to a backend. If your Bolt.new frontend runs on one origin and your API runs on another, the browser needs permission to make cross-origin requests. Express provides an official CORS middleware that lets you control which frontend origins are allowed.

For development, your frontend may run on http://localhost:5173 and your backend on http://localhost:5000. In production, your frontend may be on a domain such as https://yourapp.com. Do not use a wide-open CORS setup for authenticated production APIs.

const allowedOrigins = [
  "http://localhost:5173",
  "https://yourapp.com"
];

app.use(cors({
  origin: function (origin, callback) {
    if (!origin || allowedOrigins.includes(origin)) {
      return callback(null, true);
    }
    return callback(new Error("Not allowed by CORS"));
  },
  credentials: true
}));

Step 5: Use Environment Variables for Secrets

Never place database passwords, JWT secrets, API keys, payment keys, or private tokens inside frontend code. Anything bundled into the browser can be inspected by users. Keep secrets in the backend environment.

Node.js exposes environment variables through process.env, and the official Node.js documentation explains that process.env contains the environment variables available when the process starts. Node.js environment variable documentation should be your reference for backend configuration.

PORT=5000
FRONTEND_URL=http://localhost:5173
DATABASE_URL=postgresql://user:password@host:5432/appdb
JWT_SECRET=replace_with_a_long_random_secret

In production, set these values in your hosting dashboard rather than committing a .env file to GitHub. Add .env to .gitignore.

Step 6: Add Authentication and Authorization

Authentication answers the question “Who is this user?” Authorization answers “What is this user allowed to do?” A production backend needs both. For example, a logged-in user may be allowed to view their own projects but not another user’s projects.

The OWASP API Security Top 10 lists broken object-level authorization as a major API risk. This happens when APIs expose object IDs and fail to check whether the logged-in user is allowed to access that object. For a Bolt.new app connected to a Node.js backend, this means every route that reads or updates user-specific data must check ownership on the backend.

A safe pattern is to avoid trusting user IDs from the frontend. Instead, decode the user from a secure session or verified token and use that identity when querying the database.

app.get("/api/projects/:id", requireAuth, async (req, res) => {
  const projectId = req.params.id;
  const userId = req.user.id;

  const project = await db.project.findFirst({
    where: {
      id: projectId,
      ownerId: userId
    }
  });

  if (!project) {
    return res.status(404).json({ error: "Project not found" });
  }

  res.json(project);
});

Step 7: Choose the Right Database Strategy

Your database choice depends on the type of product you are building. For SaaS dashboards, marketplaces, booking systems, CRMs, and admin portals, PostgreSQL is often a strong option because relational data matters. MongoDB can work well when your data is document-oriented and changes shape frequently. Supabase is useful when you want a managed PostgreSQL platform with authentication, storage, edge functions, and real-time features.

Bolt has official Supabase integration documentation for adding database, authentication, or edge functions to an app. That can be a fast path for prototypes. However, a custom Node.js backend is still valuable when you want to control business logic, background jobs, payment webhooks, custom permissions, external APIs, or multi-tenant SaaS rules. Bolt’s Supabase integration docs are useful if you want to combine generated UI with a managed backend service.

Step 8: Prepare for Deployment

A working localhost connection is not the same as a production deployment. Before launch, you need separate production URLs, environment variables, CORS origins, database connection strings, and logging. A common deployment setup is:

• Frontend: Deploy the Bolt.new exported app to Vercel, Netlify, or Cloudflare Pages.
• Backend: Deploy the Node.js API to Render, Railway, Fly.io, AWS, DigitalOcean, or a VPS.
• Database: Use a hosted database such as Supabase, Neon, MongoDB Atlas, or managed PostgreSQL.
• Environment: Set FRONTEND_URL, DATABASE_URL, JWT_SECRET, and other secrets in the hosting dashboard.
• Monitoring: Add request logging, error tracking, uptime monitoring, and database backups.

After deployment, test the full user flow: signup, login, form submission, data loading, protected routes, logout, error states, mobile responsiveness, and slow-network behavior.

Common Problems When Connecting Bolt.new to Node.js

Production Checklist

• Use separate frontend and backend environment variables.
• Validate every request body on the backend.
• Protect private routes with authentication middleware.
• Check object ownership before returning or modifying user data.
• Use exact CORS origins instead of allowing every origin.
• Store secrets only on the backend or hosting provider.
• Add centralized error handling and avoid leaking stack traces to users.
• Add database indexes for frequently queried fields.
• Use HTTPS in production.
• Test the full app after deployment, not only individual endpoints.

Final Thoughts

Bolt.new is excellent for moving quickly from idea to interface. But a real business application needs more than a good-looking UI. It needs a backend that protects data, handles business logic, validates input, manages authentication, connects to a database, and survives production traffic.

The best approach is to treat Bolt.new as a powerful frontend accelerator and Node.js as the engineering layer that turns the prototype into a real product. Build the backend separately, expose clear APIs, keep secrets server-side, validate every request, configure CORS carefully, and deploy with proper environment variables.

If your AI-generated app is stuck between demo and launch, this is the exact stage where professional engineering matters most. A clean Node.js backend can turn a vibe-coded prototype into a maintainable SaaS, internal tool, marketplace, booking system, or admin platform.

Frequently Asked Questions

Can Bolt.new connect to a custom Node.js backend?

Yes. A Bolt.new frontend can connect to a custom Node.js backend by calling REST API or GraphQL endpoints using fetch, Axios, or a typed API client. The backend should handle business logic, validation, authentication, and database access.

Should I use Supabase or a Node.js backend with Bolt.new?

Supabase is useful for fast prototypes, authentication, and database features. A custom Node.js backend is better when your app needs complex business logic, custom permissions, payment webhooks, third-party integrations, or multi-tenant SaaS architecture.

Why am I getting a CORS error?

A CORS error usually means the backend has not allowed the frontend’s exact origin. Add your Bolt.new preview URL or production frontend URL to the backend CORS configuration.

Is it safe to put API keys in a Bolt.new frontend?

No. Private API keys, database credentials, JWT secrets, and payment secrets should never be placed in browser code. Keep them in backend environment variables and expose only safe public keys to the frontend.