# Welcome to Layerwise

Source: https://layerwise.app/docs

Understand the Layerwise workflow, from an idea to a live full-stack web app.





Layerwise is an AI workspace for building full-stack web apps from your computer. Describe what you want to make, iterate on real project files with an assistant, test the app locally, and publish a production release when it is ready.

![Layerwise project workspace with the conversation, local preview, and Publish control marked](/docs/screenshots/workspace.webp)

*The workspace brings together (1) the conversation, (2) the local preview, and (3) Publish.*

## How Layerwise works [#how-layerwise-works]

Layerwise organizes work around teams and projects:

* A **team** owns projects, members, a subscription, and usage credits.
* A **project** is one web application with a local workspace, conversations, preview, source code, and release history.
* A **conversation** is where you ask the assistant to create or change the project.
* A **release** is an immutable production deployment that you can inspect or roll back to.

You can work in the built-in editor or open the same local workspace in an installed editor, terminal, or file manager.

## Included with every project [#included-with-every-project]

Every project ships with a working backend — no third-party accounts, API keys, or external services to wire up:

* **Built-in analytics** — see pageviews, estimated visitors, traffic sources, and more for your published website. Filter reports and export them to CSV. See [Analytics](/docs/deploy/analytics).
* **Backend logs** — inspect local and published requests, follow incoming logs live, and export debugging context. See [Logs](/docs/deploy/logs).
* **Built-in database** — a dedicated database is provisioned automatically and bound to your app, with schema migrations applied on each release. See [Database](/docs/deploy/database).
* **Built-in Storage** — every project can save and serve images, videos, documents, and other files, with private links, public URLs, and a 7-day trash. See [Storage](/docs/deploy/storage).
* **Built-in authentication** — email-based sign in, email verification, and password reset are wired in from the first release. This includes the transactional **authentication emails** your app sends, so you do not need a separate auth provider or email delivery service. See [Authentication](/docs/deploy/authentication).
* **Built-in email** — published apps can send transactional email such as receipts and order updates. While you test, email from the local preview lands in the Layerwise app instead of real inboxes. See [Email](/docs/deploy/email).

Describe the app, and the data and login layers are already there — for prototypes and production apps alike.

## The product workflow [#the-product-workflow]

1. [Create a project](/docs/getting-started/quickstart) from a detailed prompt.
2. [Build and preview](/docs/build-your-app/chat-and-preview) it locally with the assistant.
3. [Direct the agent](/docs/build-your-app/direct-the-agent) with plans, goals, and [approvals](/docs/build-your-app/approvals-and-changes), and extend it with [skills and MCP servers](/docs/build-your-app/skills-and-mcp). You can also [build with your ChatGPT plan](/docs/build-your-app/codex).
4. [Edit the code and connect GitHub](/docs/build-your-app/code-and-github) when you need direct control.
5. [Publish the project](/docs/deploy/publish), then manage releases and domains.

## Models [#models]

Choose a model available on your team's plan when you create a project or start a conversation. Prices below are per 1 million tokens.



## Who Layerwise is for [#who-layerwise-is-for]

Layerwise is for people who want to turn a product idea into a working application, as well as developers and teams who want local code ownership alongside AI-assisted iteration. Use it for prototypes, internal tools, customer-facing applications, and small production services.

## Start here [#start-here]

If this is your first project, follow the [Quick start](/docs/getting-started/quickstart). If you already have a project, go to [Build](/docs/build-your-app/chat-and-preview) or [Deploy](/docs/deploy/publish) for the task at hand.



---

# Manage your account and GitHub

Source: https://layerwise.app/docs/account/account-and-github

Connect GitHub for project repositories and manage account deletion.



Open **Account** from the user menu to manage your Layerwise account.

## Connect GitHub [#connect-github]

Select **Connect GitHub** to authorize Layerwise for repository operations. Once connected, you can create and connect a repository from a project workspace.

Use **Reconnect** if you need to authorize the connection again.

![Account settings showing the GitHub connection; account details are blurred](/docs/screenshots/account.webp)

*Manage your GitHub connection from Account. Personal account details are blurred.*

## Delete your account [#delete-your-account]

Delete your account from the Layerwise desktop app. Deletion is permanent: it removes your account and associated server data, deletes every team you own and its projects, and cancels those teams' paid plans.

If you want a team to remain available to its members, transfer its ownership before deleting your account. The confirmation dialog lists the teams that will be deleted and provides a **Transfer** button for each one.

1. Open the user menu and select **Account**.
2. Under **Danger Zone**, select **Delete Account**.
3. Review the teams listed in the confirmation dialog. If **Delete local folders** is shown, it is on by default. Turn it off to keep the project code on this computer; the account and server data will still be deleted.
4. Type the **account email** shown in the dialog exactly, then select **Delete Account** to confirm.

After successful deletion, Layerwise signs you out.


---

# Manage billing and usage

Source: https://layerwise.app/docs/account/billing-and-usage

Review your team's plan, credits, costs, and invoices.



Billing and usage are managed per team.

## Billing [#billing]

Open **Billing** to view and manage the current subscription, available plans, additional credits, payment methods, and invoices.

![Team Billing page showing subscription controls with financial details blurred](/docs/screenshots/billing.webp)

*Review the active team's plan and billing options. Financial details are blurred.*

## Usage [#usage]

Open **Usage** to review model usage, costs, plan-credit consumption, and project activity for a selected period.

![Team Usage page showing usage and cost summaries with financial details blurred](/docs/screenshots/usage.webp)

*Review usage for the active team and selected period. Financial details are blurred.*

Chats that use [My Codex](/docs/build-your-app/codex) draw on your ChatGPT plan, so they don't use credits and aren't included in Usage.

The model picker only permits models available on the active team's plan. If you reach a model or usage limit, review the current plan and available credits, then retry after updating the plan or credits.


---

# Approvals and file changes

Source: https://layerwise.app/docs/build-your-app/approvals-and-changes

Choose what the agent can do without asking, respond to approval requests, and review the files each turn changed.



The approval mode decides which actions the agent takes on its own and which need approval first. After each turn, the conversation lists the files that changed so you can review them.

## Choose an approval mode [#choose-an-approval-mode]

Choose the approval mode button in the message box to change it. The mode applies to the current conversation, and every new conversation starts in **Approve for me**.

| Mode                         | The agent can                                                           | Approval for everything else                                                                      |
| ---------------------------- | ----------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- |
| **Ask for approval**         | Read the project.                                                       | You. The agent asks before it edits files or runs commands.                                       |
| **Approve for me** (default) | Edit files and run commands inside the project, without network access. | An automatic review decides on network access and changes outside the project. You are not asked. |
| **Full access**              | Edit any file and run commands with network access.                     | None. The agent never asks.                                                                       |

In **Approve for me**, if the automatic review declines an action, Layerwise shows **An action could not be approved. Review the request and try again.** To decide on the action yourself, switch the conversation to **Ask for approval** and send the request again.

Use **Full access** only for work you trust; the agent can change files outside the project and reach any network address.

## Respond to an approval request [#respond-to-an-approval-request]

In **Ask for approval**, the agent stops before it acts and shows an approval card. The card states why the agent needs the action, then shows what it will do:

* **Commands** — the command and the folder it runs in.
* **File changes** — each file to **Create**, **Modify**, or **Delete**, with its diff.
* **Network access** — the address the agent wants to reach.

Then choose:

* **Allow once** — approve this action only.
* **Allow for session** — approve it, and stop asking about the same action for the rest of the session.
* **Decline** — refuse the action. The agent continues without it.
* **Cancel** — refuse the action and end the turn.

Some requests offer more choices, such as always allowing a command or always allowing or blocking a network host.

## Review the changes [#review-the-changes]

When a turn finishes, the conversation summarizes it, for example **3 files changed**, with the lines added and removed. Each file is marked as added (**A**), modified (**M**), deleted (**D**), or renamed (**R**).

* Expand a file to read its diff.
* Copy a file's diff with its copy button, for example to share it or paste it into another tool.
* When more than three files changed, choose **Show *n* more files** to list the rest.

Expand **Worked for** to see each step the agent took during the turn. File paths in the agent's replies open in the built-in editor.

To undo a change, ask the agent to revert it. To change the code yourself, see [Edit the code and connect GitHub](./code-and-github).


---

# Build and preview a project

Source: https://layerwise.app/docs/build-your-app/chat-and-preview

Make changes through the project conversation, point to parts of the page, and verify the result in the local preview.



The project workspace places the conversation and local preview side by side. Use the conversation to request a focused change, then use the preview to confirm the result.

