Orchid Documentation

Introduction

Everything you need to know before you open your editor — what’s in the box, what it’s built with, and what it expects from your machine.

Welcome

Thanks for picking up Orchid. This guide walks through installing the template, understanding how the project is organized, customizing content and styling, and shipping it to production. It’s written for developers who are comfortable with the command line but new to this specific codebase — if you already know Astro well, feel free to skip ahead using the sidebar.

Orchid is a fitness and wellness marketing template built with Astro. It includes a one-page home page (hero, feature overview, category accordion, testimonials, pricing, trusted-by logos, FAQ, and app download links) plus standalone login and signup pages. It’s styled with hand-written CSS and needs no UI framework or CSS framework.

What’s Included

Features

• A one-page home page with 10 sections and smooth-scrolling nav links to each one
• Standalone login and signup pages with styled, validated forms
• GSAP + ScrollTrigger scroll-reveal animations and two infinite marquee loops (testimonials and trusted-by logos)
• Sticky header with a slide-over mobile menu, accordions, and a YouTube video lightbox, all in small inline scripts with no UI framework
• SEO-ready layout with per-page title and description, canonical URL, Open Graph and Twitter/X card tags, plus an automatic sitemap
• Fully responsive, with breakpoints at 991px, 767px, and 479px

Technology Stack

Orchid is plain Astro with vanilla JavaScript and hand-written CSS. It doesn’t use React, TypeScript, Tailwind, or Sass.

Requirements

Browser Support

The built site targets the last two versions of all evergreen browsers:

Getting Started

From a downloaded ZIP to a running dev server in five steps.

Installation & Extraction

1. Download the template ZIP from your purchase confirmation email or account downloads page.
2. Extract it to a folder on your machine — avoid folder names with spaces or special characters.
3. Open that folder in your terminal and in your code editor.

# Extract on macOS / Linux
unzip orchid-astro-package.zip -d orchid-astro-package
cd orchid-astro-package/orchid-astro

Node.js Setup

Check which version of Node.js is currently active:

node --version
# v22.12.0 or later

If you manage multiple Node versions, tools like nvm or fnm make switching painless:

nvm install 22
nvm use 22

Install Dependencies

From the project root, install packages with your preferred package manager:

npm install

pnpm install

yarn install

This reads package.json and downloads every dependency into a local node_modules/ folder. It only needs to be re-run when dependencies change.

Run the Development Server

npm run dev

pnpm dev

This starts Vite’s local dev server with hot module reloading — edits to components, pages, and styles appear in the browser immediately without a manual refresh. By default it’s available at http://localhost:4321; the terminal output will confirm the exact address.

Build for Production & Preview

# Compile an optimized production build into dist/
npm run build

# Serve that build locally to sanity-check it
npm run preview

build renders every page to static HTML, bundles and minifies the CSS and JavaScript, generates the sitemap, and writes the output to dist/. preview serves that exact output locally so you can verify it before deploying — it does not rebuild automatically, so re-run build after further changes.

Project Structure

A tour of the folders you’ll actually touch, and the ones you generally shouldn’t.

Configuration

The files that control how the project builds, and where to set site-wide values.

package.json

Defines dependencies and the scripts you run from the terminal (dev, build, preview). Add your own script here if you introduce a new tool.

{
  "name": "orchid-astro",
  "type": "module",
  "version": "0.0.1",
  "engines": { "node": ">=22.12.0" },
  "scripts": {
    "dev": "astro dev",
    "build": "astro build",
    "preview": "astro preview",
    "astro": "astro"
  },
  "dependencies": {
    "@astrojs/sitemap": "^3.7.4",
    "astro": "^7.3.3",
    "gsap": "^3.15.0",
    "lottie-web": "^5.13.0"
  }
}

gsap powers the scroll animations and marquees. lottie-web is listed as a dependency but isn’t imported anywhere in the current source, so you can remove it with npm uninstall lottie-web if you don’t plan to add a Lottie animation.

