Multi-tenant apps

One app, many tea shops

The tea shop has grown into Teahub: a service where anyone can open a small tea shop of their own. Asha runs Asha's Tea Room at asha.teahub.example. Ben runs Ben's Tea Bar, and brought his own domain, bensteabar.example. Each shop has its own name, its own teas and its own customers, and each one should feel like a site of its own.

Teahub doesn't build a new app for every shop. It runs one Next.js app, and every shop's address points at it. An app like this is called multi-tenant: one app that serves many customers, its tenants, and keeps them apart. Here a tenant is a shop. The app needs to answer one question for every request: which shop is this for? The answer is in the request itself. Every request a browser sends carries a Host header: the name the visitor typed in the address bar.

Here is Teahub, a real Next.js 16.4.3 project, built with next build and run with next start. The recorder asked for / five times, each time with the Host header a browser at that address would send:

1import { NextResponse, type NextRequest } from "next/server";2import { shopForRequest } from "./lib/shops";3 4export function proxy(request: NextRequest) {5  const shop = shopForRequest(request.headers);6  if (!shop) {7    return new NextResponse("There's no shop at this address.", { status: 404 });8  }9  const url = request.nextUrl.clone();10  url.pathname = `/${shop.slug}${request.nextUrl.pathname}`;11  return NextResponse.rewrite(url);12}13 14export const config = {15  matcher: ["/((?!_next/static|_next/image|favicon.ico).*)"],16};

proxy.ts, the file shown first, runs before every request reaches a route (proxy.ts teaches it). Line 5 hands the request's headers to shopForRequest, from lib/shops.ts, which reads the Host header and looks the name up. Lines 6 to 8 answer 404 when no shop has that name. Line 10 puts the shop's slug, its short name in addresses like asha, in front of the path, and line 11 rewrites the request there. So / on Asha's address is answered by the route /asha: the folder app/[shop], a dynamic segment, with shop set to asha.

Pick each request above the page in the Browser tab. The address bar shows the address the recorder asked for. On asha.teahub.example, the page says Asha's Tea Room and lists Asha's two teas. On ben.teahub.example and on bensteabar.example, it's Ben's shop both times, with his one tea. On zed.teahub.example, there's no page at all: the answer is a 404 with one line of text, There's no shop at this address.

Step through the visit to Ben's domain, and the one to a shop that doesn't exist:

Subdomains and custom domains

Teahub gives shops two kinds of address. A subdomain is a name under Teahub's own domain: asha.teahub.example is the label asha in front of teahub.example. A custom domain is a domain the shop owns, like bensteabar.example. To the app they look the same: a request whose Host header holds a name. What differs is who owns the name, and how it reaches Teahub's server. Each row asks one question of both:

DNS, the internet's address book, is what turns a name into the address of a server. Both kinds of name must point at Teahub's server before a single request arrives. A custom domain needs one more step first: Teahub adds bensteabar.example to its list only after Ben proves he owns it, usually by adding a DNS record Teahub asks for, or through the hosting provider's own check. Teahub keeps checking, and switches the mapping off if the proof goes away, for example when Ben lets the domain lapse and someone else buys it.

After that, the app reads the name and decides. That's the job of lib/shops.ts, and proxy.ts and every Server Action call the same two functions in it. Open it in the example above:

• Lines 2 to 6 are the list of shops. A real platform keeps it in its database, and a shop that signs up today is in it tomorrow.
• Line 9 is the list of custom domains: a Map from each domain to the shop that owns it.
• Line 13 decides which header to trust, from the deployment's settings. Line 21 reads the Host header, or X-Forwarded-Host only when TRUST_FORWARDED_HOST is 1.
• Line 22 cleans the name: toLowerCase() makes ASHA.teahub.example the same as asha.teahub.example, because domain names don't care about case, and it drops a port, like :3000, and a trailing dot (asha.teahub.example. is the same name, written fully).
• Lines 27 and 28 look for the whole name among the custom domains first. Lines 29 to 31 handle a subdomain: they cut .teahub.example off the end and look for a shop with that slug.
• Anything else ends at line 32: undefined, no shop. That includes teahub.example itself, and zed.teahub.example.

Never use the name without that lookup. A browser sends the name the visitor typed, but any other program can send any Host header it likes. The list is what decides. A name that isn't in it gets the 404, so nobody reaches a shop that doesn't exist, or a part of the app that isn't a shop.

