---
title: परिनियोजन
description: >-
  शून्य कॉन्फ़िगरेशन के साथ स्टैटिक डॉक्स को किसी भी होस्ट पर परिनियोजित करें, या जब आपको डायनामिक व्यवहार की आवश्यकता हो तो एडाप्टर के साथ सर्वर-साइड रेंडरिंग पर स्विच करें।
sidebar:
  label: परिनियोजन
  order: 2
---

## कहीं भी परिनियोजित करें (स्टैटिक) [#deploy-anywhere-static]

`blume build` आपके डॉक्स को सादे HTML, CSS, और `dist/` में एक स्थानीय खोज इंडेक्स में संकलित करता है। चलाने के लिए कोई सर्वर नहीं है — बस किसी भी स्टैटिक होस्ट को उस फ़ोल्डर की ओर इंगित करें।

| सेटिंग            | मान           |
| ----------------- | ------------- |
| बिल्ड कमांड       | `blume build` |
| आउटपुट डायरेक्टरी | `dist`        |
| Node संस्करण      | 22.12 या नया  |

ये सेटिंग्स Vercel, Netlify, Cloudflare Pages, GitHub Pages, Amazon S3 + CloudFront, या किसी भी बकेट या CDN पर काम करती हैं। सुनिश्चित करें कि `blume` एक डिपेंडेंसी है ताकि होस्ट बिल्ड चला सके।

एक स्टैटिक बिल्ड में शामिल है:

