docs: split Get Started into two deployment targets

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
 

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

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:
 
 ```

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
 

docs/developer-docs/6.x/core-concepts/local-development.mdx

@@ -11,6 +11,12 @@ import { Alert } from "@/components/Alert";
   Local AWS Lambda Development
 </Alert>
 
+<Alert type="info" title="Applies to the AWS target">
+
+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).
+
+</Alert>
+
 ## 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.

docs/developer-docs/6.x/get-started/deploy-webiny.mdx

@@ -14,6 +14,12 @@ import { Alert } from "@/components/Alert";
 
 </Alert>
 
+<Alert type="info" title="Applies to the AWS target">
+
+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.
+
+</Alert>
+
 ## 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.

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

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";
+
+<Alert type="success" title="WHAT YOU'LL LEARN">
+
+- 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
+
+</Alert>
+
+## 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.
+
+<Alert type="warning" title="Content does not move between targets">
+
+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.
+
+</Alert>
+
+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.