Which header holds the visitor's address?

On the recorded server, the Host header does: the requests reach next start directly. Many deployments put a load balancer or another reverse proxy in front: a server that receives every request first and passes it on. Some of them pass it on with their own name in Host, and the visitor's in X-Forwarded-Host. But a visitor can send X-Forwarded-Host too. Here is the same app, with two lines added to proxy.ts that write down what arrived. The example also kept what next start printed. Open the Terminal tab:

1import { NextResponse, type NextRequest } from "next/server";2import { publicHost, shopForRequest } from "./lib/shops";3 4export function proxy(request: NextRequest) {5  const sent = `host: ${request.headers.get("host")} | x-forwarded-host: ${request.headers.get("x-forwarded-host")}`;6  console.log(sent, "| publicHost:", publicHost(request.headers), "| nextUrl.host:", request.nextUrl.host);7  const shop = shopForRequest(request.headers);8  if (!shop) {9    return new NextResponse("There's no shop at this address.", { status: 404 });10  }11  const url = request.nextUrl.clone();12  url.pathname = `/${shop.slug}${request.nextUrl.pathname}`;13  return NextResponse.rewrite(url);14}15 16export const config = {17  matcher: ["/((?!_next/static|_next/image|favicon.ico).*)"],18};

$ next build▲ Next.js 16.4.3 (Turbopack)- Cache Components enabled- Partial Prefetching enabled   Creating an optimized production build ...✓ Compiled successfully  Running TypeScript ...  Finished TypeScript ...  Collecting page data ...✓ Generating static pages (6/6)  Finalizing page optimization ... Route (app)┌ ○ /_not-found└   /[shop]  ├ ◐ /[shop]  ├ ○ /asha  ├ ○ /ben  └ ○ /chai ƒ Proxy (Middleware) ○  (Static)             prerendered as static content◐  (Partial Prerender)  prerendered as static HTML with dynamic server-streamed content $ next start▲ Next.js 16.4.3- Local:         http://localhost:3000- Network:       http://localhost:3000✓ Readyhost: asha.teahub.example | x-forwarded-host: asha.teahub.example | publicHost: asha.teahub.example | nextUrl.host: localhost:3000host: ben.teahub.example | x-forwarded-host: ben.teahub.example | publicHost: ben.teahub.example | nextUrl.host: localhost:3000host: bensteabar.example | x-forwarded-host: bensteabar.example | publicHost: bensteabar.example | nextUrl.host: localhost:3000host: asha.teahub.example. | x-forwarded-host: asha.teahub.example. | publicHost: asha.teahub.example | nextUrl.host: localhost:3000host: asha.teahub.example | x-forwarded-host: ben.teahub.example | publicHost: asha.teahub.example | nextUrl.host: localhost:3000

Lines 5 and 6 log both headers, the name publicHost picked, and request.nextUrl.host. Under $ next start, five lines:

• For the first three, nobody sent X-Forwarded-Host, and it holds the Host header's name anyway: next start filled it in.
• The fourth asked for asha.teahub.example., with a trailing dot, and publicHost gave asha.teahub.example: Asha's shop.
• The fifth went to Asha's address but claimed x-forwarded-host: ben.teahub.example. That made-up value arrived as it was sent. publicHost ignored it, because nothing on this server sets that header, and the page is Asha's.

That's the trust decision in plain words: believe a header only if something you control wrote it. Set TRUST_FORWARDED_HOST=1 only where your own load balancer sets X-Forwarded-Host and replaces whatever the visitor sent; then it holds the name they typed. Anywhere else, trusting it would let a request that reached Asha's address act for Ben's shop: a review posted there would land in Ben's. Your hosting provider's docs say which header carries the public host on their servers.

And nextUrl.host was localhost:3000 all five times. That's what this recording saw with next start, not a rule: other hosts and adapters build the request's URL their own way. Don't count on it for the visitor's address; read the header your deployment trusts.

Rewriting each request to its shop's route

A rewrite answers a request with another route, while the address bar keeps what the visitor typed. That's what lets one folder of pages serve every shop. Teahub's pages all live under app/[shop]:

