Kingy AI
For AI Companies
AI News

OpenAI Sites Guide (2026): Build, Host & Share Apps in ChatGPT

June 2, 2026 Curtis Pyke AI News
OpenAI Sites interface for building and hosting a web app in ChatGPT

Reviewed July 28, 2026. OpenAI’s current Sites documentation and terms were rechecked. Access and product framing have changed since this guide first appeared.

Verdict: OpenAI Sites is now a practical public-beta path for eligible ChatGPT users to build, host and share websites, web apps and games. Its strength is an integrated build-to-deploy workflow; its limits are plan and regional access, production-by-default URLs, and restrictions around sensitive data and transactions.

Sites runs in ChatGPT on the web and desktop app. You can start from a prompt or a compatible project, save a version for review, then deploy it to OpenAI-managed hosting. The feature is broader than the early Codex-only preview described in the original article.

Primary references: OpenAI Sites documentation and the ChatGPT Sites Terms. For background, see Kingy’s Codex guide and Codex command guide.

What OpenAI Sites Is

Sites is a Codex-powered way to create and host interactive web experiences through OpenAI-managed hosting. According to OpenAI’s developer documentation, Sites lets Codex “create, save, deploy, and inspect websites, web apps, and games hosted by OpenAI.” You use the Sites plugin when you want Codex to turn either a prompt or a compatible existing project into a hosted site without setting up a separate deployment workflow.

In plain English: you describe what you want, Codex builds or adapts the site, validates the build, saves a deployable version, and can deploy it to a production URL.

OpenAI’s launch examples are practical and work-oriented. The company mentions dashboards, planners, review workspaces, project boards, galleries, and lightweight tools. The launch post also gives concrete examples such as customer review pages, scenario planners built from financial models, and launch hubs where teams can track messaging, milestones, owners, and decisions.

Who Can Use OpenAI Sites Now

Sites is in public beta for eligible paid ChatGPT plans, subject to region and workspace settings. OpenAI’s current documentation says availability can differ by plan, geography and administrator policy; Free and Go are not included at this stage, and the initial rollout excludes the EEA, Switzerland and the United Kingdom.

Workspace owners and admins control access. Enterprise public publishing is off by default, and a missing Sites entry may reflect plan, region or admin settings rather than a technical failure. Check the current availability table before relying on access.

Why Sites Matters

The biggest shift is that Codex is moving from “agent that edits code” toward “agent that produces usable work surfaces.” OpenAI says more than 5 million people now use Codex weekly, and that non-developers such as analysts, marketers, operators, designers, researchers, investors, and bankers make up about 20 percent of overall Codex users.

Sites fits that broader strategy. Instead of forcing every output into a document, spreadsheet, slide deck, or static report, Codex can package work as an interactive product-like surface.

That is useful when the output needs exploration rather than passive reading. A dashboard lets people filter and compare. A scenario planner lets leaders adjust assumptions. A project board lets a team update status. A customer review workspace can gather usage trends, open questions, next steps, and owners in one place.

How Sites Works

The official docs describe a two-stage publishing model:

  1. Save a version.
    Codex builds the deployable site and associates that version with the source Git commit used for the build. This is the review stage.
  2. Deploy a version.
    Codex publishes a saved version and gives you the production URL after deployment succeeds.

This separation is important because OpenAI says every Sites deployment URL is a production deployment. If you want to review before going live, ask Codex to save a version without deploying it.

A strong first prompt should include:

  • The audience for the site
  • The core experience or workflow
  • The data the site should use
  • Whether users need to sign in
  • Whether data should persist between visits
  • Whether the site should be owner-only, workspace-wide, or limited to specific users or groups

Example prompt:

@Sites Build a customer review workspace for the account team. Include sections for product usage trends, open risks, requested features, renewal timeline, next steps, and owner assignments. Keep access limited to me and workspace admins until I review it. Save a deployable version, but do not deploy until I approve it.

What You Can Build With Sites

Based on OpenAI’s launch post and developer docs, Sites is best suited for lightweight but useful web experiences:

  • Internal dashboards
  • Project request trackers
  • Customer review workspaces
  • Launch hubs
  • Financial scenario planners
  • Event operations dashboards
  • Product update galleries
  • Creative brief repositories
  • Lightweight games or interactive demos
  • Internal tools that use workspace identity
  • Apps that store records, progress, scores, or uploaded files

This is not the same as saying Sites replaces every production engineering workflow. OpenAI’s documentation specifically says existing projects need compatible deployment artifacts, and that Sites hosts projects that build Cloudflare Worker-compatible output as ES modules. For existing projects, ask Codex to check compatibility before deploying.

Supported Site Shapes

OpenAI’s Sites docs describe several patterns:

  • A content-led website or landing page can be built without persistent application state unless the experience needs it.
  • Saved records, user progress, or game scores can use D1, a relational database for durable structured data.
  • Images, documents, audio, video, or other uploads can use R2 object storage.
  • Uploaded files with searchable metadata can use D1 for metadata and R2 for file contents.
  • Internal sites can use workspace-authenticated user identity.
  • Public sign-in or external identity provider flows require an authentication-enabled Sites project.

The practical rule is simple: do not ask for durable storage unless the hosted site needs to remember real product data. A temporary theme preference or dismissed banner does not need durable storage. A request tracker, customer workspace, project status board, or game leaderboard probably does.

