Key takeaways
Deploying a web app turns your finished project into a live link that anyone on the internet can visit.
Keep sensitive information, like security codes and passwords, in your app's private settings instead of typing them directly into your project files.
If your app needs to remember user info or save records, make sure your storage and login settings are ready before you go live.
Connect your own website address and confirm the site loads over HTTPS so visitors can find and trust your project.
Bolt.new brings hosting, databases, authentication, and domain management into the same workflow, so you don’t have to configure them across separate tools.
Your app works. You've tested it in preview, clicked every button, and it does exactly what you built it to do.
Then you try to deploy it and hit a wall of hosting dashboards, database credentials, DNS settings, SSL certificates, none of which showed up in your prompts. Deploying a web app means configuring and publishing your finished code to a production environment so anyone can access it through a live URL.
A complete deployment often also needs hosting, environment variables, a working database, authentication, and a verified domain with SSL. That's a lot of moving parts for someone who just wants a working link to share with users, investors, or clients.
You don't need to become an infrastructure engineer to get there. You need a clear path from finished build to live production, and a way to know when each piece (hosting, data, security) is ready.
Why deploying a web app feels harder than it should be
Deployment feels harder because one launch hides several connected decisions inside a fragmented workflow. Shipping a working app means coordinating four separate systems:
Source control for your code
Hosting for the live build
Backend services for data and logins
Domain configuration for the public address people type in
Each handoff between those systems is its own failure point. Push code to the wrong branch, and hosting serves an old build. Provision a database in one dashboard while your app expects credentials from another, and forms fail silently. Configure DNS without waiting for propagation, and visitors hit a broken address.
DevOps Research and Assessment (DORA) reports that flexible infrastructure is associated with 30% higher organizational performance and helps teams reduce lead times and recover from failures faster. Teams that can provision environments without waiting on manual operations support can ship and learn sooner.
What "deploying a web app" means
A complete deployment moves your built app through configuration, service provisioning, publication, verification, and monitoring in a live production environment. Building creates the app. Deploying publishes it.
Along the way, you'll deal with staging (a private test copy) and production (the live version real users hit), plus hosting and publication, the actual act of going live.
Cloud deployment provisions computing resources on demand and scales capacity as traffic changes, automating the manual server work that used to eat a launch day.
Key terms you need to know before you launch
Navigating deployment decisions without infrastructure expertise gets easier once you understand a small set of terms:
Build: The process that turns your code into files a browser or server can run.
Deploy: Publishing that built, configured version so real visitors can reach it.
Hosting: The service that stores your files and serves them on request.
Staging: The private copy you test changes on first.
Production: The live environment real users hit.
Environment variable: A stored setting or key your app reads at runtime, kept outside your source code.
DNS: The system that points your domain name to your host.
SSL: The certificate that secures traffic over HTTPS.
CI/CD: The automated pipeline that tests and ships new code.
A frontend-only project just serves browser files. A full-stack app also includes server-side logic and may require a database, authentication, or other backend services.
The three failure points that trip up non-technical builders
Most first-time deployment failures are predictable configuration gaps involving environment variables, production databases, or domain and SSL settings. You get an immediate 500 error, a form that won't save data, or a live URL flagged with a security warning. None of these mean you built the app wrong, but each one has a likely cause and a specific fix.
Symptom | Likely cause | Fix |
500 error on load | Missing or mismatched environment variable | Make sure every key your app calls in code has a matching entry in production. |
Form submits but nothing saves | Production database not provisioned or connected | Provision the database, define its schema, set permissions, and confirm your live app can connect. |
Browser security warning | DNS or SSL not fully configured | Add the domain through your hosting dashboard, follow its DNS and any ownership-verification instructions, wait for propagation, then test the site over HTTPS. |
Environment variables and secrets
Store every required secret and configuration value in private environment settings, then confirm the names and values match what your app expects.
Environment variables are labeled configuration values (API keys, database URLs, third-party tokens) stored outside your source code so they never end up in a public repository or a browser's dev tools. Never hardcode a private key into browser-facing code. If it ships to the client, anyone can find it.
Before you publish, open your local .env file next to your hosting dashboard's Environment Variables list and compare them line by line. Every key your app calls in code needs a matching entry in production, spelled exactly the same way.
Run this prompt against your project before launch: "Audit this project for required environment variables, list each purpose, and flag any secret exposed in client code."
Database provisioning
A data-driven app isn’t deployed until its production database, schema, permissions, and connection are active and tested. Provisioning means creating the database, defining its schema, setting permissions, and confirming your live app can connect to it. Skipping any one of those four steps leaves your app half-launched.
A database differs from temporary browser storage, such as form drafts held in memory or data limited to a single browser session. Production records that need to persist across visits, users, and devices generally belong in a database.
Your homepage can load perfectly at its live URL while every form on the site quietly fails. If the production database isn't provisioned and connected, submissions vanish, dashboards stay empty, and signups error out. Test every save-and-retrieve feature before you call deployment done.
Domains and SSL
Your custom domain is launch-ready only when its DNS points to the correct host and an active SSL certificate serves the app over HTTPS. DNS records are directions. They tell browsers where to send visitors who type in your domain. SSL is the certificate that unlocks HTTPS, encrypting whatever moves between the browser and your server, including login credentials and form submissions.
Add the domain through your hosting dashboard, then follow the supplied ownership-verification and DNS instructions. After that step, wait out DNS propagation, which can take time to resolve.
Once propagation completes, load the site over HTTPS and check both the root domain and the www version. If either throws a certificate warning or fails to redirect, fix it before you send traffic there.
How Bolt.new replaces four deployment tools with one workflow
Bolt.new keeps building and deployment inside one conversational workflow instead of splitting decisions across a code repo, a hosting provider, a backend service, and a domain registrar.
Previously, you'd juggle separate logins for source control, hosting, database, and DNS, reconciling settings between each one. With Bolt.new Cloud, hosting, backend infrastructure, and domain deployment live inside the same workspace where you built the app.
But, as with any new tool, assess portability, usage limits, and your production requirements before you commit.
Built-in hosting and custom domains
Bolt.new Cloud publishes your app straight from the same workspace where you built it, eliminating the export step and the separate hosting dashboard. That's the core of the AI website builder workflow: build, then publish, in the same workspace.
You still publish to the generated URL first and test it before connecting a domain, the same order the steps below walk through in detail. But when you connect a custom domain, Bolt.new Cloud handles the certificate work behind that connection automatically, keeping SSL configuration off your plate.
Databases and authentication without extra setup
Bolt.new Cloud keeps your database and user management inside the same workspace you used to build the app, so you don’t have to sign up for a separate backend provider just to store user records. Describe what you need (accounts, saved data, roles) and Bolt.new Cloud provisions it alongside your app.
Every extra account is another place for configuration to drift: a database that expects different field names than your login form, or auth settings that don't match your production URL. Keeping both in one environment reduces the risk of that mismatch.
For founders validating an idea, this means testing a real signup flow the same day you write the prompt.
How to deploy a web app for free with Bolt.new
Move from preview to a working public URL in Bolt.new by following four steps: prepare the build, connect any required data, configure authentication, and publish.
You can publish for free to a bolt.host URL. Custom domains require a paid plan, and free-plan usage limits may change, so check the latest plan details before you launch.
Step 1: Build your app with AI-guided prompts
Prepare your app for deployment by prompting for explicit features, responsive behavior, loading states, and error states, then test every route before you publish.
Try a prompt like: "Build a responsive [app type] for [audience] with [features]. Apply [design system], include loading and error states, and make it deployment-ready." Naming the design system and both states upfront with Bolt.new's AI app builder gives Bolt.new Agent the specs it needs at the start, so it’s not guessing at them later.
Once the build finishes, preview every route yourself. Resize the browser window or use device preview to confirm mobile layouts hold up alongside the desktop view.
If something looks broken, skip the full rebuild. Send a targeted follow-up prompt instead, like "Fix the mobile nav overlap on the pricing page," and resolve visible errors one at a time before moving to Step 2.
Step 2: Connect a database if your app needs one
Connect a production database before launch whenever your app has to remember something between visits, like user accounts, form submissions, inventory counts, saved preferences, or application records. Skip this step entirely for a static page like a marketing site or landing page with no dynamic data to store.
Start by prompting Bolt.new Agent to build the structure your data needs: "Create the database schema for [records], connect every form, add validation, and test create, read, update, and delete actions." That single prompt covers the schema, the form-to-record wiring, and the guardrails.
Don't take a working homepage as proof the database is live. Test every action yourself: create a record, read it back, update it, delete it. When all four work, your data layer is deployment-ready.
Step 3: Set up authentication for your users
Sign-up, sign-in, access recovery, sign-out, and protected-route behavior all need to work before authentication is deployment-ready. A visible login screen isn’t the finish line. The real test is whether unauthenticated visitors get bounced from restricted pages, or whether they can type in a URL and reach your dashboard anyway.
Protect every restricted route, including the ones without a lock icon. When someone without an active session hits a protected page, they should see a clear error or a redirect to sign in, not a blank screen or a broken component.
Try this prompt in Bolt.new: "Add secure authentication with [methods], protect [routes], create clear error states, and test every login and recovery flow." Then run the full journey yourself: sign up, sign in, trigger a password reset, sign out, and try to reload a protected page while logged out.
Step 4: Publish to a live URL and connect your domain
Connect your custom domain only after publishing to Bolt.new's generated URL, verifying every production-critical flow, and confirming the live build passes its smoke test. A generated URL runs on the same production infrastructure your custom domain will eventually point to, so any bug you catch here is a bug you don't have to debug twice.
Before touching DNS settings, run a full smoke test on that generated URL. Click through every page in navigation, submit every form, sign up and log in through authentication, and confirm a database write saves and reloads. Check mobile rendering on a real phone, review page titles and metadata, and confirm HTTPS is active by default.
Then send the link to one real external user, someone who wasn't in the build process, and watch them use it without guidance.
Once that passes, connect your custom domain and confirm HTTPS carries over on the new address before you tell anyone it's live.
Ship your next idea without waiting on an engineer
A waitlist app with authentication and a real database uses the same basic deployment components as a more mature product. The gap between "idea in your head" and "live product with real users" comes down to how many tools you have to stitch together before writing a single feature.
Bolt.new Cloud closes that gap: hosting, integrated databases, user authentication, and custom domains live inside the same chat interface where you built, keeping launch in one place instead of four new tabs and four new accounts. The checks that matter still happen. They just stop requiring a handoff.