• app/[shop]/layout.tsx is the root layout, the one that writes <html> and <body> (Layouts and pages). There's no app/layout.tsx above it, because every page belongs to a shop.
• Line 13 of the layout finds the shop from params, and line 14 calls notFound() for a slug that isn't a shop. proxy.ts already stops unknown names, so this is a second check, in case a request ever reaches the route another way.
• Line 18 writes the shop's name into every page, and generateMetadata, on lines 8 to 10, makes it the page's title: the Browser tab shows Asha's Tea Room next to the address.
• app/[shop]/page.tsx is each shop's home page. Its line 4 asks teasFor for the teas of the shop in params.

Every path gets the shop in front

Line 10 of proxy.ts puts the slug in front of every path, not only /. That's what keeps a visitor from reaching another shop through the path. Pick the last request in the example above: on bensteabar.example, the recorder asked for /asha. proxy.ts rewrote it to /ben/asha, no route matches that, and the answer is 404, This page could not be found. Asha's shop never shows on Ben's domain.

It also means links inside a shop are written without the slug. A link to /about on Ben's page stays on bensteabar.example/about, and proxy.ts turns it into /ben/about on the server. The matcher on lines 14 to 16 lets every path through except Next.js's own files, under /_next/static and /_next/image, and the icon: those must never get a shop in front.

What the build made

Open the Terminal tab of the overview's example. The route table has a group for the folder:

Route (app)
┌ ○ /_not-found
└   /[shop]
  ├ ◐ /[shop]
  ├ ○ /asha
  ├ ○ /ben
  └ ○ /chai

generateStaticParams, on lines 4 to 6 of the layout, lists every shop, so the build made /asha, /ben and /chai ahead of time: ○, prerendered as static content. The Network tab shows what that means: each shop's page came with x-nextjs-cache: HIT, the HTML the build made. The line ◐ /[shop] is a shell the build made for shops it didn't list, like one that signed up after the build. That shop's own page is made the first time someone visits it (generateStaticParams shows how).

Root params: the shop anywhere on the server

Pages and layouts get the shop in params. Components deeper down don't: you'd pass it as a prop, through every component in between. Since Next.js 16.3, there's another way. A dynamic segment that sits above the root layout, like [shop], is a root param, and the module next/root-params gives each one as a function. Any Server Component under that root layout can call it. Here is a footer that reads the shop itself:

1import { shop } from "next/root-params";2import { findShop } from "@/lib/shops";3 4export default async function ShopFooter() {5  const current = findShop(await shop());6  return <footer>{current?.name} is a tea shop on Teahub.</footer>;7}

Line 1 of app/[shop]/shop-footer.tsx imports shop from next/root-params. The name comes from the folder: [shop] gives a function called shop. Line 5 waits for it and finds the shop. In the layout, line 21 places <ShopFooter /> with no props at all. The Browser tab shows each shop's own footer: Asha's Tea Room is a tea shop on Teahub. on Asha's address, Ben's on both of Ben's.

Root params came out in Next.js 16.3, in August 2026. In Next.js 16.4.3 they need no setting in next.config.ts: an old experimental one, experimental.rootParams, now only earns a warning that it's no longer needed. Next.js's docs give a few rules:

• Only Server Components. A Client Component can't import it: the build fails. Server Actions can't call it, and Route Handlers can't yet; the docs say support for them is planned.
• Only segments above the root layout. [shop] is one. [id] in app/[shop]/teas/[id] isn't: a page under [shop] may have no id at all, so it stays in params.
• Names must be JavaScript names. [shop] works; [shop-id] doesn't, because shop-id can't be a function's name.

With Cache Components on, there's one more: every root param needs generateStaticParams, with at least one value. Here is the same app with lines 4 to 6 of the layout taken out:

1import { notFound } from "next/navigation";2import { findShop } from "@/lib/shops";3import ShopFooter from "./shop-footer";4 5export async function generateMetadata({ params }: LayoutProps<"/[shop]">) {6  return { title: findShop((await params).shop)?.name };7}8 9export default async function ShopLayout({ children, params }: LayoutProps<"/[shop]">) {10  const shop = findShop((await params).shop);11  if (!shop) notFound();12  return (13    <html lang="en">14      <body>15        <header>{shop.name}</header>16        {children}17        <ShopFooter />18      </body>19    </html>20  );21}