Access Control

Sites is designed for team sharing, so access control is central. OpenAI’s docs say you should set the audience before sharing a deployed URL and keep a new site limited to the owner and workspace admins until you have reviewed the content, data handling, and expected audience.

The documented access modes are:

  • admins_only: the site owner and workspace admins
  • workspace_all: all active users in the workspace
  • custom: specific active users or workspace groups, while still allowing the owner

A safe deployment prompt:

@Sites Show me the current access setting, deployment URL, and saved version. If the build matches the version I approved, change access to the Revenue Operations group only.

Secrets and Environment Variables

OpenAI’s docs are explicit that hosted environment variables and secrets should be managed through the Sites panel in the Codex app. Do not store secrets in .openai/hosting.json. Keep local .env and .env.example files aligned for development, but do not commit secret values.

If you change hosted environment values, ask Codex to redeploy the approved saved version so the new configuration is used.

Legal and Policy Responsibilities

The new ChatGPT Sites Terms are worth reading before publishing anything meaningful.

Key points from the terms:

  • You retain ownership rights in your website content, to the extent permitted by law.
  • By creating or publishing ChatGPT Sites, you grant OpenAI and its third-party hosting providers a license to host and make the website content available.
  • OpenAI may display attribution text or links, such as “powered by ChatGPT.”
  • You are responsible for your ChatGPT Sites, including content, functionality, legal compliance, end users, and user-submitted content.
  • Your site must not violate OpenAI usage policies, pose security threats, include malware, target children under 13 or the applicable digital consent age, or facilitate money transfers, cryptocurrency transfers, or financial or investment transactions.
  • If your site collects or processes personal data, you are responsible for privacy compliance, notices, consent, and data-subject requests.
  • Sites must not process protected health information under HIPAA or payment card data regulated under PCI DSS.
  • OpenAI reserves the right to remove, unpublish, delete, or disable ChatGPT Sites.
  • The terms identify ChatGPT Sites as a beta service.

That last point is not a throwaway. For business use, treat Sites as a preview/beta capability and review governance, retention, user access, and compliance requirements before relying on it for sensitive workflows.

How to Get Started

  1. Confirm plan, region and workspace access.
    Check the current Sites availability table and ask a workspace admin about role or publishing controls.
  2. Open Sites in ChatGPT.
    Use the ChatGPT web experience or desktop app where Sites is available for your account.
  3. Start a Sites task.
    Describe the audience, data, access rules and desired workflow, or ask Sites to check an existing project for deployment compatibility.
  4. Start with a low-risk internal use case.
    Good first projects include a team dashboard, project tracker, meeting hub, customer review workspace, or internal launch checklist.
  5. Ask Codex to save before deploying.
    Because deployment URLs are production deployments, ask for a saved version first.
  6. Review the source changes, migrations, build status, access settings, and data handling.
    OpenAI’s docs specifically recommend reviewing source changes and any database migrations in the Codex review pane before deploying or widening access.
  7. Deploy only after approval.
    After deployment, ask Codex to confirm the deployment status and production URL before sharing.

Example Prompts

Internal Project Dashboard

@Sites Build an internal project dashboard for the operations team. It should show active projects, owners, priority, blockers, due dates, and status. Let team members update status and blockers. Require workspace sign-in and save updates between visits. Keep access limited to me and workspace admins. Save a version for review; do not deploy yet.

Launch Hub

@Sites Turn these launch notes into a living launch hub. Include messaging, milestones, owners, unresolved decisions, dependencies, and a launch readiness checklist. Use a clean internal-dashboard style. Save a review version first.

Financial Scenario Planner

@Sites Create a scenario planner from this financial model. Let leaders compare assumptions for pricing, conversion rate, hiring plan, and operating costs. Show the effect on revenue and margin. Do not deploy until I approve the saved version.

Existing Project Deployment

@Sites Check whether this project can produce Sites-compatible deployment artifacts. If it can, prepare a deployable version and summarize any changes needed. If it cannot, explain the blockers before editing anything.

Best Practices

Start with a low-risk internal project while Sites remains in public beta. This makes permissions, storage and deployment behavior easier to review.

Keep permissions narrow at first. Use owner/admin access while building and reviewing, then widen to a specific group or workspace only after approval.

Separate review from deployment. Ask Codex to save a version before deployment, especially for sites with data handling, auth, or customer-facing content.

Be explicit about persistence. Tell Codex whether the site needs saved records, uploads, user progress, searchable metadata, or only temporary UI state.

Review legal constraints. Avoid use cases involving payment card data, protected health information, children under 13, financial transactions, or anything that would violate OpenAI’s usage policies.

Treat generated sites as real software. Review source changes, database migrations, secrets, access controls, and production URLs.

Limits to Check Before You Build

  • Every deployment URL is a production deployment; save and review a version first.
  • Existing projects need compatible deployment output.
  • Data residency is not supported at launch.
  • Sites must not handle protected health information, payment-card data, under-13 services or financial transactions prohibited by the Sites Terms.
  • Public access, custom domains and sign-in options depend on account and workspace availability.

Bottom Line

OpenAI Sites is useful when a document would be too static: an internal dashboard, scenario planner, review workspace, lightweight public site or interactive tool. Start small, set the audience, save before deployment, review code and data handling, and widen access only after the production version is understood.

Related Kingy Guides

Sources