From ChatGPT Sites prototype to self-hosted production with FrontierStack

Published 2026-08-28

ChatGPT Sites is a good place to answer one question quickly: should this idea exist? You can describe an experience, try it in a browser, show it to a few people and change direction before a conventional production project would have finished its setup.

Once the answer is yes, the questions change. Who owns the domain? Where are the source and data backed up? How do releases get reviewed? Who watches the certificate at 3 a.m.? That is where self-hosting, and FrontierStack, become useful.

This is not an automatic account export. FrontierStack works from a local Sites project that you own and a build you have reviewed. It can also help you keep a Site on ChatGPT hosting while moving it to your own domain. Those are separate paths, and choosing the right one saves a lot of unnecessary work.

Use Sites as a workshop, not an accidental production process

OpenAI describes Sites as a public beta for creating, hosting and sharing websites, web apps and games. It can start with a prompt or a compatible local project. That makes it unusually good for finding the shape of a product before the hosting architecture hardens around the first guess.

There is one detail worth knowing early. Every Sites deployment URL is a production deployment. If you only want a review candidate, ask ChatGPT to save a version without deploying it. Keep access limited while you inspect the content, forms, links, data handling and sign-in behavior. OpenAI documents that review flow in its Sites guide.

Ideas that are worth trying in Sites first

• An operations dashboard. Start with sample data and settle the layout with the people who will use it. Production can later read a monitored API or database on your own network.
• A request tracker or approval tool. Test the fields, states and handoffs before choosing the permanent identity system and record store.
• A customer calculator. Try pricing, sizing, energy, capacity or migration estimates. Move it when the calculation becomes business logic that needs tests and controlled releases.
• An event or launch site. Use Sites for copy, schedule experiments and stakeholder review. Self-host the approved version when the domain, analytics and uptime need one owner.
• A small game or interactive explainer. Find out whether people understand the interaction before spending time on a production backend.
• An internal portal. Prototype navigation and workflows with a narrow audience. Treat identity and authorization as production work, not details to copy at the end.

The useful pattern is the same in each case. Sites shortens the conversation between an idea and something people can touch. FrontierStack takes over when the result needs a domain, a server, certificates, monitoring, backups and a release process you control.

Path one: keep ChatGPT hosting and use your domain

Self-hosting is not always the next step. If the Site runtime, storage and sharing controls fit the job, leave the application on ChatGPT and connect a domain you own. You keep the fast Sites editing and deployment flow while presenting an address that belongs to you.

In FrontierStack, add the Site in the Sites pane and choose Import or Move, then Use my domain. Add the domain in ChatGPT Sites first. ChatGPT supplies the exact DNS records. FrontierStack can publish those records through a connected Cloudflare account, or record the domain after you add them at another DNS provider. It never guesses a verification record.

The public Site then joins Domain Health beside your other websites. FrontierStack checks DNS, HTTP, TLS and the serving host. Keep workspace-only or owner-only Sites marked private so an outside login wall does not become a false outage.

Path two: move a reviewed build to your server

Choose this path when you need control over the runtime, deployment schedule, logs, data location or surrounding network. It starts with the source project, not the public URL.

1. Keep a local project. A hosted Site can exist without one, but FrontierStack cannot reconstruct the project by scraping its public pages. Start from a local Sites project or bring the work back into a source folder you own.
2. Review and build it. Put the project under version control. Run its normal build and inspect the output. The production candidate needs an index.html in the project root or a conventional dist, build, out or public folder.
3. Inspect it in FrontierStack. Open Sites > ChatGPT Sites > Import or Move > Self-host and choose the local project. FrontierStack reads the package metadata and .openai/hosting.json when present. It identifies the framework, deployable folder, project link, D1 and R2 binding names, and environment key names.
4. Choose the destination. Enter the production domain and document root. FrontierStack copies the reviewed web files and can create and apply a managed Apache site. It records the source project against the domain so the relationship remains visible.
5. Replace platform services deliberately. Move data, uploads, authentication and server routes using tools made for those systems. Re-enter environment values from your secret store. Test the self-hosted result before changing public DNS.
6. Make the cutover observable. Issue TLS, check the public route, enable health and certificate alerts, and keep the previous Site restricted rather than deleting it immediately. Rollback should be a DNS or deployment decision, not a rescue exercise.

What FrontierStack imports

The beta importer copies deployable static files from the folder you select. It uses a staging directory, limits imports to 50,000 files or 5 GB, and can replace a document root only when you enable that option. It skips .git, .openai, node_modules, SSH material, environment files, common credential files and symbolic links.

FrontierStack does not run npm scripts or any other package script during import. That is intentional. A migration button should not execute project code merely because a folder was selected. You build first, review the result, then choose the files to serve.

The limitations matter

• No account-wide import. OpenAI does not document an external Sites enumeration or export API. FrontierStack cannot sign in, list every Site and download them on your behalf.
• No hosted-only source recovery. A URL is not a source project. If the Site exists only on ChatGPT hosting, you need to obtain or recreate a local project before using the self-host importer.
• D1 data does not move with the build. The manifest can reveal a binding name, but FrontierStack cannot export the hosted database. Plan a schema, export and validation process separately.
• R2 uploads do not move with the build. File storage needs its own owner-controlled transfer and integrity check.
• Hosted secrets stay hosted. FrontierStack reads key names from example files but never reads secret values. Add the production values to the destination secret store yourself.
• Analytics history stays in Sites. Choose and configure production analytics before cutover if continuity matters.
• ChatGPT identity is not portable authentication. Workspace access and Sign in with ChatGPT rely on the Sites runtime. A self-hosted app needs its own identity provider, sessions and authorization checks.
• Server code may need rewriting. Functions, workers, WebSockets, background tasks and platform-specific routes are not static assets. Adapt them to PHP, Node, Go or another runtime on the destination, then test them as production code.

These are not small footnotes. A static brochure or calculator may move in one pass. A shared app with accounts, uploads and durable records is a software migration. FrontierStack identifies the work and handles the deployable files; it does not pretend that copying HTML moved a database.

Use a domain you own before the idea becomes important

A custom domain gives you room to change the hosting later. During the experiment it can point to ChatGPT Sites. When the self-hosted version is ready, the same domain can move to infrastructure you control after you have tested certificates, redirects and monitoring.

Do not print, advertise or deeply integrate a provider URL if you already suspect the project may become a product. The code is often the easy part to move. The address that users bookmarked is harder.

Know when to stay in Sites

Stay on ChatGPT Sites when the hosted runtime fits, the beta limits are acceptable, and speed matters more than infrastructure control. A small internal tool, a short-lived event page or an experiment with a handful of users may never need another hosting system.

Move when you need a runtime Sites does not support, direct access to logs and backups, private network connections, a different data location, a mature release process, or a permanent service that must remain independent of one hosted product. The move should answer a real requirement. Owning a server creates work as well as control.

A sensible prototype-to-production rule

Let ChatGPT Sites make changing your mind cheap. Keep the source local once the idea starts to matter. Give the project a domain you own. When the product needs production controls, use FrontierStack to inspect the build, expose the missing migration work, place the reviewed files in a managed site and watch the result like the rest of your infrastructure.

That division is practical. Sites helps you discover what to build. FrontierStack helps you take responsibility for running it.

Read the website hosting guide, the Sites and domains manual chapter, and OpenAI's current Sites documentation before a production move.