diff --git a/docs/developer-docs/6.x/build-with-ai/ai-assisted-development.mdx b/docs/developer-docs/6.x/build-with-ai/ai-assisted-development.mdx
index 03205a2e7..22450f815 100644
--- a/docs/developer-docs/6.x/build-with-ai/ai-assisted-development.mdx
+++ b/docs/developer-docs/6.x/build-with-ai/ai-assisted-development.mdx
@@ -29,7 +29,7 @@ A productive AI-assisted workflow with Webiny typically follows this pattern:
- **Gather context** — let the agent load the relevant MCP skill, point it at existing code, or reference docs
- **Ask for a focused implementation** — a single extension, a model change, a lifecycle hook — not an entire system at once
- **Review the result** — check that it follows Webiny patterns, uses the right imports, and belongs in the right place
-- **Test locally** — use `yarn webiny watch` to verify the change works
+- **Test locally** — use `yarn webiny watch api` or `yarn webiny watch admin` to verify the change works
- **Iterate** — refine through short follow-ups rather than starting over
This approach treats AI as a capable teammate who needs clear direction, not a magic button.
@@ -138,7 +138,7 @@ The practical workflow looks like this:
- Ask the agent to load the relevant skill
- Request a focused implementation with clear constraints
- Review the output against the checklist above
-- Test locally with `yarn webiny watch`
+- Test locally with `yarn webiny watch api` or `yarn webiny watch admin`
- Deploy with `yarn webiny deploy api` or `yarn webiny deploy admin`
- Iterate as needed
diff --git a/docs/developer-docs/6.x/cli/watch.ai.txt b/docs/developer-docs/6.x/cli/watch.ai.txt
index bf85a670e..0c6e02601 100644
--- a/docs/developer-docs/6.x/cli/watch.ai.txt
+++ b/docs/developer-docs/6.x/cli/watch.ai.txt
@@ -18,6 +18,12 @@ Behavior:
- Frontend (admin, website): local dev server + hot reload; requires API already deployed
- Backend (api): file watcher → build → Lambda redeploy cycle; no local server
+The App Argument Is Effectively Required (verified August 2026):
+- Running `yarn webiny watch` with no app and no `-p` package starts nothing. Both CLI implementations fall through to a warning: `packages/cli-aws/src/features/WatchCommand/WatchCommand.ts` prints "No watch processes were started. Please ensure that you have specified valid \"app\" or \"package\" parameters", and `packages/cli-server/src/features/WatchCommand.ts` prints "Watching all apps at once is not supported yet. Run them separately".
+- This holds on BOTH deployment targets, AWS and Standalone. Confirmed by Sven: the command must always specify `api` or `admin` at this point.
+- Watching `api` and `admin` together is planned but not available, so the docs say "not supported yet" rather than presenting it as a permanent limitation. Revisit this page and get-started/quickstart/standalone.mdx when the single-command form lands.
+- Do not write a bare `yarn webiny watch` as a runnable example anywhere in the docs. Two such examples in build-with-ai/ai-assisted-development.mdx were corrected.
+
Related Documents:
- cli/deploy.mdx — initial deployment before watch can be used for backend
- cli/output.mdx — retrieve URLs after deploy to use during watch sessions
diff --git a/docs/developer-docs/6.x/cli/watch.mdx b/docs/developer-docs/6.x/cli/watch.mdx
index f74f7bc06..aac8c3fd6 100644
--- a/docs/developer-docs/6.x/cli/watch.mdx
+++ b/docs/developer-docs/6.x/cli/watch.mdx
@@ -22,11 +22,15 @@ The command works differently depending on which app you are watching.
## Usage
+Always specify what to watch. Running `yarn webiny watch` with no `api`, `admin`, or `-p` argument starts nothing and prints a warning.
+
```
yarn webiny watch api
yarn webiny watch admin
```
+Watching `api` and `admin` at the same time is not supported yet, so run them in separate terminals.
+
With a specific environment:
```
diff --git a/docs/developer-docs/6.x/core-concepts/architecture.mdx b/docs/developer-docs/6.x/core-concepts/architecture.mdx
index f0b7ddd05..4caee25b3 100644
--- a/docs/developer-docs/6.x/core-concepts/architecture.mdx
+++ b/docs/developer-docs/6.x/core-concepts/architecture.mdx
@@ -38,13 +38,15 @@ The Webiny Framework provides:
### Infrastructure
-Webiny deploys to your AWS account with:
+On the AWS deployment target, Webiny deploys to your AWS account with:
- **Serverless Architecture** - Auto-scaling Lambda functions
- **Managed Services** - DynamoDB, S3, CloudFront, Cognito
- **Security by Default** - IAM roles, VPC isolation, encryption
- **Multi-region Support** - Deploy across AWS regions
+Webiny Standalone is the other target: a single long-running Node process backed by SQL storage, with no cloud account involved. See [Deployment Targets](/{version}/get-started/deployment-targets) for the full comparison.
+
## When to Use Webiny
### Good Fit
@@ -63,9 +65,8 @@ Webiny excels for projects requiring:
Consider alternatives for:
- **Simple Sites** - Static site generators may be more appropriate
-- **Non-AWS Hosting** - Webiny requires AWS (on-premises not supported)
- **Non-JavaScript Teams** - Requires React, TypeScript, and GraphQL knowledge
-- **Quick Prototypes** - Initial setup requires AWS account and deployment
+- **Production Without AWS** - The only production-ready deployment target today is AWS. [Webiny Standalone](/{version}/get-started/quickstart/standalone) runs without a cloud account, but it is in alpha and local only
## Architecture Principles
diff --git a/docs/developer-docs/6.x/core-concepts/local-development.mdx b/docs/developer-docs/6.x/core-concepts/local-development.mdx
index ce376ca27..73ffc7f9b 100644
--- a/docs/developer-docs/6.x/core-concepts/local-development.mdx
+++ b/docs/developer-docs/6.x/core-concepts/local-development.mdx
@@ -11,6 +11,12 @@ import { Alert } from "@/components/Alert";
Local AWS Lambda Development
+
+
+This page describes local development against deployed AWS infrastructure. On Webiny Standalone the whole instance already runs on your machine, so see [Run Webiny Locally](/{version}/get-started/quickstart/standalone).
+
+
+
## Overview
Webiny provides a streamlined local development experience through watch commands. You can develop both Admin UI and API extensions locally while connected to your deployed AWS infrastructure. This hybrid approach gives you fast iteration with a realistic environment.
diff --git a/docs/developer-docs/6.x/get-started/deploy-webiny.mdx b/docs/developer-docs/6.x/get-started/deploy-webiny.mdx
index 3628a66ea..dcefe8983 100644
--- a/docs/developer-docs/6.x/get-started/deploy-webiny.mdx
+++ b/docs/developer-docs/6.x/get-started/deploy-webiny.mdx
@@ -14,6 +14,12 @@ import { Alert } from "@/components/Alert";
+
+
+Everything on this page is specific to deploying to AWS. Webiny Standalone has no deploy command and no deploy environments, so none of it applies there. [Deployment Targets](/{version}/get-started/deployment-targets) sets out the difference.
+
+
+
## Overview
Webiny deploys three applications to AWS: **Core** (shared infrastructure like databases and file storage), **API** (backend Lambda functions and GraphQL), and **Admin** (the frontend management interface). You can deploy all three at once or target them individually. Webiny also supports multiple isolated environments — so you can maintain separate setups for development, staging, production, and even short-lived feature branches.
diff --git a/docs/developer-docs/6.x/get-started/deployment-targets.ai.txt b/docs/developer-docs/6.x/get-started/deployment-targets.ai.txt
new file mode 100644
index 000000000..7a27b13e7
--- /dev/null
+++ b/docs/developer-docs/6.x/get-started/deployment-targets.ai.txt
@@ -0,0 +1,55 @@
+AI Context: Deployment Targets (deployment-targets.mdx)
+
+Source of Information:
+1. Published npm packages at 6.6.0-alpha.0: create-webiny-project, @webiny/cli-server, @webiny/project-server, @webiny/project-server-template, @webiny/self-hosted-auth, @webiny/system-requirements
+2. webiny-js: packages/project/src/components/FeatureFlag.tsx, for how multi-tenancy is gated
+3. webiny-js: packages/api-headless-cms-sql, packages/api-headless-cms-ddb, packages/api-headless-cms-ddb-es, packages/api-headless-cms-storage
+4. Existing figures in get-started/quickstart.mdx and cli/deploy.mdx
+
+Key Documentation Decisions:
+1. This is the decision-support page, for readers choosing a platform rather than trying to get started. Getting-started material stays on quickstart.mdx and the two nested paths.
+2. Standalone's gaps are listed individually rather than summarised, because a summary lets a reader assume a gap they care about is covered.
+3. The comparison table is kept extractable: one row per dimension, short cells, no prose sentences inside cells.
+4. Cost figures for AWS are reused from the existing docs. No figure is given for Standalone hosting, because there is nothing to host it on yet. Do not invent one.
+5. The "Moving Between Targets" callout deliberately mirrors the tone of the existing DynamoDB permanence warning on the AWS page, and the section explicitly draws the parallel. The section leads with code portability before the callout, because the constraint applies to content only and burying that would overstate the cost of starting on Standalone.
+6. Multi-tenancy is stated as NOT a target difference. It is gated by the `multiTenancy` licence feature flag (FeatureFlag.CanUseMultiTenancy), and packages/api-core-sql carries a full tenancy module, so tenant scoping exists in the storage layer of both targets. The original brief listed multi-tenancy as a target difference; the code does not support that, and treating it as one would entangle the Community/Business axis with the deployment-target axis.
+7. Postgres is described as already available rather than coming. Both _templates/server/sqlite and _templates/server/postgres ship in the published alpha and the CLI prompts between them. The brief said Postgres was still to come.
+8. "Still to Come" carries no dates, and lists only Docker, other platforms, and migration tooling.
+9. Code portability is stated as settled: extensions and customisations are fully portable, and switching targets means changing a few lines in the Infra declarations of webiny.config.tsx. Confirmed by Sven, August 2026. The gap list and the callout are scoped to content only as a result. See get-started/quickstart/standalone.ai.txt for the underlying evidence.
+10. "Still to Come" names a migration script for moving content between instances rather than generic "migration tooling", matching how it was described. No dates.
+
+Verified Differences Between The Targets:
+- Runtime: one long-running Node HTTP server (Standalone) vs Lambda functions behind managed services (AWS). "No Pulumi, no stack output, no deploy, and no deploy environments in the self-hosted hosting type" is stated in project-server-template's webiny.config.base.tsx.
+- Identity: @webiny/self-hosted-auth, a built-in JWT provider with credentials in the project database, vs @webiny/cognito. This is also why Cognito federation for SSO is AWS-only.
+- Storage: SQLite or Postgres via Knex, with uploads in a local directory, vs DynamoDB with S3 and optional OpenSearch.
+- Search: Standalone and DynamoDB-only AWS share the same in-memory path in @webiny/api-headless-cms-storage. Only DynamoDB + OpenSearch is index-backed. Detail is on standalone.mdx.
+- Secrets: Standalone ships insecure development defaults for WEBINY_UPLOAD_SECRET and WEBINY_SELF_HOSTED_AUTH_SECRET.
+- Commands: @webiny/cli-server exposes only `watch` and `serve`. `serve` is described in its own help text as being for production, but no deployment path is published, so this page does not present it as one.
+
+Deployment Target Naming:
+- "Webiny Standalone" for the non-AWS target. npx today, Docker later, Kubernetes and other clouds after that, all as install options under Standalone rather than separate names. Do not introduce "Webiny Container" or "Standalone Edition".
+- The AWS target stays unlabelled. Say "AWS" or "deploy to AWS". Do not use "Webiny Serverless", since Standalone may later run on other clouds and the label would become self-contradictory.
+- Community and Business editions are a separate axis. Keep them separate.
+
+Related Documents:
+- get-started/quickstart.mdx — links here from its closing line
+- get-started/quickstart/standalone.mdx — Standalone install path and search detail
+- get-started/quickstart/aws.mdx — AWS install path
+- get-started/upgrade.mdx — the Community/Business axis, referenced for multi-tenancy
+- infrastructure/introduction.mdx — Database Setups on the AWS side
+- security/cognito-federation.mdx — SSO, which depends on the Cognito identity provider
+
+Key Code Locations:
+- /webiny-js/packages/project/src/components/FeatureFlag.tsx — multi-tenancy licence gating
+- /webiny-js/packages/api-core-sql/src/tenancy — tenant scoping on the SQL storage layer
+- /webiny-js/packages/project-server-template/template/webiny.config.base.tsx — the statement that there is no Pulumi, deploy, or environments on this target
+- /webiny-js/packages/api-headless-cms-storage/src/filtering — the in-memory filter shared by SQL and DynamoDB-only
+
+Tone Guidelines:
+- Plain and comparative. The reader is making a decision and wants the trade-offs stated, not sold
+- No em-dashes. Use commas, colons, or parentheses
+- Never the "it's not X, it's Y" reversal
+- Vary header shapes. Do not build every header on the same template
+- Avoid stacking three-item lists back to back; vary list length
+- British spelling
+- Every specific number must be real. Reuse figures already in the docs rather than estimating
diff --git a/docs/developer-docs/6.x/get-started/deployment-targets.mdx b/docs/developer-docs/6.x/get-started/deployment-targets.mdx
new file mode 100644
index 000000000..627b41f40
--- /dev/null
+++ b/docs/developer-docs/6.x/get-started/deployment-targets.mdx
@@ -0,0 +1,107 @@
+---
+id: r6c1zw5h
+title: Deployment Targets
+description: Compare Webiny Standalone and the AWS deployment target across requirements, capabilities, cost, and current gaps.
+---
+
+import { Alert } from "@/components/Alert";
+
+
+
+- what each deployment target requires before you start
+- how the two differ on scaling, identity, and storage
+- what Standalone cannot do yet
+- what each target costs to run
+
+
+
+## Overview
+
+Webiny has two deployment targets. **Webiny Standalone** runs the platform as a long-running Node process on hardware you control, backed by a SQL database. The **AWS** target deploys the platform into your own AWS account on serverless infrastructure.
+
+Both come from the same Webiny version line and expose the same applications and the same extension APIs. They differ in what they require, how they scale, how identity is handled, and how much of the platform is finished. Standalone is in alpha and has no supported deployment path, so the choice today is less about long-term architecture and more about whether you need something running in production.
+
+If you only want to get Webiny started, go to [Quickstart](/{version}/get-started/quickstart) instead.
+
+## What Each Target Requires
+
+Standalone asks for very little:
+
+- Node.js 24 or later, and Yarn
+- Nothing else. No cloud account, no credentials, and no database server at all if you choose SQLite
+
+The AWS target needs more in place first:
+
+- Node.js 24 or later, and Yarn
+- An AWS account with programmatic access configured on your machine
+- A choice of database setup, which is fixed for the life of the project
+
+## Side by Side
+
+| Dimension | Standalone | AWS |
+| -------------------- | ----------------------------------------------- | ------------------------------------------- |
+| Status | Alpha, published under the `alpha` npm tag | Stable |
+| Cloud account | Not required | AWS account with programmatic access |
+| Content database | SQLite file, or a Postgres server you run | DynamoDB, optionally with OpenSearch |
+| File storage | Local directory in the project | Amazon S3 |
+| Runtime | One long-running Node HTTP server | Lambda functions behind managed services |
+| Scaling | Bounded by the machine it runs on | Scales per request, managed by AWS |
+| Identity | Built-in provider, credentials in your database | Amazon Cognito |
+| Deploy environments | None | `dev`, `staging`, `prod`, and ad hoc |
+| Deploy command | None | `yarn webiny deploy` |
+| Search and filtering | In memory, over entries loaded per query | In memory, or served by an OpenSearch index |
+| Infrastructure cost | None | Usage-based, with an OpenSearch floor |
+| Production use | Not supported | Supported |
+
+## How They Behave
+
+**Scaling.** On AWS, the API runs as Lambda functions, so concurrency is handled for you and there are no servers to size. Standalone is a single Node process. Throughput is whatever that one machine can do, and there is no horizontal scaling story yet.
+
+**Identity.** AWS uses an Amazon Cognito user pool as the identity provider, which is also what makes [Cognito federation](/{version}/security/cognito-federation) available for SSO. Standalone uses Webiny's own built-in provider: accounts and credentials live in your project database, and sign-in is a JWT issued locally. The signing secrets ship with insecure development defaults that would have to be replaced before the instance was exposed to anyone.
+
+**Storage.** AWS stores content in DynamoDB and files in S3. Standalone stores content in SQLite or Postgres and writes uploaded files to a directory inside the project.
+
+**Search.** Both targets can filter and search entirely in the API process, loading a model's entries and applying the query in memory. That is what Standalone always does, and what a DynamoDB-only AWS project does. Adding Amazon OpenSearch on AWS replaces this with index-backed queries, which is the only configuration that gives ranked search and keeps list performance flat as models grow. [Database Setups](/{version}/infrastructure/introduction) covers the AWS side in more detail.
+
+**Multi-tenancy** is not a difference between the targets. It is gated by your Webiny licence rather than by where you run, and tenant scoping is present in the storage layer of both. See [Upgrade to Business](/{version}/get-started/upgrade).
+
+## Standalone's Current Gaps
+
+These are the specific things Standalone does not do today:
+
+- It is published only under the `alpha` npm tag, so it is absent from the current stable release
+- There is no deployment path. No Docker image, no infrastructure templates, and nothing to run it on beyond a developer machine
+- There is no content migration yet, in either direction, between Standalone and AWS. Project code is portable, content is not
+- It runs as one process, so throughput is bounded by one machine and there is no redundancy
+- Search and filtering happen in memory, so list response times grow with the number of entries in a model
+- There are no deploy environments, so there is no `dev`, `staging`, and `prod` separation
+- The default upload and auth signing secrets are development placeholders and are not safe outside your machine
+- Watching the API and Admin apps with a single command is not supported yet, so they run in separate terminals
+
+## Cost Shape
+
+On AWS you pay for what the deployment uses. A DynamoDB-only project has a generous free tier and no fixed monthly cost, so an evaluation environment can be close to free. Adding Amazon OpenSearch introduces an always-on cluster that costs roughly **$25/month** even at the smallest configuration, and that cost applies per environment that runs it. Lambda, S3, CloudFront, and Cognito all bill on usage.
+
+Standalone has no infrastructure cost, because it runs on a machine you already have. There is nothing to host it on yet, so there is no hosting figure to give.
+
+## Moving Between Targets
+
+Project code moves between the targets. Extensions and customisations are fully portable, and switching a project from one target to the other takes a few changes to the `Infra` declarations in `webiny.config.tsx`. Time spent building against Standalone is not wasted when you move to AWS.
+
+
+
+There is no migration tooling between Standalone and AWS today, in either direction. Content entries, uploaded files, user accounts, and everything else held in the database stays in the target where it was created. A migration script is planned. Until it ships, treat a move between targets as starting the content over.
+
+
+
+This mirrors the constraint on the AWS side, where the database setup chosen at project creation cannot be changed later without recreating the project. The advice is the same in both cases: decide before you put content in.
+
+## Still to Come
+
+Work in progress on the Standalone target, with no dates attached to any of it:
+
+- A Docker image, so Standalone can run somewhere other than a developer machine
+- Kubernetes and other cloud platforms after that
+- A migration script for moving content between instances
+
+Postgres is already available as an alternative to SQLite when you create a Standalone project.
diff --git a/docs/developer-docs/6.x/get-started/local-development.mdx b/docs/developer-docs/6.x/get-started/local-development.mdx
index 7b173b313..ada92ca7d 100644
--- a/docs/developer-docs/6.x/get-started/local-development.mdx
+++ b/docs/developer-docs/6.x/get-started/local-development.mdx
@@ -15,11 +15,17 @@ import { Alert } from "@/components/Alert";
+
+
+This page describes the workflow for projects deployed to AWS. Webiny Standalone runs entirely on your machine and has no deployed infrastructure to watch against, so see [Run Webiny Locally](/{version}/get-started/quickstart/standalone) for how development works there.
+
+
+
## Overview
Webiny runs on AWS, but you develop locally. The `watch` commands connect to your deployed infrastructure and let you see changes instantly — without redeploying after every edit. This gives you a fast feedback loop for both frontend and backend work.
-Before using the watch commands, make sure your project is deployed. If you followed the [Quickstart](/{version}/get-started/quickstart), you already have a `dev` environment running.
+Before using the watch commands, make sure your project is deployed. If you followed [Deploy to AWS](/{version}/get-started/quickstart/aws), you already have a `dev` environment running.
## Admin Development
diff --git a/docs/developer-docs/6.x/get-started/quickstart.ai.txt b/docs/developer-docs/6.x/get-started/quickstart.ai.txt
new file mode 100644
index 000000000..6a3e67dfe
--- /dev/null
+++ b/docs/developer-docs/6.x/get-started/quickstart.ai.txt
@@ -0,0 +1,41 @@
+AI Context: Quickstart (quickstart.mdx)
+
+Source of Information:
+1. Previous contents of this file, which was the AWS-only quickstart before the deployment-target split
+2. create-webiny-project 6.6.0-alpha.0, packages/create-webiny-project/src/features/CreateWebinyProject/projects/runHostingTypePrompt.ts
+3. Brief for the two-deployment-target docs restructure (August 2026)
+
+Key Documentation Decisions:
+1. This URL was deliberately kept. It holds all inbound links, the three vercel.json redirects that target it (`/`, `/docs`, `/docs/webiny/introduction`), and the accumulated search ranking. The AWS body moved to quickstart/aws.mdx rather than this page redirecting anywhere.
+2. The frontmatter `id` (aafeab3f) was preserved from the original AWS quickstart, because this is the same page at the same URL.
+3. Standalone is listed first in the cards. A reader at the quickstart stage wants the Admin panel open, and Standalone is the shortest route to that.
+4. No architecture, provider tables, or feature parity on this page. That material lives on deployment-targets.mdx, linked from the last line.
+5. The old anchors on this URL (#prerequisites, #create-a-new-project, #deploy-your-project, #access-the-admin-panel) no longer resolve here. Heading text was preserved verbatim on quickstart/aws.mdx so the same anchors work there. Vercel redirects cannot match a URL fragment, so this could not be fixed with a redirect.
+6. The `` email capture block was removed from this page and the component deleted. It collected emails for the non-AWS version, which now exists.
+
+Deployment Target Naming:
+- The non-AWS target is "Webiny Standalone" in the docs. Install options (npx today, Docker later, Kubernetes after that) are options under Standalone, not separate product names.
+- The AWS target is intentionally unlabelled. Refer to it as "AWS" or "deploy to AWS". Do not coin a proper noun, and specifically do not use "Webiny Serverless", since Standalone may later run on other clouds.
+- The CLI does not use the word "Standalone". Its hosting-type prompt reads "Self-hosted / server (Node HTTP server + SQL storage) — ALPHA" and the internal value is `server`. Renaming the CLI was out of scope, and the mismatch is known and to be polished later. quickstart/standalone.mdx therefore quotes the prompt verbatim, since readers must be able to identify the right option, and maps it to "Standalone" in one neutral sentence. Do not expand that into a caveat, a warning, or a known-issues note.
+- Community and Business editions are a separate axis from deployment targets. Do not entangle the two.
+
+Components:
+- `` / `` (src/components/TargetCards.js) were added for this page. No card or chooser component existed in the repo beforehand. They are registered globally in src/components/mdxComponents.js, so no import is needed in MDX.
+- `` takes `title`, `link`, and an optional `tag` pill (used here for "Alpha").
+
+Related Documents:
+- get-started/quickstart/standalone.mdx — the Standalone path
+- get-started/quickstart/aws.mdx — the AWS path, holding the former body of this page
+- get-started/deployment-targets.mdx — the comparison, for readers making a platform decision
+- get-started/welcome.mdx — links here as step 1 of the Get Started sequence
+
+Key Code Locations:
+- /webiny-js/packages/create-webiny-project/src/features/CreateWebinyProject/projects/runHostingTypePrompt.ts — the hosting-type prompt and its exact wording
+
+Tone Guidelines:
+- Conversational and welcoming, in line with the rest of get-started
+- Short. Roughly 200 words plus the cards. A reader here is choosing, not studying
+- No em-dashes. Use commas, colons, or parentheses
+- Never the "it's not X, it's Y" reversal. State the claim directly
+- British spelling, since this is customer-facing
+- Every specific number must be verifiable. "About 20 minutes" for the AWS deploy is carried over from the existing docs; Standalone uses "a few minutes" because no timing has been measured
diff --git a/docs/developer-docs/6.x/get-started/quickstart.mdx b/docs/developer-docs/6.x/get-started/quickstart.mdx
index e95581bbc..d980044c7 100644
--- a/docs/developer-docs/6.x/get-started/quickstart.mdx
+++ b/docs/developer-docs/6.x/get-started/quickstart.mdx
@@ -1,98 +1,41 @@
---
id: aafeab3f
title: Quickstart
-description: Create a new Webiny project, deploy it to AWS, and access the Admin panel.
+description: Choose how to run Webiny, either locally on your own machine or deployed to your AWS account.
---
import { Alert } from "@/components/Alert";
-- how to set up the prerequisites for a Webiny project
-- how to create a new Webiny project
-- how to deploy it to your AWS account and access the Admin panel
+- which deployment targets Webiny supports
+- which one to start with, and what each one asks of you
## Overview
-By the end of this page you will have a fully working Webiny instance — deployed to your own AWS account, with the Admin panel ready to use. The entire process takes about 20 minutes, most of which is waiting for the first deployment to finish.
+Webiny runs on two deployment targets. Both come from the same Webiny version line, and both give you the whole platform: Headless CMS, File Manager, Website Builder, and the Admin panel.
-## Prerequisites
+**Webiny Standalone** runs on your own machine as a single Node process with a local SQL database. It needs nothing beyond Node and Yarn, which makes it the quickest way to get the Admin panel open in front of you. It is in alpha and runs locally only. Code you write there is portable to AWS. Content is not, until a migration script ships.
-Before you begin, make sure you have the following:
+**Deploying to AWS** puts Webiny into your own AWS account on serverless infrastructure. This is the production path, and it is what the rest of these docs assume unless a page says otherwise. You need an AWS account with programmatic access before you start.
-- **Node.js ≥22** — download it from the [official website](https://nodejs.org/en/) or use [nvm](https://github.com/nvm-sh/nvm) to manage versions
-- **Yarn** — Webiny works with both [Yarn 1 (Classic)](https://yarnpkg.com/en/docs/install) (version 1.22.0 or later) and [Yarn ≥2 (Berry)](https://yarnpkg.com/)
-- **AWS account and credentials** — you need a valid AWS account with programmatic access configured on your system. If you don't have this set up yet, follow the [Configure AWS Credentials](/5.x/infrastructure/aws/configure-aws-credentials) guide
+Pick whichever matches what you are doing right now. Starting with one does not commit you to it.
-
+
+
+ Node and Yarn, no cloud account. SQLite. Running in a few minutes.
+
+
+ Serverless, multi-tenant, production-ready. Needs an AWS account with programmatic access, and
+ about 20 minutes for the first deploy.
+
+
-## Create a New Project
-
-Run the following command in your terminal:
-
-```bash
-npx create-webiny-project my-webiny-project
-```
-
-Follow the on-screen prompts. The setup asks a few questions about your project, including which AWS region to deploy to and which database setup to use.
-
-### Database Setup
-
-Webiny supports two database configurations:
-
-- **Amazon DynamoDB** — a fully serverless option ideal for small-to-medium projects or when you're evaluating Webiny for the first time
-- **Amazon DynamoDB + Amazon OpenSearch** — recommended for large or enterprise-level projects that will handle hundreds of thousands or millions of records
-
-If you're just getting started, choose **Amazon DynamoDB**. It has a generous free tier and scales on demand with no fixed monthly cost.
-
-
-
-The database setup you pick during project creation **cannot be changed later** without recreating the project. If you expect your project to grow significantly, consider starting with DynamoDB + OpenSearch.
-
-Note that the OpenSearch setup includes an always-on cluster that costs roughly **$25/month** even at the smallest configuration.
-
-
-
-Once the setup finishes, you will have a new project folder with two key pieces:
-
-- **`webiny.config.tsx`** — the main configuration file where all extensions and infrastructure settings are declared
-- **`extensions/`** — the folder where all your custom code lives
-
-## Deploy Your Project
-
-Navigate into the project folder and deploy:
-
-```bash
-cd my-webiny-project
-yarn webiny deploy
-```
-
-This deploys all three Webiny applications — Core, API, and Admin — to the `dev` environment in your AWS account.
-
-
-
-The first deployment typically takes **5–15 minutes** as AWS provisions all the necessary resources. It may look like nothing is happening in the terminal — this is normal. Let it finish. If something goes wrong, an error message will appear.
-
-
-
-Once the deployment completes, the terminal displays the URL for your Admin panel.
-
-If you miss it, you can always retrieve it by running:
-
-```bash
-yarn webiny info
-```
-
-## Access the Admin Panel
-
-Open the Admin URL in your browser. Since this is a fresh deployment, you will see the installation wizard. Fill in your name, email, and password to create the first admin account.
-
-After completing the wizard, you will land on the Webiny dashboard. Your instance is now fully operational — Headless CMS, File Manager, and all other Webiny apps are ready to use.
-
-## What's Next
-
-Now that you have a running Webiny instance, the next step is to connect your AI coding environment so it can assist you with customizations.
-
-Continue to [Connect Your AI Environment](/{version}/get-started/connect-ai-environment).
+Making a platform decision rather than getting started? [Deployment Targets](/{version}/get-started/deployment-targets) compares what each target requires, what it gives you, and where Standalone's gaps currently sit.
diff --git a/docs/developer-docs/6.x/get-started/quickstart/aws.ai.txt b/docs/developer-docs/6.x/get-started/quickstart/aws.ai.txt
new file mode 100644
index 000000000..242e0f3a4
--- /dev/null
+++ b/docs/developer-docs/6.x/get-started/quickstart/aws.ai.txt
@@ -0,0 +1,42 @@
+AI Context: Deploy to AWS (aws.mdx)
+
+Source of Information:
+1. The former body of get-started/quickstart.mdx, moved here as part of the deployment-target split
+2. Published npm package @webiny/system-requirements@6.4.8, constraints.js
+3. Published npm package create-webiny-project@6.4.8, which contains no server/standalone code
+
+Key Documentation Decisions:
+1. The body was moved largely unchanged. The database setup section, the permanence warning, the deployment timing expectations, and the admin panel steps are all preserved.
+2. Heading text was preserved verbatim ("Prerequisites", "Create a New Project", "Deploy Your Project", "Access the Admin Panel") so the anchors that used to work on /get-started/quickstart resolve on this page instead. Do not reword these headings.
+3. The `` email capture block was removed and the component deleted from the repo. It collected emails for a non-AWS version of Webiny, which now exists as Webiny Standalone.
+4. A pointer to Standalone was added near the top, framed as an option for readers without an AWS account, along with a link to the deployment-targets comparison.
+5. Em-dashes were replaced with commas, colons, or parentheses throughout, so this page differs stylistically from surrounding docs that still use them. The en-dash range "5-15 minutes" became "5 to 15 minutes".
+6. Node.js was corrected from >=22 to >=24, and Yarn from "1.22.0 or later / Yarn >=2" to "1.22.21 or later / Yarn >=3". These match the constraints @webiny/system-requirements enforces in 6.4.8, which ensureSystemRequirements() checks before anything else runs. The original figures were wrong, not merely stale.
+7. The install command remains a plain `npx create-webiny-project my-webiny-project`. create-webiny-project@latest has no hosting-type prompt, so nothing about target selection belongs on this page yet. When Standalone reaches the stable release, this page will need the hosting-type prompt documented, since the first prompt a reader sees will change.
+
+Verified Figures On This Page:
+- "About 20 minutes" total, carried from the original quickstart and consistent with cli/deploy.mdx
+- "5 to 15 minutes" for the first deployment, matching get-started/deploy-webiny.mdx
+- "Roughly $25/month" for the smallest always-on OpenSearch cluster
+- DynamoDB "generous free tier and no fixed monthly cost"
+
+Related Documents:
+- get-started/quickstart.mdx — the chooser that links here
+- get-started/quickstart/standalone.mdx — the local path, linked from the overview
+- get-started/deployment-targets.mdx — full comparison
+- get-started/deploy-webiny.mdx — environments and deployment in depth, AWS only
+- get-started/local-development.mdx — the day-to-day workflow, AWS only
+- infrastructure/introduction.mdx — Database Setups
+- 5.x/infrastructure/aws/configure-aws-credentials.mdx — the credentials guide this page links to. Note this is a 5.x page linked from a 6.x page; there is no 6.x equivalent yet.
+
+Key Code Locations:
+- /webiny-js/packages/system-requirements/src — the Node, npm, npx, and Yarn constraints enforced at project creation
+- /webiny-js/packages/create-webiny-project/_templates/aws/ddb and _templates/aws/ddb-os — the two AWS webiny.config.tsx templates behind the database choice
+
+Tone Guidelines:
+- Conversational and welcoming, in line with the rest of get-started
+- Practical and sequential. The reader is following along in a terminal
+- No em-dashes on this page. Use commas, colons, or parentheses
+- Never the "it's not X, it's Y" reversal
+- British spelling
+- Every specific number must be real and verifiable against the published CLI
diff --git a/docs/developer-docs/6.x/get-started/quickstart/aws.mdx b/docs/developer-docs/6.x/get-started/quickstart/aws.mdx
new file mode 100644
index 000000000..9302599d4
--- /dev/null
+++ b/docs/developer-docs/6.x/get-started/quickstart/aws.mdx
@@ -0,0 +1,98 @@
+---
+id: b7k3n9qd
+title: Deploy to AWS
+description: Create a new Webiny project, deploy it to AWS, and access the Admin panel.
+---
+
+import { Alert } from "@/components/Alert";
+
+
+
+- how to set up the prerequisites for a Webiny project
+- how to create a new Webiny project
+- how to deploy it to your AWS account and access the Admin panel
+
+
+
+## Overview
+
+By the end of this page you will have a fully working Webiny instance, deployed to your own AWS account, with the Admin panel ready to use. The entire process takes about 20 minutes, most of which is waiting for the first deployment to finish.
+
+If you do not have an AWS account yet, Webiny Standalone runs on your own machine with no cloud credentials at all. It is currently in alpha and intended for local evaluation, so see [Run Webiny Locally](/{version}/get-started/quickstart/standalone) if that is the faster way for you to see the product. For a side-by-side view of what each target requires and provides, read [Deployment Targets](/{version}/get-started/deployment-targets).
+
+## Prerequisites
+
+Before you begin, make sure you have the following:
+
+- **Node.js ≥24**: download it from the [official website](https://nodejs.org/en/) or use [nvm](https://github.com/nvm-sh/nvm) to manage versions
+- **Yarn**: Webiny works with both [Yarn 1 (Classic)](https://yarnpkg.com/en/docs/install) (version 1.22.21 or later) and [Yarn ≥3 (Berry)](https://yarnpkg.com/)
+- **AWS account and credentials**: you need a valid AWS account with programmatic access configured on your system. If you don't have this set up yet, follow the [Configure AWS Credentials](/5.x/infrastructure/aws/configure-aws-credentials) guide
+
+## Create a New Project
+
+Run the following command in your terminal:
+
+```bash
+npx create-webiny-project my-webiny-project
+```
+
+Follow the on-screen prompts. The setup asks a few questions about your project, including which AWS region to deploy to and which database setup to use.
+
+### Database Setup
+
+Webiny supports two database configurations:
+
+- **Amazon DynamoDB**: a fully serverless option ideal for small-to-medium projects or when you're evaluating Webiny for the first time
+- **Amazon DynamoDB + Amazon OpenSearch**: recommended for large or enterprise-level projects that will handle hundreds of thousands or millions of records
+
+If you're just getting started, choose **Amazon DynamoDB**. It has a generous free tier and scales on demand with no fixed monthly cost.
+
+
+
+The database setup you pick during project creation **cannot be changed later** without recreating the project. If you expect your project to grow significantly, consider starting with DynamoDB + OpenSearch.
+
+Note that the OpenSearch setup includes an always-on cluster that costs roughly **$25/month** even at the smallest configuration.
+
+
+
+Once the setup finishes, you will have a new project folder with two key pieces:
+
+- **`webiny.config.tsx`**: the main configuration file where all extensions and infrastructure settings are declared
+- **`extensions/`**: the folder where all your custom code lives
+
+## Deploy Your Project
+
+Navigate into the project folder and deploy:
+
+```bash
+cd my-webiny-project
+yarn webiny deploy
+```
+
+This deploys all three Webiny applications (Core, API, and Admin) to the `dev` environment in your AWS account.
+
+
+
+The first deployment typically takes **5 to 15 minutes** as AWS provisions all the necessary resources. It may look like nothing is happening in the terminal, which is normal. Let it finish. If something goes wrong, an error message will appear.
+
+
+
+Once the deployment completes, the terminal displays the URL for your Admin panel.
+
+If you miss it, you can always retrieve it by running:
+
+```bash
+yarn webiny info
+```
+
+## Access the Admin Panel
+
+Open the Admin URL in your browser. Since this is a fresh deployment, you will see the installation wizard. Fill in your name, email, and password to create the first admin account.
+
+After completing the wizard, you will land on the Webiny dashboard. Your instance is now fully operational, with Headless CMS, File Manager, and all other Webiny apps ready to use.
+
+## What's Next
+
+Now that you have a running Webiny instance, the next step is to connect your AI coding environment so it can assist you with customizations.
+
+Continue to [Connect Your AI Environment](/{version}/get-started/connect-ai-environment).
diff --git a/docs/developer-docs/6.x/get-started/quickstart/standalone.ai.txt b/docs/developer-docs/6.x/get-started/quickstart/standalone.ai.txt
new file mode 100644
index 000000000..579ed775a
--- /dev/null
+++ b/docs/developer-docs/6.x/get-started/quickstart/standalone.ai.txt
@@ -0,0 +1,63 @@
+AI Context: Run Webiny Locally (standalone.mdx)
+
+Source of Information:
+1. Published npm package create-webiny-project@6.6.0-alpha.0, specifically _templates/server/sqlite/webiny.config.tsx and _templates/server/sqlite/.env.example
+2. Published npm package @webiny/cli-server@6.6.0-alpha.0, features/WatchCommand.js and features/ServeCommand.js
+3. Published npm package @webiny/system-requirements@6.6.0-alpha.0, constraints.js
+4. webiny-js: packages/create-webiny-project/src/features/CreateWebinyProject/projects/runHostingTypePrompt.ts and projects/server/runInteractivePrompt.ts
+5. webiny-js: packages/self-hosted-auth/src/api/features/UserInstaller/UserInstaller.ts
+6. webiny-js: packages/api-headless-cms-sql/src/operations/entry/queryHelpers.ts, packages/api-headless-cms-storage/src/filtering/fullTextSearch.ts, packages/db-utils/src/valueFilter/filters/ContainsFilter.ts
+
+Status of the facts on this page: every deviation from the original brief below was put to Sven and confirmed in August 2026. Standalone really is alpha-tag only, two watch commands really are required (a single command is planned), Node 24 really is the requirement, a database prompt really does appear, and multi-tenancy really is a licence feature flag rather than a target difference. The "self-hosted / server" versus "Standalone" naming mismatch is known and will be polished later, so state the mapping neutrally rather than flagging it as a defect.
+
+Key Documentation Decisions:
+1. The alpha constraint sits above the install command, not below it. The failure mode being designed against is a reader taking the fast path, spending a week on content models and extensions, then discovering they cannot deploy and cannot move their content.
+2. The install command pins the exact alpha version rather than using `@alpha`. Standalone is absent from create-webiny-project@latest (6.4.8) entirely, so a plain `npx create-webiny-project` will not offer the hosting-type prompt at all. The pinned version needs updating when a newer alpha ships.
+3. Node 24 is stated, not Node 22. @webiny/system-requirements pins `node: ">=24"` in both 6.4.8 and 6.6.0-alpha.0, the scaffolded package.json sets engines.node "^24.0.0", and ensureSystemRequirements() runs as the first action in create-webiny-project. The "Node.js >=22" in the old quickstart was wrong.
+4. Yarn is stated as 1.22.21 or later, or 3 or later, matching the enforced constraint `yarn: ">=1.22.21 || >=3"`. The old quickstart said "1.22.0 or later" and "Yarn >=2".
+5. The run instructions use `yarn webiny watch api` and `yarn webiny watch admin` in separate terminals. A bare `yarn webiny watch` does NOT work: WatchCommand warns "Watching all apps at once is not supported yet" and exits. The scaffolded template's own comment says "Run it with `yarn webiny watch`", which is incorrect.
+6. The database prompt IS documented, briefly and inline rather than as its own section. The original brief said to omit database selection entirely on the grounds that Standalone is SQLite-only, but the CLI does prompt for SQLite or PostgreSQL and both templates ship in the published alpha. Leaving it out would strand the reader at a live prompt.
+7. The absence of AWS credentials is stated explicitly, because readers arriving from the AWS docs will expect to need them.
+8. No timing estimate is given for the Standalone path. "A few minutes" is used because no measurement has been taken.
+9. The top callout states code portability explicitly, because it changes how the alpha should be read. Confirmed by Sven, August 2026: extensions and customisations users write are fully portable to AWS, webiny.config.tsx needs only a few lines changed in its Infra declarations, and a migration script for moving content between instances is planned. This is what turns the alpha from a dead end into a usable head start, so the callout scopes "disposable" to content created in the Admin panel rather than to the whole project.
+
+Standalone Runtime Facts:
+- Bin name in a scaffolded project is `webiny` (@webiny/cli-server declares `bin: { "webiny": "./bin.js" }`), which sets WEBINY_HOSTING_TYPE=server. The monorepo's separate `webiny-server` bin is a monorepo-only convenience, and WatchCommand's warning text still names it, which is misleading in a scaffolded project.
+- Only two commands exist on this target: `watch` and `serve`. There is no `deploy`, no Pulumi, and no deploy environments.
+- `serve` exists and is described as "Serves built apps as long-running servers (production)", but no deployment path, image, or infrastructure template is published, so the docs do not present it as a way to deploy.
+- Admin serves on port 3001 (WEBINY_ADMIN_PORT), API on 3002 (WEBINY_API_PORT).
+- SQLite file defaults to ./.webiny/server.sqlite and uploads to ./.webiny/storage, both resolved against the project root rather than the disposable app workspace, so data survives rebuilds.
+- Identity is @webiny/self-hosted-auth: a built-in JWT provider replacing Cognito. UserInstaller is an AppInstaller that creates the first admin with the `full-access` role, so the installation wizard flow matches AWS.
+- WEBINY_UPLOAD_SECRET and WEBINY_SELF_HOSTED_AUTH_SECRET default to "dev-only-insecure-..." placeholders.
+
+Search Behaviour Under SQL (verified, load-bearing):
+- listEntries pushes only tenant, modelId, isLatest/isPublished, and wbyDeleted down to SQL. Every field filter, the search term, sorting, and pagination are applied in Node memory after the rows are loaded. MAX_LIST_LIMIT is 1,000,000.
+- Full-text search goes through the shared `contains` value filter: the term is split on whitespace, and every word must appear as a case-insensitive substring within a single field value. No stemming, no relevance ranking, no fuzzy matching.
+- This is the SAME code path (@webiny/api-headless-cms-storage) that the DynamoDB-only AWS setup uses. It differs from DynamoDB + OpenSearch, which is query/index based. Stating the equivalence is more useful to readers than describing it in isolation.
+
+Related Documents:
+- get-started/quickstart.mdx — the chooser that links here
+- get-started/quickstart/aws.mdx — the AWS path
+- get-started/deployment-targets.mdx — full comparison and the gap list
+- infrastructure/introduction.mdx — Database Setups, for how the AWS search options compare
+Code Portability Between Targets (resolved, August 2026):
+- Extensions and customisations users write are fully portable between Standalone and AWS. This matches what the code suggests: the server API handler is documented as using "the same shared, transport-agnostic request stack the AWS handler uses", and both targets run the same @webiny/api-headless-cms behind different storage-operations packages.
+- webiny.config.tsx is not portable as-is, but the change is small and confined to the Infra declarations. The server scaffold renders Infra.Sqlite / Infra.FileStorage / Infra.ApiUrl / SelfHostedAuth with Infra imported from @webiny/project-server, while the AWS scaffold renders Infra.Aws.DefaultRegion / Infra.Encryption / Cognito with Infra from webiny/extensions. The monorepo keeps these in separate files (webiny.config.aws.tsx, webiny.config.server.tsx) switched on WEBINY_HOSTING_TYPE, so treat the split as the shape a portable project takes rather than as a blocker.
+- Content does not move between targets yet. A migration script for moving content between instances is planned. Do not attach a date to it.
+- Consequence for the copy: scope "disposable" to content, never to the project. Saying the whole project is throwaway understates the alpha and is now wrong.
+
+Key Code Locations:
+- /webiny-js/packages/create-webiny-project/src/features/CreateWebinyProject/projects/server/SetupServerWebinyProject.ts — server project scaffolding and its dependency set
+- /webiny-js/packages/cli-server/src/features/WatchCommand.ts — the per-app watch restriction
+- /webiny-js/packages/api-headless-cms-sql/src/operations/entry/queryHelpers.ts — listEntries, showing what is and is not pushed to SQL
+- /webiny-js/packages/self-hosted-auth/src/api/features/UserInstaller/UserInstaller.ts — first admin creation
+
+Tone Guidelines:
+- Conversational and welcoming, matching the rest of get-started, but blunt about the alpha limits
+- The constraint comes before the reward. Do not soften the callout
+- No em-dashes. Use commas, colons, or parentheses
+- Never the "it's not X, it's Y" reversal
+- Vary header shapes. Do not build every header on the same template
+- Avoid stacking three-item lists back to back
+- British spelling
+- Do not invent timings, costs, or version numbers. Verify against the published packages
diff --git a/docs/developer-docs/6.x/get-started/quickstart/standalone.mdx b/docs/developer-docs/6.x/get-started/quickstart/standalone.mdx
new file mode 100644
index 000000000..d3f10b8b4
--- /dev/null
+++ b/docs/developer-docs/6.x/get-started/quickstart/standalone.mdx
@@ -0,0 +1,104 @@
+---
+id: m4x8vt2p
+title: Run Webiny Locally
+description: Run Webiny Standalone on your own machine with no cloud account, using SQLite for storage.
+---
+
+import { Alert } from "@/components/Alert";
+
+
+
+- what Webiny Standalone is, and what it cannot do yet
+- how to create a Standalone project and start it on your machine
+- how to create your first admin account
+- how search behaves when Webiny runs on SQLite
+
+
+
+
+
+Standalone runs on your machine, and there is no supported way to deploy it to a server yet. The code you write does carry over: extensions and customisations are fully portable, and moving a project to AWS takes a few changes to the `Infra` declarations in `webiny.config.tsx`. Content is what cannot move yet, so treat anything you create in the Admin panel as disposable until the migration script ships.
+
+
+
+## Overview
+
+Webiny Standalone is a deployment target that runs Webiny as a long-running Node process on your own machine, backed by a SQL database. No AWS account, no cloud credentials, no infrastructure to provision. You get the same Admin panel, Headless CMS, File Manager and Website Builder that the AWS target gives you, running entirely locally.
+
+Standalone is in alpha. It is the fastest way to see Webiny working, and it is not a production deployment path. If you are weighing the two targets against each other rather than trying to get started, read [Deployment Targets](/{version}/get-started/deployment-targets) first.
+
+## Before You Start
+
+You need:
+
+- **Node.js ≥24**: download it from the [official website](https://nodejs.org/en/) or use [nvm](https://github.com/nvm-sh/nvm) to manage versions
+- **Yarn**: either [Yarn 1 (Classic)](https://yarnpkg.com/en/docs/install) 1.22.21 or later, or [Yarn ≥3 (Berry)](https://yarnpkg.com/)
+
+You do **not** need an AWS account, AWS credentials, or any other cloud provider account. If you arrived here from the AWS documentation, none of the credential setup described there applies to this target. Nothing on this page reaches outside your machine.
+
+## Create the Project
+
+Standalone ships under the `alpha` npm tag. It is not part of the current stable release, so the version has to be given explicitly:
+
+```bash
+npx create-webiny-project@6.6.0-alpha.0 my-webiny-project
+```
+
+The first prompt asks how you want to host the project. Choose the second option:
+
+```
+Self-hosted / server (Node HTTP server + SQL storage) — ALPHA
+```
+
+The CLI's wording for this target is "self-hosted / server", which is the same thing this page calls Standalone.
+
+Next you are asked which database to use. Pick **SQLite (single-file local database)**, which needs nothing installed and writes to a single file in your project. PostgreSQL is offered as well, and connecting it means running a Postgres server yourself. Unlike the AWS target, where the database choice is fixed for the life of the project, nothing here is permanent: throw the project away and create another one.
+
+The last prompt asks which AI agent you use, so the project can be set up with matching configuration.
+
+## Starting the Instance
+
+There is no deploy step on this target and no `deploy` command. The `watch` command builds your code and runs it, so what you edit is what is running.
+
+Open two terminals. In the first, start the API:
+
+```bash
+cd my-webiny-project
+yarn webiny watch api
+```
+
+In the second, start the Admin app:
+
+```bash
+yarn webiny watch admin
+```
+
+Watching both apps with a single command is not supported yet, which is why they run separately. The API serves on `http://localhost:3002` and the Admin app on `http://localhost:3001`.
+
+Your data is written to `.webiny/server.sqlite` and uploaded files to `.webiny/storage`, both resolved against the project root, so they survive rebuilds and restarts.
+
+## Your First Admin Account
+
+Open `http://localhost:3001` in your browser. Because the database is empty, you will see the installation wizard. Fill in your name, email, and password, and the first admin account is created with full access.
+
+Standalone uses Webiny's built-in identity provider rather than Amazon Cognito, so the account you just created lives in your local database and you sign in against it directly. From here you land on the dashboard, with all Webiny apps ready to use.
+
+## How Search Behaves
+
+Search and filtering on this target run inside the API process rather than in the database. Webiny loads the entries for the model being queried, then applies filtering, search, sorting and pagination in memory.
+
+For a search term, this means:
+
+- the term is split on whitespace, and every word must appear as a case-insensitive substring of one of the model's searchable fields
+- there is no stemming, so "run" will not match "running"
+- there is no relevance ranking or fuzzy matching, and results come back in the model's sort order
+
+This is the same behaviour as the DynamoDB-only setup on AWS. It differs from DynamoDB + Amazon OpenSearch, where queries are served by an OpenSearch index and you get ranked, index-backed search. See [Database Setups](/{version}/infrastructure/introduction) for how the AWS side compares.
+
+Because every list query loads the model's entries before filtering them, response times grow with the number of entries in a model. That is comfortable for evaluation and local development, and it is one of the reasons Standalone is not a production path today.
+
+## What's Next
+
+You have Webiny running locally. The next step is to connect your AI coding environment so it can help you build against it.
+
+Continue to [Connect Your AI Environment](/{version}/get-started/connect-ai-environment).
diff --git a/docs/developer-docs/6.x/get-started/welcome.mdx b/docs/developer-docs/6.x/get-started/welcome.mdx
index 0965c2f69..b11478d4d 100644
--- a/docs/developer-docs/6.x/get-started/welcome.mdx
+++ b/docs/developer-docs/6.x/get-started/welcome.mdx
@@ -68,11 +68,13 @@ If you’re new to GraphQL or TypeScript, start with the Getting Started section
If you're new to Webiny, follow the Get Started guides in order:
-1. [Quickstart](/{version}/get-started/quickstart) — create a project and deploy it to AWS
-2. [Connect Your AI Environment](/{version}/get-started/connect-ai-environment) — set up the MCP server so AI can assist with customizations
-3. [First Customization](/{version}/get-started/first-customization) — build a content model as your first code extension
-4. [Local Development](/{version}/get-started/local-development) — learn the day-to-day development workflow
-5. [Deploy Webiny](/{version}/get-started/deploy-webiny) — understand environments and deployment in depth
+1. [Quickstart](/{version}/get-started/quickstart): choose a deployment target, either locally with Webiny Standalone or deployed to your AWS account
+2. [Connect Your AI Environment](/{version}/get-started/connect-ai-environment): set up the MCP server so AI can assist with customizations
+3. [First Customization](/{version}/get-started/first-customization): build a content model as your first code extension
+4. [Local Development](/{version}/get-started/local-development): learn the day-to-day development workflow
+5. [Deploy Webiny](/{version}/get-started/deploy-webiny): understand environments and deployment in depth
+
+If you are weighing the two deployment targets against each other, [Deployment Targets](/{version}/get-started/deployment-targets) compares what each one requires and provides.
For a more guided, lesson-by-lesson learning experience, check out the **Learn Webiny Course** — a free, self-paced course at learn.webiny.com.
diff --git a/docs/developer-docs/6.x/navigation.tsx b/docs/developer-docs/6.x/navigation.tsx
index 552afa36e..ecabd96f6 100644
--- a/docs/developer-docs/6.x/navigation.tsx
+++ b/docs/developer-docs/6.x/navigation.tsx
@@ -11,6 +11,9 @@ export const Navigation = ({ children }: { children: React.ReactNode }) => {
link={"get-started/quickstart"}
>
+
+
+
diff --git a/src/components/StandaloneVersionNotice.js b/src/components/StandaloneVersionNotice.js
deleted file mode 100644
index 6910e01fa..000000000
--- a/src/components/StandaloneVersionNotice.js
+++ /dev/null
@@ -1,18 +0,0 @@
-import React from "react";
-import { Alert } from "@/components/Alert";
-import { InputFooter } from "@/components/page/InputFooter";
-
-export const StandaloneVersionNotice = () => {
- return (
-
-
- We're building a standalone version of Webiny that doesn't require AWS — runs on any
- infrastructure. It's weeks away, not months. Drop your email and we'll ping you the
- moment it's ready.
-
-
-
-
-
- );
-};
diff --git a/src/components/TargetCards.js b/src/components/TargetCards.js
new file mode 100644
index 000000000..6b9f2294b
--- /dev/null
+++ b/src/components/TargetCards.js
@@ -0,0 +1,52 @@
+import Link from "next/link";
+import clsx from "clsx";
+import { stripBasePath } from "@/utils/stripBasePath";
+
+/**
+ * A two-up (or three-up) grid of linked cards, used when a page asks the reader to pick a path
+ * rather than read straight through. Cards stack on small screens and sit side by side from `lg`.
+ */
+export function TargetCards({ children }) {
+ return
{children}
;
+}
+
+/**
+ * A single card. The whole card is one link, so there is no separate call to action to miss.
+ * `tag` renders an optional pill next to the title (for example "Alpha") and `note` a de-emphasised
+ * qualifier under the body.
+ *
+ * Keep the body a single paragraph. A blank line followed by indented text inside JSX is parsed as
+ * an indented code block by MDX and ends up rendered as a code editor. Use `note` for a second line.
+ */
+export function TargetCard({ title, link, tag, note, children }) {
+ return (
+
+