- हर डॉक्स और कस्टम पेज स्टैटिक HTML के रूप में
- एक स्थानीय खोज इंडेक्स (डिफ़ॉल्ट रूप से Orama, Pagefind वैकल्पिक)
- जब `deployment.site` सेट हो तो एक [`sitemap.xml`](/docs/discoverability/sitemap-and-robots#sitemap) और [`robots.txt`](/docs/discoverability/sitemap-and-robots#robots)
- AI टूल्स के लिए `llms.txt` और `llms-full.txt`
- रीडायरेक्ट पेज
- जब `seo.og.enabled` चालू हो तो प्रीरेंडर की गई [Open Graph छवियाँ](/docs/discoverability/open-graph)

### अपना साइट URL सेट करें [#set-your-site-url]

साइटमैप, कैनोनिकल टैग, RSS, और Open Graph छवियों को एक निरपेक्ष ऑरिजिन की आवश्यकता होती है। **Vercel**, **Netlify**, और **Cloudflare Pages** पर, Blume इसे बिल्ड समय पर प्लेटफ़ॉर्म के परिवेश से पहचान लेता है — किसी कॉन्फ़िग की आवश्यकता नहीं।

पहचाने गए मान को ओवरराइड करने के लिए, या उन होस्ट्स पर मान उपलब्ध कराने के लिए जो इसे उजागर नहीं करते (GitHub Pages, S3, एक कस्टम CDN), `deployment.site` सेट करें:

```ts blume.config.ts lineNumbers
deployment: {
  site: "https://docs.example.com",
}
```

स्वचालित रूप से पहचान करते समय, Blume प्रति-डिप्लॉय प्रीव्यू URL की तुलना में आपके स्थिर प्रोडक्शन डोमेन को प्राथमिकता देता है, ताकि कैनोनिकल ऑरिजिन डिप्लॉय-दर-डिप्लॉय एक जैसा बना रहे।

`blume dev` के दौरान, जब कोई सेट न हो तो साइट URL आपके स्थानीय डेव सर्वर (जैसे `http://localhost:4321`) पर वापस चला जाता है, ताकि साइट-आधारित सुविधाएँ — Open Graph छवियाँ, कैनोनिकल, साइटमैप — बिना किसी अतिरिक्त सेटअप के काम करें। बिल्ड कभी इस फ़ॉलबैक का उपयोग नहीं करते, इसलिए प्रोडक्शन आउटपुट कभी localhost की ओर इंगित नहीं होता।

## स्थानीय रूप से पूर्वावलोकन करें [#preview-locally]

शिप करने से पहले, प्रोडक्शन बिल्ड का ठीक वैसे ही पूर्वावलोकन करें जैसे एक स्टैटिक होस्ट इसे परोसेगा:

```bash
blume build
blume preview
```

## सबपाथ परिनियोजन [#subpath-deploys]

डॉक्स को `example.com/docs` जैसे पथ के अंतर्गत परोस रहे हैं? `deployment.base` सेट करें — GitHub Pages प्रोजेक्ट साइटों के लिए यह सामान्य है। पूरी साइट, रूट सहित, बेस के अंतर्गत चली जाती है, और आंतरिक लिंक व एसेट्स को इसे शामिल करने के लिए पुनर्लिखित किया जाता है।

```ts blume.config.ts lineNumbers
deployment: {
  base: "/docs",
}
```

## डॉक्स को किसी पथ के अंतर्गत माउंट करें [#mount-the-docs-under-a-path]

`basePath` हर जनरेट किए गए रूट को एक सेगमेंट (`/docs/getting-started`) के अंतर्गत माउंट करता है जबकि साइडबार को अछूता छोड़ देता है — शीर्ष स्तर आपके सेक्शन हैं, कोई रैपर समूह नहीं। इसका उपयोग तब करें जब डॉक्स `/docs/*` पर रहें लेकिन साइट रूट आपका ही बना रहे (जैसे Docusaurus का `routeBasePath` या Fumadocs का `baseUrl`)।

```ts blume.config.ts lineNumbers
basePath: "/docs",
```

लिंक ऐसे लिखें मानो वे रूट पर माउंट हों (`/getting-started`); Blume उन्हें, साथ ही रीडायरेक्ट, साइटमैप, कैनोनिकल URL, Open Graph छवियाँ, `llms.txt`, और खोज इंडेक्स को पुनर्लिखित करता है। सार्वजनिक एसेट्स (छवियाँ, `public/` के अंतर्गत फ़ाइलें) साइट रूट पर ही रहती हैं।

यह ऊपर दी गई दो अवधारणाओं से अलग है:

- प्रति-स्रोत [`prefix`](/docs/content/sources#multiple-sources) **एक** स्रोत को नेमस्पेस देता है और एक साइडबार समूह **जोड़ता है**।
- `deployment.base` वह होस्ट सबडायरेक्टरी है जहाँ से **पूरा** ऐप परोसा जाता है। दोनों साथ मिलकर काम करते हैं — दोनों सेट होने पर, एक पेज `{deployment.base}/{basePath}/page` पर पहुँचता है।

## सर्वर रेंडरिंग [#server-rendering]

स्टैटिक आउटपुट अधिकांश डॉक्स के लिए पर्याप्त है। जब आपको अनुरोध-समय की सुविधाओं की आवश्यकता हो तो सर्वर आउटपुट पर स्विच करें — विशेष रूप से [Ask AI](/docs/configuration/ask-ai) एंडपॉइंट के लिए:

```ts blume.config.ts lineNumbers
deployment: {
  output: "server",
  adapter: "vercel",
}
```

`vercel` और `node` एडाप्टर Blume के साथ आते हैं — इनमें से किसी एक को चुनना ही काफ़ी है। `netlify` और `cloudflare` एडाप्टर आपके प्रोजेक्ट में इंस्टॉल करने होंगे (जैसे `bun add -d @astrojs/netlify`); पैकेज गायब होने पर CLI आपको चेतावनी देता है:

| एडाप्टर      | पैकेज                 | किसके लिए उपयोग करें                  |
| ------------ | --------------------- | ------------------------------------- |
| `vercel`     | `@astrojs/vercel`     | Vercel — सबसे परिष्कृत रास्ता         |
| `netlify`    | `@astrojs/netlify`    | Netlify Functions                     |
| `node`       | `@astrojs/node`       | स्वयं-होस्ट किए गए Node सर्वर, कंटेनर |
| `cloudflare` | `@astrojs/cloudflare` | Cloudflare Workers और Pages           |

**Vercel**, **Netlify**, और **Cloudflare Pages** पर, Blume सर्वर आउटपुट के लिए मेल खाने वाला एडाप्टर स्वतः चुन लेता है — बस `output: "server"` सेट करें और परिनियोजित करें (Netlify और Cloudflare पर, एडाप्टर पैकेज भी इंस्टॉल करें)। पहचाने गए मान को ओवरराइड करने के लिए, या `node` के साथ स्वयं-होस्टिंग करते समय, `adapter` को स्पष्ट रूप से सेट करें।

एक सर्वर बिल्ड में वह सब कुछ शामिल होता है जो एक स्टैटिक बिल्ड में होता है, साथ ही आपके द्वारा जोड़े गए कोई भी Astro एंडपॉइंट या मिडलवेयर। `node` एडाप्टर एक स्वतंत्र सर्वर बनाता है जिसे आप सीधे चला सकते हैं।

Vercel और Cloudflare पर, एक सर्वर बिल्ड [`Accept: text/markdown` कंटेंट नेगोशिएशन](/docs/discoverability/markdown#content-negotiation) को भी चालू कर देता है, ताकि उस हेडर के साथ किसी भी कंटेंट पेज का अनुरोध करने वाले एजेंट को उसी URL पर उसका रॉ-Markdown मिरर मिले। Vercel पर, Blume डिप्लॉय के रूटिंग कॉन्फ़िग में हेडर-सशर्त रीराइट्स जोड़ देता है; Cloudflare पर, यह Astro वाले Worker के आगे एक छोटा Worker उत्पन्न करता है और `assets.run_worker_first` को कंटेंट रूट्स तक सीमित कर देता है, क्योंकि अन्यथा प्लेटफ़ॉर्म कोई भी सर्वर कोड चलने से पहले ही प्रीरेंडर किए गए पेज परोस देता — अन्य एसेट्स अपना शून्य-Worker तेज़ रास्ता बनाए रखते हैं। जब प्रीरेंडर किए गए प्रति-पेज JSON दस्तावेज़ों (`/api/docs/pages/{route}.json`) में से किसी का अनुरोध उस Worker तक पहुँचता है, तो वह Worker उसका उत्तर भी एसेट बाइंडिंग से देता है, क्योंकि अन्यथा Astro उसे `/api/` कैच-ऑल की ओर रूट कर देता।

:::note
सर्वर सुविधाओं का अपना कॉन्फ़िगरेशन होता है — उदाहरण के लिए, Ask AI को एक मॉडल API कुंजी की आवश्यकता होती है। सेटअप के लिए [Ask AI गाइड](/docs/configuration/ask-ai) देखें।
:::

## रीडायरेक्ट [#redirects]

`blume.config.ts` में पुराने URL को नए URL से मैप करें:

```ts blume.config.ts
redirects: [{ from: "/old", to: "/new", status: 301 }];
```

`status` `301`, `302`, `307`, या `308` स्वीकार करता है (डिफ़ॉल्ट `301`)। सर्वर बिल्ड रीडायरेक्ट को अनुरोध-समय पर संभालते हैं। स्टैटिक बिल्ड रीडायरेक्ट पेज **और** प्लेटफ़ॉर्म फ़ाइलें दोनों उत्पन्न करते हैं ताकि आपका होस्ट एक वास्तविक HTTP रीडायरेक्ट जारी करे: `_redirects` (Netlify, Cloudflare Pages), `vercel.json` (Vercel), और `blume-redirects.json` — बाकी सब कुछ के लिए एक संरचित मैनिफ़ेस्ट (nginx/Apache नियम, एक एज वर्कर)। `public/` में आपके द्वारा शिप की गई `_redirects` या `vercel.json` फ़ाइल अछूती छोड़ दी जाती है।

:::note
`from` का मिलान एक सटीक पथ के रूप में किया जाता है — वाइल्डकार्ड और पैटर्न मिलान (जैसे `/blog/:slug` या `/old/*`) समर्थित नहीं हैं। यदि आपको पैटर्न-आधारित नियमों की आवश्यकता है, तो उन्हें इसके बजाय `vercel.json` जैसी इन्फ़्रास्ट्रक्चर फ़ाइल (जो वाइल्डकार्ड `source` पैटर्न का समर्थन करती है) या अपने होस्ट के रीडायरेक्ट कॉन्फ़िग में संभालें। `public/` में आपके द्वारा शिप की गई `vercel.json` जस की तस संरक्षित रहती है।
:::

:::note
`from` और `to` दोनों को ऐसे लिखें मानो वे रूट पर माउंट हों — [`deployment.base`](#subpath-deploys) और [`basePath`](#mount-the-docs-under-a-path) दोनों के अंतर्गत, Blume आपके लिए दोनों पक्षों को पुनर्लिखित कर देता है, ताकि रीडायरेक्ट बेस के भीतर ही पहुँचे। जो बेस आपने `to` में पहले से हाथ से लिख दिया है, वह दोहराया नहीं जाता बल्कि संरक्षित रखा जाता है।
:::

## कंटेंट प्रकार [#content-types]

एक स्टैटिक बिल्ड एक `_headers` फ़ाइल भी उत्पन्न करता है जो रॉ AI-तैयार एंडपॉइंट्स — `/<route>.md`, `/<route>.mdx`, और `.txt` फ़ाइलों (`llms.txt`, `llms-full.txt`) — पर `charset=utf-8` निर्धारित करती है। वे प्रतिक्रियाएँ वैध UTF-8 होती हैं, लेकिन कई स्टैटिक होस्ट उन्हें **बिना** किसी charset के `text/markdown` / `text/plain` के रूप में परोसते हैं, और तब ब्राउज़र Windows-1252 पर वापस चले जाते हैं — इसलिए गैर-ASCII डॉक्स (जापानी, उच्चारण-चिह्न वाली लैटिन, …) रॉ URL सीधे खोलने पर मोजिबाके के रूप में दिखते हैं। HTML पेज इससे अप्रभावित रहते हैं क्योंकि उनमें `<meta charset>` होता है। Netlify और Cloudflare (Pages/Workers स्टैटिक एसेट्स) `_headers` पढ़ते हैं; जो होस्ट नहीं पढ़ते (Vercel, S3) वे इस फ़ाइल को हानिरहित रूप से अनदेखा कर देते हैं। `public/` में आपके द्वारा शिप की गई `_headers` फ़ाइल अछूती छोड़ दी जाती है।

## परिवेश चर [#environment-variables]

जब किसी सुविधा को रनटाइम सीक्रेट की आवश्यकता होती है, तो Blume `blume dev`/`build` पर चेतावनी देता है यदि वह गायब है — ताकि समस्या पहले अनुरोध के बजाय पहले ही सामने आ जाए:

| सुविधा | चर |
| --- | --- |
| Ask AI (AI Gateway) | `AI_GATEWAY_API_KEY` (या Vercel OIDC) |
| Ask AI (अन्य प्रदाता) | प्रदाता का डिफ़ॉल्ट कुंजी एन्व चर (`OPENROUTER_API_KEY`, `LLMGATEWAY_API_KEY`, `INKEEP_API_KEY`), या आपका कॉन्फ़िगर किया गया `apiKeyEnv` |
| Mixedbread खोज | `MIXEDBREAD_API_KEY` |

स्थानीय डेव के लिए इन्हें `.env.local` में और प्रोडक्शन के लिए अपने होस्ट के परिवेश में सेट करें। खोज-इंडेक्स सिंक (Algolia, Orama Cloud, Typesense) के लिए बिल्ड-समय के सीक्रेट्स के बारे में सिंक चरण के दौरान अलग से चेतावनी दी जाती है।

## बिल्ड कैश [#build-cache]

Blume दो कैश रखता है जिनका एक बिल्ड पुन: उपयोग कर सकता है। Astro और Vite के कैश `.blume/.cache/` के अंतर्गत रहते हैं (इनमें कंटेंट स्टोर और इमेज ट्रांसफ़ॉर्म शामिल हैं)। रेंडर किए गए [OG कार्ड](/docs/discoverability/open-graph#card-cache) `node_modules/.cache/blume/og` में रहते हैं, ताकि एक रीबिल्ड केवल उन्हीं कार्डों को रेंडर करे जिनका शीर्षक, विवरण, या ब्रांडिंग बदली है। कोई प्लेटफ़ॉर्म डिप्लॉय के बीच उस डायरेक्टरी को बनाए रखता है या नहीं, यह अलग-अलग होता है:

- **Vercel** अपने बिल्ड कैश से `node_modules/**` को पुनर्स्थापित करता है, इसलिए कार्ड आगे बने रहते हैं (कैश 1 GB का होता है, एक महीने तक रखा जाता है, और प्रति ब्रांच कुंजीबद्ध होता है — एक नई ब्रांच प्रोडक्शन कैश से शुरू होती है)।
- **Netlify** `node_modules` को पुनर्स्थापित करता है, इसलिए कार्ड आगे बने रहते हैं।
- **Cloudflare Workers Builds** केवल पैकेज-मैनेजर कैश और, पहचाने गए Astro प्रोजेक्ट के लिए, `node_modules/.astro` को बनाए रखता है — `node_modules/.cache` को कभी नहीं — इसलिए वहाँ हर डिप्लॉय हर कार्ड को रेंडर करता है।
- **GitHub Actions** और आपके द्वारा प्रबंधित अन्य रनर कुछ भी नहीं रखते, जब तक कि आप स्वयं उस डायरेक्टरी को कैश न करें:

```yaml
- uses: actions/cache@v4
  with:
    path: node_modules/.cache/blume/og
    key: blume-og-${{ runner.os }}-${{ hashFiles('**/bun.lock', '**/package-lock.json', '**/pnpm-lock.yaml') }}
    restore-keys: blume-og-${{ runner.os }}-
```

कार्ड कंटेंट के आधार पर कुंजीबद्ध होते हैं, इसलिए एक अपरिशुद्ध कुंजी भी ठीक है: पुनर्स्थापित कैश केवल रेंडर बचाता है, कभी गलत कार्ड नहीं परोसता।

एक इंस्टॉल कमांड हर प्लेटफ़ॉर्म पर कैश को हटा देता है: `npm ci` इंस्टॉल करने से पहले `node_modules` को हटा देता है। पुन: उपयोग का लाभ पाने के लिए इंस्टॉल कमांड के रूप में `npm install`, `bun install`, या `pnpm install` का उपयोग करें।

## बिल्ड सारांश [#build-summary]

हर बिल्ड एक सारांश प्रिंट करता है — आउटपुट मोड, एडाप्टर, हल किया गया साइट URL, खोज प्रदाता, रीडायरेक्ट संख्या, साइटमैप और `llms.txt` की स्थिति, और कोई भी सक्षम सर्वर सुविधाएँ — ताकि परिनियोजित करने से पहले आप पुष्टि कर सकें कि क्या शिप हुआ (स्वतः पहचानी गई हर चीज़ सहित)।