astro.config.mjs

Controls integrations, the deployed site URL, and build behavior. Orchid registers a single integration, @astrojs/sitemap, and builds as a fully static site (Astro’s default output).

// @ts-check
import { defineConfig } from 'astro/config';

import sitemap from '@astrojs/sitemap';

// https://astro.build/config
export default defineConfig({
  site: 'https://example.com',
  integrations: [sitemap()]
});

tsconfig.json

Orchid is written in plain JavaScript and has no .ts files. tsconfig.json only extends Astro’s base preset so the Astro editor extension can offer autocomplete. It defines no path aliases, so all imports use relative paths like ../components/Nav.astro.

{
  "extends": "astro/tsconfigs/base",
  "include": [".astro/types.d.ts", "**/*"],
  "exclude": ["dist"]
}

Environment Variables (.env)

Orchid doesn’t read any environment variables and ships no .env file. If you add an integration that needs one, create a .env file in the project root for values that differ between environments (API URLs, keys) or shouldn’t be committed to Git. Variables must be prefixed PUBLIC_ to be readable in client-side code.

# Exposed to the browser — never put secrets here
PUBLIC_SITE_URL=https://example.com

# Server-only — safe for secrets, not readable in browser code
API_SECRET_KEY=your_secret_key

Pages

How routes are created, and how Orchid’s three pages are put together.

Creating a New Page

Astro uses file-based routing: any .astro or .md file placed in src/pages/ automatically becomes a route matching its file path. Orchid ships three routes:

src/pages/index.astro   →  /        (home page with every marketing section)
src/pages/login.astro   →  /login   (login form)
src/pages/signup.astro  →  /signup  (signup form)

To add a page, create a new file in src/pages/ using the layout and structure of an existing, similar page as a starting point. Pages render their own Nav and Footer, so include them explicitly:

---
import Layout from '../layouts/Layout.astro';
import Nav from '../components/Nav.astro';
import Footer from '../components/Footer.astro';
---
<Layout title="About — Orchid" description="About our fitness platform.">
  <Nav />
  <h1>About Orchid</h1>
  <Footer />
</Layout>

Editing an Existing Page

Open the relevant file under src/pages/. index.astro is just a list of section components (Hero, Overview, Pricing, and so on), so to change the home page’s content, edit the matching file in src/components/. To reorder or remove a section, move or delete its tag in index.astro. The login and signup pages keep their form markup inline in the page file.

Dynamic Routes

Orchid has no dynamic routes. If you add one, note that files wrapped in square brackets, such as [slug].astro, generate multiple pages from a single template — commonly used for blog posts or product pages. Astro requires a getStaticPaths() function for these on statically-generated sites:

---
export async function getStaticPaths() {
  const posts = await import.meta.glob('./posts/*.md');
  return Object.keys(posts).map((path) => ({
    params: { slug: path.split('/').pop().replace('.md', '') },
  }));
}
---

Layouts

Orchid has one layout, src/layouts/Layout.astro. It renders the <html> shell and every <head> tag (title, description, canonical, Open Graph and Twitter/X meta, Google Fonts, favicons), imports global.css, and injects the page into <body> via a <slot />. It doesn’t add a header or footer, so each page includes Nav and Footer itself. It accepts five optional props:

---
import '../styles/global.css';

const {
  title = 'Orchid — Fitness & Wellness Astro Template',
  description = "The Hassle-free world of fitness. …",
  ogImage = '/images/Hero-Image-with-shadow_1.webp',
  bodyClass = '',      // extra class on <body> (login uses "with-body-color")
  noindex = false,     // true adds <meta name="robots" content="noindex">
} = Astro.props;
---
<html lang="en">
  <head><title>{title}</title> <!-- …plus SEO meta, fonts, favicons --></head>
  <body class={bodyClass}>
    <slot /> <!-- page content is injected here -->
  </body>
</html>

Page Metadata & the 404 Page

