NIST
NIST AI RMF Map Function: How to Identify AI Risks
Learn how NIST Map and MAP 1-5 establish AI system context and help identify risks, benefits, components, limitations and potential...
An AI website builder can produce an attractive website quickly, but a project that works inside a builder or on your computer is not automatically ready for real users.
An AI website builder uses artificial intelligence to generate website layouts, components, content, styles, or code from instructions. Vibe coding is an AI-assisted development approach in which you describe what you want, review the result, and refine the project through additional prompts.
The challenge often begins after website generation. You still need to understand the project, test its features, create a production build, select compatible hosting, configure environment variables, connect a domain, enable HTTPS, and verify that everything works online.
There is no single deployment method for every AI-built website. A static HTML site, a React frontend, and a full-stack application with authentication and a database require different infrastructure.
Deployment depends on architecture, not how the website was created.
Static, framework-based, and full-stack projects require different hosting.
Test the production build before uploading or publishing anything.
Keep API keys, passwords, and access tokens out of source code.
Verify the domain, HTTPS, application features, and logs after deployment.
Use previews and rollback options before changing a live website.
To deploy a vibe-coded website, first identify whether the project is static, framework-based, or full-stack. Test it locally, run its configured production build, and choose a host that supports its output and runtime. Then upload or connect the project, configure environment variables, connect the domain, enable HTTPS, and test the live deployment.
Use this table to find the appropriate starting point:
|
What the project contains |
Likely project type |
Typical deployment path |
|
HTML, CSS, JavaScript, and images |
Static website |
Upload files to static hosting or a web server |
|
package.json and frontend framework files |
Framework application |
Build the project and deploy its output or supported runtime |
|
Backend routes, authentication, or database configuration |
Full-stack application |
Deploy the frontend, backend, database, and private configuration |
The files produced by an AI website builder determine what happens next. Do not select hosting until you know what kind of application you have.
A static project usually consists of HTML, CSS, JavaScript, images, fonts, and other browser assets. A server can deliver these files without continuously running application code.
Static does not mean non-interactive. A static website can still have menus, animations, browser-based forms, or calls to external APIs. It means the host primarily serves prepared files instead of generating each page through backend code.
The project may use React, Next.js, Vue, Astro, Vite, or another framework or build tool. You may see a package.json, source directories, configuration files, and build scripts.
One framework can support several deployment models. A project may produce static output, use server-side rendering, or depend on platform functions. Read the project configuration instead of assuming that every framework deploys in the same way.
A full-stack project may contain a frontend, backend routes, APIs, authentication, authorization, database access, file storage, and external integrations. It normally requires more than uploading frontend files.
The backend needs a compatible runtime and running process. The database needs production credentials, network access, and migrations. Private values require secure environment configuration.
The governing principle is simple: deployment depends on the project’s architecture, not simply on the fact that AI created it.
If the platform allows source-code export, obtain the complete project. Source access lets you inspect dependencies, change configuration, create production builds, and fix deployment errors.
Not every AI website builder provides exportable source code. Some platforms publish websites only within their own hosting environment. Check the builder’s publishing, export, and ownership options before planning an independent deployment.
Git provides version history, backup, collaboration, rollback, and a reliable connection between your code and a deployment platform. GitHub is one common repository service, but it is not mandatory.
A Git repository can also support continuous integration and continuous deployment, commonly called CI/CD. GitHub Actions workflows can build, test, and deploy a project when events such as pushes or pull requests occur. The official GitHub Actions documentation explains how workflows, jobs, steps, events, and runners work.
Never commit API keys, access tokens, database passwords, private keys, or other secrets to Git.
Possible hosting options include static hosting, shared hosting, managed application platforms, virtual private servers, and cloud infrastructure.
The best choice is the least complex environment that reliably supports the project. A static landing page rarely needs a VPS. A full-stack application with a custom backend may need a managed runtime, container platform, or server-level control.
Look at the files in the project root:
index.html can indicate a static entry point.
package.json identifies JavaScript dependencies and scripts.
Framework configuration files indicate how the project is processed.
Directories such as api, server, or backend may contain server code.
.env.example may document required environment variables.
Schema and migration files indicate database requirements.
An environment file such as .env may contain private local credentials. It should not automatically be uploaded or committed.
A package.json may contain scripts similar to:
"scripts": {
"dev": "...",
"build": "...",
"start": "..."
}
These names are common, but their underlying commands vary. Inspect the actual values. A build script might generate static files, compile a server application, or prepare framework-specific output. A start script may not exist.
Ask three questions:
Does the final website consist only of files a browser downloads?
Does it require server-side rendering, server functions, or a running application process?
Does it use authentication, a private API, persistent data, or a database?
The answers will usually place the project in the static, framework-based, or full-stack category.
Local testing should happen before you configure a production server.
For an npm-based project, a common local installation command is:
npm install
The project may use pnpm or Yarn instead. Check its lockfile and documentation before selecting a package manager.
For an automated build with a committed package-lock.json, the project may use:
npm ci
According to the official npm documentation, npm ci performs a clean installation based on the lockfile and exits with an error if the lockfile does not match package.json. It is intended for automated environments but is appropriate only when the project meets its requirements.
If the project defines a dev script, an example command is:
npm run dev
This runs the command assigned to dev. It is only an example. A development server should not automatically be used to serve production traffic.
Test navigation, direct page URLs, images, forms, buttons, responsive layouts, authentication, APIs, database operations, and external integrations.
Inspect the browser console and network panel. Search the code for development-only values such as localhost, 127.0.0.1, local file paths, test databases, and development API domains.
These values frequently explain why an application works locally but fails after deployment.
AI-generated code is not inherently insecure, but it still requires normal review. Check for incorrect dependencies, incomplete logic, unused packages, hardcoded credentials, weak input validation, configuration mistakes, and access controls enforced only in the browser.
When AI coding tools are used within an organization without approval or adequate visibility, the code, prompts, credentials, and connected systems can also create governance concerns. The guide to Shadow AI cybersecurity risks explains how unapproved AI tools can interact with sensitive data, code, identities, and business systems.
Development mode prioritizes quick feedback. A production build prepares the application for live use by compiling code, optimizing assets, or generating deployable server output.
If the project defines a build script, a common example is:
npm run build
The exact command depends on the project. A plain HTML website may not need a build, while another application may use pnpm, Yarn, a framework CLI, or containers.
Possible output locations include dist, build, a public directory, or framework-specific server and client folders.
Never assume every project uses dist. Review the build log and configuration. Vite, for example, uses dist by default for a static build, but its output directory can be changed through configuration. The official Vite static deployment guide documents that specific behavior.
Common causes include missing dependencies, invalid imports, type errors, filename capitalization, incompatible runtime versions, missing environment variables, and framework configuration errors.
Fix the first meaningful error and run the production build again. Uploading unbuilt source code rarely resolves a failed build.
|
Hosting option |
Best suited to |
Complexity |
|
Static hosting |
Static websites and compatible frontend builds |
Low |
|
Managed deployment platform |
Supported frameworks and application runtimes |
Low |
|
Shared hosting |
Simple sites supported by the provider |
Low |
|
VPS |
Applications requiring server control |
Medium |
|
Cloud infrastructure |
Larger or more complex applications |
Medium to high |
A managed platform can provide Git integration, automated builds, preview deployments, environment variables, custom domains, HTTPS, logs, and rollback features.
Vercel is one example for compatible projects. It should not be treated as the universal solution. Confirm support for the project’s framework, runtime, backend behavior, storage, and other services.
A VPS is useful when you need control over operating-system packages, web server configuration, ports, runtimes, background processes, or custom backend workloads.
That control creates additional responsibilities, including updates, firewall rules, process management, certificates, backups, logs, and recovery.
A simple static project may need only a web root containing the HTML, CSS, JavaScript, and assets. Shared hosting or static hosting may be sufficient.
Choose hosting according to what the finished website needs, not according to which AI tool generated it.
A static deployment normally follows this sequence:
Create the production build if required.
Locate the final files.
Connect to the host or server.
Upload the production output.
Configure the web root.
Test the website.
Connect the domain.
Enable HTTPS.
You may transfer files through SFTP, SCP, a hosting control panel, or an approved Git-based process.
Upload only the files the web server must serve. Do not place source code, local caches, test data, .env files, or credentials inside a publicly accessible web root.
Nginx is one possible web server. Its root directive maps requests to a directory containing website files. The official Nginx beginner’s guide explains static-file serving and configuration structure.
A basic file-based static configuration might resemble:
server {
listen 80;
server_name yourdomain.com www.yourdomain.com;
root /path/to/your/production/files;
index index.html;
location / {
try_files $uri $uri/ =404;
}
}
The domain, path, permissions, and configuration location are placeholders that must be adapted to the server.
A client-side single-page application may instead need an entry-page fallback:
location / {
try_files $uri $uri/ /index.html;
}
Use that fallback only when the application intentionally handles routes in the browser. A server-rendered application or ordinary multi-page site may require different routing.
Use a temporary hostname, preview address, or another host-supported testing method. Check the homepage, assets, and nested routes directly. A homepage that loads successfully does not prove that every URL is configured correctly.
If the server has authorized Git access, you can clone the repository:
git clone YOUR_REPOSITORY_URL
cd YOUR_PROJECT
YOUR_REPOSITORY_URL and YOUR_PROJECT are placeholders. Never place repository credentials directly in a public command, script, or URL.
For an npm-based project, follow the project’s documented installation process:
npm install
A production pipeline with a valid package-lock.json may use npm ci. Projects using pnpm or Yarn require the corresponding package manager.
Configure production variables through the hosting platform, process manager, container configuration, or another secure mechanism.
A build-time variable is used while creating the production output. A runtime variable is read by the running server process. Changing a frontend build-time variable normally requires a new build. Changing a runtime server variable may require an application restart or redeployment.
Node.js applications can access process environment values through process.env, as explained in the official Node.js environment variables documentation.
Never assume every environment variable is private. Values embedded in browser-delivered JavaScript can be inspected by users.
Run the project’s documented build, such as:
npm run build
After the build, the project may require static-file hosting, a framework-specific production server, serverless functions, containers, or another runtime.
Do not assume npm start works for every framework. Inspect the scripts and framework deployment documentation.
A server application may listen on a private local port. A reverse proxy receives public requests and passes them to the application:
Visitor → Domain → Nginx → Application
Nginx supports this through directives such as proxy_pass. Its official HTTP proxy module documentation explains the available configuration.
The correct forwarded headers, timeouts, request limits, and WebSocket settings depend on the application.
Determine whether the frontend will be built as static files, served by the backend, or deployed separately. Replace local API addresses with the correct production endpoint and ensure client-visible variables contain no secrets.
The backend requires its runtime, dependencies, port, start process, and private configuration. Confirm that its API routes are reachable and that authentication and authorization are enforced on the server.
Use a managed runtime, process manager, container platform, or operating-system service that can restart the application and preserve useful logs.
Set up a production database supported by the application. Configure its connection string, credentials, network access, TLS requirements, migrations, and backups.
Never publish the connection password or commit it to Git. Do not run an unfamiliar migration against production data until you have reviewed its operations and confirmed that a tested backup or recovery path exists.
A reverse proxy can send website requests to the frontend and requests under /api/ to the backend. Another architecture may use a separate API subdomain.
Choose the routing pattern according to cookies, CORS, authentication, framework behavior, and hosting capabilities.
For an organizational or higher-impact application, deployment review should consider more than whether the code runs. The AI risk assessment guide explains how security, privacy, reliability, operational, compliance, and third-party risks can be evaluated across an AI system’s lifecycle.
Register the domain with the hosting project or add it to the web server’s virtual host configuration. The host should be ready to answer requests before DNS is changed.
Use the values supplied by the hosting provider:
An A record points a hostname to an IPv4 address.
An AAAA record points a hostname to an IPv6 address.
A CNAME record makes one hostname an alias of another hostname.
Do not copy an IP address from a generic tutorial. Vercel, for example, instructs users to obtain the required values from their own project’s domain settings. Its domains documentation explains how domains and DNS records connect to deployments.
DNS records can remain cached by browsers, devices, networks, and recursive resolvers. Changes therefore do not appear everywhere at the same moment.
The delay depends on previous records, caching, time-to-live settings, the DNS provider, and the resolver. Do not rely on a fixed propagation time.
Confirm that the root domain and www hostname resolve to the intended deployment. Check that the correct application answers and that outdated or conflicting records have been removed.
HTTPS uses TLS to protect information exchanged between the browser and server. TLS provides encryption in transit, integrity protection, and server authentication through a certificate.
MDN recommends serving both pages and their subresources over HTTPS. Its TLS guidance explains certificates, secure contexts, mixed content, and HTTP upgrades.
Use the certificate and renewal process supported by your hosting environment. Managed hosts often automate both. A self-managed server requires you to configure and monitor renewal.
After HTTPS works, redirect HTTP requests to the same resource over HTTPS. Confirm that scripts, images, fonts, and API calls do not use insecure HTTP URLs.
Building with AI involves more than generating code from prompts. Understanding project files, dependencies, frontend and backend concepts, testing, environment configuration, deployment, security, and infrastructure helps you evaluate and improve the applications AI creates.
The AI Vibe Coding: Build Apps Without Coding course provides structured learning on AI-assisted application development, testing, deployment, security, privacy, and responsible development.
Vercel is one managed deployment option for compatible projects. Check its supported frameworks and runtimes before selecting it.
A common workflow is:
GitHub → Vercel → Build → Preview → Production
Vercel can create preview deployments for non-production branches and production deployments from the configured production branch. The official Vercel Git deployment documentation explains its current branch-based workflow.
A typical setup involves:
Connect the supported Git provider.
Select the repository and project root.
Review framework detection.
Confirm the build command and output settings.
Add required environment variables.
Start the deployment.
Automatic detection is useful, but it should be checked against the project’s configuration.
A preview provides a hosted version for testing without replacing the live website. Check pages, direct routes, forms, APIs, authentication, mobile layout, redirects, environment variables, and logs.
Keep preview and production configuration separate where appropriate. Do not give every preview unrestricted access to production systems or data.
Production may be triggered by updating the configured production branch. If you use the Vercel CLI, the production command is:
vercel --prod
This command is specific to the Vercel CLI. CLI deployment is not mandatory. The Vercel CLI deployment guide distinguishes preview and production deployments.
Add the domain to the project and follow the DNS instructions generated for that project. Monitor build logs, runtime errors, failed requests, and environment configuration.
If a release creates a production problem, restore a known working deployment when appropriate. Vercel documents its current process and plan limitations in its production rollback guide.
This example applies only to a Vite project configured for static output.
Inspect package.json and confirm that the project defines the expected build script. Install the dependencies using the package manager associated with the lockfile, start the development server, and test the website.
Run:
npm run build
Vite produces dist by default, although build.outDir can change that location. Test the production output using the project’s configured preview script. Vite’s preview server is for local verification, not production hosting.
Push the project to GitHub, import the repository into compatible static hosting, verify the build command and output directory, configure non-sensitive frontend variables, and create a preview deployment.
Test direct routes, assets, forms, and API calls. When the preview works, create the production deployment, connect the domain, enable HTTPS, and inspect the live logs.
If the project uses Vite server-side rendering or includes a separate backend, this static workflow is not sufficient.
GitHub Actions can automate installation, testing, building, and deployment. A workflow may run after a push, pull request, release, schedule, or manual trigger.
Use separate staging and production environments where appropriate. GitHub environments can hold environment-specific secrets, restrict deployment branches, and apply protection rules. Feature availability depends on repository visibility and plan, so check the current GitHub deployment environments documentation.
Avoid copying complex YAML without reviewing it. Workflow permissions, secret names, artifact paths, runtime versions, and provider-specific actions must match your project.
For business deployments, the workflow should also fit the organization’s ownership, approval, monitoring, and incident-response processes. The AI governance framework guide explains how responsibilities, lifecycle controls, monitoring, and documented decisions fit within broader AI governance.
|
Problem |
Check first |
Common causes |
|
Works locally but not online |
Production logs and variables |
Runtime differences, local URLs, or missing dependencies |
|
Build fails |
First meaningful build error |
Invalid imports, types, variables, or configuration |
|
Nested route returns 404 |
Hosting route rules |
Incorrect web root or missing SPA fallback |
|
CSS or images are missing |
Browser network panel |
Incorrect paths, filename case, or base path |
|
API does not work |
Request URL and backend logs |
Wrong API URL, CORS, HTTPS, or unavailable backend |
|
Domain does not work |
DNS lookup and hosting status |
Incorrect, conflicting, or cached DNS |
|
Application stops |
Process and system logs |
Crash, restart, resource limit, or missing supervision |
Compare runtime versions, environment variables, paths, operating-system behavior, and network access. Confirm that production code does not call localhost or a development database.
Reproduce the production build locally. Resolve dependency conflicts, imports, type errors, missing variables, and framework configuration instead of disabling checks without understanding the consequences.
Confirm the correct web root. If the homepage works but a direct nested route fails, determine whether the site needs file-based routing, an SPA fallback, or actual server routes.
Check the exact failed URL, filename capitalization, relative paths, asset inclusion, and base-path configuration. Production filesystems may treat uppercase and lowercase filenames differently.
Verify the production API address, backend availability, CORS rules, cookies, environment variables, and HTTPS. Do not solve CORS problems by allowing every origin without reviewing the security effect.
Check the A, AAAA, or CNAME value against the host’s current instructions. Confirm that the domain is registered with the hosting project and that no conflicting DNS record remains.
The application may have been started in an interactive terminal without a process-management service. It may also be crashing because of an unhandled error, missing variable, database failure, or resource limit.
Inspect application and system logs. Use a suitable process manager, container runtime, operating-system service, or managed hosting process.
Search for API keys, database passwords, access tokens, private credentials, private key files, and credentials embedded in URLs.
Never expose private API keys. Never publish database passwords. Never commit secrets to Git. If a secret was previously committed or deployed, remove it and rotate it. Deleting it from the latest file may not remove it from Git history.
Store private values through the hosting platform, server service, container configuration, or an approved secret-management system.
Separate public browser configuration from server-only secrets. Any value included in frontend JavaScript should be treated as publicly visible.
Identify packages that are unused, outdated, unsupported, or affected by known vulnerabilities. Review advisories in context and test updates before deploying them.
Authentication verifies identity. Authorization determines what that identity may access.
Enforce both on the server. Test whether one user can access another user’s records, restricted API routes, administrative functions, or protected files.
Test input validation, file uploads, database queries, external integrations, permissions, and error handling. Production errors should not expose credentials, stack traces, or private infrastructure details to users.
For a wider review of application and AI-related threats, Fundamentals of AI Security, AI Governance & AI Compliance covers AI security, attack surfaces, governance controls, monitoring, and responsible deployment.
AI assistance does not replace human review, security testing, or accountability for released software.
Test navigation, direct URLs, forms, authentication, authorization, APIs, integrations, and database operations using controlled test accounts and data.
Check mobile, tablet, and desktop layouts. Test menus, long content, forms, tables, touch controls, and orientation changes.
Review server response time, page loading, image size, caching, and JavaScript execution. Core Web Vitals measure aspects of loading, interactivity, and visual stability. Google’s Web Vitals documentation explains the current metrics and measurement methods.
Confirm that HTTPS works without mixed content, private values do not appear in browser code, protected routes reject unauthorized access, and dependencies have been reviewed.
Logs can reveal missing variables, unavailable services, permission errors, timeouts, resource limits, and unexpected inputs that do not appear locally.
Monitoring should be connected to a response process. The article on AI failures, causes, and lessons explains why staged deployment, continuous monitoring, traceable records, and tested rollback procedures matter after an AI-enabled system reaches production.
Source code exported or stored in Git
Project architecture identified
Website tested locally
Production build succeeds
Environment variables identified
Secrets removed from source
Hosting supports the project
Domain is ready
Project uploaded or connected to Git
Correct package manager used
Production build completed
Environment variables configured
Backend and database configured if required
Server or hosting routes configured
Domain connected
HTTPS enabled
Homepage and direct routes work
Navigation and forms work
Authentication and authorization work
APIs and database operations work
Mobile layout works
HTTPS has no mixed content
Logs contain no critical errors
Backup or rollback option is available
Deploying a website created with an AI website builder is not one universal action. The process depends on whether the project is static, framework-based, or full-stack.
Follow this sequence:
Build → Inspect → Test → Create production output → Choose hosting → Deploy → Configure the domain → Enable HTTPS → Test → Monitor
A static project may need only its finished files and a web server. A framework application may require a specific build process or production runtime. A full-stack application may also need backend services, environment variables, a database, migrations, and process management.
Once you understand these distinctions, vibe coding becomes more useful because you can move beyond generating a prototype and make informed decisions about how the completed application should run.
Yes, if the platform offers publishing or allows you to export the required files or source code. The correct deployment method depends on whether the website is static, framework-based, or full-stack. Check the builder’s export options and the project’s technical requirements before selecting separate hosting.
Identify the architecture, test the project locally, run its production build, and select compatible hosting. Upload or clone the project, configure the runtime and environment variables, connect the domain, enable HTTPS, and test the live website. A full-stack application also requires backend and database configuration.
Yes. The VPS must support the project’s runtime, server software, storage, and database requirements. A VPS gives you control but also makes you responsible for updates, process management, security, TLS, logs, backups, and recovery. Simple static websites usually do not need that complexity.
Yes, if the exported project and its required features are supported by Vercel. Connect the Git repository or use the Vercel CLI, verify framework and build settings, configure environment variables, test a preview deployment, and then create the production deployment.
Yes. Connect the GitHub repository to compatible hosting or create a GitHub Actions workflow. Keep credentials out of the repository and configure them through protected secrets or the hosting platform. Test the build and deployment workflow before relying on it for production releases.
Production may use different runtime versions, paths, variables, permissions, API URLs, or network settings. The production build can also expose errors hidden in development mode. Compare the environments, search for local-only configuration, and inspect browser, build, application, and server logs.
No. Static hosting, shared hosting, or a managed deployment platform may be sufficient. A VPS is useful when you need a custom runtime, persistent backend process, background worker, special server configuration, or greater infrastructure control.
Yes, but every required component must be deployed. This may include the frontend, backend, database, migrations, environment variables, API routing, authentication, process management, domain, and HTTPS. Before using real data, follow a structured AI risk assessment process appropriate to the application’s context and impact.
Yes. Review dependencies, configuration, logic, input validation, authentication, authorization, database access, secrets, and error handling. AI-generated code is not inherently unsafe, but AI assistance does not replace technical review. Organizations should also consider the security and governance controls discussed in the AI security and governance course.
NIST
Learn how NIST Map and MAP 1-5 establish AI system context and help identify risks, benefits, components, limitations and potential...
Ai Governance
New to AI governance? Learn the skills, principles and frameworks to study first, then compare beginner training options and choose...
Learn how Claude Cowork, plugins and agentic workflows work for business, including practical use cases, security risks and responsible AI...