Announcing Console IV: the website and Console as one app_

For most of Appwrite's life, appwrite.io and the Console were two products that happened to share a logo. The website lived in appwrite/website. The Console lived in appwrite/console. Two Svelte apps, two build pipelines, two design systems drifting apart at their own pace, and a hard border down the middle: docs on one side of it, your project on the other.

The cost of that border was small each time and constant. For example, you are setting permissions on a storage bucket, and you want to check whether Role.users() covers anonymous sessions or only signed-in ones. The answer is one line in the permissions reference, and reaching it means leaving the form you are in the middle of filling out.

That hop is a miniature of a larger pattern. Building on Appwrite has always meant bouncing between the IDE, the docs, the SDKs, the CLI, and a terminal, and we have wanted to shrink that context switching for years. Console IV is our dig at it.

Today we are announcing Console IV, the fourth generation of the Appwrite Console. It is rebuilt on TanStack Start, and it absorbs appwrite.io. The marketing pages, more than 600 documentation pages, the blog, the changelog, and every Console route now run in one application.

Nothing about your projects changes. Console IV is a new interface over the same APIs, and your bookmarks, API keys, and SDK code keep working.

The docs are in the Console now

This is arguably the biggest benefit of the merge.

Click a docs link while you are inside a project and the page opens in a pane on the right of the screen you are already on. The form you were filling in stays where it was. The pane carries its own breadcrumb and back navigation, so you can follow a link from the auth reference into the SDK reference and still find your way back.

One deliberate exception: docs links inside dialogs and setup wizards still open a new tab. Covering a flow you are halfway through with a docs pane is worse than the tab was.

One Command Center across the whole product

The Command Center is scoped rather than duplicated. Every command declares the scopes it belongs to, out of account, organization, project, and docs, so the palette offers project navigation when you are in a project and docs navigation when you are reading a guide.

Search documentation is registered in all four. From a table row, a billing page, or the quick starts index, ⌘ + K and a few characters put you in the docs, and the result opens in the same right pane instead of a new tab.

Two developer tools we are shipping today live in the same app:

• Appwrite Terminal runs the Appwrite CLI in the browser with your session and project already configured. Open it with ⌘ + ;.
• Appwrite Explorer builds and sends live REST requests against the project you are viewing, using your project's OpenAPI specification.

Terminal, Explorer, and the docs pane are three answers to one question: how far do you have to travel to act on something you just saw?

Why we rebuilt on TanStack instead of SvelteKit

Svelte was not the problem. The previous Console shipped a large product on it, and Svelte 5's runes are a genuinely good reactivity model. The honest reasons are elsewhere.

Ecosystem depth. A console is an unusually component-hungry application. It needs sortable and virtualized data tables, a code editor, charts, a terminal emulator, a DNS record editor, a query builder, and a few hundred smaller pieces. React has mature, maintained answers for nearly all of them. We build on ShadCN UI on top of Radix, with TanStack Query for server state and TanStack Router for type-safe routing. Every one of those is a component we did not have to write and do not have to maintain.

Agents write React better than they write Svelte. A large share of the code in this repository was written with coding agents, and the gap in output quality across frameworks is not subtle. Models have seen far more React than Svelte, far more TanStack Query than SvelteKit load functions, and far more ShadCN than any Svelte component library. An agent asked to add a route to this codebase gets the loader, the prefetch, the query key, and the component shape right on the first attempt, because our conventions are the conventions it already knows.

That compounds in a way worth saying out loud. When contributors, ours and yours, work with agents, the framework choice sets how much of their intent survives the trip from prompt to pull request. Picking the stack agents know best is a decision about contribution throughput, not about syntax preferences.

One router that does both jobs. Merging a documentation site with a console means server rendering the auth quick start and running a live, client-heavy user table in the same application, out of one set of components. TanStack Start does this with route loaders that prefetch into the same TanStack Query cache the components read from. A docs page prerenders for search engines, a console page hydrates against fresh data, and neither needs its own codebase.

Every route fetches its data while the router is still resolving, so a page arrives with rows in the table rather than a spinner that becomes rows and shifts the layout under your cursor. Applying that consistently across every route is most of why the new Console feels quicker than the old one.

The trade-off is real. React ships more JavaScript than Svelte's compiler output, and we are not going to pretend otherwise. We spend the difference on prefetching, so the data is in the cache before the component asks for it, which is where the perceived latency of a console actually comes from.

One design system instead of two that drift

The less visible win is that the website and the Console can no longer disagree with each other.

Under two repositories, every shared element existed twice. A button, a badge, a table row, a code block, the dark theme, the type scale. Fixing a focus ring in the Console did nothing for the docs. A brand refresh meant shipping the same change twice and living with the gap in between, which is the state appwrite.io and the Console were in for most of the past two years.

There is now one component library, one set of tokens, and one theme implementation behind all of it. The code block in a documentation page is the code block in a function's deployment logs. The table on the blog index is the table in your storage bucket. When we fix something, it is fixed everywhere, and neither half can quietly fall behind.

Agent-readable by default

Because the docs and the Console are one application, the machine-readable exports come out of the same content pipeline the pages render from. llms.txt and llms-full.txt describe the product for models, and any documentation page is available as raw Markdown by appending .md to its path. Point an agent at appwrite.io/docs.md and it gets the index without parsing a page of navigation chrome.

What self-hosting looks like

The same codebase builds the Cloud Console and the self-hosted one. A console profile decides which features exist, and the self-hosted profile turns off everything tied to Appwrite Cloud: billing, Domains, Firewall, usage statistics, the marketplace, multi-region, and the marketing and documentation routes. Docs links on a self-hosted instance open appwrite.io/docs in a new tab instead.

One build, two products, and no separate self-hosted fork drifting a release behind.

Getting started with Console IV

Console IV goes live on Appwrite Cloud during Init week alongside the rest of Appwrite 2.0. Community Edition ships it for self-hosting when the week wraps up.

The fastest way to feel the difference is to go configure something you do not already know how to configure. Open a project, start setting up an OAuth provider or a Firewall rule, and click the docs link in the description instead of reaching for a new tab. The instructions arrive next to the form.