Microsoft SQL Server's mssql driver uses TCP protocol and fails in Bolt's WebContainer during development. Three options: (1) Deploy to Netlify/Bolt Cloud first, then use mssql in API routes normally; (2) Azure SQL Database's REST API works over HTTPS without TCP; (3) Use Prisma with SQL Server connector after deployment. For new projects, Supabase (PostgreSQL) is the path of least resistance as Bolt's native database.
Connecting Bolt.new to SQL Server: Deployment-First Approach
Microsoft SQL Server is a cornerstone database in enterprise environments. If you have an existing SQL Server database — on-premises, Azure SQL Database, or Azure SQL Managed Instance — connecting a Bolt-built application to it requires understanding one architectural reality before writing a single line of code: the Node.js SQL Server driver (mssql, also called node-mssql) uses Microsoft's Tabular Data Stream (TDS) protocol over TCP. Bolt's WebContainer cannot open raw TCP connections. This means mssql will fail to connect during development in the Bolt editor.
This is not a bug or a configuration problem. It is a fundamental constraint of Bolt's browser-based runtime. StackBlitz's WebContainers virtualize Node.js inside a browser tab using WebAssembly, and browsers cannot make TCP socket connections to arbitrary hosts. Every call to mssql.connect() will throw an error in the WebContainer, regardless of your SQL Server's firewall settings, connection string format, or package version.
The three practical paths forward are: (1) Deploy first, then build — Netlify and Bolt Cloud run your Next.js API routes as real serverless functions with full TCP access, so mssql works perfectly after a 30-second deploy. Use the deployed environment as your test environment for database-connected features. (2) Use Azure SQL Database's REST API — if your database is on Azure SQL Database, Microsoft provides an HTTP-based REST endpoint that works in the WebContainer, though it has fewer features than direct SQL. (3) Use Prisma ORM with the SQL Server adapter — Prisma's serverless adapter for SQL Server uses HTTP-based connectivity in some configurations, though this still works better in deployed environments. For new projects without an existing SQL Server dependency, Supabase (PostgreSQL) is the path of least resistance as Bolt's native database with no TCP limitations.
Integration method
SQL Server integration with Bolt requires understanding a fundamental constraint upfront: the mssql driver uses TCP (TDS protocol) which fails in Bolt's WebContainer. The recommended pattern is to deploy first and use mssql in Next.js API routes on Netlify or Bolt Cloud, where TCP connections work normally. Alternatively, Azure SQL Database's REST endpoint works over HTTPS and can be tested in the WebContainer during development. Supabase is the recommended alternative for new projects that do not have an existing SQL Server database to connect.
Prerequisites
- A Bolt.new account with a Next.js project
- An accessible SQL Server instance — Azure SQL Database, Azure SQL Managed Instance, or on-premises SQL Server with a publicly accessible endpoint
- SQL Server credentials (server hostname, database name, username, password) or Azure AD service principal credentials
- A Netlify or Bolt Cloud deployment target for testing the mssql connection
- For Azure REST API: an Azure AD application with SQL Server permissions
Step-by-step guide
Understand the WebContainer Limitation and Choose Your Path
Understand the WebContainer Limitation and Choose Your Path
Before writing any SQL Server integration code in Bolt, decide which approach fits your situation. This decision affects everything else. Option A — Deploy First (Recommended for existing SQL Server databases): If you have a SQL Server you need to connect to right now, build your API routes with mssql, deploy to Netlify or Bolt Cloud immediately, and use the deployed environment for all SQL-connected development. The deployment takes 30-60 seconds. Your React frontend components can still be previewed and iterated in the WebContainer — only the database-connected API routes need the deployed environment. You will test API routes by calling them from your deployed URL or using the Netlify Functions tab to test serverless functions directly. Option B — Azure SQL REST API (WebContainer-compatible): If your database is on Azure SQL Database, Microsoft provides an HTTP REST API for executing T-SQL queries. This works in the WebContainer during development. The trade-off: the REST API is less powerful than direct SQL, has more complex authentication (requires Azure AD OAuth tokens), and is primarily designed for lightweight operations. Not all SQL Server features are available through the REST API. Option C — Supabase migration (New projects): If you are starting fresh and SQL Server is not an organizational requirement, Supabase (PostgreSQL) is Bolt's native database. It works in the WebContainer, has zero configuration, and requires no deployment to start developing. For new features and new applications, this eliminates the TCP limitation entirely. For the rest of this tutorial, Option A (deploy first with mssql) is the primary path, with notes on the Azure REST API alternative where relevant.
Set up the project structure for SQL Server integration. Create a lib/sqlserver.ts file with a comment at the top explaining that mssql uses TCP protocol and requires a deployed environment (Netlify/Bolt Cloud) to connect — it will not work in Bolt's WebContainer preview. Export a getPool() function that lazily initializes an mssql connection pool using MSSQL_SERVER, MSSQL_DATABASE, MSSQL_USER, MSSQL_PASSWORD, and MSSQL_PORT (default 1433) from process.env with encrypt: true and trustServerCertificate: false. Export a query() helper function that executes a SQL string and returns typed results.
Paste this in Bolt.new chat
1// lib/sqlserver.ts2// ⚠️ IMPORTANT: mssql uses TCP (TDS protocol) and CANNOT connect from Bolt's3// WebContainer preview environment. TCP connections are not supported in4// browser-based runtimes. This file only works after deploying to Netlify,5// Bolt Cloud, or another serverless hosting environment.6//7// For development testing, either:8// 1. Deploy first, then test API routes at your deployed URL9// 2. Use Azure SQL Database REST API (HTTPS-based, works in WebContainer)10// 3. Use Supabase (PostgreSQL) for new projects — native Bolt support, no TCP1112import sql from 'mssql';1314const config: sql.config = {15 server: process.env.MSSQL_SERVER || '',16 database: process.env.MSSQL_DATABASE || '',17 user: process.env.MSSQL_USER || '',18 password: process.env.MSSQL_PASSWORD || '',19 port: parseInt(process.env.MSSQL_PORT || '1433', 10),20 options: {21 encrypt: true, // Required for Azure SQL, recommended for all22 trustServerCertificate: process.env.NODE_ENV === 'development', // Only for dev with self-signed certs23 enableArithAbort: true,24 },25 pool: {26 max: 10,27 min: 0,28 idleTimeoutMilliseconds: 30000,29 },30 connectionTimeout: 15000,31 requestTimeout: 30000,32};3334let pool: sql.ConnectionPool | null = null;3536export async function getPool(): Promise<sql.ConnectionPool> {37 if (pool && pool.connected) return pool;3839 if (!config.server || !config.database || !config.user) {40 throw new Error(41 'SQL Server is not configured. Set MSSQL_SERVER, MSSQL_DATABASE, MSSQL_USER, and MSSQL_PASSWORD in .env. ' +42 'Note: mssql requires a deployed environment — it cannot connect from Bolt\'s WebContainer preview.'43 );44 }4546 pool = await sql.connect(config);47 return pool;48}4950export async function sqlQuery<T = sql.IRecordSet<Record<string, unknown>>>(51 queryString: string,52 params?: Record<string, unknown>53): Promise<T> {54 const connection = await getPool();55 const request = connection.request();5657 if (params) {58 Object.entries(params).forEach(([key, value]) => {59 request.input(key, value);60 });61 }6263 const result = await request.query(queryString);64 return result.recordset as T;65}Pro tip: Set trustServerCertificate to true only in development environments and only when your SQL Server uses a self-signed certificate (common with SQL Server Express). For Azure SQL Database and production SQL Server, always keep it false and use a valid certificate.
Expected result: The SQL Server helper is in place with clear documentation of the WebContainer limitation. The connection configuration reads all values from environment variables. The file is ready — but will only actually connect after deployment.
Install mssql and Build API Routes
Install mssql and Build API Routes
Install the `mssql` package from the Bolt terminal. In the Bolt terminal panel, run `npm install mssql`. Also install the TypeScript types: `npm install --save-dev @types/mssql`. The package installs successfully in the WebContainer — the failure happens only when it actually tries to open a TCP connection. With the helper and package installed, create your SQL Server API routes. The route pattern is straightforward: import the sqlQuery helper, call it with your SQL query, and return the results. Parameterize all user-provided values using the params object — never interpolate user input directly into SQL strings as this creates SQL injection vulnerabilities. For the query pattern with Bolt-generated apps, prefer table-specific routes over a generic query endpoint. A generic query endpoint that accepts raw SQL from the client is both a security risk and an anti-pattern. Instead, create specific routes for each data operation: `/api/products` that runs a fixed SELECT query for products, `/api/products/[id]` that runs a parameterized SELECT by ID, `/api/orders` for orders, etc. This keeps SQL server-side and prevents unauthorized data access. Note: when you test this API route in the Bolt preview by calling it from your React component or navigating to the URL, you will get a connection error. This is expected. The error will look like 'Failed to connect to server' or 'ConnectionError: Failed to connect to localhost:1433'. Do not try to debug this as a configuration problem — it is the TCP limitation. The route will work correctly once deployed. For connection pooling in serverless environments (Netlify Functions, Bolt Cloud), the getPool() function caches the pool in the module scope. Serverless functions reuse the module between warm invocations, so the pool stays connected between requests. On cold starts, the pool reconnects automatically.
Install mssql and @types/mssql. Create a Next.js API route at app/api/sqlserver/products/route.ts that fetches a product list from a SQL Server table. Use the sqlQuery helper from lib/sqlserver.ts. Accept query params: search (optional name filter), category (optional category filter), page (default 1), pageSize (default 20). Build parameterized SQL using @search and @category params (never string interpolation). Return { products: [...], total, page }. Add a comment at the top noting this requires deployment to test.
Paste this in Bolt.new chat
1// app/api/sqlserver/products/route.ts2// NOTE: This route requires a deployed environment to function.3// The mssql driver uses TCP protocol which is not supported in Bolt's WebContainer preview.4// Deploy to Netlify or Bolt Cloud, add environment variables, then test this route.5import { NextResponse } from 'next/server';6import { sqlQuery } from '@/lib/sqlserver';78interface Product {9 id: number;10 name: string;11 category: string;12 price: number;13 stock: number;14 description: string;15 createdAt: Date;16}1718export async function GET(request: Request) {19 const { searchParams } = new URL(request.url);20 const search = searchParams.get('search') || '';21 const category = searchParams.get('category') || '';22 const page = parseInt(searchParams.get('page') || '1', 10);23 const pageSize = parseInt(searchParams.get('pageSize') || '20', 10);24 const offset = (page - 1) * pageSize;2526 try {27 // Build WHERE clause based on provided filters28 const whereClauses: string[] = ['1=1'];29 const params: Record<string, unknown> = { offset, pageSize };3031 if (search) {32 whereClauses.push('(p.name LIKE @search OR p.description LIKE @search)');33 params.search = `%${search}%`;34 }3536 if (category) {37 whereClauses.push('p.category = @category');38 params.category = category;39 }4041 const whereClause = whereClauses.join(' AND ');4243 // Use parameterized queries — never interpolate user input44 const products = await sqlQuery<Product[]>(45 `SELECT46 p.id, p.name, p.category, p.price, p.stock, p.description, p.created_at AS createdAt47 FROM Products p48 WHERE ${whereClause}49 ORDER BY p.name50 OFFSET @offset ROWS FETCH NEXT @pageSize ROWS ONLY`,51 params52 );5354 // Get total count for pagination55 const countResult = await sqlQuery<Array<{ total: number }>>(56 `SELECT COUNT(*) AS total FROM Products p WHERE ${whereClause}`,57 search ? { search: `%${search}%` } : category ? { category } : {}58 );5960 return NextResponse.json({61 products,62 total: countResult[0]?.total || 0,63 page,64 pageSize,65 });66 } catch (err) {67 const message = err instanceof Error ? err.message : 'Database query failed';68 const isTcpError = message.includes('Failed to connect') || message.includes('ECONNREFUSED');69 return NextResponse.json(70 {71 error: message,72 hint: isTcpError73 ? 'mssql requires TCP which is not supported in Bolt WebContainer. Deploy to Netlify or Bolt Cloud to test SQL Server connections.'74 : undefined,75 },76 { status: 500 }77 );78 }79}Pro tip: Use OFFSET / FETCH NEXT for pagination in SQL Server 2012 and later. For older SQL Server versions, use the ROW_NUMBER() approach. Azure SQL Database supports OFFSET/FETCH on all current versions.
Expected result: The route is created and mssql is installed. The route will return a TCP connection error in the WebContainer preview — that is expected. After deployment with proper environment variables, it returns the products from your SQL Server database.
Add Environment Variables and Deploy
Add Environment Variables and Deploy
SQL Server connection details belong in environment variables for security. The connection string contains credentials that must never be hardcoded in source code or committed to version control. Add them to your .env file for the deployed environment. For Azure SQL Database, the server address follows the format `yourserver.database.windows.net`. The database name is the specific database within the SQL Server instance. Authentication options: SQL authentication (username/password) is simplest for getting started. Azure AD authentication is more secure for production and uses a service principal with client ID and secret instead of a database username/password. For on-premises SQL Server or SQL Server on a VM, the server address is the hostname or IP. If your SQL Server is behind a corporate firewall, you may need to whitelist the IP addresses of your hosting provider (Netlify or Bolt Cloud's function IP ranges) before connections can succeed. For Azure SQL Database specifically, there is also a firewall rule in the Azure Portal. Navigate to your Azure SQL Server resource (not the database) → Firewall and virtual networks → Add client IP or allow Azure services. If deploying to Netlify, enable 'Allow Azure services and resources to access this server' as Netlify's IPs are in Azure's service range. Deploy to Netlify by going to Bolt Settings → Applications → Netlify → Deploy. After deployment, go to the Netlify dashboard → Site → Site configuration → Environment variables and add all the MSSQL_ variables. Alternatively, create a `.env.production` file that Netlify reads during build (but never commit this file — add it to .gitignore). After adding environment variables to Netlify, trigger a redeploy for the variables to take effect in your serverless functions.
Add SQL Server environment variables to .env with placeholder values and clear comments. Create a connection test route at /api/sqlserver/health that calls getPool() and returns { connected: true, server, database } on success or { connected: false, error, hint } on failure. Include a hint in the error response if it's a TCP error explaining the WebContainer limitation. Add the health route to a simple admin page that shows the connection status.
Paste this in Bolt.new chat
1# .env — SQL Server connection configuration2# WARNING: Never commit this file to version control3# Add these values to Netlify or Bolt Cloud environment variables after deploying45# Azure SQL Database example:6MSSQL_SERVER=your-server.database.windows.net7MSSQL_DATABASE=your-database-name8MSSQL_USER=your-sql-login9MSSQL_PASSWORD=your-secure-password10MSSQL_PORT=14331112# On-premises / VM SQL Server example:13# MSSQL_SERVER=192.168.1.10014# MSSQL_DATABASE=ProductionDB15# MSSQL_USER=appuser16# MSSQL_PASSWORD=SecurePassword123!17# MSSQL_PORT=14331819# Azure SQL with named instance (use port instead of instance name):20# MSSQL_SERVER=your-vm.eastus.cloudapp.azure.com21# MSSQL_PORT=1434 # Named instances often use a different portPro tip: For Azure SQL Database, always use encrypt: true in the mssql config. Azure SQL requires TLS encryption and will reject unencrypted connections. Setting trustServerCertificate to false (the default) validates the server's certificate, which is correct for Azure SQL's valid certificates.
Expected result: After deploying and adding environment variables in Netlify dashboard, the /api/sqlserver/health endpoint returns { connected: true } and the products endpoint returns real data from your SQL Server database.
Alternative: Azure SQL REST API for WebContainer Development
Alternative: Azure SQL REST API for WebContainer Development
If your database is Azure SQL Database and you want to test queries in the WebContainer without deploying, Microsoft provides a REST API endpoint. This uses HTTPS rather than TCP and is therefore compatible with Bolt's WebContainer runtime. The Azure SQL Database REST API is accessed via Azure REST management APIs or the `sys.database_query` REST endpoint. Authentication uses Azure AD tokens obtained via the OAuth 2.0 client credentials flow — you need an Azure AD service principal (application registration) with SQL Server access. The authentication flow: first POST to `https://login.microsoftonline.com/{tenantId}/oauth2/v2.0/token` with client_id, client_secret, and scope `https://database.windows.net/.default` to get an access token. Then use this bearer token to call Azure SQL REST endpoints. Note the limitations of the REST approach compared to direct mssql: it is primarily designed for management operations (creating databases, listing tables) rather than arbitrary T-SQL execution. For full T-SQL support, the direct mssql connection after deployment is always the better option. The REST API is a workaround for development preview only. A more practical alternative for getting WebContainer-compatible database access during development: point your development .env to a Supabase instance (PostgreSQL) with a schema that mirrors your SQL Server tables, develop and test with Supabase, then switch to SQL Server API routes in production. This gives you fast iteration in the preview without the TCP constraint.
Create an alternative API route at /api/azure-sql/query that uses the Azure SQL Database REST management API instead of mssql. It should authenticate using Azure AD client credentials with AZURE_TENANT_ID, AZURE_CLIENT_ID, AZURE_CLIENT_SECRET from process.env to get an access token from https://login.microsoftonline.com/{tenantId}/oauth2/v2.0/token. Then call the Azure SQL REST API using the token. Add a comment that this approach works in Bolt's WebContainer preview unlike the mssql TCP approach.
Paste this in Bolt.new chat
1// app/api/azure-sql/token/route.ts2// This approach uses Azure AD OAuth2 tokens with Azure REST API3// It works in Bolt's WebContainer (HTTPS-based, no TCP required)4// Trade-off: more complex auth setup, but testable in the preview5import { NextResponse } from 'next/server';67let tokenCache: { token: string; expiresAt: number } | null = null;89export async function getAzureSqlToken(): Promise<string> {10 if (tokenCache && Date.now() < tokenCache.expiresAt - 60_000) {11 return tokenCache.token;12 }1314 const tenantId = process.env.AZURE_TENANT_ID;15 const clientId = process.env.AZURE_CLIENT_ID;16 const clientSecret = process.env.AZURE_CLIENT_SECRET;1718 if (!tenantId || !clientId || !clientSecret) {19 throw new Error('Azure AD credentials not configured: AZURE_TENANT_ID, AZURE_CLIENT_ID, AZURE_CLIENT_SECRET required');20 }2122 const response = await fetch(23 `https://login.microsoftonline.com/${tenantId}/oauth2/v2.0/token`,24 {25 method: 'POST',26 headers: { 'Content-Type': 'application/x-www-form-urlencoded' },27 body: new URLSearchParams({28 grant_type: 'client_credentials',29 client_id: clientId,30 client_secret: clientSecret,31 scope: 'https://database.windows.net/.default',32 }),33 }34 );3536 const data = await response.json() as { access_token?: string; error?: string; expires_in?: number };3738 if (!data.access_token) {39 throw new Error(`Azure AD token failed: ${data.error || 'unknown error'}`);40 }4142 tokenCache = {43 token: data.access_token,44 expiresAt: Date.now() + (data.expires_in || 3600) * 1000,45 };4647 return data.access_token;48}4950export async function GET() {51 try {52 const token = await getAzureSqlToken();53 return NextResponse.json({ status: 'ok', tokenPreview: token.substring(0, 20) + '...' });54 } catch (err) {55 const message = err instanceof Error ? err.message : 'Token acquisition failed';56 return NextResponse.json({ error: message }, { status: 500 });57 }58}Pro tip: The Azure AD client credentials flow for SQL Server access requires granting the service principal 'db_datareader' (and db_datawriter if needed) database role. Run in SSMS or Azure Data Studio: CREATE USER [your-app-name] FROM EXTERNAL PROVIDER; ALTER ROLE db_datareader ADD MEMBER [your-app-name];
Expected result: The Azure AD token endpoint returns a valid token in the WebContainer preview. This confirms Azure AD authentication works for SQL Server connections without TCP. The token can then be used with Azure SQL REST management endpoints.
Common use cases
Connect Existing Corporate SQL Server Database
If you have an existing SQL Server database with business data — ERP tables, customer records, product inventory — build a Bolt app that reads and displays this data through a clean UI. The mssql API route approach works perfectly once deployed, giving you a modern interface on top of a legacy data source without migrating the underlying database.
Build a Next.js app that connects to a Microsoft SQL Server database. Create a lib/sqlserver.ts helper that initializes a mssql connection pool using MSSQL_SERVER, MSSQL_DATABASE, MSSQL_USER, and MSSQL_PASSWORD from process.env with connection encryption enabled. Create a Next.js API route at /api/sqlserver/query that accepts a POST with a SQL query string, executes it against the database using the connection pool, and returns the results as JSON. Add error handling for connection failures and SQL errors. Note in comments that mssql requires TCP and will not work in Bolt's WebContainer preview — deploy to Netlify first.
Copy this prompt to try it in Bolt.new
Azure SQL Database REST API (Works in Preview)
Azure SQL Database exposes an HTTP-based REST API that allows executing T-SQL queries over HTTPS. Since this uses HTTP rather than TCP, it works in Bolt's WebContainer during development. Ideal for building dashboards that read from Azure SQL without needing to deploy first for basic testing.
Build a dashboard that reads from Azure SQL Database using the REST API (not mssql). Create a Next.js API route at /api/azure-sql/query that calls the Azure SQL REST endpoint using the OAuth2 token from Azure AD. Use AZURE_SQL_SERVER, AZURE_SQL_DATABASE, and AZURE_CLIENT_SECRET for authentication. Return query results as JSON. Build a React table component that displays the results. This approach works in Bolt's WebContainer preview unlike the mssql TCP approach.
Copy this prompt to try it in Bolt.new
Prisma ORM with SQL Server (Post-Deployment)
Use Prisma ORM with the SQL Server (sqlserver) provider for a type-safe, migration-managed approach to SQL Server access. Define your schema in Prisma schema file, generate the TypeScript client, and use it in API routes. Prisma provides better TypeScript types and query building than raw mssql queries, at the cost of slightly more setup.
Set up Prisma ORM for SQL Server in this Next.js project. Create a prisma/schema.prisma file with datasource db using provider sqlserver and url from DATABASE_URL env var. Add a model for the main table I am working with. Run npx prisma generate to create the client. Create a lib/prisma.ts singleton. Build an API route at /api/data/products that uses the Prisma client to fetch products with filtering and pagination. Note that Prisma SQL Server connector requires deployment to work — add a comment explaining the WebContainer limitation.
Copy this prompt to try it in Bolt.new
Troubleshooting
ConnectionError: Failed to connect to {server}:{port} - connect ECONNREFUSED or ETIMEDOUT
Cause: This is the expected TCP limitation in Bolt's WebContainer. The mssql driver is trying to open a TCP socket, which browsers and WebContainers cannot do. This is not a configuration error — it is an architectural constraint.
Solution: Deploy to Netlify or Bolt Cloud. After deployment, add environment variables in the hosting dashboard and trigger a redeploy. Test the SQL Server API routes at your deployed URL. The error will not appear in the deployed environment where real TCP connections work.
1// Check for TCP error in your API route and return a helpful message:2const isTcpError = message.includes('ECONNREFUSED') || 3 message.includes('ETIMEDOUT') || 4 message.includes('Failed to connect');5if (isTcpError) {6 return NextResponse.json({7 error: 'SQL Server connection failed',8 hint: 'mssql uses TCP which is blocked in Bolt WebContainer. Deploy first, then test.'9 }, { status: 503 });10}Cannot find module 'mssql' or similar import error after installing
Cause: The mssql package installed but the TypeScript types are not found, or the package has native binary dependencies that fail to compile in the WebContainer.
Solution: Install both the package and types: npm install mssql && npm install --save-dev @types/mssql. If mssql fails to install entirely, try the exact version: npm install mssql@10. Note that even with successful installation, the package can only establish TCP connections in a deployed environment.
1// In package.json after installation:2// "dependencies": { "mssql": "^10.0.0" }3// "devDependencies": { "@types/mssql": "^9.1.0" }Login failed for user when connecting to Azure SQL Database after deployment
Cause: The Azure SQL Server firewall is blocking connections from the serverless function's IP range, or the SQL login credentials are incorrect.
Solution: In Azure Portal, navigate to your SQL Server resource (not the database) → Security → Networking. Either add a specific IP rule for Netlify's outbound IPs, or enable 'Allow Azure services and resources to access this server' if deploying to Netlify (whose IPs are in Azure ranges). Also verify MSSQL_USER and MSSQL_PASSWORD match exactly what is configured in the SQL Server.
Prisma SQL Server connector fails with unsupported connector error
Cause: Prisma's SQL Server connector (sqlserver) requires the same TCP connection as mssql and shares the same WebContainer limitation. Prisma does not have an HTTP-based serverless adapter for SQL Server equivalent to the Neon adapter for PostgreSQL.
Solution: Use Prisma with SQL Server only in deployed environments. For local development, use DATABASE_URL pointing to a Supabase PostgreSQL database with matching schema, then switch to SQL Server credentials in the deployed environment. Alternatively, use the mssql-based approach directly without Prisma.
Best practices
- Adopt a deploy-first workflow for SQL Server integration: build API routes in Bolt, deploy to Netlify in 30 seconds, and test database connections from the deployed URL rather than fighting the WebContainer limitation.
- Never store MSSQL_PASSWORD or SQL Server credentials in client-side environment variables with the NEXT_PUBLIC_ prefix — database credentials must always remain server-side.
- Use parameterized queries exclusively, never string interpolation for SQL — mssql's request.input() method properly escapes all parameters and prevents SQL injection attacks.
- Configure connection pooling with appropriate limits for serverless environments — a max pool size of 10 connections is appropriate for most serverless functions, as each function instance may start its own pool.
- Enable encrypt: true for all SQL Server connections, especially Azure SQL Database which requires TLS — unencrypted SQL traffic exposes credentials and query results in transit.
- For new projects without an existing SQL Server database, strongly consider Supabase (PostgreSQL) as the primary database — it works natively in Bolt's WebContainer with zero configuration and eliminates the TCP constraint entirely.
- Handle connection errors with helpful messages that distinguish between TCP errors (WebContainer limitation) and credential errors (configuration issues) so developers understand the root cause immediately.
- Test deployed SQL Server API routes with a simple health check endpoint before building complex queries — verify the connection fundamentals work before debugging query logic.
Alternatives
MySQL has the same TCP limitation in the WebContainer, but PlanetScale's HTTP-based MySQL client works in the preview and offers a better development experience for MySQL users.
PostgreSQL via Supabase or Neon is the recommended path for Bolt projects — their HTTP-based clients work in the WebContainer, eliminating the deployment-first requirement for database development.
MongoDB Atlas Data API uses HTTPS rather than TCP, making it fully compatible with Bolt's WebContainer for development without requiring deployment first.
Oracle Database has similar TCP-based connectivity requirements to SQL Server, sharing the same WebContainer limitation and requiring the same deployment-first workflow.
Frequently asked questions
Can mssql ever work in Bolt's WebContainer preview?
No — mssql uses the TDS (Tabular Data Stream) protocol over TCP, which browsers and WebContainers cannot support at the architectural level. This is not a configuration issue that can be solved with different connection strings, firewall rules, or package versions. The only way to use mssql is in a deployed server environment where TCP connections work normally.
Does Bolt.new have any native SQL Server integration?
No — Bolt.new's native database is Bolt Database (built on Supabase/PostgreSQL). There is no native SQL Server connector. SQL Server integration requires building Next.js API routes with the mssql package and deploying to a hosting environment where TCP connections work.
What is the fastest way to test SQL Server API routes built in Bolt?
Deploy to Netlify via Bolt Settings → Applications → Netlify → Deploy. The deployment takes 30-60 seconds. After deployment, add MSSQL_SERVER, MSSQL_DATABASE, MSSQL_USER, and MSSQL_PASSWORD in the Netlify environment variables. Trigger a redeploy. Your API routes at the Netlify URL will have full TCP access to SQL Server. You can continue iterating in Bolt — changes push to the same Netlify site.
Is Prisma ORM a solution to the SQL Server TCP limitation?
No — Prisma's SQL Server connector (sqlserver provider) uses the same TCP-based connection as mssql directly. Unlike Neon's PostgreSQL serverless adapter which uses HTTP, there is no HTTP-based serverless adapter for Prisma SQL Server. Prisma with SQL Server has the same WebContainer limitation and requires a deployed environment. However, Prisma provides better TypeScript types and query building once you are in the deployed environment.
Should I migrate from SQL Server to Supabase to avoid the TCP limitation?
For new features or new projects, Supabase (PostgreSQL) eliminates the TCP constraint and is Bolt's native database. For projects with an existing SQL Server database containing years of business data, migration is a major undertaking that should be evaluated separately from the Bolt integration. The deploy-first workflow makes SQL Server perfectly workable — you just accept that the database connection only functions in the deployed environment.
Talk to an Expert
Our team has built 600+ apps. Get personalized help with your project.
Book a free consultation