docs: split Get Started into two deployment targets

[SvenAlHamad]

Splits the Get Started section along the two deployment targets. The quickstart URL is preserved and becomes a chooser; the target-specific instructions move into nested pages.

Pages

URL	Change
/get-started/quickstart	Rewritten as a chooser. Same URL, same frontmatter id.
/get-started/quickstart/standalone	New. Webiny Standalone, alpha constraint above the install command.
/get-started/quickstart/aws	New. Holds the former quickstart body.
/get-started/deployment-targets	New. Comparison, cost shape, Standalone's gaps.

Nothing was redirected away from /get-started/quickstart, so the inbound links, the three vercel.json redirects that target it (/, /docs, /docs/webiny/introduction) and the search ranking all stay put. No new redirects were needed, since every changed page either keeps its URL or is new.

Also in this PR: a new <TargetCards> / <TargetCard> component (none existed), removal of StandaloneVersionNotice, the sidebar reordering, and scoping notes on the pages that turned out to be AWS-only.

Anchor links that will break

Four anchors on /get-started/quickstart stop resolving: #prerequisites, #create-a-new-project, #deploy-your-project, #access-the-admin-panel.

This cannot be fixed with a redirect. A URL fragment is never sent to the server, so Vercel cannot match on one. All seven existing anchor redirects in vercel.json put the anchor in the destination only, which is a different thing. Vercel's has / missing conditions match headers, cookies and query params, not fragments.

What I did instead: the heading text on /get-started/quickstart/aws is preserved verbatim, so all four anchors resolve on that page. Anyone landing on the chooser with a stale fragment gets a valid page with no scroll target rather than a 404. If that is not good enough, the only remaining option is a small client-side useEffect on the chooser that maps known legacy hashes to the AWS page. Say the word and I will add it.

Code portability: resolved

The open question is answered, and the copy now states it.

Extensions and customisations users write are fully portable between the two targets. webiny.config.tsx is not portable as-is, but the change is small and confined to the Infra declarations. Content does not move yet; a migration script for moving content between instances is planned, with no date attached.

That changes the risk callout materially, as expected. "Disposable" is now scoped to content created in the Admin panel rather than to the whole project, so the alpha reads as a usable head start instead of a dead end:

Local only for now. 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.

Four other places were updated to match: the chooser's Standalone paragraph, the "Moving Between Targets" section on the comparison page (which now leads with code portability before the content warning), the gap list entry, and "Still to Come", which names the migration script rather than generic tooling. Both .ai.txt files record the answer and the reasoning, so this does not get re-litigated.

Findings that contradict the brief: all confirmed

Six things I could not write as specified, because the published code said otherwise. All six were put to Sven and confirmed, so the pages describe reality and nothing here is outstanding. Verified against create-webiny-project@6.6.0-alpha.0 and the local webiny-js checkout.

1. Standalone is not in the stable release. create-webiny-project@latest is 6.4.8 and contains no server code at all: no hosting-type prompt, no server templates. Standalone exists only under the alpha tag (6.6.0-alpha.0). Confirmed. The page pins that version explicitly, and will need updating when a newer alpha ships.

2. yarn webiny watch on its own does not work. WatchCommand bails with "Watching all apps at once is not supported yet. Run them separately". The page documents yarn webiny watch api and yarn webiny watch admin in two terminals. Confirmed, and a single command is planned, so the page says "not supported yet". Two smaller CLI messaging bugs remain worth filing, since they mislead users today: the scaffolded template's own comment says "Run it with yarn webiny watch", and the warning text names webiny-server, a monorepo-only bin that does not exist in a scaffolded project.

3. Node 24, not 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 existing quickstart's "Node.js ≥22" was already wrong for the shipped CLI, so I corrected it on the AWS page too. Yarn was wrong the same way: the enforced constraint is >=1.22.21 || >=3, not "1.22.0 or later" and "Yarn ≥2".

4. There is a database prompt on Standalone. The brief said to omit database selection because Standalone is SQLite-only. The CLI prompts between "SQLite (single-file local database)" and "PostgreSQL (connect to a Postgres server)", and both templates ship in the published alpha. Omitting it would strand the reader at a live prompt, so it gets one short inline paragraph rather than its own section, including the sentence you wanted about the contrast with AWS permanence. Postgres is therefore described as already available rather than coming.

5. The CLI does not say "Standalone". Its prompt reads Self-hosted / server (Node HTTP server + SQL storage) — ALPHA, the value is server, the env var is WEBINY_HOSTING_TYPE. Renaming the CLI was out of scope, so the page quotes the prompt text verbatim and states that it is the same thing. Confirmed as a known mismatch to be polished later, so the page maps the two names in one neutral sentence rather than presenting the CLI wording as out of date. The prompt text stays quoted verbatim, since readers need it to pick the right option.

