ChatGPT Sites in Codex: Create, Deploy & Manage Web Apps

Most guides about ChatGPT Sites focus on the "describe what you want" magic. That's the easy part. The real work shows up after: managing deployments, controlling access, handling secrets, and remembering that every URL you generate is live. This guide treats Sites like what it really is: a lightweight release pipeline for small web apps.

What ChatGPT Sites Actually Is

ChatGPT Sites turns Codex from a code generator into a hosted-app workflow. You describe a dashboard, tracker, or internal tool in plain English, and you don't just get code files. You get a live URL with hosting, analytics, identity management, and access controls baked in.

That shift matters because it closes the usual gap between "it works locally" and "it's deployed." There’s no separate hosting service to set up, no CI/CD pipeline to wire, and no DNS to touch unless you want a custom domain. The flip side is straightforward: Sites is best for focused internal tools and prototypes, not full production engineering stacks.

Creating Your First Site

Creation starts with the @Sites command in ChatGPT web (Work interface) or the desktop app. Describe what you want, and ChatGPT generates a complete site you can preview, refine, and deploy.

textCopy
@Sites Create a project status dashboard showing:
- Active projects with completion percentages
- Team member assignments
- Upcoming deadlines in the next 14 days
- Filter by department

That prompt produces a working dashboard, not a code snippet. ChatGPT handles the HTML, CSS, JavaScript, and hosting setup. You’ll see the site in a preview pane where you can click around before you deploy.

Refinement is conversational. If the colors don’t match your brand or the date format looks off, spell out the change:

textCopy
Change the header color to #1a365d and format all dates as DD MMM YYYY

Each change creates a new version. If something breaks, you can roll back. It’s lightweight versioning, closer to "git commits without the command line" than a full repo workflow.

Where Management Actually Happens

Codex CLI and IDE extensions can help you edit and test locally, but they don’t give you the Sites management screens. Publishing, access controls, analytics, secrets, and settings live in the ChatGPT web or desktop interface.

This split setup usually works well for teams: build and tweak however you like, then come back to ChatGPT for deployment and governance. It’s a separation between development and operations, on purpose.

Access Controls and Sharing

New sites default to owner and workspace admins only. That default matters because every deployment goes live immediately at its URL. If someone has the URL but doesn’t have access, they’ll hit an authentication prompt instead of seeing the site.

Access tiers look like this:

Owner/admin only - Default. Only you and workspace admins can view. Keep it here while you’re iterating.

Selected users/groups - Share with specific people or groups in your workspace. This is the typical setting for team tools.

Anyone in workspace - Everyone in your ChatGPT Business or Enterprise workspace can access. Works well for company dashboards.

Public internet - Anyone with the URL can view. Enterprise workspaces usually have this disabled by default and require an admin to turn it on.

For public sites, the "Sign in with ChatGPT" flow handles authentication. Visitors sign in with a ChatGPT account, and analytics can show who accessed the site. For workspace-restricted sites, the visitor’s workspace identity is used automatically.

Built-in App Primitives

Sites is more than static pages. It comes with primitives that would normally mean stitching together extra services:

D1 (structured data) - SQLite-compatible storage for form submissions, user preferences, or app state. No separate database setup.

R2 (object storage) - File storage for uploads, images, or documents. Think "simple S3-like bucket" that’s integrated with your site.

Analytics - Automatic tracking for unique visitors and page views. You can see metrics like "190 unique visitors, 359 page views over seven days" without adding tracking code.

Identity - Built-in authentication, so you can avoid OAuth setup and custom user management for simple access control.

These pieces are what make Sites practical for real internal tools. A project tracker can store data in D1. An asset library can serve files from R2. A dashboard can show who’s actually using it.

Secrets and Security

Secrets follow one hard rule: don’t put credentials in prompts, files, or page content. Put them in Site settings, and only there.

textCopy
@Sites Add Slack integration to post updates when project status changes

That prompt explains the integration. The Slack webhook URL belongs in Site settings after the site exists, not in the conversation. Keeping secrets out of chat history, version snapshots, and generated comments is the whole point.

OpenAI's security documentation covers sandboxing, approval workflows, and audit trails for Codex. For Sites, the practical bits are:

• Network policies restrict what external services sites can contact
• Managed configurations reduce the chance of accidentally exposing workspace data
• Telemetry and audit trails track who deployed what and when

Sites doesn’t support data residency requirements at launch. PHI, payment card data, and policy-violating uses are prohibited. If the project touches regulated data, Sites probably isn’t the right fit.

Governance Before Publishing

Before switching access from owner-only, run a real review. A solid checklist:

Content review - Read every page. AI-generated text can include made-up details, awkward phrasing, or incorrect info. Your team owns what gets published.

Interactive behavior - Click every button, test every form, and validate dynamic elements. Broken flows create bad UX and can mean lost data.

Sign-in flows - If authentication is required, test it the way your audience will use it. Try a different account or an incognito window.

Visitor data collection - Know what data is collected and where it goes. Form submissions land in D1. Analytics track visitors. Third-party integrations may receive data too.

External dependencies - If the site calls external APIs, check reliability and fit. A dashboard that goes stale because an API flakes out reflects back on your tool.

Practical Use Cases That Work

OpenAI positions Sites for focused, reviewable web outputs rather than complex products. Where it tends to shine:

