AI Agent Website Hosting: Runtime vs Static

AI agent website hosting starts with one distinction

In short, use runtime hosting for live computation and static hosting for finished files. Website hosting for AI agents covers two different jobs. One job is to run an agent: it calls a model, uses tools, stores state and answers new requests. The other job is to publish the files that the agent finished at a live URL. If you mix up the two jobs, you can choose the wrong host, expose secrets or send an awkward link to the client.

This guide shows when you need runtime hosting and when static hosting is enough. It also shows how an agent can publish its output to a static host, such as Cloudflare Pages, Netlify or GitHub Pages. The agent gets only the access that it needs.

Agent runtime hosting versus static AI website hosting

A runtime runs server-side code after deployment. It receives events, loads credentials, calls APIs and can read or write a database. AWS describes its Lambda runtime as a language-specific environment that passes invocation events and responses between the service and your function. That compute has a lifecycle and resource limits. The AWS Lambda documentation gives a clear example.

Static hosting serves finished HTML, CSS, JavaScript, images, PDFs and CSV exports. Browser JavaScript can still run filters, charts or calculators. The host does not run your Python process, model loop, queue worker or private API logic.

Question	Agent runtime host	Static host
What runs after a visitor arrives?	Server code, model calls, tools or jobs	Files load. Optional JavaScript runs in the browser
Where do secrets live?	A protected server environment	Nowhere: they must not be in published files
Typical state	Database, memory, queue, sessions	Versioned files and deployment configuration
Operations work	Logs, scaling, timeouts, dependencies	Deploys, access rules, caching
Examples	Cloudflare Workers, AWS Lambda, Railway, a container platform or a VPS	Cloudflare Pages, Netlify, GitHub Pages, Vercel serving static output

Some hosts do both. Netlify Functions, Vercel Functions and Pages Functions run server code next to static files. If you use these functions, you are back in runtime hosting, with its limits, logs and secrets.

When you need agent runtime hosting for an AI agent website

You need runtime hosting when the action of a visitor must start trusted server code. For example, a prospect asks a research agent a new question. The system must send the prompt to a model, retrieve private records, enforce permissions and return a fresh answer. A static folder cannot do that safely.

You need runtime hosting for:

• Live model calls: every user request needs a new model response.
• Private credentials: the application uses model, CRM, payment or database keys.
• Server-held state: users have accounts, sessions, histories or saved work.
• Background work: queues, scheduled jobs, webhooks or long tasks continue without an open browser.
• Controlled actions: the agent sends messages, changes records or starts actions in other systems.

Run that layer on a container platform, a serverless function service, a managed agent platform or a VPS (virtual private server). Each option has compute limits. For example, Cloudflare’s Workers limits allow up to 128 MB of memory per isolate (one running instance of a Worker). The CPU time per request is different on the Free and Paid plans. Because of limits like these, a runtime needs correct sizing, retries, logs and failure handling. Our Railway walkthrough shows one way to host an app that needs a server.

When static AI website hosting is enough

Static hosting fits work that is complete before anyone opens the link. The link opens a finished deliverable and does not ask for more computation. Much of the work that freelancers, consultants, agencies and small teams send to clients is of this type.

Good static outputs include:

• A proposal in PDF plus a short HTML cover page
• A presentation with images, notes and supporting spreadsheets
• A browser demo built from HTML, CSS and JavaScript
• A generated report with charts, CSV data and a methodology page
• A documentation folder with Markdown, media and downloadable files

A static demo can offer browser-based tabs, local search, charts, form validation and calculations. It cannot safely contain a private key or an unrestricted backend credential.

Before you publish, test the output from the point of view of a stranger. Largest Contentful Paint (LCP) is the time until the largest visible element shows. The Google target for LCP is 2.5 seconds or less for at least 75% of visits. Google’s LCP guidance is a useful target for demos with many images. WCAG 2.2 asks for a contrast of at least 4.5:1 for ordinary text. It also asks that a page can resize to 200% without loss of content. WCAG 2.2 applies whether a person or an agent wrote the page.

Static hosting is simpler because the risky compute step ends before you publish.

How to let an AI agent publish to a static host

The steps below use Cloudflare Pages Direct Upload with the Wrangler CLI. The equivalent steps for Netlify and GitHub Pages follow. A person does the setup one time. The agent repeats the deploy.

A person does steps 1 to 3 one time:

1. Tell the agent to write finished files to one output folder, such as out/. Put index.html at the root of that folder. Keep source files, prompts, logs and .env files outside that folder.

2. Run npx wrangler login. Then run npx wrangler pages project create to create the project. Wrangler asks for a project name and a production branch, for example client-report and main. Store the project name in the configuration of the agent. Then every run updates the same site.

3. Make a narrow credential for the agent. In the Cloudflare dashboard, open Account API tokens. Select Create Token. Under Custom Token, select Get started. Set the permission to Account, Cloudflare Pages, Edit, and then create the token. Give the token to the environment of the agent as CLOUDFLARE_API_TOKEN. Also give it CLOUDFLARE_ACCOUNT_ID (CI setup docs). If a mistake by the agent can damage unrelated client sites, keep those sites in a separate account. This permission can create, edit and delete every Pages project in that account (permission list).

Repeat steps 4 to 7 on every run:

4. Let the agent deploy a preview with this command:

   npx wrangler pages deploy out --project-name=client-report --branch=review

   The preview appears at review.client-report.pages.dev. Each deployment also gets its own address at <hash>.client-report.pages.dev.

5. Open the preview yourself on desktop and on mobile. Make sure that the names, figures, links, downloads and access rules are correct.

6. After you approve the preview, let the agent deploy the same folder to the production branch:

   npx wrangler pages deploy out --project-name=client-report --branch=main

