ChatGPT Sites and Data Persistence: What Building Flowboard Taught Me

I recently built a Kanban board with ChatGPT Sites. I call it Flowboard, and I use it to track work across this blog and several other IdeaVortex projects.

I expected the visual design and task workflow to be interesting. What surprised me most was a less visible question: where does the data live, and what does “saved” really mean when I return from another device?

That question turned a useful board into an architectural exercise. It also showed me how quickly ChatGPT Sites can move an idea from conversation to a hosted application, and how much important design work begins after the first version looks finished.

A Site Can Look Persistent Without Being Shared

A browser application can save information with APIs such as localStorage or sessionStorage. These tools are useful, but they solve a narrower problem than many users assume.

• sessionStorage is temporary state associated with a browser tab or session.
• localStorage can survive reloads and later visits, but it remains tied to a particular browser profile, device, and web origin.
• Neither one is automatically a centralized database or a multi-user identity system.

This distinction matters. A board can appear to remember everything on my laptop and still look empty when I open it elsewhere. It can also store data in a shared browser profile without actually knowing which human is using that profile.

A ChatGPT Sites interface may say “saved,” but the architectural question remains: saved where, for whom, for how long, and under whose control?

The Encrypted-Sync Idea

Flowboard now uses a practical local-first, zero-knowledge sync design. Each browser keeps a usable local copy of the board. When I enable private sync, the browser derives an encryption key from a passphrase that I choose, encrypts the complete board before it leaves the device, and sends only an unreadable encrypted envelope to a Sites-managed D1 database.

ChatGPT sign-in identifies the owner whose encrypted record may be retrieved. On another signed-in device, I enter the same passphrase so the browser can download and decrypt that record. The server never receives the passphrase or the plaintext tasks. The browser remembers the derived key on that device so normal return visits can reconnect without making me type the phrase every time.

This first implementation deliberately favors simplicity. It synchronizes one encrypted snapshot of the whole board, with the most recent save replacing the earlier one. D1 is still a centralized availability layer, even though it cannot read the task content. If I lose the passphrase and every device that already holds the key, there is no password reset that can recover the board.

That is what exists today. A more ambitious multi-user version would need a different key model: a random key for each board, separately protected for every approved user or device. That pattern is often called envelope encryption. It would also need revisions that merge safely, member roles, invitations, revocation, recovery, and clear handling of a lost or stolen device.

The important point is not merely that a key exists. Encryption does not automatically make a design secure. Browser security, malicious scripts, backups, metadata, conflict handling, and recovery all remain part of the real system.

What ChatGPT Sites Supports Now

At the time of writing, OpenAI describes Sites as a public-beta service for creating, hosting, refining, and sharing websites and web applications. A Site can be a persistent hosted output that remains available after the original conversation ends.

OpenAI’s current pricing documentation says Sites is included with eligible ChatGPT plans during the beta, but it does not promise availability to every Plus account. Plan, region, workspace settings, rollout, and plan-specific limits can affect which accounts can create Sites or add storage. The Sites interface shown in an account is the practical indicator of current eligibility.

More importantly for ChatGPT Sites application architecture, the platform now documents several managed capabilities:

• D1 relational storage for durable structured records such as tasks, memberships, progress, and revisions.
• R2 object storage for uploaded images, documents, audio, video, and other files.
• Sign in with ChatGPT for identity-aware features on public Sites.
• Workspace identity and sharing controls for Sites intended for an internal audience.
• Saved versions and deployments, separating a reviewable build from the production release.

This means browser-only storage is no longer the only path to cross-device persistence. Flowboard combines these capabilities: D1 supplies durable availability, ChatGPT sign-in identifies the owner, and browser-side encryption keeps the hosted copy unreadable. A less private Kanban board could store ordinary task records in D1 and rely on server-side authorization alone.

Encryption can still be valuable when the goal is different: protecting the content so that the hosting layer stores ciphertext rather than readable board data. Managed persistence and end-to-end confidentiality are related, but they are not the same requirement.

Four Persistence Choices and Their Tradeoffs

Approach	What it does well	Main tradeoff
Browser-only storage	Fast, simple, private to the local browser, and useful offline	Not naturally cross-device or multi-user; clearing browser data can remove it
Managed D1 storage	Durable records, centralized queries, backups, and simpler collaboration	The application and hosting layer can normally read the stored data
Encrypted synchronized state	Cross-device access while keeping board content protected from the storage layer	Key management, recovery, revocation, migrations, and conflict resolution become harder
Hybrid local-first design	Responsive offline work combined with durable synchronization	Requires careful merging, versioning, and a clear source-of-truth policy

There is no universal winner. The correct choice depends on what the application promises. A personal scratchpad, a shared family board, and a confidential commercial workspace should not inherit the same threat model by accident.

A Proposed Architecture for Multiple Users

If I extend Flowboard into a secure multi-user application, I would separate identity, authorization, storage, and encryption rather than treating them as one feature.

1. Identity: Use Sign in with ChatGPT or workspace authentication to establish who is making each request.
2. Membership and roles: Store projects, invitations, members, and roles in D1. Authorization remains a server-side decision even when the content is encrypted.
3. Device keys: Enroll each authorized device with a public/private key pair. The private portion should never be sent to the application server in plaintext.
4. Project key: Give each board or project a random data-encryption key. Use it to encrypt tasks, notes, comments, and revision payloads.
5. Key wrapping: Encrypt, or wrap, the project key separately for every authorized member or device. Adding a collaborator creates another wrapped copy; it does not require exposing the project key to every visitor.
6. Durable storage: Store memberships, encrypted revisions, wrapped keys, and synchronization metadata in D1. Store encrypted attachments in R2.
7. Conflict handling: Give every change a stable identifier and revision number. Detect simultaneous edits and merge compatible changes instead of silently allowing the last save to erase someone else’s work.
8. Revocation: When access is removed, rotate the project key for future changes and rewrap it only for remaining members. Revocation cannot make a copy that someone already downloaded disappear, so the product must state that limitation honestly.
9. Recovery: Decide whether recovery is possible and who controls it. Strong end-to-end encryption without a recovery path can make lost keys equivalent to lost data.

What This Could Enable with ChatGPT Sites

The same capability extends beyond a Kanban board. Sites could support focused applications such as:

• Private project boards that follow a user across devices.
• Creative workspaces where musicians, visual artists, and collaborators exchange drafts and decisions.
• Collector or commission rooms with controlled access to developing artwork and video material.
• Offline-first field tools that synchronize when a connection returns.
• Small internal products that begin as one useful workflow and grow only when the need becomes real.

For an entrepreneur, that last point is especially interesting. With ChatGPT Sites, a conversation can become a working interface, then a hosted tool, then a tested product idea. The distance between imagining and evaluating a system has become much shorter.

The Interface Was the Beginning

Flowboard impressed me because ChatGPT Sites helped create a useful application quickly. But the deeper lesson came from asking what the application should remember, who should be allowed to see it, and how that trust should travel between devices.

Persistence is not a checkbox. It is a set of promises about identity, durability, confidentiality, recovery, and collaboration.

That is where a working interface becomes an architecture. It is also where an experiment can begin to look like a product.

Technical note: The multi-user encrypted design in this article is a proposed architecture, not a security certification. Any production implementation should receive focused threat modeling, cryptographic review, privacy review, and adversarial testing.