## Continue the conversation [#continue-the-conversation]

Write the next task in the conversation panel. State the desired outcome and constraints that matter. Keep related work in the same conversation; use the project sidebar to switch to another conversation when you are starting a different thread of work.

To plan before building, set a longer-running goal, or queue requests while the agent works, see [Direct the agent](./direct-the-agent).

## Test the preview [#test-the-preview]

The preview header lets you:

* Select desktop, tablet, or phone widths.
* Refresh the local preview.
* Open the preview in your default browser.
* Show or hide preview logs from **Project actions**.

![Preview header with device widths, refresh, browser opening, and Project actions marked](/docs/screenshots/preview-controls.webp)

*(1) Change the preview width, (2) refresh, (3) open in your browser, or (4) open Project actions to show the console.*

Test the user path affected by the change, rather than only checking whether a screen rendered.

## Point to part of the page [#point-to-part-of-the-page]

The local preview shows a small Layerwise toolbar, in the bottom-left corner by default. Use it to show which part of the page your next message is about. Published sites do not include the toolbar.

* **Grab page element** selects one element, such as a button or heading. Use it when the change belongs to a specific element.
* **Annotate page** lets you draw on a capture of the preview. Use it for layout, spacing, or changes that span several areas.

### Select an element [#select-an-element]

1. Click **Grab page element** in the preview toolbar.
2. Move the pointer over the page. Layerwise outlines the element under it and labels its tag, text, and size.
3. Click the element. A **1 selection** chip appears above the message box.
4. Describe the change and send the message.

The selection tells the agent which element you mean, including its text, HTML, size, and main styles. For elements written in your project's code, it also includes the source file and line that render them. You can attach one element at a time; grabbing another replaces it. Press Esc to stop selecting, or use the chip's remove button to discard the selection.

### Annotate the preview [#annotate-the-preview]

Annotations are sent as images, so the selected model must support image input.

1. Scroll the preview to the area you want to mark. Only the visible part of the page is captured.
2. Click **Annotate page** in the preview toolbar.
3. Draw on the capture with the pen, highlighter, arrow, rectangle, ellipse, or text tool. You can also change the color and line width. In a narrow preview, these tools are under **More annotation tools**.
4. Click **Save**. The marked-up image is attached to your message.
5. Describe the change and send the message.

Use Command+Z or Ctrl+Z to undo, and add Shift to redo. Click **Cancel** or press Esc to discard the annotation.

### Move or hide the toolbar [#move-or-hide-the-toolbar]

Open the toolbar's menu and choose **Toolbar position** to move it to another corner or edge, or **Hide toolbar** to remove it from the page. To bring it back, open **Project actions** in the preview header and choose **Show toolbar**.

## Let the agent test its work [#let-the-agent-test-its-work]

The agent can use the local preview to check a change before it reports back. It opens pages, clicks, types, scrolls, reads the page content and console errors, and takes screenshots, then fixes what it finds and checks again. Each step appears in the conversation.

For the agent to use the preview:

* Show **Preview** rather than the **Built-in editor** in the workspace, and keep the preview loaded.
* Choose a model that supports image input if you want the agent to read screenshots. Other models check the page through its content instead.

Screenshots capture only the visible part of the preview, at the width you selected. The agent can only act on your app: external links, form submissions to other sites, and navigation away from the preview are blocked.

To ask for a specific check, describe the path to test, such as “Add a habit, mark it done, and confirm the streak goes up by one.”

## Fork an experiment [#fork-an-experiment]

Open the three-dot menu beside the conversation title and choose **Fork project** to create a separate project from the current state. A fork does not copy the GitHub connection, custom domains, or release history.

Use a fork to explore an alternative direction while preserving the original project.

## When the preview is not ready [#when-the-preview-is-not-ready]

