From repository to live site.

From the repository to a running site and a production build.

Requirements

Requirement	Version
Node.js	24.x
npm	11 or newer (ships with Node 24)
Git	Any recent version
Operating system	macOS, Linux, or Windows
Accounts or API keys	None, and no secrets. A production build needs the site's URL (step 4).

Check your versions:

node -v   # v24.x.x
npm -v    # 11.x.x

1. Get the source

Clone the Nauras repository you were given access to, then start your own project from it. Your license does not allow the source in a public repository, and you cannot add anyone to the Nauras repository, so your project lives in a private repository of your own:

git clone https://github.com/vlavera/nauras.git my-restaurant
cd my-restaurant
git remote rename origin nauras        # keep it, to pull future releases
git remote add origin <your own private repository>
git push -u origin main

2. Install dependencies

npm ci

npm ci installs the exact versions in package-lock.json. It reports two moderate vulnerabilities in test tooling. That is expected; read docs/TROUBLESHOOTING.md before doing anything about it.

3. Run the site locally

npm run dev

Open http://localhost:4321 (or the port it prints). You'll see the demo: a fictional restaurant, kept out of search, with every contact button inert and a table request that can be filled in and goes nowhere.

To run your own configuration once you've created it (docs/CUSTOMIZE.md):

NAURAS_FIXTURE=client npm run dev                    # macOS / Linux
$env:NAURAS_FIXTURE="client"; npm run dev            # Windows PowerShell

Stop the development server with Ctrl+C in the terminal where it runs.

4. Check and build

npm run typecheck          # TypeScript and the configuration's shape
npm test                   # the configuration is coherent and its media files exist
SITE_URL=https://your-domain.com npm run build   # production build, into dist/
npm run preview            # serve the production build at http://localhost:4321 (Ctrl+C to stop)

npm run build and npm run dev check whichever configuration NAURAS_FIXTURE makes active, and stop, naming the path, if it references a photo that is not in public/restaurant/. npm run build also stops if that configuration is switched on and still carries one of the demo's invented claims (docs/CUSTOMIZE.md, "What the build refuses").

The site URL

npm run build needs to know where the site will live, because the page carries a canonical link that points there. It looks in this order:

1. SITE_URL in the environment, as in the command above (PowerShell: $env:SITE_URL="https://your-domain.com"; npm run build).
2. seo.siteUrl in your configuration (docs/CUSTOMIZE.md).
3. The project's production domain, when Vercel builds the site from a connected Git repository. A build run anywhere else does not have it.

If none of these gives a real https:// URL, the build stops and says so. There is no placeholder that quietly works. npm run dev does not need it.

Next steps

• Make it your own restaurant: docs/CUSTOMIZE.md.
• Replace the example photos and understand their license: docs/ASSETS.md.
• Deploy: docs/DEPLOY.md.

Everything that makes a Nauras site one restaurant is in one file: the configuration, src/restaurant/fixtures/*.ts. Every word, price and photo is there, with the facts they belong to. Its shape is RestaurantContract in src/restaurant/contract.ts, where every field is described.

Nauras builds to a static site (npm run build produces dist/): no server process, no adapter, no secrets. The build needs the site's URL. When Vercel builds the site from a connected Git repository it is picked up automatically; anywhere else, set SITE_URL (docs/INSTALL.md, "The site URL").

All notable changes to Nauras are recorded here. Versions follow Semantic Versioning.

1.0.0

First release.

• A tasting-menu restaurant's site in one page: a hero, the table, the chef, the menu and its dial, the room, a long table, reviews, a visit panel with a table request, and a footer.
• A heat dial of two to five settings. Each course has one or more forms, each served from a given heat upward, and the page shows the form for the chosen heat. A course can be held back below a heat, with something else in its place, and the card says so.
• A detail view for each course.
• It says whether the restaurant is open: open, last orders or closed, from your opening hours and your time zone, worked out when the page is built and again in the visitor's browser every minute.
• A table request: a visitor chooses where to sit, how many and which night; the page builds one line from that and the heat, and every request button opens the one contact you configure with that line in the message, where the link can carry one.
• A build check for the demo's invented claims: the build refuses a switched-on site that still carries one of the claims it lists. docs/CUSTOMIZE.md has the list.
• Buyer guides in docs/, AGENTS.md for coding agents, and the license.

Known limitations

• One restaurant, one page, one language (English). Two labels read by a screen reader are typed in the page's component, not in the configuration (docs/CUSTOMIZE.md, "One language").
• No CMS: content is a TypeScript file in src/restaurant/fixtures/. The menu is what that file says; changing it is an edit and a deploy.
• No booking system. The table request does not know whether a table is free, holds nothing and sends nothing: its buttons are links to wherever you take requests. The request is carried by an email or WhatsApp link only.
• The dial, a course's detail view and the table request need the page's script. Without it the page shows the menu at its default heat.
• Open and closed need opening hours that are the same every week. A one-off closure is an edit and a deploy.
• No map: the drawing beside the address shows no real place. A directions button is shown on phones once you give a map pin.
• Sentences that name a number of courses, an hour or a day are text, and nothing keeps them in step with the courses or the opening hours.
• The demo's dish names, and the words it uses for the nine moods of its menu, have not been checked against a source. They are content you replace.
• Colours, the heat ramp and typefaces are CSS, not configuration.
• The example photographs are AI-generated and must be replaced before a commercial site goes live (LICENSE.md section 8). Two of them show the demo's name painted in the room.
• Deployment is verified on Vercel through its Git integration only.