Build your private app.Let ChatGPT host the whole thing.
Learn what ChatGPT Sites already offers by building one useful personal command center—not six disconnected demos and not another infrastructure project.
Begin with an outcome, not infrastructure.
One useful app can teach the entire platform.
The application is intentionally ordinary: a private home page where you can save requests, attach reference files, see your own records, and trigger a small number of approved actions. The important part is where it runs and how little infrastructure you need to own.
ChatGPT Sites is the host, identity boundary, storage layer, and operational surface. Your code defines the product and its authorization rules. Everything else must earn its way into the architecture.
The useful parts of a web-app stack, already assembled.
Each capability appears once in the command center. That keeps the entry practical while still covering the whole platform.
Managed hosting
Start from a prompt or compatible local project. Sites builds, stores versions, and deploys a production URL without a separate hosting account.
Prompt → version → deploymentIdentity and access
Keep the whole Site owner-only, share it with selected people, or publish it. Add Sign in with ChatGPT when the app needs identity-aware behavior.
Audience and identity are separateD1 structured data
Persist records that the app must remember: requests, preferences, progress, notes, statuses, and user-owned rows.
Relational application stateR2 file storage
Store uploaded images, documents, audio, video, or other objects. Pair it with D1 when files need searchable metadata.
Durable objects and uploadsOutbound API calls
Call approved external HTTPS APIs from server-side code. Keep their credentials in hosted environment secrets instead of prompts, source files, or browser code.
Short-lived, request-driven integrationsOperations included
Review built-in traffic analytics, connect an owned custom domain where available, restrict access, redeploy approved versions, or take the Site down.
Operate without another dashboardWho can visit is not the same as who they are.
This is the most important Sites concept to get right. Sharing settings protect the front door. Sign in with ChatGPT gives your server a verified identity for personalization and ownership. Keep authorization in server-side code in both cases.
Owner only, selected people, workspace, or public.
Signed-out visitor or verified ChatGPT user.
The server decides which records and actions are allowed.
Six steps. One coherent application.
- 01
Start private
Create the Site with owner-only access. Describe the audience, behavior, and data before describing the visual design.
- 02
Add the identity boundary
Use Site access for who may visit. Use Sign in with ChatGPT inside the app only when records or views must belong to a particular person.
- 03
Store one useful record
Add a small D1-backed inbox—notes, requests, or tasks. Make every row belong to the authenticated user and authorize on the server.
- 04
Add one optional upload
Use R2 for a reference image or document. Keep its searchable metadata and owner relationship in D1.
- 05
Connect one approved service
Call its HTTPS API from server-side code, keep its credential in hosted secrets, and expose one narrow action instead of a generic proxy.
- 06
Review, version, and deploy
Save a reviewable version first. Test the intended visitor experience, then deploy that exact version and inspect its analytics.
Sites is a managed web runtime—not a rented Linux machine.
The platform is enough for this app. It is not a promise that every framework, database, network, or background process will run unchanged. Add outside infrastructure only when a real requirement crosses one of these boundaries.
- Native cron jobs, scheduled events, or continuously active background workers
- Private-network access or APIs that are not reachable over supported outbound HTTPS
- Heavy compute, unusual system packages, or full operating-system control
- A database or hosting pattern outside the supported Sites runtime
- Strict data or inference residency requirements
- Workloads involving payment-card data, financial transactions, or protected health information
Need a schedule? Use a trusted external scheduler to call one narrow, authenticated Site endpoint. Keep the schedule outside; keep the application logic inside.
Private, useful, and good enough to use tomorrow.
At the end, you should have one hosted app with a real access model, durable records, optional files, one safe integration, a reviewed deployment, and no extra server waiting to be maintained.