Korean Saju Web App Source: Start Locally Before Cloudflare D1
If you are evaluating a Korean Saju web app source, begin with a local run. The delivered package uses Node.js 22.13 or newer, installs with npm ci, and starts with npm run dev. That local path uses an isolated Miniflare D1 binding. A public deployment is a separate buyer-owned Cloudflare setup: you still need your own D1 database, DB binding, database ID, Worker configuration, and DNS decision.
Answer first: run and inspect the package locally before creating any remote resource. The package includes the checked-in Drizzle migration and a local D1 path; its shipped wrangler.jsonc intentionally has an empty d1_databases array. Do not treat a local page as proof that a buyer’s Cloudflare account or production domain is configured.
What does the package include?
The source package is a starting point for a Korean traditional Saju four-pillars application. Its README documents Korean birth-date input, solar/lunar conversion, seasonal-boundary and true-solar-time correction, four pillars, five-elements balance, ten-god and hidden-stem readings, Korean name-study Hanja selection, anonymous share links, and optional D1 persistence. It has no paid AI API dependency.
The $99 product is a one-buyer, one-project source license. You may rebrand, modify, operate one end product, and charge that product’s users. The license does not grant permission to resell or redistribute the raw source. Read the included LICENSE.md and THIRD_PARTY_NOTICES.md before operating a public service.
How do I run it locally?
Use the package root and a supported Node version:
npm ci
npm run dev
Open the exact URL printed by Vite. The package’s predev script applies the checked-in Drizzle migration to the local database named saju-source-local through wrangler.local.jsonc. The DB binding is local and disposable; the first run creates .wrangler/. No Cloudflare account, remote database, domain, or paid AI service is needed for this local path.
After the page opens, the documented checks are:
npm run build
npm test
npm run selftest
npm run lint
selftest starts an isolated local server, checks the page, local D1 view counter, and anonymous share API, then shuts down. Treat these as package checks to run on your machine, not as a claim that every buyer environment has passed.
What changes for a Cloudflare D1 deployment?
The production database belongs to the buyer. First create it with Wrangler, then put the returned database name and UUID into the project’s D1 configuration. Cloudflare documents that wrangler d1 create returns the binding and UUID to place in configuration; see the official D1 Wrangler command reference.
Create the buyer-owned database first:
npx wrangler d1 create your-saju-db
Copy the returned database name and ID into wrangler.jsonc. The shipped remote array is empty; the local config is the one that currently carries the migration directory. Add a buyer-specific entry like this, replacing every placeholder before deployment:
"d1_databases": [
{
"binding": "DB",
"database_name": "your-saju-db",
"database_id": "<returned-database-id>",
"migrations_dir": "./drizzle"
}
]
Then apply the migration, build, and deploy:
npx wrangler d1 migrations apply your-saju-db --remote
npm run build
npx wrangler deploy
The DB binding must be exactly DB, database_name must match the buyer’s database, database_id must be the returned ID, and migrations_dir must point to ./drizzle for this package. Cloudflare’s D1 migration documentation explains that migrations are applied against the selected database and that a binding can define the migration directory. Confirm the package’s Drizzle layout and current Wrangler behavior before adding further migrations.
Cloudflare’s D1 getting-started guide separates local and remote operations. A remote database is a real account resource with its own access, data, and possible charges. Choose the buyer’s Worker name, account, region or jurisdiction needs, and custom domain or route deliberately. Add the buyer-owned DNS or route only after those details are known.
Runtime
Local: Node.js 22.13+ and Vite dev server.
Production: Confirm Node, Wrangler, account, and deployment access.
Database
Local: Local Miniflare D1, DB binding.
Production: Create buyer-owned D1 and set database_id.
Migration
Local: Checked-in Drizzle SQL applied by predev.
Production: Apply the intended migration to the selected remote DB.
Origin
Local: http://localhost:5173 while developing.
Production: Set the buyer’s HTTPS origin and review metadata/share origin.
Domain
Local: None required.
Production: Configure buyer-owned route or custom domain and DNS.
Privacy
Local: Local sample stays in the local run.
Production: Review notices and production data handling with a person.
What should I review before going public?
Change the brand and copy in app/page.tsx, metadata and share origin in app/layout.tsx, and visual tokens in app/globals.css. Before real users arrive, review the privacy notice, Korean legal notices, third-party terms, and production settings. The README states that the browser calculates the chart locally, while the share route stores a redacted derived result and excludes birth date, birth time, birthplace correction, Hanja name, and per-character stroke data. Verify the implementation and write your own notices for the service you operate.
If you only need to learn the flow or build a prototype, use the public demo and the Cloudflare documentation, then build from scratch. The Korean Saju source pack is for a buyer who values a packaged starting point, documented source, and bounded one-project rights. It does not include custom installation, rebranding, DNS, hosting, legal review, or ongoing operations. If that matches your use case, review the license and the buyer-owned deployment steps before choosing the pack.
Sources
This article uses Cloudflare’s official D1 Wrangler command reference, D1 migration documentation, and D1 getting-started guide, plus the delivered package’s README.md, docs/KO_QUICKSTART.md, package.json, wrangler.jsonc, and checked-in migration files.