Wait for workspace setup to finish, then refresh the preview. If it still fails, open the preview console and follow [Preview does not load](../reference/troubleshooting#preview-does-not-load).


---

# Work with project code

Source: https://layerwise.app/docs/build-your-app/code-and-github

Edit the local workspace, export it, or create a connected GitHub repository.



Layerwise keeps each project's source in a local workspace. Assistant changes and changes you make yourself use those same files.

## Use the built-in editor [#use-the-built-in-editor]

1. Open the mode menu in the preview header.
2. Choose **Open in** → **Built-in editor**.
3. Select a file, make the edit, and save it.
4. Return to **Preview** and refresh the app.

![Built-in editor showing the project file tree and source code](/docs/screenshots/editor.webp)

*Select a file in the tree to edit the same source used by the local preview.*

The file tree supports creating, renaming, and deleting files or folders. Markdown files can be previewed. Binary files and files larger than 10 MB cannot be edited inline.

## Open the workspace elsewhere [#open-the-workspace-elsewhere]

The **Open in** menu lists supported installed editors, terminals, and file managers. Select one to open the same local workspace in that app.

![Open in menu listing the built-in editor and installed apps for opening the workspace](/docs/screenshots/open-in.webp)

*Open in lets you choose the built-in editor or an installed app for the project workspace.*

If an app is not listed, use a listed file manager to open the workspace folder.

## Export a project [#export-a-project]

Open the three-dot menu beside the conversation title and choose **Export ZIP** to save a ZIP archive of the current local workspace.

![Conversation header menu with Fork project, Export ZIP, and Star project](/docs/screenshots/project-menu.webp)

*The menu beside the conversation title contains project copying and export actions.*

## Connect GitHub [#connect-github]

1. In **Account**, select **Connect GitHub** if you have not connected it yet.
2. In the project preview header, select the GitHub icon.
3. Choose the owner, repository name, description, homepage, and visibility.
4. Select **Create repository**.

Layerwise creates and connects the repository. The page then shows **Repository settings**, where you can open the repository, change its settings, or select **Disconnect repository**. Disconnecting removes the project link; it does not delete the GitHub repository.


---

# Build with your ChatGPT plan

Source: https://layerwise.app/docs/build-your-app/codex

Connect Codex to Layerwise and build with your ChatGPT plan's Codex usage instead of Layerwise credits.



If your ChatGPT plan includes Codex, you can use it to build in Layerwise. Chats that use **My Codex** run on the Codex installed on your computer and draw on your ChatGPT plan instead of your team's Layerwise credits. You can switch any chat between Layerwise and My Codex whenever you like.

My Codex works on every Layerwise plan.

## Before you start [#before-you-start]

* Install the ChatGPT app or the Codex CLI on your computer.
* Sign in to Codex with your ChatGPT account. API key sign-in isn't supported.

## Connect Codex [#connect-codex]

1. Open **Account** from the user menu and find the **My Codex** card.
2. Choose **Connect**.

Layerwise uses your existing Codex sign-in, so there's nothing else to log in to. The card then shows **Connected**, the signed-in account, and its plan. If Codex isn't found or isn't signed in, the card says what to fix. Fix it, then choose **Connect** again.

The connection is saved for you on this device. Each teammate connects their own Codex account, and no one can build with another member's account.

To see which Codex Layerwise found and whether it's compatible, open the card's menu and choose **Connection details**.

## Build with My Codex [#build-with-my-codex]

1. When you create a project or start a chat, open the model picker.
2. Under **Agent**, choose **My Codex**.
3. Choose a **Model** and an **Effort** level. The list comes from your Codex account.

Layerwise remembers your choice for new projects and chats. A My Codex chat has the same project tools, preview, skills, MCP servers, and permission modes as any other chat. If you change the model or effort while a task is running, the change applies to the next message.

## Switch a chat's agent [#switch-a-chats-agent]

You can move a chat between Layerwise and My Codex at any time. For example, switch to My Codex when your team's credits run out, or back to Layerwise when a Codex limit is reached.

1. Open the chat's model picker.
2. Under **Agent**, choose **Layerwise** or **My Codex**.

The chat keeps its history, and the new agent picks up where the conversation left off. It starts with that agent's default model, which you can change in the same picker. The first message after a switch takes a little longer while the new agent reads the chat's history.

Switching happens between messages. Wait for any running task to finish, and send or clear any queued messages. If the chat has an unfinished goal, clear it first.

## Usage and limits [#usage-and-limits]

* **Credits** — My Codex chats don't use Layerwise credits and don't appear in Usage Details. See [Manage billing and usage](/docs/account/billing-and-usage).
* **Codex usage** — The **My Codex** card shows how much of each Codex limit remains and when it resets. When a limit is reached, wait for the reset or switch the chat to Layerwise.
* **Plan limits** — Your Layerwise plan's daily message limit and project limit still apply. On Free, that's 10 messages a day across all chats.

## Privacy [#privacy]

* Codex sends model requests from your computer directly to OpenAI. Your Codex sign-in stays on your computer.
* Your personal Codex MCP servers, plugins, and hooks are turned off in Layerwise chats, and Layerwise doesn't change your Codex settings.
* Like any Layerwise chat, a My Codex chat's history is saved with the project and syncs across devices, so project members can read it.
* Project and chat names come from your first message rather than a Layerwise model.

## Troubleshooting [#troubleshooting]

| Problem                                          | What to do                                                                                                                                      |
| ------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------- |
| Codex isn't installed or found                   | Install the ChatGPT app or the Codex CLI, then check again on the **My Codex** card.                                                            |
| Codex needs a ChatGPT account or isn't signed in | Sign in to Codex with your ChatGPT account in the ChatGPT app or the Codex CLI, then check again.                                               |
| Your Codex version isn't supported               | Open **Connection details** to see the version Layerwise found. Update the ChatGPT app or the Codex CLI, then check again.                      |
| Your Codex account reached its usage limit       | Check the reset time on the **My Codex** card, or switch the chat to Layerwise.                                                                 |
| The model is unavailable to your Codex account   | Choose another Codex model.                                                                                                                     |
| The Codex account for this chat changed          | Stop any running task, then choose **Reconnect My Codex** in the chat. The chat's history stays, and the next message uses the current account. |


---

# Direct the agent

Source: https://layerwise.app/docs/build-your-app/direct-the-agent

Plan before building, set a goal for longer work, queue follow-up requests, stop a turn, and answer the agent's questions.



The agent works through each message you send in the conversation. These controls change how it works: agree on a plan first, keep it going toward a larger goal, line up your next requests, and give it a decision when it asks for one.

## Open the command menu [#open-the-command-menu]

Type `/` at the start of the message box, or after a space, to open the command menu. It lists:

* **Commands** — **Plan mode** and **Goal**.
* **Skills** — the skills turned on for this project. See [Skills and MCP servers](./skills-and-mcp).

Keep typing to filter the list. Use the arrow keys to move, Enter or Tab to choose, and Esc to close the menu. **Plan mode** and **Goal** are also in the **+** menu beside the message box.

While the agent is working, the command menu lists only skills.

## Plan before building [#plan-before-building]

Turn on **Plan mode** when you want to agree on an approach before the agent changes the project. A **Plan** chip appears in the message box, and the agent answers with a plan for you to review.

When the plan is ready, Layerwise asks **Implement this plan?** Choose **Implement plan** to have the agent carry it out in the default mode, or **Cancel** to keep refining it. Plan mode stays on for the conversation until you choose **Exit Plan mode** on the chip.

## Set a goal [#set-a-goal]

Use a goal for work that needs many turns, such as “Build the complete onboarding flow and check every step at phone width.” The agent keeps working, turn after turn, until the goal is complete, you pause it, or it needs your input.

1. Type `/` and choose **Goal**. A **Goal** chip appears in the message box.
2. Describe the objective and send the message.

The goal bar above the message box shows the goal's status, its objective, and how long it has been running. Use it to:

* **Pause goal** or **Resume goal**.
* **Edit goal** to change the objective.
* **Clear goal** to remove it. A conversation has one goal at a time, so clear the current goal before starting another.
* **Show goal details** to see how many tokens the goal has used.

A message you send while the agent works on a goal steers the current work instead of waiting in the queue. Stopping the agent pauses the goal. A goal is also paused when Layerwise reloads the conversation, for example after a restart. Choose **Resume goal** to continue.

A goal does not stop after a set number of turns or minutes. Check its progress from time to time, and pause it if the work heads in the wrong direction.

## Queue your next request [#queue-your-next-request]

You can keep writing while the agent works. Messages you send are added to **Queued prompts** above the message box and run in the order you added them, each after the previous turn ends.

* Choose **Edit queued prompt** to change a prompt's text, or **Delete queued prompt** to remove it.
* To change the order, delete a prompt and send it again.
* Queued prompts are kept when you quit Layerwise.

If a turn fails or you stop it, the queue pauses and shows **Queue paused. Resume when you’re ready.** Choose **Resume queue** to continue. Sending another prompt also resumes it.

Wait for queued prompts to finish before you start a goal.

## Stop the agent [#stop-the-agent]

While the agent works and the message box is empty, choose **Stop** to end the current turn. The conversation marks the turn **Cancelled by you.** Changes the agent made before you stopped it remain in the project.

## Answer the agent's questions [#answer-the-agents-questions]

When a decision is yours to make, the agent asks instead of guessing. Its question takes the place of the message box until you answer; anything you had typed is kept.

* Choose one of the options, each with a short description. When **Other** is offered, choose it to write your own answer.
* Some questions ask for text. Secret values, such as API keys, use a masked field.
* When the agent asks several questions, they appear one at a time. Choose **Next** after each answer and **Submit** after the last one.

The agent waits until you submit your answers.


---

# Skills and MCP servers

Source: https://layerwise.app/docs/build-your-app/skills-and-mcp

Teach the agent your conventions with skills, and connect tools from other services through MCP servers.



A **skill** is a set of instructions the agent can follow for a kind of task, such as your stack's conventions or a design process. An **MCP server** gives the agent tools from another service, such as reading a design from Figma or querying an issue tracker.

## Personal and project settings [#personal-and-project-settings]

Skills and MCP servers can be added in two places:

* **Personal** — Open **Account** from the user menu, then choose **Skills** or **MCP Servers**. Personal skills and servers are available in all your projects on this device.
* **Project** — In the project sidebar, open **Settings**, then choose **Skills** or **MCP Servers**. Project skills and server definitions are saved in the project's repository, so everyone who works on the project gets them. Whether each one is turned on is your own setting.

Personal skills and servers also appear in each project's settings. You can turn them on or off there, but edit them from your personal settings.

Changes apply to the next message you send; a turn already running keeps its settings. If the project settings ask you to prepare the workspace, open a conversation in the project first.

## Skills [#skills]

### Install a skill from skills.sh [#install-a-skill-from-skillssh]

1. In **Discover skills**, search for a skill.
2. Choose a result to read its files, or choose **Install** to add it.

### Add your own skill [#add-your-own-skill]

Choose **Add skill**, then one of:

* **Create skill** — Write the skill in Layerwise.
* **Import from GitHub** — Enter a repository or folder URL. Optionally, enter the skill's directory and a branch, tag, or commit. Layerwise copies the skill folder and its files without running any scripts.
* **Import folder** — Choose a skill folder on your computer.

A skill is a folder with a `SKILL.md` file. The file starts with a name and a description:

```md
---
name: release-notes
description: Write release notes in the team's format. Use when asked for release notes or a changelog entry.
---

1. List the user-facing changes since the last release.
2. Group them under Added, Changed, and Fixed.
```

The name uses lowercase letters, numbers, and hyphens, up to 64 characters. The description can be up to 1,024 characters; write it so the agent can tell when the skill applies. An imported skill can be up to 20 MB and 1,000 files, and cannot contain symbolic links.

Project skills are stored in the repository's `.agents/skills` folder.

### Manage skills [#manage-skills]

Use the switch beside a skill to turn it on or off, and its menu to **Edit** or **Remove** it. **Built-in** skills come with Layerwise and cannot be edited or removed.

### Use a skill in a message [#use-a-skill-in-a-message]

Type `/` in the message box and choose the skill under **Skills**. It is added to the message as `$skill-name`, and the agent follows it for that request. The agent can also use a skill that is turned on without being asked, when your request matches its description.

## MCP servers [#mcp-servers]

### Add a server [#add-a-server]

1. Choose **Add server**.
2. Enter a **Server ID**, such as `figma`. It can contain letters, numbers, `_`, and `-`, and cannot be changed later.
3. Choose a **Connection type**:
   * **Streamable HTTP** — Enter the **Server URL** and choose **Authentication**: **None**, **API token**, or **OAuth**.
   * **Local command (stdio)** — Enter the **Command**, such as `npx`, and its **Arguments (JSON array)**. Add environment variables under **Advanced**.
4. Save the server.
5. For OAuth, choose **Authorize** on the server and sign in from your browser.
6. Turn on the server's switch. New project servers stay off until you turn them on.

Local commands run on your computer, so add only commands you trust. Tokens and other credentials are stored encrypted on this device, not in the repository.

### Check a server [#check-a-server]

Choose **Test connection** to connect to the server and list the tools it offers. The server's status shows **Connected**, **Needs authorization**, **Not tested**, **Error**, or **Disabled**.

### MCP tools in the conversation [#mcp-tools-in-the-conversation]

The conversation lists each MCP tool the agent calls. When a server needs information from you, the agent shows **MCP input required**; choose **Accept**, **Decline**, or **Cancel**.


---

# Analytics

Source: https://layerwise.app/docs/deploy/analytics

Understand your published website's traffic, receive scheduled email reports, and export filtered results.



Analytics shows how people find and use your published website. It is built into every project and enabled by default, with no tracking code to install or separate analytics account to connect.

## View your traffic [#view-your-traffic]

1. [Publish your project](./publish) if you have not already.
2. Open **Analytics** in the project sidebar, above **Database**.
3. Visit your published website, then allow a few minutes for visits to appear.

Visits to your production domain and connected [custom domains](./custom-domains) appear in the same project. Local previews do not collect visits.

The report refreshes automatically every minute while the page is active. You can also use the **Refresh** icon at the top right of the report. Collection and processing take time, so refreshing does not make newly received visits appear immediately.

![Analytics dashboard showing traffic metrics, the date selector, domain selector, and report menu](/docs/screenshots/analytics-overview.webp)

*Use (1) the date selector and (2) the domain selector to narrow the report. (3) opens the report menu.*

## Read the summary [#read-the-summary]

| Metric             | Meaning                                                                                                                                                                            |
| ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Pageviews**      | The number of recorded page views, including navigation between pages.                                                                                                             |
| **Visitors**       | Estimated daily unique visitors, summed across the selected range. The same person can count again on another day; this is not a count of distinct people across the entire range. |
| **Bounce rate**    | The percentage of visits containing only one pageview. A new visit starts after 30 minutes without a pageview.                                                                     |
| **Visit duration** | Average time between the first and last pageview in a visit. Time on the last page is not measured, and single-page visits count as zero seconds.                                  |

The **Visits over time** chart shows pageviews and visitors across the selected range.

Changes beside the summary numbers compare against the preceding period with the same filters. Hover over a change to see the comparison details. When the previous period has no visits, the change is hidden. If a metric rises from zero, its change is labeled **New** instead of a percentage. Changes, including bounce rate, are relative percentages.

## Choose a date range [#choose-a-date-range]

Use the date selector at the top of the report. Dates and chart times follow your computer's local time zone.

* **Today** starts at local midnight. **Last 24 hours** is a rolling window ending now, so it can include part of yesterday.
* **This week**, **This month**, **This quarter**, and **This year** start at the beginning of the current calendar period. Weeks start on Monday.
* The **Last…** options let you review recent days, months, or years, subject to your team's plan.
* For exact dates, select **Custom dates**, choose a start and end date in the calendar, then select **Apply**.

Ranges ending today compare through the same local time in the previous period. **Last 24 hours** compares against the preceding 24 hours.

## Filter and explore [#filter-and-explore]

Choose a domain next to the date selector, or leave **All domains** selected to combine the project's domains. Then use the breakdown cards to narrow the report:

| Card           | What you can do                                                                                                                                             |
| -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Pages**      | Click a path to filter by that page. Use the external-link icon to open it in your browser.                                                                 |
| **Sources**    | Switch between referrers and UTM source, medium, or campaign values, then click a value to filter by it. **Direct** means no referring domain was recorded. |
| **Countries**  | Click a country to filter by the estimated visitor location.                                                                                                |
| **Technology** | Switch between devices, browsers, and operating systems, then click a value to filter by it.                                                                |

Filters apply across the report, so you can combine a domain, page, and country to explore a particular audience. Remove a filter using its chip above the report.

Click **Pageviews** or **Visitors** in a table header to sort by that count. Tables initially sort by pageviews from highest to lowest. Pages, Sources, and Countries show ten rows per page; use their pagination controls to see more results.

For campaign reporting, add `utm_source`, `utm_medium`, and `utm_campaign` to links you share. For example:

```text
https://your-app.layerwise.site/?utm_source=newsletter&utm_medium=email&utm_campaign=launch
```

Use campaign labels, not personal information, in these values. Ordinary query parameters and URL fragments are excluded from the tracker payload.

## Export a report [#export-a-report]

1. Select the date range and filters you want.
2. Open the menu next to the **Analytics** title and choose **Export CSV**.
3. Choose where to save the file.

The export includes summary metrics, the time series, and breakdowns for the selected filters. It includes all matching breakdown rows, not just the current table page, along with the report's time zone and filter details.

![Analytics report menu with Export CSV and Settings](/docs/screenshots/analytics-menu.webp)

*Choose Export CSV from the report menu to save the selected report.*

## Receive email reports [#receive-email-reports]

Get a regular summary of your published website's traffic by email.

1. Open the menu next to the **Analytics** title and select **Settings**.
2. Keep **Collect visits** on to show the **Email reports** setting.
3. Choose **Monthly**, **Weekly**, or **Off**, depending on your team's plan.
4. Select **Confirm** to save.

| Plan       | Available frequencies  | Default |
| ---------- | ---------------------- | ------- |
| Free       | Off                    | Off     |
| Pro        | Monthly or Off         | Monthly |
| Business   | Weekly, Monthly or Off | Weekly  |
| Enterprise | Weekly, Monthly or Off | Weekly  |

Reports are enabled by default on paid plans. Options that require an upgrade show the required plan; selecting one opens an upgrade dialog and keeps your current frequency.

Each project has one report recipient. Saving an enabled schedule sends future reports to your verified account email. Before anyone saves the schedule, reports go to the project's creator. The recipient must still belong to the team.

The schedule uses the time zone shown in **Settings**:

* **Monthly** reports cover the previous calendar month and are scheduled for the 1st at 9:00 AM.
* **Weekly** reports cover the previous Monday through Sunday and are scheduled for Monday at 9:00 AM.

Emails include the summary metrics and comparisons, visits over time, and the **Pages**, **Sources** (including UTM values), **Countries**, and **Technology** breakdowns. Each breakdown shows up to ten entries, ordered by pageviews. Reports cover all of the project's domains; filters selected in the dashboard do not change the email report.

When **Collect visits** is off, **Email reports** is hidden and scheduled emails pause. Turning collection back on resumes the saved frequency. To stop emails while continuing to collect visits, select **Off** and confirm.

## History available on your plan [#history-available-on-your-plan]

Your team's subscription determines how far back you can view and export data:

| Plan       | Available history |
| ---------- | ----------------- |
| Free       | Latest 7 days     |
| Pro        | Latest 6 months   |
| Business   | Latest 1 year     |
| Enterprise | Latest 3 years    |

Selecting a range beyond your plan's history opens an upgrade dialog. Upgrading can unlock older data that was already collected and is still retained. It cannot recover visits from before collection began or after data was deleted.

Report access and data retention are separate. See [Analytics privacy and retention](/analytics/privacy#retention) for the retention and deletion policy.

## Pause collection [#pause-collection]

1. Open the menu next to the **Analytics** title and select **Settings**.
2. Turn **Collect visits** off.
3. Select **Confirm** to save the change.

Pausing keeps existing history available. Turn the setting back on and confirm to resume collection. Changes may take a short time to reach the published website, and requests already in progress may still arrive. Team viewers cannot change this setting.

## If you do not see visits [#if-you-do-not-see-visits]

* Publish the project first, then visit its live URL rather than the local preview.
* Check that **Collect visits** is on.
* Allow a few minutes for processing, then refresh.
* Check the selected date range, domain, and filter chips. A published project with no matching visits shows zero values.
* Browser extensions and a site's Content Security Policy can prevent collection. Reports may therefore show fewer visits than actually occurred.

## Privacy [#privacy]

The built-in tracker does not set tracking cookies or store persistent visitor identifiers in the browser. Raw IP addresses are not stored in Analytics events. Visitor counts are estimates, and cookie-free does not mean that all collected data is anonymous.

Read [Layerwise Analytics Privacy](/analytics/privacy) for the fields collected, processing, and deletion details. That notice covers Layerwise's built-in Analytics; your website still needs its own privacy information for forms, accounts, payments, and any other tools you add.


---

# Authentication

Source: https://layerwise.app/docs/deploy/authentication

Every project ships with built-in email authentication and delivery — no auth provider or email service to set up.



Every project includes a working authentication system. Sign in, email verification, and password reset are wired into your app from the first release, and Layerwise delivers the authentication emails for you — there is no separate auth provider or email service to configure.

## What's included [#whats-included]

* **Email sign in and sign up** for your app's end users.
* **Email verification** and **password reset** flows.
* **Authentication emails** — the one-time codes and links these flows send are delivered by Layerwise.
* **Sessions and secrets** are managed automatically; there are no keys to set or rotate.
* **User management** for local development and published apps.

Authentication works the same way in the local preview as it does in production, except that the preview never sends real email. Sign-in codes appear in **Email** → **Local** in the Layerwise app instead. See [Test in the local preview](./email#test-in-the-local-preview).

![Email sign-in screen in a project built with Layerwise](/docs/screenshots/sign-in.webp)

*A project's email sign-in screen.*

## Manage users [#manage-users]

Open **Authentication** from the project sidebar to view and manage your app's users.

* Switch between **Local** and **Online** to manage users in the local preview or the published app. Online becomes available after the project's first [publish](./publish).
* Search by name or email. Use **Filters** to narrow the list by account status or email verification status.
* Sort the list by user, status, verification status, or creation date. The table also shows each user's ban reason and ban expiration.
* Click **Add user** to create an account with a name, email, and verification status. A password is optional. Leave it blank to create a passwordless account that signs in with an email code.
* Open a user's actions menu to ban or unban them, set a new password, or delete the account.

Team viewers can browse users but cannot make changes.

![Authentication users page with environment tabs, status and verification filters, Add user, and row actions marked; personal details are blurred](/docs/screenshots/authentication.webp)

*(1) Choose the environment, (2) filter users, (3) add an account, or (4) open a user's actions. Personal details are blurred.*

### Ban a user [#ban-a-user]

Choose **Ban user** from the user's actions menu. Enter a reason and, optionally, a future expiration date and time. Leave the expiration blank for a permanent ban.

Banning a user revokes all of their active sessions. The table displays the ban reason and expiration until you unban the user.

### Delete a user [#delete-a-user]

Deleting a user permanently removes the user and their sessions and linked accounts. This action cannot be undone.

### Local and Online data [#local-and-online-data]

Local and Online use separate databases. Changes are not copied between them.

* **Local** changes affect the local preview database. Start the project preview before managing local users.
* **Online** changes affect the published app's production authentication data immediately.

## Authentication emails [#authentication-emails]

Authentication emails are the login codes, verification links, and password reset messages your app sends to its own users. They are separate from the emails Layerwise sends to you as an account holder.

Because Layerwise handles delivery, you do not need to connect an email provider (such as an SMTP server or a transactional email service) to your app.

Authentication emails come from an address based on your `layerwise.site` subdomain, such as `acme-shop@auth.layerwise.dev`, with the project name as the sender name. Replies go to the team owner. Sent emails appear as sign-in emails under **Email** → **Online** for 30 days. See [Email](./email#monitor-email).

### Limits [#limits]

Your app can have an **unlimited number of users on every plan** — Layerwise never caps how many people can sign up, even on Free. Only authentication email delivery has a daily limit, based on your plan. Each project has its own limit, and a team limit caps all of the team's projects together:

| Plan       | Total users | Per project per day | Per team per day |
| ---------- | ----------- | ------------------- | ---------------- |
| Free       | Unlimited   | 10                  | 10               |
| Pro        | Unlimited   | 100                 | 300              |
| Business   | Unlimited   | 500                 | 1,000            |
| Enterprise | Unlimited   | Unlimited           | Unlimited        |

These limits are separate from the email your app sends for other reasons, such as receipts, so that email never uses up sign-in emails. Emails from the local preview don't count.

If a project or team reaches its daily limit, Layerwise pauses new authentication emails until midnight in the team's time zone. Sign-in attempts that need a fresh email will not go through until the limit resets or the plan is upgraded. Upgrade the plan for a higher daily limit.

Each email address can receive up to 5 authentication emails per hour from a project, so repeated requests can't flood someone's inbox.

To check today's count, open the menu next to the **Authentication** title and choose **Usage**. It shows the project's count and your team's total.

## Related [#related]

* [Email](./email)
* [Database](./database)
* [Billing and usage](../account/billing-and-usage)


---

# Connect a custom domain

Source: https://layerwise.app/docs/deploy/custom-domains

Point a hostname at a published Layerwise project and verify DNS.



Custom domains are available on Pro and higher plans.

Publish the project at least once before adding a custom domain.

## Add the domain [#add-the-domain]

1. Open **Domains** in the project sidebar.
2. Enter a hostname, such as `app.example.com`, then select **Add**.
3. Copy the DNS record shown by Layerwise into your DNS provider.
4. Keep the page open while Layerwise validates the domain.

For a subdomain, create a CNAME pointing to the Layerwise production domain. For an apex/root domain, use ALIAS, ANAME, or CNAME flattening when your DNS provider supports it.

![Domains page with the hostname field, Add button, and site domain marked](/docs/screenshots/domains.webp)

*Enter (1) your hostname and select (2) Add. (3) shows the project's existing site domain.*

## Check validation [#check-validation]

Layerwise refreshes domain status every 15 seconds while the page is open. The table shows the hostname, current status, last check, and whether it is canonical.

DNS propagation can take time. Do not remove the domain while validation is in progress. If validation does not complete, see [Custom domain validation](../reference/troubleshooting#custom-domain-does-not-validate).


---

# Database

Source: https://layerwise.app/docs/deploy/database

Every project ships with a built-in production database — no third-party service to set up.



Every project includes its own database. It is provisioned automatically, bound to your app, and deployed with each release, so there is no separate database service to sign up for, configure, or connect.

## How it works [#how-it-works]

* Each project gets one dedicated **SQLite database** (Cloudflare D1) exposed to your app as the `DB` binding.
* Locally, the app runs against a local SQLite file so you can build and test offline.
* On [publish](./publish), the production database is created on first release and your schema migrations are applied automatically.

Because it is standard SQLite, the generated app talks to it through an ORM and ordinary SQL — nothing Layerwise-specific to learn.

## View and edit your data [#view-and-edit-your-data]

Open **Database** from the project sidebar to browse and edit your data directly, no SQL required.

* Switch between **Local** and **Online** at the top of the page to work with your local development data or your live production data. Online becomes available once you have [published](./publish) the project.
* The left panel lists your tables with a search box. Single-click a table to preview it, double-click to keep it open in a pinned tab.
* Click a column header to **sort**, and page through large tables at the bottom.
* **Add a row** with Insert, **edit a value** by double-clicking a cell, and **delete rows** by selecting them and choosing Delete. True/false and date/time columns show the right control — a dropdown, a date & time picker — so you never enter raw `0`/`1` or timestamps.
* **Export** the current table to CSV or JSON from the menu; the file is saved and revealed in your file browser.

Local and Online are independent databases — your local file is for building and testing, and production is created on first publish. Edits made to **Online** change your live production data immediately.

![Database browser with environment tabs, table list, Insert, and Export controls marked; records are blurred](/docs/screenshots/database.webp)

*(1) Choose Local or Online, (2) select a table, then use (3) Insert or (4) Export. Record contents are blurred.*

## Storage limits [#storage-limits]

You get a number of databases (one per project) and a size cap per database, based on your team's plan:

| Plan       | Databases | Storage per database |
| ---------- | --------- | -------------------- |
| Free       | 1         | 100 MB               |
| Pro        | 10        | 1 GB                 |
| Business   | 100       | 10 GB                |
| Enterprise | Unlimited | 10 GB                |

Changing plans takes effect immediately: an upgrade raises the limits right away, and a downgrade applies the new caps at once.

## Monitor usage [#monitor-usage]

Open the menu next to the **Database** title and choose **Usage** to see how much of the limit the selected database uses and how much remains. The **Publish** menu in the preview header also shows the online database's size and limit, with a color indicator as it fills up. Both show the latest measurement each time you open the menu.

## When a database fills up [#when-a-database-fills-up]

As a database approaches its limit, Layerwise notifies everyone who has worked on the project — by email and in the app — at 50%, 75%, 85%, 95%, and 100% of the limit.

At **100%**, the published app is paused and serves a temporary notice instead of your app. This protects your data from writes that would exceed the limit. To bring the app back online:

* **Upgrade your plan** for a higher limit — the app is restored automatically, or
* **Free up space** in the database.

## Related [#related]

* [Publish a project](./publish)
* [Release history](./release-history)
* [Storage](./storage)


---

# Email

Source: https://layerwise.app/docs/deploy/email

Apps you build can send transactional email, such as receipts and order updates, with no email service to set up.



Every project can send transactional email, such as receipts, order and booking updates, and account notices, to the people who use your app. Layerwise delivers it, so there is no email service to sign up for, no domain to verify, and no API key to manage.

Sign-in codes from [Authentication](./authentication) go through Layerwise Email too, with their own daily limits.

## How it works [#how-it-works]

* Ask the agent for the email you need, such as "Email customers a receipt when they pay." It adds the code that sends the email from your app's server.
* Each email goes to one person. It can include HTML, plain text, or both, up to 1 MiB together. Attachments, cc, and bcc are not supported, so link to the page or file in your app instead.
* Email works after the project's first [publish](./publish). It comes from an address based on your `layerwise.site` subdomain: a project at `acme-shop.layerwise.site` sends from `acme-shop@mail.layerwise.site`, with the project name as the sender name.
* The sending address does not receive mail. To get replies, have your app set a reply-to address, such as your support inbox. Custom sending domains are not supported.

## What you can send [#what-you-can-send]

Layerwise Email is for transactional email: messages a person expects because of something they did or something about their account.

| Send                                     | Don't send                         |
| ---------------------------------------- | ---------------------------------- |
| Receipts and invoices                    | Newsletters                        |
| Order, shipping, and booking updates     | Marketing and promotions           |
| Password, security, and account notices  | Cold outreach or purchased lists   |
| Replies to something the person sent you | Announcements to all of your users |

Sending other email can get your project's email paused. See [Paused email](#paused-email).

## Test in the local preview [#test-in-the-local-preview]

Your local preview never sends real email. Every email your app sends while you test, including sign-in codes, goes to **Email** in the project sidebar instead, under **Local**.

* A notification appears in the Layerwise app when an email arrives, and you can copy a sign-in code right from it. A red dot on **Email** marks new mail until you open **Local**.
* Open an email to read it and see the address the published app will send it from. The unsubscribe link and the Free plan footer are added only to real email.
* Local email doesn't count toward your limits. **Local** keeps the newest 200 emails for each project.
* The agent can read **Local** to finish a sign-in test, but it can't send real email.

Projects created before Email send their sign-in codes to **Local** without any changes. To send other email from an older project, ask the agent to add Layerwise Email, and it updates the project's setup.

## Monitor email [#monitor-email]

After the project's first publish, open **Email** and select **Online**.

* **Usage today** shows today's sign-in and app emails against the project and team limits, and when the counts reset. Each meter changes color as it passes 50%, 75%, 85%, and 95%.
* The log lists the last 30 days of email with the time, type, recipient, subject, and status, such as **Delivered**, **Bounced**, or **Unsubscribed**.
* Owners, admins, and editors can open an email to read its content, including sign-in codes. Viewers see the log but not the content.

## Unsubscribes [#unsubscribes]

Every app email includes a one-click unsubscribe link, which mail apps such as Gmail can show next to the sender.

* After someone unsubscribes, your app can't send them app email from this project. The log shows those emails as **Unsubscribed**.
* The unsubscribe page has a **Resubscribe** button for anyone who changes their mind.
* Owners and admins can open the menu next to the **Email** title, choose **Unsubscribes**, and remove an address so it can receive app email again. Layerwise records who removed it. Remove an address only when that person asks you to.
* Unsubscribing covers one project's app email. Sign-in codes still arrive.

## Limits [#limits]

Sign-in emails and app emails have separate daily limits, so app email never uses up the sign-in emails your users need. Each project has its own limits, and a team limit caps all of the team's projects together. The counts reset at midnight in your team's time zone.

| Plan       | Sign-in emails per project | Sign-in emails per team | App emails per project | App emails per team |
| ---------- | -------------------------- | ----------------------- | ---------------------- | ------------------- |
| Free       | 10                         | 10                      | 20                     | 20                  |
| Pro        | 100                        | 300                     | 200                    | 600                 |
| Business   | 500                        | 1,000                   | 1,000                  | 1,500               |
| Enterprise | Unlimited                  | Unlimited               | Unlimited              | Unlimited           |

Each address can receive up to 5 sign-in emails per hour and 20 app emails per day from a project, so no one's inbox gets flooded. Your app can still have an unlimited number of users on every plan. On Free, app emails include a short Layerwise footer.

## When you reach a limit [#when-you-reach-a-limit]

When a project or team uses up a daily limit, that kind of email stops until midnight in your team's time zone, and Layerwise emails the team owner.

* **Sign-in emails:** sign-in attempts that need a new code fail until the limit resets.
* **App emails:** your app's emails are not sent, and the app gets an error it can show or log.

Emails blocked by a limit, an unsubscribe, or a pause don't count toward your limits. To raise the limits, upgrade your plan.

## Paused email [#paused-email]

Layerwise pauses a project's app email automatically when too many of its emails bounce or are marked as spam over the past 7 days. Layerwise can also pause it after confirming an [abuse report](/abuse). Sign-in emails keep working while app email is paused.

The **Email** page shows why app email is paused, and the team owner gets an email. To resume it, contact [Layerwise support](mailto:support@layerwise.app); teams can't resume paused email themselves.

To avoid a pause, send only the email described in [What you can send](#what-you-can-send), only to addresses people gave you, and stop emailing addresses that bounce.

## For developers [#for-developers]

Apps send email from server code with `env.EMAIL.send()`. It returns the email's ID or an error code instead of throwing:

```ts
import { env } from 'cloudflare:workers';

const { data, error } = await env.EMAIL.send({
  to: 'ada@example.com',
  subject: 'Your order shipped',
  html: '<p>Order #1042 is on its way.</p>',
  text: 'Order #1042 is on its way.',
  replyTo: 'support@example.com'
});
```

| `error.code`               | Meaning                                                                                    |
| -------------------------- | ------------------------------------------------------------------------------------------ |
| `invalid_message`          | A field is missing or invalid, there is more than one recipient, or the email is too large |
| `not_published`            | The project hasn't been published yet                                                      |
| `paused`                   | The project's app email is paused                                                          |
| `unsubscribed`             | The recipient unsubscribed from this project's email                                       |
| `suppressed`               | The address can't receive email, usually after an earlier bounce or spam report            |
| `recipient_limit_reached`  | The address already received 20 app emails from this project today                         |
| `daily_limit_reached`      | The project's daily app email limit is used up                                             |
| `team_daily_limit_reached` | The team's daily app email limit is used up                                                |
| `send_failed`              | Delivery failed and the email didn't count toward your limits; try again later             |

Subjects can be up to 998 characters. In the local preview, limits and unsubscribes don't apply, so the only errors are `invalid_message` and, if the preview can't reach the Layerwise app, `send_failed`.

## Related [#related]

* [Authentication](./authentication)
* [Publish a project](./publish)
* [Report abuse](/abuse)


---

# Logs

Source: https://layerwise.app/docs/deploy/logs

Inspect local and published backend logs, follow requests live, and export logs for debugging.



Open **Logs** in your project's sidebar to inspect backend requests, console messages, and errors. Messages from the same request are grouped together so you can follow what happened without searching through separate entries.

## Choose Local or Online [#choose-local-or-online]

* **Local** shows logs from the project's local development workspace. Start the preview and make a request to your app to generate logs. Local logs come from the running workspace's buffer, so the available history may be shorter than your plan's time limit.
* **Online** shows logs from your [published project](./publish). Use the **Deployment** filter to inspect all deployments, the current production deployment, or a specific release.

Both tabs use the same table, filters, and export menu. These are backend logs; browser console messages are not part of the request log stream.

![Logs page with environment tabs, the time selector, Live, and filters marked](/docs/screenshots/logs.webp)

*(1) Choose the environment, (2) select a time range, (3) follow logs live, and (4) narrow the requests with filters.*

## Read a request [#read-a-request]

The table shows **Time**, **Level**, **Host**, **Request**, **Status**, **Duration**, and **Messages**. Times use your computer's local time zone. A dash means the value was not recorded, which can happen for local process output that is not an HTTP request.

The tag beside a message counts the loaded log events for that request, including its request event. The row previews an error message when one is available. Scroll down to load more requests automatically.

Click a row to open its details. You can inspect the request ID, URL, status and outcome, timing, deployment, and individual messages. Expand structured data or long messages when available. Use **Copy request ID**, **Copy loaded logs**, or a message's **Copy** action to share the relevant context.

![Request details showing timing, status, and grouped log messages; request identifiers and sensitive data are blurred](/docs/screenshots/logs-details.webp)

*Open a request to inspect its status, timing, and messages. Request identifiers and sensitive data are blurred.*

## Choose a time range [#choose-a-time-range]

The time selector offers **Last 15 minutes**, **Last 30 minutes**, **Last hour**, **Last 24 hours**, **Last 3 days**, and **Last 7 days**.

On Pro and higher plans, choose **Custom range** for an exact interval. Select dates in the calendar, adjust the **From** and **To** times, and select **Apply**. The dialog checks that the start is before the end, both dates are within your available history, and the end is not in the future. Live updates are unavailable for a custom range.

### History available on your plan [#history-available-on-your-plan]

| Team plan  | Available history | Custom range |
| ---------- | ----------------- | ------------ |
| Free       | Latest 1 hour     | No           |
| Pro        | Latest 3 days     | Yes          |
| Business   | Latest 7 days     | Yes          |
| Enterprise | Latest 7 days     | Yes          |

These limits apply to both Local and Online. All time options remain visible. A plan tag appears only beside an option your team has not unlocked; selecting it opens the upgrade dialog without changing your current filters. See [Billing and usage](/docs/account/billing-and-usage) to manage your team's plan.

## Filter logs [#filter-logs]

Use **Search logs** to find text in log messages and request information. Press Enter or leave the search field to apply it. Combine it with the filters on the left:

* **Level**: select Info, Warn, Error, or a combination.
* **Status**: choose a status group such as 4xx or 5xx, or enter an exact code such as `503`.
* **Method**: select one or more HTTP methods.
* **Host**: select one or more available hostnames.
* **Path**: select suggested paths or enter a path to add it to the filter.
* **Request ID**: narrow the list to a particular request.

Use **Reset** to clear the sidebar filters while keeping your time range and search text.

## Follow logs live [#follow-logs-live]

Select **Live** to insert incoming requests at the top of the list automatically. The selected button shows a pause icon; select it again to pause incoming updates. When paused, it shows a play icon. You can scroll through older logs while Live is active.

Online Live uses Cloudflare's live log stream. Local Live refreshes from the local workspace about once per second. Live updates pause while the page is hidden.

Use the **Refresh** icon to reload logs. Published logs can take time to become available in historical queries, so a request seen in Live may not appear in history immediately. If the live connection fails, use **Reconnect** when prompted.

## Export or copy logs [#export-or-copy-logs]

Open the download menu to the right of the time selector:

* **Export CSV** saves one row per loaded log event, with request metadata, message text, and any recorded stack or structured data.
* **Export JSON** saves the loaded requests with their grouped log events.
* **Copy visible logs** copies the loaded list as text, including timestamps, levels, request IDs, and messages.

All three actions use the current filtered list already loaded into the table, including rows loaded by scrolling. They do not fetch every matching request in the selected time range. Scroll to load any additional history you need before exporting. CSV and JSON exports open a save dialog; their timestamps use UTC.

## If logs are missing [#if-logs-are-missing]

1. Check that you selected the environment where the request ran: **Local** for the preview or **Online** for the published app.
2. Clear restrictive filters and choose a time range that includes the request.
3. Make another request, then enable **Live** or select **Refresh**. Historical Online logs may arrive later than Live logs.
4. If Online shows **Collection off · Redeploy to enable**, publish a new release to enable collection for that deployment.

**Partial results** means the historical query returned only part of the matching data. **Truncated** in request details means some recorded content was cut short. Narrow the time range or filters to inspect the relevant request more closely.


---

# Publish a project

Source: https://layerwise.app/docs/deploy/publish

Deploy the current local workspace as a production release.



Publishing creates a production release from the current local workspace. Test the relevant path in the local preview before publishing.

## Publish [#publish]

1. Open the project in **Preview** mode.
2. Select **Publish** in the preview header.
3. Confirm that the preview is up to date, then select **Publish** from the menu.
4. Wait for the operation to finish.

After the first successful release, the menu shows the live URL. **Up to date** means the local source revision matches the last published revision.

![Publish menu showing the live website URL, database storage usage, and Publish button](/docs/screenshots/publish.webp)

*The menu shows (1) the live URL, (2) database storage usage, and (3) the Publish button.*

## Keep a project private [#keep-a-project-private]

Turn on **Private** in the Publish menu to limit the live URL to members of your team. Anyone who opens it signs in with Layerwise first, using GitHub, Google, or a one-time email code. Visitors who aren't on the team see an access error instead of your app.

Privacy applies to the layerwise.site address and to every [custom domain](./custom-domains). You can switch it off or on at any time without publishing again.

Private projects require a paid plan, and new projects on paid plans start private. To give someone access, [invite them to your team](/docs/workspace/teams-and-members#invite-a-collaborator); every role can open private projects.

## Check deployment status [#check-deployment-status]

Open **Settings** in the project sidebar to see the production domain, active release, last known healthy release, and current deployment status.

Open [Deployments](./release-history) for the complete release list and deployment timeline.

## Before you publish [#before-you-publish]

Keep the local workspace available until publishing completes. Publishing is unavailable while another publish is running or if the local workspace has not finished preparing.

## View website traffic [#view-website-traffic]

After publishing, open **Analytics** in the project sidebar to see visits to your live website. Collection is enabled by default. See [Analytics](./analytics) for metrics, filters, CSV exports, and history limits.


---

# Manage releases

Source: https://layerwise.app/docs/deploy/release-history

Inspect deployed releases, fix a failed deployment, and roll back safely.



Open **Deployments** in the project sidebar to view immutable releases and their deployment timeline.

## Read release status [#read-release-status]

The release list shows each release's label, status, creation time, verification time, and whether it is active or the last known healthy release.

Use this page to understand whether a deployment completed, failed before activation, or was superseded by a later release.

![Deployments page with the active release and release actions marked; publisher details are blurred](/docs/screenshots/deployments.webp)

*(1) Active identifies the release serving your website. (2) opens a release's available actions.*

## Fix a failed deployment [#fix-a-failed-deployment]

Hover a failed release's status to see its error message, or open the release's actions and select **View logs**. Fix the problem in the local preview, then [publish](./publish) again.

## Roll back production [#roll-back-production]

Open the actions on a superseded release and select **Instance rollback** to make it active in production. You cannot roll back to the active release or to a failed one.

Rollback changes the production release only. It does not change your local workspace or remove later releases. Review your local code before the next publish.


---

# Storage

Source: https://layerwise.app/docs/deploy/storage

Every project includes file Storage for images, videos, documents, and other files, with no third-party service to set up.



Every project includes Storage for the files your app and your team keep, such as uploads, images, avatars, attachments, documents, and video. There is no separate storage service to sign up for, configure, or connect.

## How it works [#how-it-works]

* Your app saves and serves files through the `STORAGE` binding in its server code. Ask the agent to add uploads, galleries, or downloads, and it connects them to Storage.
* Your local preview and your published app use the same files, so Storage works before you [publish](./publish). Files saved while you test also appear in the published app.
* Files are **private** by default and open through links that expire. A **public** file has a lasting URL that anyone can open, which suits product images or public avatars.
* Apps running in the local preview cannot make files public. Test public files in the published app.

## Manage files [#manage-files]

Open **Storage** from the project sidebar to work with your project's files.

* Select **Upload** to add files or a whole folder, or drag them onto the file list. Choose **Private** or **Public** before uploading. Upload progress stays in the header after the dialog closes.
* Browse folders, then search, filter, and sort the list.
* **Preview** images, video, audio, PDFs, text, and Markdown. Other files can be downloaded.
* Open a file's menu to **Download** it, copy its private link or public URL, **Rename** it, make it public or private, or **Move to trash**.

Programs and other executable files cannot be public. A public file that is replaced or deleted can stay visible at its URL for up to 5 minutes.

## Trash [#trash]

Files that are deleted or replaced stay in **Trash** for 7 days. Restore a file from there, or delete it permanently. Files in the trash do not count toward your limit, but restoring one needs free space.

## Work with the agent [#work-with-the-agent]

The agent can upload and organize your project's files. Files it replaces or deletes go to the trash. Making a file public or emptying the trash needs your [approval](/docs/build-your-app/approvals-and-changes).

## Export files [#export-files]

Select **Export** above the file list, then **Choose folder**. Layerwise saves the files you're looking at, including any on other pages:

* In a folder, every file in it and its subfolders.
* With a search or filters, every matching file.

The files go into a new folder inside the one you choose, with the same subfolders as in Storage, and Layerwise shows that folder when the export is done. Files in the trash are not included.

The export continues if you close the dialog, and you can stop it from the same dialog; files already saved stay where they are. It works even while the project's Storage is read-only.

## Storage limits [#storage-limits]

Each project's Storage and largest file depend on your team's plan:

| Plan       | Storage per project | Largest file |
| ---------- | ------------------- | ------------ |
| Free       | 1 GB                | 10 MB        |
| Pro        | 10 GB               | 100 MB       |
| Business   | 50 GB               | 1 GB         |
| Enterprise | 100 GB              | 5 GB         |

Changing plans takes effect immediately. To check usage, open the menu next to the Storage title and choose **Usage**. It shows how much is used and remaining, the number of files, the size of the trash, and the largest file allowed.

## When Storage fills up [#when-storage-fills-up]

As a project's Storage approaches its limit, Layerwise emails everyone who has worked on the project at 50%, 75%, 85%, 95%, and 100% of the limit.

At &#x2A;*100%**, the project's Storage becomes read-only. Your published app stays online, and files can still be opened, downloaded, and deleted, but new uploads pause. To upload again:

* **Upgrade your plan** for a higher limit, or
* **Free up space** by deleting files.

## Related [#related]

* [Database](./database)
* [Publish a project](./publish)


---

# Prompting for a useful first version

Source: https://layerwise.app/docs/getting-started/prompting

Give Layerwise enough product context to produce a testable first project.



The initial prompt defines the starting point. A useful prompt says who the app is for, what they need to do, what information the app stores, and any design constraints.

## Include the essentials [#include-the-essentials]

* **Users** — Who will use the app and whether they need to sign in.
* **Main workflow** — The important steps a user completes.
* **Data** — Records the app needs to create, view, or update.
* **Screens** — Key pages or dashboards.
* **Design direction** — Brand, tone, layout, or examples to follow.

## Start specific, then iterate [#start-specific-then-iterate]

Ask for one clear outcome per follow-up message. After each result, inspect the local preview and test the affected user path before requesting the next change.

Attach reference images when your selected model supports image input. Use them to communicate layout, style, or content hierarchy; also describe the behavior the image cannot show.

To show which part of the current preview a follow-up is about, select an element or draw on the page from the preview toolbar. See [Point to part of the page](../build-your-app/chat-and-preview#point-to-part-of-the-page).

For a larger change, turn on **Plan mode** to agree on the approach before the agent edits anything, or set a **Goal** to let it work across many turns. See [Direct the agent](../build-your-app/direct-the-agent).

## Example [#example]

```text
Build an internal tool for a five-person support team. Agents need to view a
queue of customer requests, assign each request to a teammate, update its
status, and add internal notes. Add email sign-in. Use a compact desktop-first
layout with a left navigation panel and a table on the main screen.
```

## Verify the first result [#verify-the-first-result]

Before moving on, confirm that the preview loads, the primary screen exists, and the main workflow can be exercised. If it does not, use a concrete follow-up such as “The assignment menu is missing from the request detail page; add it and keep the existing table.”


---

# Quick start

Source: https://layerwise.app/docs/getting-started/quickstart

Create a project, make a change, and publish a working version.



This guide takes you through the core Layerwise workflow. You need Layerwise installed and an account signed in with GitHub or Google.

## 1. Choose a team [#1-choose-a-team]

Select a team from the sidebar. If you do not have one yet, open the team switcher, choose **New Team**, and enter a name.

Projects, members, subscription, and usage belong to the selected team.

## 2. Create a project [#2-create-a-project]

On the team home page, enter a description in &#x2A;*Describe the app you want to build...**. Choose a model available on the team's plan, then send the prompt.

![Create a project from the team home page, with the prompt, model picker, and send button marked](/docs/screenshots/create-project.webp)

*(1) Describe your app, (2) choose a model, then (3) send the prompt.*

For example:

```text
Create a booking app for a small photography studio. Include a public service
list, available time slots, customer sign-in, and an owner dashboard for
managing bookings. Use a calm black-and-white visual style.
```

Layerwise creates the project, prepares its local workspace, and starts the initial conversation.

## 3. Review and change the app [#3-review-and-change-the-app]

Wait for the local preview to load beside the conversation. Test the main user path, then ask for one focused change. For example:

```text
Add a booking confirmation screen. Keep the existing visual style, show the
date, time, and service, and add a link back to the dashboard.
```

See [Build and preview](../build-your-app/chat-and-preview) for the workspace controls.

![Project workspace showing the conversation beside a working local preview](/docs/screenshots/workspace.webp)

*(1) Ask for a change in the conversation, (2) test it in the preview, then (3) publish when it is ready.*

## 4. Publish it [#4-publish-it]

When the local preview works, choose **Publish** in the preview header and select **Publish** again from the menu. The menu shows the live URL after the first successful release.

See [Publish a project](../deploy/publish) for release checks and recovery.

## Next steps [#next-steps]

* Learn how to write effective [prompts](./prompting).
* [Edit the local code or connect GitHub](../build-your-app/code-and-github).
* [Add a custom domain](../deploy/custom-domains).


---

# Troubleshooting

Source: https://layerwise.app/docs/reference/troubleshooting

Recover from common problems in the Layerwise workflow.



Keep any displayed error message when diagnosing a problem or contacting support.

## Preview does not load [#preview-does-not-load]

1. Wait for project workspace setup to complete, then select **Refresh**.
2. Open [Logs](/docs/deploy/logs) and select **Local** to inspect backend errors. You can also open **Project actions** and show the console for preview output.
3. Return to the team project list, reopen the project, and wait for its local workspace to become ready.

Do not publish until the preview is working; publishing requires the local workspace.

## Built-in editor cannot edit a file [#built-in-editor-cannot-edit-a-file]

The built-in editor only edits text files smaller than 10 MB. Binary files are previewed instead. Use **Open in** to edit other files in an installed editor or file manager.

## GitHub asks you to connect an account [#github-asks-you-to-connect-an-account]

Open **Account** from the user menu and select **Connect GitHub**. Then return to the project and select its GitHub icon again. The project must also have a ready local workspace.

## Publish is unavailable [#publish-is-unavailable]

Return to the local preview and wait for workspace setup to finish. Publishing is disabled while another publish is running. **Up to date** means the current local source already matches the last published revision.

For a failed deployment, open **Deployments** and hover the release's **Failed** status to see the error. Fix the problem in the local preview, then publish again.

## Custom domain does not validate [#custom-domain-does-not-validate]

Check the DNS record shown on the **Domains** page:

* Use CNAME for a subdomain such as `app.example.com`.
* Use ALIAS, ANAME, or CNAME flattening for an apex/root domain when your provider supports it.

Keep the **Domains** page open to inspect validation status and required records. DNS changes can take time to propagate.


---

# Find and organize projects

Source: https://layerwise.app/docs/workspace/projects

Navigate a team's project list and return to the work that matters.



The team home page lists all projects owned by the active team. Open a project to return to its conversations, local preview, code, settings, and releases.

## Filter the list [#filter-the-list]

Use the project filter to sort by:

* Most recent or least recent activity.
* Title, ascending or descending.
* Projects you created or updated.
* Projects you starred.

Star a project from its conversation header to make it easier to find later.

![Team project list with the project filter and star indicator marked; author details are blurred](/docs/screenshots/projects.webp)

*Use (1) the project filter to find your work. (2) identifies a starred project.*

## Keep experiments separate [#keep-experiments-separate]

Open the three-dot menu beside the conversation title and choose **Fork project** when you want to explore a variation. The fork starts from the current state but keeps releases, custom domains, and GitHub connections separate from the original.

## Transfer a project [#transfer-a-project]

Open **Settings** in the project sidebar, select **Transfer Project**, and choose another team. You need to be an editor, admin, or owner in both teams. The project keeps its visibility unless the new team is on the Free plan, where projects are public.

## Delete a project [#delete-a-project]

Use the project card's delete action only after exporting or publishing anything you need to keep. Deleting a project removes it from the team.


---

# Manage teams and members

Source: https://layerwise.app/docs/workspace/teams-and-members

Organize projects into teams and give collaborators the right access.



A team is the shared home for projects, members, subscription, and usage. Use separate teams for different clients, products, or groups of collaborators.

## Create or switch teams [#create-or-switch-teams]

Open the team switcher in the sidebar or team breadcrumb. Select an existing team, or choose **New Team** and enter a name.

## Invite a collaborator [#invite-a-collaborator]

Open **Members** and select **Invite Member**. Enter an email address and choose a role:

| Role   | Access                                |
| ------ | ------------------------------------- |
| Viewer | Can view team content.                |
| Editor | Can edit team content.                |
| Admin  | Can manage team settings and members. |

Pending invitations appear on the Members page. Invitees accept the invitation through the authenticated Layerwise web flow.

![Invite Member dialog with the role menu open](/docs/screenshots/members.webp)

*Choose the collaborator's role before sending an invitation.*

## Rename or delete a team [#rename-or-delete-a-team]

Open **Settings** to rename or delete the active team. Deleting a team is permanent; export or move work you need before confirming it.