7. Always deploy to the same project, so that the URL stays the same. If a release is wrong, open Deployments. Choose an earlier production deployment. Select Rollback to this deployment (rollback docs).

On Netlify, the agent runs netlify deploy --dir=out --site=<site>. Without --prod, the Netlify CLI creates a draft deploy that you can review. To publish to the live site, add --prod. For unattended runs, pass a personal access token with --auth.

On GitHub Pages, the agent commits the finished files to a repository. Then Pages publishes them. In the repository, open Settings > Pages. Under Build and deployment, set Source to Deploy from a branch (root or /docs folder). You can also set it to GitHub Actions (publishing source docs). Give the agent a fine-grained token with Only select repositories and Contents write access (token docs). With this token, the agent can push to that one repository and to nothing else. GitHub Pages sites are public unless your organization uses GitHub Enterprise Cloud and publishes privately.

Manual publishing is still the shortest path for occasional work

You do not need to connect the agent to a host to publish its output. For occasional client work, a person can publish by hand and see exactly what the link shares.

1. Let the agent build the finished folder.
2. Review the files locally.
3. Drag the folder into Cloudflare Pages or into Netlify Drop. In Cloudflare, go to Workers & Pages > Create application > Get started > Drag and drop your files.
4. Set the access: public, password or email sign-in.
5. Later, upload each new version to the same project. In Cloudflare Pages, use Create a new deployment. On Netlify, drag the folder onto the Deploys page of the site.

A designer who sends one deck does not need a deploy token. For a consultant who updates a quarterly report, drag and drop can be enough. An agency that publishes the same preview every day saves time if an agent deploys it. Start with manual publishing. Automate it when the repetition is worth the setup.

Four practical AI agent website hosting examples

These examples are representative workflows, not named customers. They show where the runtime ends and the shared output starts.

Scenario	What produces the work	What the static host serves	Who can open it
Freelancer sends a 12-page proposal	An agent drafts copy, and the freelancer reviews pricing	A PDF plus an HTML introduction on Cloudflare Pages	Client contacts who sign in with an email code through Cloudflare Access
Agency shares a browser prototype	A coding agent builds static HTML, CSS and JavaScript	A Netlify site	The review group, with a site password on a Netlify Pro plan
Consultant refreshes a Monday report	A scheduled agent runs elsewhere at 08:00, creates charts and deploys a preview with Wrangler	The approved report, promoted to the same Pages project	Everyone at the client’s email domain
Founder offers a live support agent	A runtime host handles model calls, sessions and private tools	A static sales page or a recorded demo only	The public

The third example shows the pattern. A scheduler wakes the agent on a compute service. The agent gathers data, generates static output and deploys it to a known project. A person approves the preview. Then the static host serves that reviewed output at the same URL.

The fourth example shows the same boundary. If visitors expect a new answer, persistent memory or a private system action, use runtime hosting. Do not hide a model key in browser JavaScript.

Protect the link and the agent’s access

Match visitor access to the audience and to the sensitivity of the work:

• Public access suits material for broad discovery.
• Password access suits a group that can receive the shared password separately. Netlify offers it on Pro and Enterprise plans. Vercel offers Password Protection as a paid option on Pro.
• Email sign-in suits proposals, reports and demos for named people. Cloudflare Access can send a one-time code to addresses or domains that you allow. Its logs record which email signed in and when. Our Cloudflare Pages Access guide shows the setup.

Give agent access the same care as visitor access. NIST defines least privilege as giving a user or process only the access that it needs for its assigned task. NIST’s definition supports a simple rule. Give an agent a token for the one project or repository that it updates. Keep production deploys behind a human approval. Revoke the token when the automation ends.

Common publishing mistakes and a final QA pass

Most mistakes come from a wrong boundary or a skipped review. A five-minute review can prevent public secrets, broken demos or updates sent to the wrong client.

Mistake	What goes wrong	Better action
Treating a static host as a runtime	Server code, model calls or database features do not run	Put compute on a runtime host. Publish only its static output
Publishing source instead of output	Visitors see project files or a blank page	Build first, then deploy the finished dist, build, out or public folder
Putting secrets in JavaScript	Anyone can inspect the browser bundle	Revoke the secret and move the call behind a trusted server
Giving an agent broad account access	A mistaken instruction can affect unrelated sites	Use a token for one project, a separate account or a token for one repository. Keep production deploys behind human approval
Creating a new project for every edit	Clients get many links and open old versions	Deploy to the same project name every time
Trusting generated files without review	Claims, names, totals, links or accessibility can be wrong	Before you promote the preview, review its URL on desktop and on mobile

If static JavaScript exposes no private credential, it can call APIs that are made for browser access. An agent can update the site with a deploy to the existing project. The static host cannot run the Python or Node process of the agent. That boundary makes it simpler to choose website hosting for an AI agent.

Final thoughts on AI agent website hosting

If you separate ongoing computation from finished output, the hosting choice is easier. Use runtime platforms for agents that must wake up, call models, hold secrets, save state or act on visitor requests. Use static hosting for finished reports, decks, demos, documentation and browser-ready sites.

The simplest start is to drag a folder into Cloudflare Pages or Netlify. When publishing becomes repetitive, let the agent deploy previews with a token for one project. Keep a person on the production step. Deploy to the same project every time, so that the client link never changes.

A docs portal with Ask AI
and support tickets

Connect a repository, or describe your product to start. Each docs site has search, Ask AI, an API console, an MCP server and support tickets.

• Publishes from GitHub on every push
• Works with Mintlify repositories
• API console from your OpenAPI file
• MCP server and llms.txt for AI agents
• Ask AI and support tickets
• Analytics for people and AI agents

Start Free→ Questions? Ask AI in our docs

No card required.