6. Multi-tenancy is not a target difference. It is gated by the multiTenancy licence feature flag (FeatureFlag.CanUseMultiTenancy) and api-core-sql carries a full tenancy module, so tenant scoping is in the storage layer of both targets. Presenting it as a target difference would entangle the Community/Business axis with this one, which the brief itself rules out, so the comparison page states plainly that it is a licence feature. The AWS card still says "multi-tenant" as drafted, which is true of AWS. I have not verified multi-tenancy end to end on Standalone in alpha.

One smaller nuance: @webiny/cli-server does expose a serve command, described in its own help text as "Serves built apps as long-running servers (production)". Since no image, template or deployment path is published, the pages do not present it as a way to deploy, and the "no supported way to deploy" callout stands as written. Flagging it because it sits slightly awkwardly against that sentence.

Search behaviour under SQLite, since you asked

Verified, and it differs from OpenSearch in a way worth documenting. 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 load (MAX_LIST_LIMIT is 1,000,000). The search 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 the DynamoDB-only AWS setup uses (@webiny/api-headless-cms-storage). Only DynamoDB + OpenSearch is index-backed. Stating the equivalence is more useful than describing SQLite in isolation, so both new pages do that.

Scoping: Local Development and Deploy Webiny

Both are AWS-only end to end, as suspected. Each now carries an "Applies to the AWS target" note pointing at the Standalone page, and nothing else was rewritten in this pass.

• get-started/local-development.mdx: "Webiny runs on AWS, but you develop locally", and the whole watch model depends on deployed infrastructure. Its Quickstart link now points at the AWS page, since it tells the reader their project is already deployed.
• get-started/deploy-webiny.mdx: "Webiny deploys three applications to AWS", plus environments and destroy, none of which exist on Standalone.
• core-concepts/local-development.mdx has the same problem and was not in the brief. It got the same note.
• core-concepts/architecture.mdx (a hidden page) claimed "Webiny requires AWS (on-premises not supported)" and listed "Quick Prototypes" as a poor fit because "initial setup requires AWS account and deployment". Both are now wrong in a way that matters, so they are corrected. Standalone is arguably the best answer for quick prototypes now.

These two genuinely need rewriting rather than annotating, but that is a separate pass.

webiny watch requires an app argument, everywhere

Confirmed that yarn webiny watch must always name api or admin at this point, so I swept the rest of 6.x for the bare form. It is enforced on both targets: cli-aws warns "No watch processes were started. Please ensure that you have specified valid "app" or "package" parameters", and cli-server warns "Watching all apps at once is not supported yet".

Two pages outside the Get Started section were showing a command that does nothing:

• build-with-ai/ai-assisted-development.mdx had two bare yarn webiny watch examples, in the workflow list and the closing checklist. Both now name an app.
• cli/watch.mdx, the canonical reference, showed only the correct forms but never stated the rule. It now says so explicitly, and notes that watching both apps at once is not supported yet.

Everything else in 6.x already specified an app. cli/watch.ai.txt records the requirement, both CLI warning strings, and a note to revisit when the single-command form lands.

This is slightly outside the brief's scope, but it was a documented command that could not work, on the exact point being confirmed.

Repo notes

• AGENTS.md says docs live in docs/developer-docs/6.0.x/; the tree is 6.x. It also lists get-started/install-webiny.mdx and overview/pricing.mdx as validation exceptions, neither of which exists in 6.x, and says "no shell/bash code blocks" while every Get Started page uses them. Worth a tidy-up.
• yarn validate:mdx already fails on master: 12 missing .ai.txt and 3 orphaned. This PR adds companions for all four pages it touches, which takes the missing count from 12 to 11. The rest is pre-existing.
• yarn generate already fails on master on 10 files with broken /reference/api/... links. None of them is a file this PR touches, and no link on the new pages is flagged.
• yarn format:check baseline is unchanged at 43 files. yarn lint produces only pre-existing warnings.
• The docs 6.x tree describes 6.4.8 while Standalone needs 6.6.0-alpha.0. If the split-version situation persists, the Standalone page may want a version notice component.

Verification

yarn build:next passes with all four routes statically prerendered. Served the production build and confirmed: both cards render in the right order with correct hrefs and the Alpha pill; the comparison table renders with 12 dimension rows; the sidebar reads Quickstart, Run Webiny Locally, Deploy to AWS, Deployment Targets, Connect Your AI Environment, First Customization, Local Development, Deploy Webiny, Upgrade to Business.

One bug caught and fixed during that check: a blank line followed by indented text inside the card JSX was parsed by MDX as an indented code block, so the second line of each card rendered through <Editor> as a code snippet. TargetCard now takes a note prop, and the component carries a comment so the trap is not re-set later.

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
docs-webiny-com	Ready	Preview	Aug 13, 2026 11:37am