Everything about Jinpa
How it works, why we built it, who built it, and how you can support us. Part technical reference, part mission statement, part grant proposal.
Getting Started with Jinpa
Jinpa is designed so that anyone — regardless of technical background — can create a fully functional website in under two minutes. Here is exactly what happens at each step.
Create a free GitHub account
Jinpa uses your own GitHub account to store your website's files and publish it to the web — completely free. Your repository, your code, your content: everything belongs to you. Jinpa never takes ownership of anything you create. If you don't already have a GitHub account, go to github.com and sign up. It takes about a minute and you only ever need a basic, free account.
Go to Jinpa and click "Get Started"
Visit getjinpa.com and click Get Started or Use This Template. You will be taken to the Jinpa setup wizard.
Log in with GitHub
The wizard's first step shows a single button: "Login with GitHub". Clicking it redirects you to GitHub's official login page. You enter your GitHub username and password there — Jinpa never sees your password. After you approve, GitHub sends you back to Jinpa automatically.
Name your site
Give your website a name (e.g. "Sera Monastery") and a short description. Jinpa also suggests a URL-friendly repository name automatically. You can leave everything as-is or customize it.
Jinpa creates everything automatically
This is where the magic happens. Behind the scenes (explained in detail in the Architecture section), Jinpa:
- Copies the Jinpa website template into your GitHub account
- Updates it with your site name and description
- Enables GitHub Pages so your site is live on the internet
- Waits for the first build to complete (about 60–90 seconds)
Set your admin password and start editing
Once your site is live, Jinpa prompts you to set a password for the admin panel. This password protects your site's control panel — choose something memorable. After that, you land directly in the admin panel, where you can write posts, add pages, upload images, and customize your site's look — all from a visual editor, no coding required.
yourusername.github.io/your-site-name. Share it with anyone in the world.
Returning to your site later
To edit your site after the initial setup, go to your site's URL and add /admin/
at the end (e.g., yourusername.github.io/your-site-name/admin/). Enter your password
and you're back in the editor.
Connecting a Custom Domain
By default your site lives at yourusername.github.io/repo-name. If you want a proper
domain like seramonastery.org, you can connect one you own. You need to buy the domain
first (from a registrar like Namecheap, Google Domains, or GoDaddy — usually $10–15/year).
Step 1: Add the domain to GitHub Pages
- Go to your repository on GitHub (e.g.,
github.com/yourusername/your-site) - Click Settings (top tab)
- In the left sidebar, click Pages
- Under Custom domain, type your domain (e.g.,
seramonastery.org) - Click Save
- Check the box for Enforce HTTPS (this gives your site a padlock — secure)
Step 2: Update your domain's DNS settings
Log in to wherever you bought your domain. Find the DNS settings or DNS management section. Add the following records:
| Type | Name / Host | Value / Points to |
|---|---|---|
A | @ | 185.199.108.153 |
A | @ | 185.199.109.153 |
A | @ | 185.199.110.153 |
A | @ | 185.199.111.153 |
CNAME | www | yourusername.github.io |
DNS changes take anywhere from a few minutes to 48 hours to fully propagate. Once done, your custom domain will point to your Jinpa site — with HTTPS automatically enabled.
Architecture & Design
Jinpa is built on a deliberate set of choices: use as little infrastructure as possible, depend on as few third-party services as possible, and keep websites alive permanently without recurring costs. Here is what powers it and why.
The Technology Stack
The heart of Jinpa is its own original software — built from scratch, with no borrowed CMS engine underneath. The CMS Core is approximately 2,600 lines of standards-compliant vanilla JavaScript that runs entirely in the browser, with zero external dependencies. It includes a full single-page admin application, a Markdown editor with live preview, a complete GitHub API client, a hash-based SPA router, a content cache layer, and a four-step site setup wizard. The security layer — an encrypted credential vault using AES-256-GCM and PBKDF2 with a novel vault-handoff pattern — is also original work. Together these form a complete, self-contained content management system that has no equivalent in the open-source ecosystem.
Astro is a modern web framework that builds websites into pure HTML, CSS, and JavaScript files — no server needed. The output is just static files that can be hosted anywhere. We chose Astro because it produces extremely fast, lightweight sites (no JavaScript frameworks shipped to the browser by default), has excellent support for content-heavy sites like blogs and monastery pages, and has a thriving open-source community.
GitHub Pages is GitHub's free static hosting service. Every public repository can have a live website at no cost. GitHub's infrastructure is backed by Microsoft and has been running for over a decade. We chose it because it is free forever for public sites, has no bandwidth limits that would affect a community organization, and — critically — the content lives in a Git repository that the user fully owns. Even if Jinpa ceased to exist, every user's website would continue running indefinitely.
GitHub Actions is GitHub's automation system. Every time a user publishes a post or changes their site, Jinpa commits the new content to GitHub, which automatically triggers a build pipeline. Astro compiles the site and GitHub Pages deploys it — typically in under 60 seconds. GitHub Actions is free for all public repositories, meaning every build is free regardless of volume.
The admin panel is built with zero JavaScript frameworks — no React, no Vue, no Svelte. It is
~2,600 lines of hand-written, standards-compliant JavaScript using only APIs that are built into
every modern browser. The encryption uses the browser's native Web Crypto API with
AES-256-GCM — the same standard used in banking applications. This means the admin panel has
zero external dependencies and will continue to work even if the entire JavaScript ecosystem changes.
GitHub's OAuth system requires a server to securely exchange an authorization code for an access token (due to browser security restrictions). We run a single lightweight Cloudflare Worker as this exchange proxy. It does one job: receive the OAuth code from GitHub, exchange it for a token using Jinpa's client secret, and return that token to the user's browser via URL hash so it never appears in server logs. The worker runs at the edge (Cloudflare's global network) and handles this in milliseconds. This is free on Cloudflare's generous free tier.
What Actually Happens When You Click "Use This Template"
When a user completes the Jinpa setup wizard, a precise sequence of API calls happens in the background. Here is what occurs step by step:
The browser redirects to GitHub's authorization endpoint. The user approves access. GitHub redirects back with a one-time authorization code.
The code is sent to the Cloudflare Worker, which exchanges it with GitHub's API
for a real OAuth access token (scoped to repo and workflow only).
The token is returned to the browser via URL hash and stored encrypted in localStorage.
The wizard calls the GitHub API to fork getjinpa/jinpa-starter into the user's
account under their chosen repository name. This is a deep copy — the user now owns their
own independent copy of the template.
The wizard reads site.config.json from the new repo via GitHub API,
updates the site title and description with what the user entered, then commits
the change back — triggering the first build automatically.
The wizard calls the GitHub Pages API to enable Pages on the repository,
configured to deploy from the gh-pages branch that GitHub Actions
will populate.
The wizard polls the GitHub Actions API every few seconds, watching for the build workflow to complete. A progress bar fills as the build runs. When complete, the live site URL is displayed.
The user sets an admin password. The wizard encrypts the OAuth token using
AES-256-GCM with the password as the key (via PBKDF2 key derivation). The
encrypted blob is passed to the admin panel via URL hash. The admin panel receives
it, stores it in localStorage, and the user is immediately logged in —
no second password entry needed.
The result: from pressing "Get Started" to having a live, editable website takes approximately 90 seconds. No command line. No configuration files. No server to manage.
The Admin Panel
The admin panel is a full single-page application (SPA) that lives inside your website at
/admin/. Because it is part of the static site, it is hosted on GitHub Pages
alongside your content — no separate server needed.
It communicates with GitHub's API directly from the browser using the stored OAuth token to read, create, update, and delete content. When you publish a post, the admin panel commits the Markdown file to your GitHub repository, which triggers a rebuild — just as if a developer had pushed code. The full list of capabilities:
- Create, edit, and delete blog posts with a visual Markdown editor
- Create and manage pages (About, Contact, etc.)
- Upload and manage images
- Edit site settings (title, description, navigation)
- Customize theme colors, fonts, and layout
- View a real-time Markdown preview while writing
Security and Authentication
Every piece of sensitive information in Jinpa is encrypted at rest using AES-256-GCM — a NIST-standardized algorithm used in government and financial systems. Your GitHub token (which allows editing your site) is never stored in plain text. It is encrypted with a key derived from your admin password using PBKDF2 with 100,000 iterations. This means even if someone accessed your browser's localStorage, they could not use your token without knowing your password.
Jinpa never stores your password, your GitHub token, or any personal data on any server. All sensitive material lives encrypted in your own browser. The Cloudflare Worker performs only the OAuth exchange — it does not log or retain any tokens.
Why We Built Jinpa
Who built it
Jinpa was created by Thupten Chakrishar, a Tibetan technologist, and a small group of collaborators who believe that the digital divide is not just an economic problem — it is a cultural and historical one. Thupten and collaborators have spent months designing, architecting, and building this system from the ground up, driven by a simple observation: the Tibetan community, one of the world's most culturally rich and historically significant civilizations, is dramatically underrepresented on the internet.
The problem we are solving
The web has become the primary archive of human civilization. But participation in that archive is not equal. For a Tibetan monastery, a thangka painter, a traditional medicine practitioner, or a diaspora community organization to have a website today, they typically need either significant technical skill or money to hire developers and pay for hosting. Most have neither. The result is silence — an entire civilization's living knowledge simply absent from the internet.
The AI dimension: why this is now urgent
The stakes of this absence have grown dramatically in the last few years. The dominant AI systems shaping the world — GPT, Claude, Gemini, Llama, and dozens of others — are trained on web-crawled data. The largest of these crawls is Common Crawl, which indexes billions of web pages every few months and feeds virtually every major AI model trained today.
This means that what exists on the internet today directly determines what AI systems will "know" about the world for decades to come. When a Tibetan monastery publishes their founding history, when a thangka painter documents their technique, when a Tibetan writer shares their stories in their own words — that content enters the training data that shapes global AI knowledge. The inverse is equally true: if a community's knowledge is not documented online in a format these crawlers can read, that community risks being erased from the AI's understanding of human history.
This is not hypothetical. Researchers and communities around the world have begun talking about "data sovereignty" — the right of a people to have their history, language, and culture represented in the systems that increasingly mediate human knowledge. Jinpa is, in part, a direct response to this challenge. Every website created through Jinpa adds Tibetan voices, Tibetan stories, and Tibetan knowledge to the public web in a way that search engines and AI crawlers can read, index, and learn from.
The technology is a means to an end. The end is cultural sovereignty on the digital frontier.
Why the name "Jinpa"
Jinpa (སྦྱིན་པ་) is the Tibetan word for generosity — the first of the six paramitas, or transcendent virtues, in Buddhist practice. Everything Jinpa offers is free. That is not a business model decision — it is a values decision.
What Jinpa Needs to Grow
Jinpa has gone from concept to working prototype through months of unpaid work. What exists today is a complete, functional V1 system. What is needed now is the resources to make V1 production-ready, secure, and accessible to thousands of people. V2 is a separate, longer-term vision that only becomes relevant after V1 is stable and widely used — see the V2 Vision section below.
What has been built
The current prototype represents a substantial body of technical work, completed without institutional funding:
- A complete Astro website template with 13 core components, fully responsive and accessible
- A full-featured admin panel (~2,600 lines of vanilla JavaScript) covering all content operations
- A novel encrypted credential system using browser-native Web Crypto API (AES-256-GCM + PBKDF2)
- A four-step setup wizard with full GitHub API integration — site live in ~90 seconds
- A Cloudflare Worker OAuth proxy handling secure token exchange
- An automated GitHub Actions build and deploy pipeline
- A plugin system architecture for future extensibility
This system is, to our knowledge, the first open-source website creation platform purpose-built for the Tibetan community, and the first CMS of its kind to implement GitHub-native deployment with a zero-dependency browser admin and an encrypted vault handoff authentication pattern.
Why it is urgent
The window for shaping AI training data is not infinite. The models being trained today and in the next few years will encode a particular understanding of the world that will be very difficult to correct later. Every month without Tibetan voices on the web is a month of absence in that record. Beyond AI, the generation of elders who hold living knowledge of Tibetan traditions, medicine, art, and history is aging. Digital documentation cannot wait indefinitely.
What funding would support — V1
These are all V1 priorities: making the current system production-grade and reaching the communities it was built for. V2 development is a separate future phase that comes after V1 is stable.
Infrastructure & Security
- Security audits of the authentication and encryption systems
- OAuth server hardening and rate limiting
- High-volume CI/CD pipeline capacity for thousands of simultaneous builds
- Monitoring, alerting, and uptime guarantees
- Penetration testing and vulnerability disclosure program
Ongoing Engineering
- Continuous bug fixes and compatibility updates as browsers evolve
- GitHub API maintenance as their platform changes
- Performance optimization and mobile improvements
- Accessibility audits and compliance
- New template designs — portfolio, organization, archive, teaching
Tibetan Language Support
- Full Tibetan script (Uchen) interface localization
- Wylie transliteration input support
- Tibetan font integration (Noto Serif Tibetan, Jomolhari)
- Right-to-left and vertical text layout research
- Translation of all documentation into Tibetan
Community & Outreach
- In-person onboarding workshops in Dharamsala, Bylakuppe, and other settlements
- Documentation and video tutorials in Tibetan and English
- Community support and helpdesk
- Partnerships with monasteries, schools, and cultural organizations
- User research to understand real community needs
Why Jinpa is a uniquely sustainable model
Unlike most technology projects targeting underserved communities, Jinpa does not create dependency on continued funding for the websites it creates. This is by design:
Get in touch
If you represent a foundation, grant-making organization, or institution interested in supporting Jinpa's development or learning more about the project, please reach out via GitHub or open an issue in the repository. We are grateful for any form of support — code contributions, design, translation, outreach, or funding.
V2 Vision: Zero-Account Publishing
The current version of Jinpa (V1) requires every user to have a GitHub account. That is already simpler than any comparable platform — but it is still one step too many. A monk in Bylakuppe should not need to understand what GitHub is to have a website. V2 removes that requirement entirely.
User-owned GitHub
- User fully owns their GitHub repository
- Site lives on indefinitely even if Jinpa closes
- Simpler to build and maintain
- Requires creating a GitHub account
- GitHub account management (2FA, password reset) falls on the user
- Custom domains require manual DNS configuration
Jinpa-managed hosting
- Sign up with just an email and password
- No GitHub account required at any point
- Custom domains with one DNS record (not five)
- Jinpa handles SSL, routing, and domain verification automatically
- Sites live in Jinpa's GitHub org (not user's own account)
- Adds backend complexity: user auth, password reset, subdomain routing
How V2 works: no GitHub account required
In V2, Jinpa runs a shared GitHub organization (already exists: getjinpa).
When a user creates a site, Jinpa's own service account creates the repository
(e.g., getjinpa/site-sera-monastery) using a server-side Cloudflare Worker.
The user never interacts with GitHub directly. From their perspective, they visit
getjinpa.com, type an email and password, name their site, and it is live —
the same ~90 second experience, but with zero GitHub knowledge required.
All site builds still run on GitHub Actions (free for public repositories), and all sites are still hosted on GitHub Pages (free, permanent). The user's data is still in a standard Git repository with standard Markdown files. What changes is that Jinpa holds the repository on behalf of the user, rather than the user owning it directly.
Controlling your site with a password
In V2, users authenticate with Jinpa's own system — not GitHub. Under the hood:
User picks an email and password. Jinpa stores a securely hashed password (bcrypt) in a lightweight database — likely Cloudflare D1 (SQLite at the edge) or Cloudflare KV. No GitHub credentials are ever shared with or entered by the user.
On login, a short-lived session token is issued (JWT or opaque token stored in a secure, httpOnly cookie). The admin panel uses this token to authenticate API calls to Jinpa's Worker, which then calls GitHub's API using Jinpa's service account token.
Each user can only read and write to their own repository. The Worker enforces this: every API call is validated against the user's session before proxying to GitHub. A user cannot access or modify another user's site.
Standard email-based password reset flow — a time-limited token sent to the user's email, handled entirely by Jinpa. No GitHub account recovery needed.
The admin panel experience is unchanged. The user still types a password to unlock their site editor. The only difference is that the password is now Jinpa's own auth system rather than a locally encrypted GitHub token.
One-record custom domains
The current V1 custom domain process requires adding four A records and one CNAME — five DNS changes across two record types, plus manual steps inside GitHub. In V2 this collapses to one record.
V2 sites are routed through a Cloudflare Worker that sits in front of GitHub Pages. This means Jinpa controls the domain routing layer. Using Cloudflare's Custom Hostnames feature (part of their "Cloudflare for SaaS" product), the flow becomes:
They type seramonastery.org in Settings → Custom Domain.
Jinpa registers it as a custom hostname with Cloudflare.
The admin panel displays a single DNS record to add at the domain registrar:
| Type | Name | Value |
|---|---|---|
CNAME | www | sites.getjinpa.com |
That is it. One record. The user goes to their registrar (GoDaddy, Namecheap, Google Domains, etc.), adds this single line, and is done.
Cloudflare detects when DNS propagates, automatically provisions an SSL
certificate (HTTPS), and begins routing seramonastery.org to the
correct site. The admin panel polls for verification and shows a green
confirmation when the domain is live.
seramonastery.org without www)?
Some registrars support ALIAS or ANAME records that work like
CNAME for root domains. Alternatively, Jinpa can instruct users to transfer DNS management
to Cloudflare (free), which enables the same one-record setup for the root domain too.
For most community organizations, www.seramonastery.org redirecting to
seramonastery.org (or vice versa) is handled automatically by the Worker.
V1 vs V2 custom domain comparison
| Step | V1 (today) | V2 (planned) |
|---|---|---|
| DNS records to add | 5 (four A records + one CNAME) | 1 (one CNAME) |
| GitHub Pages settings | Must be configured manually | Not needed (Jinpa proxies) |
| HTTPS / SSL | Must enable "Enforce HTTPS" manually | Automatic (Cloudflare) |
| Verification | Manual check in GitHub | Automatic, shown in admin panel |
| Technical knowledge needed | Moderate (understand DNS record types) | Minimal (copy one value) |
V2: A future milestone
The architecture for V2 is fully designed. It is a longer-term vision that we will pursue after V1 is stable, secure, and serving the community it was built for. Once V1 reaches that stage, V2 development becomes the natural next phase.