How it works

This page shows what happens between your first message in the studio and a live app that visitors use. It is enough to understand the moving parts and where your data lives. It leaves out the internals.

1. The studio opens a sandbox

Each project is one app. When you open a project in PhiWebs Studio, it starts an isolated sandbox that only this project uses. The sandbox holds the app’s files and the AI coding agent that works on them.

• The agent changes files only inside that sandbox.
• The only credential the sandbox holds is a short-lived token for this one project. It holds no secrets for your connections and none of your passwords.
• After 15 minutes with nothing happening, the project is saved and the sandbox stops. The next time you open the project it starts again from that save, with its files and history.

2. You chat, the agent builds

You describe what you want in the chat. The agent writes the app as files:

• pages,
• data models (app/definitions/entities.json),
• access rules and roles (app/definitions/auth.json),
• starting records (app/content/ and app/data/),
• the packs it uses: blocks, capabilities, patterns and themes from your workspace’s marketplace installs.

After each turn the agent checks the app. Every change is a step in the project’s history, and you can go back to any earlier step. You can also read the files and run the checks yourself. See Working in the studio.

The agent’s AI calls go through the PhiWebs AI gate. They are paid for by your workspace. See AI.

3. The live preview

While the app is being built it runs in a live preview next to the chat. The preview has its own address, separate from the studio. Only your workspace sees it. The preview has its own records, so you can try the app without touching the published one.

4. Publish

When you press Publish, the studio:

1. checks the app. An app with errors is not published;
2. builds it into the web app that visitors load;
3. stores that build as a new version and makes it the live one;
4. writes the project’s starting records into the app’s own data store:
   • app/content/<Model>.json is written on every publish, so the project’s copy wins;
   • app/data/<Model>.json is written only while that model has no records yet, so your visitors’ records are never overwritten;
5. passes your connection secrets to the published app. There they are locked with a key that belongs to that one app.

Publishing again with no changes makes that same version live again. Earlier versions stay stored, so the owner can roll back or unpublish. See Preview, versions and rollback.

The first person to publish an app with an empty people list becomes its first admin.

5. The live app

The app is served at https://<app>.phiwebs.app. Each published app has:

• its own data store for its records, its visitors’ sessions, its people list and its connection secrets. Apps share nothing with each other: no data, no cookies;
• its own access rules, enforced on every request to its records. A data model that no rule names is closed to visitors;
• its own sign-in: none, a PhiWebs account, or your company’s account. The sign-in says who the visitor is. What they may do comes from the app’s roles and its people list;
• its own path to your connections. When the app calls an outside service that needs a secret, the call goes through the app’s own address. The secret is added on the server, and only for the address you set it for. The secret never reaches the visitor’s browser.

The owner keeps working on the live app from the studio: the people list, visitor sign-in, records and connections are all there.

Where things live

Next steps

• API reference: read and write a published app’s records.
• Self-hosting: what an exported app needs to run somewhere else.