fastsite एक प्रकाशन इंजन है, CMS नहीं। आप सामग्री भेजते हैं, यह पूरी तरह स्टैटिक HTML तैयार करता है, इसे प्रति साइट कमिट करता है, और आपके CDN को इसे सर्व करने देता है। यहाँ पूरा मॉडल है, शुरू से अंत तक।
1. आप बॉडी भेजते हैं, पेज नहीं
सामग्री केवल बॉडी HTML होती है। आप कभी भी पूरा पेज नहीं बनाते — शेल क्रोम का स्वामी होता है, और इंजन बिल्ड के समय हर बॉडी को उसमें लपेटता है। प्रवेश के चार तरीके हैं, और वे सभी एक ही जगह पहुँचते हैं:
- REST — API key के साथ
POST /api/v1/sites/{site}/content। - MCP —
create_postऔरcreate_pageटूल्स, OAuth सहमति के अंतर्गत। - Webhooks — किसी अपस्ट्रीम सिस्टम से HMAC-हस्ताक्षरित पेलोड, जो किसी पोस्ट, पेज, मीडिया इम्पोर्ट, या कॉम्पोनेंट से मैप किया गया हो।
- डैशबोर्ड — जब आप खुद टाइप करना पसंद करें।
इन सभी मार्गों पर एक ही सैनिटाइज़र चलता है: एक निश्चित टैग अनुमति सूची, इनलाइन स्टाइल हटाए जाते हैं, स्क्रिप्ट और iframes हटाए जाते हैं। समस्याएँ रिकॉर्ड से जुड़ी चेतावनियाँ बन जाती हैं — इन्हें सामान्य किया जाता है और प्रकाशित किया जाता है, कभी भी विफल अनुरोध में नहीं बदला जाता। एक खराब पेस्ट आपकी पाइपलाइन को अवरुद्ध नहीं कर पाना चाहिए।
2. शेल बाकी सब कुछ का स्वामी है
शेल Twig टेम्पलेट्स का एक छोटा ट्री है, एक tokens.css डिज़ाइन सिस्टम है, और प्रति-लोकेल UI स्ट्रिंग्स हैं। यह साइट का संपूर्ण डिज़ाइन है, और यही वह है जिसे कोई AI एजेंट API या MCP पर पढ़ता और पुनर्लिखित करता है।
एक टोकन बदलें और अगले बिल्ड पर पूरी साइट पुनः थीम हो जाती है। क्योंकि डिज़ाइन एक ही जगह रहता है और सामग्री हमेशा केवल एक बॉडी होती है, पेजों के बीच कोई टेम्पलेट ड्रिफ्ट नहीं होता और डिज़ाइन बदलने पर माइग्रेट करने के लिए कुछ नहीं होता।
शेल राइट्स सुरक्षित हैं — पाथ कंटेनमेंट, एक एक्सटेंशन अनुमति सूची, एक साइज़ कैप — और एक टेम्पलेट जो ऑडिट में थ्रो या विफल होता, उसे सेव करते समय अस्वीकार किया जाता है, बिल्ड चलने पर नहीं। किसी जोखिम भरे बदलाव से पहले स्नैपशॉट लें; पुनर्स्थापना पहले अपना स्नैपशॉट लेती है, इसलिए अनडू खुद भी अनडू करने योग्य है।
3. इंजन स्टैटिक HTML बनाता है
हर बिल्ड पर इंजन:
<img data-media-id>को रेस्पॉन्सिव<picture>मार्कअप में विस्तारित करता है — पाँच चौड़ाइयों पर AVIF और WebP, एक ओरिजिनल-फॉर्मेट फॉलबैक, स्पष्ट आयाम, और हर जगह लेज़ी-लोडिंग, सिवाय फ़ीचर्ड इमेज के जिसे बजाय इसके प्रीलोड किया जाता है।- कॉम्पोनेंट्स को स्टैटिक मार्कअप में रेंडर करता है। React कॉम्पोनेंट्स को बिल्ड के समय सर्वर-रेंडर किया जाता है और परिणाम HTML होता है — फ्रेमवर्क कभी ब्राउज़र तक नहीं पहुँचता।
- पहले टोकन के साथ मिनिफाइड CSS इनलाइन करता है, और बिल्कुल भी JavaScript नहीं भेजता।
- एक पूर्ण हेड लिखता है: टाइटल, डिस्क्रिप्शन, कैनोनिकल, Open Graph, और JSON-LD।
sitemap.xml,robots.txt,llms.txt, कैश हेडर्स, और रीडायरेक्ट्स जेनरेट करता है — जिसमें एक रीडायरेक्ट भी शामिल है जो स्लग बदलने पर स्वचालित रूप से जुड़ जाता है, ताकि पुराने लिंक काम करते रहें।
बिल्ड इंक्रीमेंटल होते हैं। एक मैनिफेस्ट हर आउटपुट फाइल के हैश को ट्रैक करता है, इसलिए केवल वही लिखा जाता है जो वास्तव में बदला है, और जिन फाइलों का स्रोत गायब हो गया वे अनाथ छोड़े जाने के बजाय हटा दी जाती हैं।
4. ऑडिट तय करता है कि क्या शिप हो सकता है
परफेक्ट स्कोर वह चीज़ नहीं है जिसे आप बाद में खोजते हैं — इसे कुछ भी लिखे जाने से पहले लागू किया जाता है। हर बिल्ड एक पेज ऑडिट चलाता है जो दो प्रकार की समस्याओं को अलग करता है:
- विफलताएँ बिल्ड को रोकती हैं। एक गायब इमेज आयाम या alt एट्रिब्यूट, एक बाहरी संसाधन, एक शिप किया गया
<script>, बजट से अधिक स्टाइलशीट — ये पाइपलाइन इनवेरियंट हैं, और एक बिल्ड जो इनमें से किसी को तोड़ता, पूरा नहीं होता। - चेतावनियाँ इसे कभी नहीं रोकतीं। एक छोड़ा गया हेडिंग लेवल, एक भारी पेज, एक नॉन-एपेक्स कैनोनिकल, एक लिंक जो क्रॉल करने योग्य नहीं — ये सामग्री संबंधी संकेत हैं। इन्हें रिपोर्ट किया जाता है और पेज फिर भी प्रकाशित होता है।
विभाजन ही बात है। इंजन अपनी खुद की गारंटी तोड़ने से इनकार करता है, और किसी स्टाइल राय के कारण आपकी सामग्री को बंधक बनाने से भी इनकार करता है।
कठोर लक्ष्य: हर प्रकाशित पेज पर Google PageSpeed पर 100/100/100/100। ऑडिट वही है जो उस वादे को ईमानदार रखता है।
5. यह कमिट और डिप्लॉय करता है
प्रकाशन एक स्पष्ट कदम है, साइड इफेक्ट नहीं। सामग्री लिखना उसे स्टोर करता है; प्रकाशन साइट बनाता है और उसे पुश करता है। इसका मतलब है कि कोई एजेंट या स्क्रिप्ट जितना चाहे ड्राफ्ट, संशोधन और स्टेज कर सकता है, बिना कुछ भी आपके विज़िटर्स तक पहुँचे।
जब कोई पब्लिश चलती है, तो आउटपुट आपकी साइट के git रिपॉजिटरी में कमिट किया जाता है — प्रति पब्लिश एक कमिट — और पुश किया जाता है। आपका स्टैटिक होस्ट पुश पर बिल्ड करता है। Cloudflare Pages वह है जो इस साइट उपयोग करती है; कोई भी चीज़ जो रिपो देखती है वही तरीके से काम करती है।
बिल्ड और पब्लिश एक कतार पर चलते हैं, इसलिए एक को ट्रिगर करने वाला कॉल तुरंत वापस आता है और आप परिणाम के लिए पोल करते हैं। विफलताएँ गायब होने के बजाय बैकऑफ के साथ पुनः प्रयास करती हैं, और संपादनों की एक बर्स्ट प्रति बदलाव एक के बजाय एक ही बिल्ड में समेकित हो जाती है।
क्योंकि हर पब्लिश एक कमिट है, आपका डिप्लॉयमेंट इतिहास एक रोलबैक मैकेनिज़्म भी है। कुछ भी डायनामिक डिप्लॉय नहीं होता: एज पर कोई रनटाइम नहीं, इंटरनेट से पहुँच योग्य कोई डेटाबेस नहीं, और लोड के तहत गिरने वाला कोई ओरिजिन नहीं।
एक से अधिक भाषाएँ
एक लोकेल जोड़ें और इंजन प्रकाशित सामग्री और शेल की UI स्ट्रिंग्स को उसमें अनुवाद करता है, फिर पुनर्निर्माण करता है। प्राथमिक लोकेल रूट पर रहता है और प्रत्येक अतिरिक्त लोकेल को अपना सबट्री मिलता है, जिसमें hreflang ऑल्टर्नेट और x-default पूरे क्लस्टर और प्रति भाषा एक साइटमैप पर वायर्ड होते हैं।
अनुवाद प्रति पंक्ति उनके स्रोत के हैश के विरुद्ध ट्रैक किए जाते हैं, इसलिए एक पैराग्राफ संपादित करने पर उस पेज का पुनः अनुवाद होता है और कुछ नहीं। जो कुछ भी आप मैन्युअल रूप से अनुवादित के रूप में चिह्नित करते हैं उसे कभी अधिलेखित नहीं किया जाता। एक पेज जिसका अभी तक अनुवाद नहीं हुआ है वह उस भाषा में बस अनुपस्थित रहता है — विज़िटर्स को कभी भी ऐसा पेज नहीं परोसा जाता जो चुपचाप गलत भाषा पर फॉलबैक करता हो।
क्विकस्टार्ट
- एक साइट बनाएँ और उसका शेल डिज़ाइन करें, या डिफ़ॉल्ट स्कैफोल्ड से शुरू करें।
- एक API key बनाएँ, या MCP पर किसी एजेंट को कनेक्ट करें।
- एक पोस्ट भेजें, फिर प्रकाशित करें। देखें कैसे एक स्टैटिक पेज प्रकट होता है, कमिटेड और लाइव।
- बिना डिप्लॉय किए कभी भी प्रिव्यू करें — प्रिव्यू बिल्ड सेल्फ-कंटेन्ड है और किसी सर्वर की आवश्यकता नहीं।
- एक लोकेल जोड़ें और इंजन को ट्री का अनुवाद और पुनः उत्सर्जन करने दें।
विशिष्टताओं के लिए तैयार हैं? REST API संदर्भ, MCP संदर्भ, या webhooks वॉकथ्रू पढ़ें। यदि आप अपना खुद का इंजन सेटअप कर रहे हैं, तो इंस्टॉल से शुरू करें।