$ next build▲ Next.js 16.4.3 (Turbopack)- Cache Components enabled- Partial Prefetching enabled   Creating an optimized production build ...✓ Compiled successfully  Running TypeScript ...  Finished TypeScript ...  Collecting page data ...Error: A required root parameter (shop) was not provided in generateStaticParams for /[shop], please provide at least one value.    at ignore-listed frames > Build error occurredError: Failed to collect page data for /[shop]    at ignore-listed frames {  type: 'Error'}

The build stopped while it collected the pages' data: A required root parameter (shop) was not provided in generateStaticParams for /[shop], please provide at least one value. Put the list back, even if it only names one shop.

Keeping each shop's data apart

Teahub keeps every shop's teas in one table, with a shop column. That's common: one database for all tenants. It also means one forgotten filter shows one shop's data on another shop's site. Every query must say whose data it wants, and that "whose" must come from the server's lookup. Here is a page for one tea, /teas/[id], in two versions. Each was asked for tea 3, which is Ben's, on Asha's address:

1import { teaById, teasFor } from "@/lib/db";2 3export async function generateStaticParams({ params }: { params: { shop: string } }) {4  return (await teasFor(params.shop)).map((tea) => ({ id: tea.id }));5}6 7export default async function TeaPage({ params }: PageProps<"/[shop]/teas/[id]">) {8  const { id } = await params;9  const tea = await teaById(id);10  if (!tea) return <p>This shop doesn't sell that tea.</p>;11  return (12    <main>13      <h1>{tea.name}</h1>14      <p>${tea.price} a box</p>15    </main>16  );17}

The first version calls teaById(id) on line 9: tea 3 from the whole table, whoever owns it. The Browser tab shows Ben's Smoky lapsang, at $5 a box, under Asha's Tea Room. Nothing broke, and no error was printed. The page just showed one shop's data on another shop's site. If the tea were one Ben hadn't launched yet, his secret would be out.

The second version takes shop from params on line 8 too, and line 9 calls teaInShop(shop, id): tea 3, but only inside Asha's shop. There's none, so the page says This shop doesn't sell that tea. On Ben's address, tea 3 is still his. Each row is one value the page uses, and who chose it:

The id is fine to take from the visitor. It's only ever looked for inside the shop the server picked, so the worst a made-up id can do is find nothing.

Server Actions look the shop up themselves

A Server Action writes data, so it matters even more where its shop comes from. And it can't use root params. So Teahub's review form does the same lookup proxy.ts does:

1"use server";2 3import { headers } from "next/headers";4import { redirect } from "next/navigation";5import { updateTag } from "next/cache";6import { saveReview } from "@/lib/reviews";7import { shopForRequest } from "@/lib/shops";8 9export async function leaveReview(formData: FormData) {10  const shop = shopForRequest(await headers());11  if (!shop) throw new Error("There's no shop at this address.");12  const text = String(formData.get("text") ?? "").trim().slice(0, 200);13  if (text) {14    await saveReview(shop.slug, text);15    updateTag(`reviews-${shop.slug}`);16  }17  redirect("/reviews");18}19 

Line 10 gets the request's headers with headers() (Request-time APIs) and hands them to the same shopForRequest that proxy.ts uses, so one function decides which host to trust, everywhere. Line 11 stops when there's no shop. Line 12 takes the review's text from the form, which is fine: that's what the visitor is meant to choose. Line 14 saves it under the shop from line 10, and line 15 expires that shop's cached reviews, which the caching section explains. There's no shop field in the form at all. A hidden field would be easy to add, and just as easy for anyone to change before sending.

Here it is recorded. The recorder opened /reviews on Asha's address, posted the form there the way a browser does before the page's JavaScript loads, then opened /reviews on Asha's and on Ben's:

1"use server";2 3import { headers } from "next/headers";4import { redirect } from "next/navigation";5import { updateTag } from "next/cache";6import { saveReview } from "@/lib/reviews";7import { shopForRequest } from "@/lib/shops";8 9export async function leaveReview(formData: FormData) {10  const shop = shopForRequest(await headers());11  if (!shop) throw new Error("There's no shop at this address.");12  const text = String(formData.get("text") ?? "").trim().slice(0, 200);13  if (text) {14    await saveReview(shop.slug, text);15    updateTag(`reviews-${shop.slug}`);16  }17  redirect("/reviews");18}

The post was answered 303 with location: /reviews, the redirect on line 17. Afterwards, Asha's page shows The rose oolong is lovely., and Ben's still says No reviews yet. The reviews are a stand-in for a database, kept in the server's memory for the recording. Anyone may post a review here, so the action checks nothing else. An action that changes a shop's own data, like its prices, must also check who is signed in and whether they run that shop; Authorization and the data access layer builds that.

Caching each shop's results

A cached function stores its result under a key, and gives the same key the same stored result, to every request that asks (The 'use cache' directive). In a multi-tenant app, the shop must be part of that key. If it isn't, the first shop to ask fills the entry, and every other shop gets that shop's result. Each row is one thing that could go into a key:

The module-level variable is the row to watch. It looks like a handy way to skip props: the layout writes the current shop into a variable at the top of lib/current-shop.ts, and any function reads it. Here is today's special, in three versions. In all three the layout sets that variable, and generateStaticParams lists only Asha's shop, so the others are made the first time someone visits. The recorder visited Ben's shop first, then Chai Corner's, then Asha's:

1import { currentShop } from "./current-shop";2 3const specials: Record<string, string> = {4  asha: "Rose oolong",5  ben: "Smoky lapsang",6  chai: "Masala chai",7};8 9export async function getSpecial() {10  "use cache";11  const shop = currentShop();12  console.log("getSpecial ran for", shop);13  return specials[shop];14}

The first version reads the shop from the module variable on line 11. Its key is only getSpecial, with no arguments. Under $ next start, the Terminal has one line: getSpecial ran for ben. Chai Corner's visit found that entry, so its page says Smoky lapsang, Ben's special, under Chai Corner. Asha's page is right only because the build made it, and the build's own call printed getSpecial ran for asha above the route table.

The second version takes shop as an argument, and the third reads the root param inside the cached function. Both print two lines under $ next start, one for ben and one for chai, and every page shows its own special. For the third, Next.js notices which root params the function reads and adds only those to its key. A module variable has a second problem, with or without a cache: the server renders many requests at the same time, and they all share that one variable.

One tag for each shop

Tags follow the same rule. In lib/reviews.ts, from the review example, the cached reviewsFor calls cacheTag(`reviews-${shop}`) on line 9, and the action calls updateTag with the same name (Cache lifetimes and tags). One shared reviews tag would expire every shop's reviews whenever any shop got one. In the recording, Asha's page after the review came with x-nextjs-cache: MISS: made again, with the new review. Ben's came with HIT: still the stored page, untouched.

Any cache in front of the server, like a CDN, needs the same care: it must keep pages apart by host as well as by path, or / on one shop could be stored and sent for / on another.

Where may the shop come from?

Each leak in Teahub came from one question answered wrongly: where did this code get the shop? Sort each source. Can it pick whose data a request reads or changes?

In short: the Host header, found in your own list, picks the shop, once, on the server. Pages read it from params or a root param, Server Actions look it up again, and everything the visitor sends is searched for only inside that shop.

Common mix-ups

• "Each subdomain is a separate app." No. Every shop's name points at one app, built once. proxy.ts tells them apart by the Host header.
• "request.nextUrl.host is the address the visitor typed." Don't count on it. In this recording, with next start, it was localhost:3000 for every shop, and other hosts build it their own way. Read the host from the header your deployment trusts.
• "The Host header can be used as the shop's name." No. Any program can send any Host header. Look it up in your list, and answer 404 when it isn't there.
• "A visitor can open another shop by typing its slug in the path." Not when proxy.ts puts the shop in front of every path: /asha on Ben's domain became /ben/asha, a 404.
• "Root params work everywhere on the server." No. Server Components only: a Server Action threw, and Route Handlers aren't supported yet.
• "A cached function knows which shop it's for." Only through its key: arguments, closures and the root params it reads. A module variable isn't part of it.
• "Filtering on the page is enough." Every query needs the shop: in pages, Server Actions, Route Handlers and cached functions.

Practice exercises

These exercises are about Next.js projects, which can't run inside this page. Answer first, then use the hints.

Host: ASHA.teahub.example
Host: chai.teahub.example:443
Host: shop.bensteabar.example
Host: teahub.example

import { teaById, teasFor } from "@/lib/db";

export async function generateStaticParams({ params }: { params: { shop: string } }) {
  return (await teasFor(params.shop)).map((tea) => ({ id: tea.id }));
}

export default async function TeaPage({ params }: PageProps<"/[shop]/teas/[id]">) {
  const { id } = await params;
  const tea = await teaById(id);
  if (!tea) return <p>This shop doesn't sell that tea.</p>;
  return (
    <main>
      <h1>{tea.name}</h1>
      <p>${tea.price} a box</p>
    </main>
  );
}

import { teaInShop, teasFor } from "@/lib/db";

export async function generateStaticParams({ params }: { params: { shop: string } }) {
  return (await teasFor(params.shop)).map((tea) => ({ id: tea.id }));
}

export default async function TeaPage({ params }: PageProps<"/[shop]/teas/[id]">) {
  const { shop, id } = await params;
  const tea = await teaInShop(shop, id);
  if (!tea) return <p>This shop doesn't sell that tea.</p>;
  return (
    <main>
      <h1>{tea.name}</h1>
      <p>${tea.price} a box</p>
    </main>
  );
}

import { notFound } from "next/navigation";
import { findShop } from "@/lib/shops";
import ShopFooter from "./shop-footer";

export async function generateMetadata({ params }: LayoutProps<"/[shop]">) {
  return { title: findShop((await params).shop)?.name };
}

export default async function ShopLayout({ children, params }: LayoutProps<"/[shop]">) {
  const shop = findShop((await params).shop);
  if (!shop) notFound();
  return (
    <html lang="en">
      <body>
        <header>{shop.name}</header>
        {children}
        <ShopFooter />
      </body>
    </html>
  );
}

import { notFound } from "next/navigation";
import { findShop, shops } from "@/lib/shops";
import ShopFooter from "./shop-footer";

export function generateStaticParams() {
  return shops.map((shop) => ({ shop: shop.slug }));
}

export async function generateMetadata({ params }: LayoutProps<"/[shop]">) {
  return { title: findShop((await params).shop)?.name };
}

export default async function ShopLayout({ children, params }: LayoutProps<"/[shop]">) {
  const shop = findShop((await params).shop);
  if (!shop) notFound();
  return (
    <html lang="en">
      <body>
        <header>{shop.name}</header>
        {children}
        <ShopFooter />
      </body>
    </html>
  );
}

"use server";

import { redirect } from "next/navigation";
import { updateTag } from "next/cache";
import { shop } from "next/root-params";
import { saveReview } from "@/lib/reviews";

export async function leaveReview(formData: FormData) {
  const slug = await shop();
  const text = String(formData.get("text") ?? "").trim().slice(0, 200);
  if (text) {
    await saveReview(slug, text);
    updateTag(`reviews-${slug}`);
  }
  redirect("/reviews");
}

"use server";

import { headers } from "next/headers";
import { redirect } from "next/navigation";
import { updateTag } from "next/cache";
import { saveReview } from "@/lib/reviews";
import { shopForRequest } from "@/lib/shops";

export async function leaveReview(formData: FormData) {
  const shop = shopForRequest(await headers());
  if (!shop) throw new Error("There's no shop at this address.");
  const text = String(formData.get("text") ?? "").trim().slice(0, 200);
  if (text) {
    await saveReview(shop.slug, text);
    updateTag(`reviews-${shop.slug}`);
  }
  redirect("/reviews");
}

import { currentShop } from "./current-shop";

const specials: Record<string, string> = {
  asha: "Rose oolong",
  ben: "Smoky lapsang",
  chai: "Masala chai",
};

export async function getSpecial() {
  "use cache";
  const shop = currentShop();
  console.log("getSpecial ran for", shop);
  return specials[shop];
}

Check your understanding

For each question, ask where the shop came from, and who could have chosen it.

Key takeaways

• A multi-tenant app is one app for many tenants. Each tenant's subdomain or custom domain points at it, and every request names its address in the Host header.
• proxy.ts reads the Host header, looks it up in a list you control, answers 404 for anything else, and rewrites every path to app/[shop]/…. One function decides which header to trust, and proxy.ts and every Server Action use it.
• Pages and layouts get the shop in params. Since Next.js 16.3, any Server Component can call it from next/root-params; Server Actions look it up from the Host header again.
• Every query takes the shop from that server-side lookup. Ids and other values from the visitor are searched for only inside it.
• A cached function's key is its arguments, closures and the root params it reads. Put the shop in it, and in its tags; a module variable isn't part of it.

Coming next: Authentication. The tea shop gets accounts: passwords stored safely, a session in a signed cookie, and signing out.