Pass a title and description into Layout on every page for correct browser tabs and search results (see also SEO). Orchid doesn’t ship a custom 404 page. Add a file named 404.astro in src/pages/ and it will be served automatically whenever no route matches.

Components

The building blocks pages are assembled from, and how data flows into them.

Reusable Components

Components live in src/components/ and encapsulate one piece of UI so it can be reused across pages without copy-pasting markup. All of Orchid’s components are .astro files. Most are self-contained page sections with no props:

Props

Props are the inputs a component accepts, similar to HTML attributes. Orchid is plain JavaScript, so props are read by destructuring Astro.props with default values rather than through TypeScript interfaces. Nav is the main example:

---
const { current = '' } = Astro.props;

const isHome = current === 'home';
const anchor = (hash) => (isHome ? `#${hash}` : `/#${hash}`);
---

In plain language: current is optional and tells the nav which page it’s on. With "home", the section links point at in-page anchors (#Overview), and anywhere else they point back to the home page (/#Overview). With "login" or "signup", the matching button gets aria-current="page". UtilityHero accepts title and description, and Layout’s props are listed under Layouts.

Component Composition

Larger pages are composed from smaller components rather than written as one long block of markup. This is the whole body of the home page:

<Layout title="Orchid — Fitness & Wellness Astro Template" description="…">
  <AnnouncementBar />
  <Nav current="home" />
  <Hero />
  <Overview />
  <CtaBand />
  <Category />
  <Reviews />
  <Pricing />
  <TrustedBy />
  <Faq />
  <AppLinks />
  <Footer />
</Layout>

Passing Data to Components

In Astro, props are passed the same way as HTML attributes and read via Astro.props:

---
import UtilityHero from '../components/UtilityHero.astro';
---
<UtilityHero title="About Orchid" description="The all-in-one fitness platform." />

Styling

Where to change colors, type, and spacing without fighting the build.

Global Styles & CSS Variables

Orchid uses plain CSS with no preprocessor or utility framework. Layout.astro imports src/styles/global.css, which pulls in the other stylesheets in order:

Brand colors and font families are CSS custom properties at the top of src/styles/orchid.css. Change a value here and it updates across the whole site:

:root {
  --font--body: var(--font-family--general-sans);
  --font-color--body: var(--color--slate-blue);
  --font--heading: var(--font-family--figtree);
  --font-color--heading: var(--color--midnight-blue);
  --font-color--text-highlight: var(--color--green);
  --color--white: white;
  --color--green: #00b172;
  --color--light-pink: #faeaf0;
  --color--yellow: #f2c94c;
  --color--light-green: #e6f7f1;
  --radius--radius-1: 20px;
  --radius--radius-2: 10px;
  --color--pink: #8e2690;
  --color--black: black;
  --color--midnight-blue: #2b2e45;
  --color--slate-blue: #555777;
  --font-family--general-sans: "Generalsans Variable", sans-serif;
  --font-family--figtree: Figtree, sans-serif;
}

Component Styles

Astro components support scoped <style> blocks, where CSS only applies to that component so class names never collide across files. Orchid’s components don’t use them. All styling lives in the shared stylesheets above, keyed off class names like .pricing-section or .footer-link, so search orchid.css for a class to find its rules. You’re free to add a scoped block to any new component:

<style>
  .card { padding: 20px; border-radius: var(--radius--radius-1); }
</style>

Responsive Design, Typography & Spacing

Responsive rules use three max-width breakpoints throughout orchid.css and global.css: 991px (tablet, where the nav switches to the slide-over menu), 767px (large phone), and 479px (small phone). Headings use Figtree and body text uses General Sans, via the --font--heading and --font--body tokens. Prefer adjusting these shared values over overriding sizes on individual elements, so the site keeps a consistent rhythm as you edit it.

Images & Assets

Two homes for static files, and when to use each.

Replacing Images

Images are plain <img> tags pointing into public/images/. Either swap the file in place (keeping the same filename), or drop in your new file and update the src:

<img src="/images/Logo.svg" loading="lazy" alt="logo" class="logo" />

Some images are set in data arrays instead of markup: review avatars in Reviews.astro, category icons in Category.astro, and partner logos in TrustedBy.astro. The logo appears in Nav.astro (twice, for desktop and mobile) and Footer.astro. The default social-share image is the ogImage prop in Layout.astro.

Supported Formats & SVGs

Orchid ships WebP photos, a few PNGs, and SVGs for logos, icons, and section backgrounds. Any format a browser can display works from public/. Small UI icons (arrows, social icons) are inline <svg> elements using fill="currentColor", so they inherit the surrounding text color.

Image Optimization

Because everything lives in public/, Astro serves Orchid’s images exactly as they are, with no build-time resizing. The bundled photos are already compressed WebP files. Compress your replacements before adding them (WebP at roughly the same dimensions is a good target). If you’d rather have Astro optimize images, move them into src/assets/ and render them with the Image component from astro:assets:

---
import { Image } from 'astro:assets';
import hero from '../assets/hero.webp';
---
<Image src={hero} alt="Woman doing yoga" width={1200} height={630} />

Fonts & Icons

Swapping typefaces and icon sets without touching every component.

Google Fonts

The heading font, Figtree (weights 300–900), loads from Google Fonts via a <link> tag in Layout.astro’s <head>. To change it, replace that tag with your chosen font’s embed code, then update --font-family--figtree (or point --font--heading at a new variable) in orchid.css:

<link rel="preconnect" href="https://fonts.googleapis.com" />
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />
<link
  href="https://fonts.googleapis.com/css2?family=Figtree:wght@300;400;500;600;700;800;900&display=swap"
  rel="stylesheet"
/>

Local Fonts

The body font, General Sans, is self-hosted as a single variable font file, public/fonts/GeneralSans-Variable.ttf. It’s declared with @font-face in orchid.css, which supplies --font-family--general-sans. To swap it, replace the file in public/fonts/ and update the @font-face rule. The same rule is declared at both the top and the bottom of orchid.css, so update both or delete one:

@font-face {
  font-family: 'Generalsans Variable';
  src: url('/fonts/GeneralSans-Variable.ttf') format('truetype');
  font-weight: 200 700;
  font-style: normal;
  font-display: swap;
}

Icon Libraries

Orchid doesn’t use an icon library package. Icons come in two forms. Small UI icons (link arrows, the five footer social icons) are inline <svg> markup inside their components. Larger illustrative icons (category icons, check marks, rating stars, tags) are SVG files in public/images/. base-framework.css also embeds a tiny base64 icon font (orchid-icons) for its built-in w-icon-* classes.

Replacing & Adding Icons

To change an inline icon, replace the <svg>…</svg> block in the component, and keep fill="currentColor" so it still picks up the theme color. To change a file-based icon, swap the SVG in public/images/ or point the src (or the icon field in Category.astro’s items array) at your new file. If you prefer a library such as Lucide or Heroicons, copy its SVG markup in the same way. No package is required.

Content Editing

The fastest, lowest-risk way to make the site say what you want it to say.

Headings, Paragraphs & Buttons

Home page text lives in the section components in src/components/. Login and signup text lives in src/pages/login.astro and src/pages/signup.astro. Locate the text between the tags and edit it directly:

<!-- before -->
<h1 class="display-and-page-title">The Hassle-free world of fitness</h1>
<p class="body---variant-3">Orchid is the all‑in‑one fitness platform that supports members across all their goals — helps you to grow.</p>

<!-- after -->
<h1 class="display-and-page-title">Train smarter at Riverside Fitness</h1>
<p class="body---variant-3">Classes, coaching, and progress tracking in one membership.</p>

Keep the class attributes as they are, since they carry the typography styles. Button labels are plain text inside the <a> tags. Other one-off text to look for: the promo message in AnnouncementBar.astro, the CTA band in CtaBand.astro, and the app download copy in AppLinks.astro.

Navigation & Footer

Menu links are a small links array at the top of Nav.astro, and footer quick links are a quickLinks array at the top of Footer.astro. Edit a label or URL once there rather than hunting through every page. See Navigation for the full pattern.

Cards, Testimonials & Pricing

Repeating content blocks are driven by a data array in the frontmatter of the component that renders them, so adding or removing an item is a matter of editing the list:

const plans = [
  {
    name: 'Starter Plan',
    modifier: 'starter',
    blurb: 'Our standard membership, with unlimited access to your home club.',
    price: '19',
  },
  {
    name: 'Premium Plan',
    modifier: 'premium',
    blurb: 'Access to any program + digital workouts, and so much more!',
    price: '39',
  },
];

The FAQ answers in Faq.astro ship as placeholder text (“A wonderful serenity has taken possession…”), so replace them with your real answers before launch.

Blog Content & Contact Information

Orchid has no blog and no contact page. If you add a blog, Markdown files in src/pages/blog/ or a content collection in src/content/ are the usual approach. Brand and contact-related details are spread across a few files:

• Copyright line (“RNN studio”): Footer.astro, plus the copyright line at the bottom of login.astro and signup.astro.
• Social links (Facebook, Messenger, WhatsApp, Twitter/X, Dribbble): the hrefs in Footer.astro. They currently point at each network’s home page.
• App store links: the two buttons in AppLinks.astro. They currently point at apple.com and play.google.com.
• Hero video: the YouTube embed URL in the data-src attribute near the bottom of Hero.astro.

Navigation

Header, mobile menu, and footer links, in one predictable place.

Header Navigation

Primary nav links are defined as a small array at the top of src/components/Nav.astro, so adding, removing, or reordering a link doesn’t require touching markup. Each link points at a section anchor on the home page. The anchor() helper makes it a same-page #hash on the home page and a /#hash link everywhere else:

const links = [
  { label: 'Home', href: anchor('Home') },
  { label: 'Overview', href: anchor('Overview') },
  { label: 'Features', href: anchor('Features') },
  { label: 'Membership', href: anchor('Membership') },
  { label: "FAQ's", href: anchor('FAQs') },
];

The anchors are empty <div id="…" class="anchor-div"> elements inside the section components: Home and Overview in Hero.astro, Features in Overview.astro, Membership in Pricing.astro, and FAQs in Faq.astro. If you rename one, update both sides. The Login and Signup buttons are written directly in the nav markup below the array. global.css turns on smooth scrolling for these jumps unless the visitor prefers reduced motion.

Mobile Menu & Dropdown Menus

Below 991px the nav links collapse into a slide-over panel opened by the hamburger button. This is a vanilla inline <script> at the bottom of src/components/Nav.astro, not a framework component. It toggles an is-open class on the nav, locks page scrolling while open, and closes the menu when the overlay or any link is clicked. The slide animation itself is CSS in global.css. Orchid has no dropdown menus.

Footer Navigation

Footer quick links follow the same data-driven pattern in a quickLinks array at the top of src/components/Footer.astro. The “Others” column (Login, Signup, Powered by Astro) and the social icons are written directly in the footer markup.

Internal vs. External Links

Internal links should be root-relative (/about, not the full domain) so they keep working across environments. External links should open safely in a new tab:

<a href="/about">About</a>
<a href="https://partner-site.com" target="_blank" rel="noopener noreferrer">Partner</a>

Forms

What ships out of the box, and what still needs a backend.

Contact Forms

Orchid has no contact form. The two forms live inline in src/pages/login.astro (username, password, terms checkbox) and src/pages/signup.astro (name, work email, password, confirm password, terms checkbox). Each <form> carries a data-static-form marker attribute but nothing else. To send submissions somewhere, add an action and method pointing at your endpoint:

<!-- before -->
<form class="utility-form" data-static-form>

<!-- after -->
<form class="utility-form" action="https://your-backend.example.com/signup" method="POST">

Newsletter Forms

Orchid has no newsletter form and isn’t pre-wired to any email provider. If you add one (for example in the footer), point its action at your provider’s embed endpoint (Mailchimp, ConvertKit, etc.).

Form Validation

Validation uses standard HTML attributes only. Every field is required with maxlength="256", the signup email field uses type="email", and the “I accept Terms of use” checkbox is required. The browser checks these before submission and gives users immediate feedback without a round trip to a server. Note that nothing checks that “Password” and “Confirm Password” match, so add that in your submit logic. The checkbox is a styled custom control (native input hidden, CSS in global.css) that stays keyboard-accessible.

Third-Party Form Services

If you add a contact or lead-capture form and would rather not run your own backend, services like Formspree, Getform, or Basin accept form submissions directly from static HTML and forward them to your email — typically a one-line change to the form’s action attribute.

API & Data

Orchid fetches no data from any API — this section only matters if you add one.

API Configuration

If you connect an API, read URLs and keys from environment variables (see Configuration) rather than hard-coded, so the same code can point at a staging or production API depending on environment:

PUBLIC_API_URL=https://example.com/api
PUBLIC_API_KEY=your_api_key

Fetch Requests

const res = await fetch(`${import.meta.env.PUBLIC_API_URL}/products`, {
  headers: { Authorization: `Bearer ${import.meta.env.PUBLIC_API_KEY}` },
});
const data = await res.json();

Data Structures

The closest thing Orchid has to a data model is the arrays in its components (see Content Editing). If you move content to an API or CMS, have it return the same shapes so the existing markup keeps working:

// Reviews.astro — one testimonial card
{ rating: '4.7', ratingClass: '', avatar: '/images/reviewer-image.png', name: 'Alex Carter', role: 'Member since 2023' }

// Pricing.astro — one plan (modifier picks the card style: 'starter' | 'premium')
{ name: 'Starter Plan', modifier: 'starter', blurb: 'Our standard membership…', price: '19' }

// Faq.astro — one question
{ q: 'What are your opening hours?', a: '…' }

Error Handling

try {
  const res = await fetch(apiUrl);
  if (!res.ok) throw new Error(`Request failed: ${res.status}`);
  const data = await res.json();
} catch (err) {
  // show a fallback UI state instead of a blank page
  console.error(err);
}

SEO

Per-page metadata, social previews, and the machine-readable files search engines expect.

Page Title & Meta Description

Pass a unique title and description into Layout on every page — these drive both the browser tab and the snippet shown in search results. Each of Orchid’s three pages already does this:

<Layout
  title="Login — Orchid"
  description="Designed to optimize your wellness journey. …"
  bodyClass="with-body-color"
>

If you don’t want the login and signup pages indexed, add noindex to their <Layout> tag (<Layout noindex …>). It’s off by default on every page.

Canonical URL, Open Graph & Twitter/X Cards

Already set inside Layout.astro’s <head>, using the site value from astro.config.mjs to build absolute URLs. The share image defaults to /images/Hero-Image-with-shadow_1.webp. Override it per page with the ogImage prop:

<meta property="og:title" content={title} />
<meta property="og:description" content={description} />
<meta property="og:image" content={new URL(ogImage, Astro.site)} />
<meta property="og:type" content="website" />
<meta property="og:url" content={canonicalURL} />
<meta name="twitter:card" content="summary_large_image" />
<meta name="twitter:title" content={title} />
<meta name="twitter:description" content={description} />
<meta name="twitter:image" content={new URL(ogImage, Astro.site)} />
<link rel="canonical" href={canonicalURL} />

Sitemap & Robots.txt

Orchid includes Astro’s official sitemap integration (@astrojs/sitemap), which generates sitemap-index.xml automatically at build time from the site value. Set that to your real domain first. Orchid doesn’t ship a robots.txt. To add one, create public/robots.txt to control crawler access and point it at the sitemap:

User-agent: *
Allow: /
Sitemap: https://example.com/sitemap-index.xml

Structured Data & Semantic HTML

Use landmark elements (<header>, <nav>, <main>, <article>) and a single <h1> per page so both search engines and screen readers can parse the page’s structure. Each Orchid page has exactly one <h1>. No JSON-LD ships with the template. Add JSON-LD structured data in the layout’s <head> for rich results (e.g. Organization or Article schema) where relevant to your content.

Deployment

Platform-by-platform steps. Confirm your rendering mode first — it changes the build output you deploy.

Vercel

1. Push the project to a GitHub, GitLab, or Bitbucket repository.
2. In Vercel, choose Add New → Project and import that repository.
3. Build command: npm run build · Output directory: dist (Astro static) — Vercel’s Astro preset detects this automatically in most cases.
4. Orchid needs no environment variables. If you’ve added a .env file, copy its values under Project Settings → Environment Variables.
5. Click Deploy.

Netlify

[build]
  command = "npm run build"
  publish = "dist"

Connect the repository in the Netlify dashboard, confirm these build settings, add environment variables under Site configuration → Environment variables, and deploy.

Cloudflare Pages

Connect the repository, set the build command to npm run build and the output directory to dist. For SSR Astro sites, use the official @astrojs/cloudflare adapter instead of the static preset.

GitHub Pages

Set site and base in astro.config.mjs to match your repository URL, then build and publish the dist/ folder to the gh-pages branch (via the official astro build + a deploy action, or manually). GitHub Pages only serves static output — it cannot run an SSR adapter.

Traditional Hosting

Because Orchid builds to static files, upload the contents of dist/ to your host’s public web root via FTP/SFTP or your host’s file manager. Any shared host works, and no Node.js is needed on the server. Only if you later convert the site to SSR would the host need to run node continuously (a VPS or a Node-compatible host).

Build & Production

What happens when you run build, and a checklist before you ship.

npm run build     # render pages, bundle assets, generate the sitemap, and write dist/
npm run preview   # serve dist/ locally, exactly as it will run in production

Build Output

The build writes one HTML file per route (index.html, login/index.html, signup/index.html), hashed CSS/JS bundles (including GSAP), sitemap-index.xml, and a copy of everything in public/ to dist/. This folder is disposable and regenerated by every build. Orchid’s .gitignore already keeps it out of Git.

Environment Variables in Production

Orchid uses no environment variables, so there’s nothing to set out of the box. If you add some, remember that variables from your local .env are not deployed automatically — each hosting platform requires you to set them again in its dashboard (see Deployment). A missing production variable is one of the most common causes of a build that works locally but fails, or behaves unexpectedly, once deployed.

Production Checklist

• Run npm run build locally and confirm it completes with no errors.
• Run npm run preview and click through the main pages.
• Replace site: 'https://example.com' in astro.config.mjs with your real domain.
• Set every environment variable from .env (if you added any) in your hosting platform’s dashboard.
• Wire the login and signup forms to a real backend, or remove them. Out of the box they don’t submit anywhere.
• Replace the placeholder FAQ answers, social links, app store links, and the hero YouTube video.
• Verify the favicons (favicon.svg, images/favicon.png, images/webclip.png), the Open Graph image, and the meta descriptions are your own, not the template defaults.
• Keep or remove the Freepik images that require attribution (see README.md → Credits).

Troubleshooting

The most common problems, in the order you’re likely to hit them.

FAQ

Quick answers to the questions we hear most.

Changelog

Every notable change, newest first. Add a new entry above the last one for each release.

Support

Stuck on something this guide didn’t cover? Here’s how to reach us.

What to Include in a Support Request

The fastest way to get a useful answer is to include the details below in your first message:

When contacting support, please include:

- Template name and version
- Browser (and version)
- Operating system
- Node.js version (node --version)
- The exact error message
- Steps to reproduce the problem