Announcing Console IV: the website and Console as one app_

Building on Appwrite has always meant bouncing between the IDE, the docs, the SDKs, the CLI, a terminal, and the agent. Write a few lines in the editor. Flip to the docs for a method signature. Open the Console to create a bucket. Copy an ID into .env. Drop into a shell for the CLI. Ask the agent to fill a gap. Come back and rebuild the mental model you just abandoned. Each hop is cheap. The stack of them is constant tax. We have wanted to cut that context switching for years.

Today we are announcing Console IV, the fourth generation of the Appwrite Console, and our dig at that problem. It puts the docs next to the form you are filling out, runs the CLI in the browser with your session already configured, and keeps Explorer, Terminal, and the Command Center in the same app as your project. Fewer of the hops that used to leave the page have to leave the page.

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. Collapsing appwrite/website and appwrite/console into one codebase was how we got there. Two Svelte apps, two build pipelines, and two design systems drifting apart was a real cost, and we are glad to stop paying it. That is a side effect. We did not rebuild the Console to save ourselves a repository.

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 the most visible part of that bet.

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.

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.