Project hubs - Dashboards for status, timelines, and ownership. The fast iteration loop helps you tune layout and clarity quickly.

Launch trackers - Countdown pages with task lists and stakeholder visibility. With D1, the tracker keeps state across visits.

Internal calculators - Pricing estimators, resource allocation tools, budget planners. Built-in primitives handle the logic and storage without lots of external plumbing.

Onboarding pages - New hire info, process docs, team directories. Access controls keep sensitive info inside the workspace.

Prototypes - Working mockups for stakeholder review before committing to a full build. Sites is well-suited to early validation.

What’s usually a poor match: apps that require specific frameworks, private network access, background services, or complex database operations. Sites is intentionally lightweight.

Connecting Projects to Outcomes

Stack Overflow's 2026 Pulse data shows daily AI-agent use at work rose to 37% (up from 14% in 2025), with OpenAI Codex showing 22% usage and 56% stated interest among coding-agent tools. But Gartner reports only 35% of software engineering leaders see significant ROI from AI in the SDLC.

That gap between adoption and ROI usually comes from fuzzy goals. Teams that start with "let's see what AI can build" often struggle to prove value. Teams that start with "weekly reporting is too slow" and use Sites to fix that specific pain can actually measure the result.

The pattern that works: pick one internal friction point, build a focused site for it, then measure the improvement. A tracker that cuts 30 minutes from a weekly status meeting has clear ROI. A generic "AI-built dashboard" typically doesn’t.

Working with Codex CLI for Advanced Customization

Codex CLI is the escape hatch when conversation alone isn’t enough. Export the site’s code, edit it in your editor or IDE, test locally, then deploy the updated version through the ChatGPT interface.

This hybrid approach is a good fit when requirements are easier to express in code, like:

• Complex CSS layouts that need pixel-perfect adjustments
• JavaScript logic that needs debugging in developer tools
• Integration patterns that need to match team conventions
• Accessibility fixes that require manual testing

One constraint stays in place: Codex CLI doesn’t include the Sites management views. Local edits are fine, but deployment, access controls, and analytics still happen in ChatGPT. Plan for it as a hybrid workflow, not a fully local environment.

Common Problems and Solutions

Site shows stale data after update - Sites caches aggressively. Ask ChatGPT to clear the cache or deploy a new version. If you’re using D1, double-check the query logic.

Access controls don't seem to work - Access changes can take a few minutes to propagate. Test in an incognito window so cached auth doesn’t mislead you.

External API calls fail - Outbound connections are restricted by network policies. Confirm the endpoint is allowed for Sites. Some internal/private APIs won’t be reachable.

Custom domain not available - Enterprise workspaces don’t support custom domains at launch. That’s a product limitation, not a misconfiguration.

Analytics show unexpected traffic - Bots and crawlers can inflate counts. Analytics separate unique visitors from page views, but they won’t filter all automated traffic.

Site disappeared from dashboard - Sites are tied to the conversation that created them. If that conversation is deleted, management becomes harder to find. The URL stays live until the site is explicitly deleted.

Enterprise Considerations

ChatGPT Sites is available to Business and Enterprise plan subscribers, with availability depending on plan, region, and workspace settings.

Enterprise-specific considerations:

Public publishing disabled by default - Workspace admins need to turn it on. This helps prevent accidental exposure of internal tools.

Custom domains not available at launch - Enterprise sites use OpenAI-provided URLs. If branded URLs are a must-have, this is a current blocker.

Data residency not supported - Sites doesn’t guarantee residency in specific regions. For strict data sovereignty requirements, that may be a deal-breaker.

Audit trails available - Enterprise plans include telemetry and audit trails for compliance. Deployments are tracked with who/what/when.

The OpenAI Help Center covers training and data-control notes for enterprise contexts.

Hands-On Steps

Start here (your first step)
Open ChatGPT web, type @Sites Create a simple team status page with three project cards, and deploy it. You can usually get through the full loop in under five minutes, and it makes the workflow click.

Quick wins (immediate impact)

• Pick one status update that’s still sent manually and turn it into a Sites dashboard
• Set access controls for your immediate team and collect feedback early

Deep dive (for those who want more)

• Export a site to Codex CLI, make local changes, and redeploy to get comfortable with the hybrid flow
• Add D1 storage to a form submission so the site keeps data between visits

Useful Resources

• Sites - ChatGPT Learn / OpenAI Developers - Official documentation covering deployment, analytics, access controls, and storage options
• Creating and managing ChatGPT Sites - OpenAI Help Center - Step-by-step guide for creation, sharing, and governance
• ChatGPT Sites - OpenAI Academy - Practical examples and use cases with review steps
• Running Codex safely at OpenAI - Security analysis covering sandboxing, credentials, and audit trails
• Codex for every role, tool, and workflow - Product context for Sites within the broader Codex ecosystem

The Bottom Line

ChatGPT Sites shifts Codex from "AI writes code" to "AI creates, hosts, and helps govern web experiences." It’s strongest for focused internal tools where speed and iteration matter more than framework choice.

The mindset you need: every deploy is production. Save versions before deploying, review generated content carefully, and set access controls on purpose. Building is fast, but governance still sits with your team.

Start with a bounded problem you can measure. A tracker that saves 30 minutes a week beats a flashy demo that doesn’t change anything. Teams that get ROI tend to connect the tool’s capabilities to a specific outcome.