[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-80252":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":16,"subscribersCount":16,"size":16,"stars1d":16,"stars7d":17,"stars30d":18,"stars90d":16,"forks30d":16,"starsTrendScore":19,"compositeScore":20,"rankGlobal":10,"rankLanguage":10,"license":10,"archived":21,"fork":21,"defaultBranch":22,"hasWiki":23,"hasPages":21,"topics":24,"createdAt":10,"pushedAt":10,"updatedAt":25,"readmeContent":26,"aiSummary":27,"trendingCount":16,"starSnapshotCount":16,"syncStatus":14,"lastSyncTime":28,"discoverSource":29},80252,"vibe","di-sukharev\u002Fvibe","di-sukharev","God's chosen objectively true vibecoding template 🛕","https:\u002F\u002Fvibe.sukharev.dev",null,"TypeScript",222,36,2,1,0,18,90,4,4.7,false,"master",true,[],"2026-06-12 02:04:00","# Vibe Coding Template\n\n\u003Cp align=\"center\">\n  \u003Cimg src=\"docs\u002Fassets\u002Fvibe_tmpl_schema.png\" alt=\"Vibe Coding Template architecture schema\" width=\"100%\">\n\u003C\u002Fp>\n\nA full-stack starter for web and backend products: one repository with a Bun\u002FHono backend, a React CSR browser client (`webapp`), an Astro SSG\u002FSSR site (`website`), and shared API contracts. The runnable Expo mobile template lives on the `mobile` branch so the default branch stays focused on webapp, backend, website, infrastructure, and shared contracts.\n\n## Agent Intake Checklist Before Installing\n\nBefore cloning or installing this template for an end user, the agent should ask a short product-focused intake in the user's language and record the answers during setup:\n\n- Confirm whether this is a new project from the template or work on the template itself.\n- Ask for the project name\u002Fslug and the user's own GitHub destination, if they already have one.\n- Ask what product they want to build first and the first user journey that should work.\n- Ask which surfaces are active now: `webapp`, `mobile`, `backend\u002FAPI`, `website`, or full-stack. Mark the rest as deferred.\n- Route each browser feature by SEO need, not by habit: public, search-indexable, or link-previewed pages (landing, content, marketplace catalog) belong in `website` (SSG, SSR per route); behind-login app screens with no SEO belong in `webapp` (CSR). See \"Choosing `webapp` vs `website`\". The user usually will not know this distinction — decide it for them and explain it in product terms.\n- If `mobile` is active, clone or checkout the `mobile` branch before setup; that branch is the mobile-ready template line with payments, Expo Push, and mobile-specific release\u002Fsetup foundation.\n- Ask whether the first version needs accounts\u002Fauth, persistence, file uploads, images\u002Fmedia, payments, admin tools, or external integrations.\n- Ask whether the product needs real-time collaboration, chat, presence, live notifications, or other WebSocket-style updates.\n- If `mobile` is active, switch to the `mobile` branch before setup and ask whether Expo\u002FEAS builds and Maestro E2E validation are needed now or can be left unconfigured until later.\n- For files\u002Fimages\u002Fmedia, ask whether assets are public or private, what users upload, expected max file size, allowed file types, whether thumbnails\u002Foptimized variants are needed, and when files should be deleted.\n- Ask whether deployment is needed now. If yes, use DigitalOcean by default and ask for production domains\u002FURLs and release targets, not for a cloud provider choice.\n- For DigitalOcean deployment, verify App Platform GitHub integration first, then generate specs with `bun run deploy:do:specs`; never hand-substitute secrets or URLs into app specs.\n- If the user explicitly asks for Yandex Cloud, follow [docs\u002FYANDEX_CLOUD.md](docs\u002FYANDEX_CLOUD.md) instead of improvising provider choices.\n- If backend\u002FAPI, full-stack, uploads, or database-backed validation is active, verify Docker Compose and the Docker daemon before local setup.\n\n## Agent Repo Download Instructions\n\nWhen installing this repository from a GitHub URL into a fresh Codex or agent session, treat setup as an onboarding task before feature work. This README is the source of truth for first-run setup because fresh installers may not read `AGENTS.md`.\n\nGive the agent this initial prompt:\n\n```text\nInstall this repository into the project. Before cloning from a GitHub URL, ask whether I plan to develop a mobile app now. If yes, clone the `mobile` branch with `git clone --branch mobile --single-branch \u003Crepo-url>` or checkout `mobile` immediately after cloning; that branch is the mobile-ready template line with Expo, payments, Expo Push, social auth, and mobile-specific release\u002Fsetup foundation. If mobile is deferred, use the default branch; it intentionally contains only `mobile\u002FREADME.md` as a pointer to the mobile template branch. First read README.md, CLAUDE.md if present, and relevant docs\u002F*.md, including docs\u002FLOCAL_DATABASE.md when backend\u002FAPI or full-stack work is active, docs\u002FSTORAGE.md when uploads, files, images, or media are active, and docs\u002FYANDEX_CLOUD.md only when I explicitly ask for Yandex Cloud. Before setup, ask me what project name\u002Fslug I want to use, what product I want to build first, which surfaces I need now (webapp, mobile, backend\u002FAPI, website, or full-stack), whether the first version needs auth\u002Fpersistence\u002Fuploads\u002Fmedia\u002Fintegrations, whether it needs real-time chat\u002Fpresence\u002Flive updates, and whether I need deployment now. If mobile is active, confirm the checkout is on the `mobile` branch before running mobile setup, then follow that branch's README for Expo\u002FEAS, Maestro, IAP, push, and social auth setup. Prefer the monolithic backend in this repository; do not introduce microservices during setup. If real-time features later need horizontal scaling across multiple backend instances, use managed Redis-compatible Pub\u002FSub such as DigitalOcean Managed Valkey or Yandex Managed Service for Valkey to fan out events between WebSocket connections. If deployment is needed, use DigitalOcean App Platform, DigitalOcean Managed PostgreSQL, and DigitalOcean Spaces by default; ask me for production domains\u002FURLs and release targets, but do not ask me to choose a cloud provider unless I explicitly request another provider. For DigitalOcean deployment, first verify that App Platform is connected to my GitHub account\u002Forganization and has access to the full monorepo branch, then generate concrete specs with `bun run deploy:do:specs` into `.scratch\u002Fdeploy`; do not use manual `sed`, `perl`, or shell substitution for secrets, CORS origins, `VITE_API_URL`, or `PUBLIC_WEBAPP_URL`. If I explicitly request Yandex Cloud, use Yandex Serverless Containers, Yandex Managed Service for PostgreSQL, Yandex Object Storage, and Yandex Cloud CDN according to docs\u002FYANDEX_CLOUD.md. If backend\u002FAPI, full-stack, uploads, or any database-backed validation is active, verify Docker Compose with `docker compose version` and the Docker daemon with `docker info`; if Docker is missing or not running, explain how to install\u002Fstart it for my OS before continuing. Treat this checkout as a new project by default, not as a pull request back to the template: detach the original template remote unless I explicitly say I am contributing to the template, and add my own GitHub remote only if I provide one or ask you to create\u002Fpublish it. Rename package.json and other repository-specific identifiers to the chosen project name where applicable. After first-run setup is complete, delete the marked Bootstrap-Only Instructions blocks from AGENTS.md and CLAUDE.md. Use Docker Compose for local PostgreSQL on Windows, macOS, and Linux; do not require native PostgreSQL or cloud credentials for local development.\n```\n\n- First read `README.md`, `CLAUDE.md` if present, and relevant `docs\u002F*.md`, then inspect package scripts and `.env.example` files before running setup commands.\n- Inspect `git remote -v` before any branch, commit, push, or PR workflow. If `origin` points to the template repository and the user has not explicitly said they are contributing to the template, treat this as a new project and detach from the template remote with `git remote remove origin`.\n- If the user provides their own GitHub repository URL or asks to publish the new project, add that URL as the new `origin` after the template remote is removed. If the user has not chosen a destination yet, leave the repository with no `origin` and report that publishing is not configured.\n- Do not open pull requests against the template repository during first-run project setup. Ask only if the user explicitly says this checkout is for improving the template itself.\n- Ask the user a short intake in the user's language before making product or deployment choices:\n  - what project name\u002Fslug to use;\n  - what product or app they want to build first;\n  - which surfaces are active now: webapp, mobile, backend\u002FAPI, website, or full-stack;\n  - if mobile is active, whether the checkout is already on the `mobile` branch; if not, switch to `mobile` before setup;\n  - whether the first version needs accounts\u002Fauth, persistence, uploads\u002Ffiles\u002Fimages\u002Fmedia, payments, admin tools, or external integrations;\n  - whether real-time chat, presence, collaboration, live notifications, or WebSocket-style updates are needed now;\n  - whether Expo\u002FEAS builds and Maestro E2E validation are needed now when mobile is active;\n  - whether deployment is needed now, and if yes, the production domains\u002FURLs and release targets.\n- After the user answers, record durable project choices in the relevant README sections before feature work: project name\u002Fslug, active surfaces, deferred surfaces, validation scope, and what deployment\u002Frelease work is in or out of scope. Once setup is complete, remove the marked `Bootstrap-Only Instructions` blocks from `AGENTS.md` and `CLAUDE.md`.\n- If only the webapp is active, keep mobile deferred on the default branch: do not run Expo\u002FEAS\u002FMaestro setup and do not add mobile features. When the user later asks for mobile, switch to the `mobile` branch first.\n- If only the mobile app is active, keep webapp and website intact but deferred: do not add browser-only features or Playwright flows unless they support the active mobile\u002Fbackend work, and add or update a short deferred-surface note in `webapp\u002FREADME.md` or `website\u002FREADME.md` as relevant. When the user later asks for webapp, remove or rewrite that note, then set up and validate webapp normally.\n- On the `mobile` branch, keep template-level Expo\u002FEAS config universal. Do not commit an `expo.owner` or `extra.eas.projectId` to the template. In an installed project, write `expo.owner` and run EAS project init only after the user selects the real Expo personal account or organization that should own the app.\n- On the `mobile` branch, use an installed Expo development build for Maestro E2E, not Expo Go. Follow that branch's mobile README before running mobile flows.\n- Prefer README-level deferred-surface notes over source-code comments. Add code comments only when a dormant code path would otherwise mislead future work.\n- Default to local-only setup when the user does not need deployment yet. Local development must not require DigitalOcean credentials.\n- Use [docs\u002FLOCAL_DATABASE.md](docs\u002FLOCAL_DATABASE.md) and `docker-compose.yml` as the local PostgreSQL source of truth. The default local database path is Docker Compose, not a native PostgreSQL install.\n- If deployment is requested, use DigitalOcean App Platform as the supported production path. Use DigitalOcean Managed PostgreSQL for production databases; do not use App Platform dev databases for production.\n- For the default DigitalOcean production backend\u002FAPI service, start with one `apps-s-1vcpu-1gb` App Platform container (`instance_count: 1`) plus the smallest DigitalOcean Managed PostgreSQL production cluster. This keeps the initial backend and database infrastructure around $27\u002Fmonth before taxes, traffic overages, storage, and optional add-ons. `webapp` and `website` are Static Sites and do not need runtime container sizing (until a `website` route opts into SSR, which then deploys as a service).\n- Deploy `webapp` and `website` as DigitalOcean App Platform Static Sites, not App Platform services. They do not get `instance_size_slug` or `instance_count`; static site assets are served through DigitalOcean's global CDN by default. Use an external CDN only when the product needs advanced controls such as bot filtering, custom rate limiting, or geographic traffic rules.\n- For DigitalOcean app specs, use committed `.do\u002F*.yaml.example` templates plus `bun run deploy:do:specs`; generated specs stay in `.scratch\u002Fdeploy` and must fail on empty values or unresolved placeholders before `doctl apps create`. Concrete App Platform machine defaults live in `scripts\u002Fprepare-do-specs.mjs`; update that script and [docs\u002FDEPLOYMENT.md](docs\u002FDEPLOYMENT.md) together when changing infrastructure tiers.\n- Before deployment or cloud-resource updates, verify `git remote -v` and `git status --short --branch`. Deploy only from the intended pushed release branch with a clean worktree; if local changes, untracked files, or branch sync issues are present, stop instead of cleaning, stashing, resetting, or checking out over another session's work.\n- Use DigitalOcean Spaces Standard Storage plus Spaces CDN for persistent files, uploads, and public media. Do not store uploads on the App Platform container filesystem.\n- If the user explicitly chooses Yandex Cloud, use [docs\u002FYANDEX_CLOUD.md](docs\u002FYANDEX_CLOUD.md): Serverless Containers for backend\u002FAPI, Managed Service for PostgreSQL for production data, Object Storage for files\u002Fstatic sites, and Cloud CDN for public static\u002Fmedia delivery.\n- Explain manual prerequisites only for the active release path: DigitalOcean account, billing\u002Fproject setup, `doctl auth init`, registry access when using DigitalOcean Container Registry, DigitalOcean Managed PostgreSQL, and production domains\u002FDNS. Expo\u002FEAS\u002FApp Store\u002FGoogle Play setup lives on the `mobile` branch.\n- The agent may create uncommitted local `.env` files from `.env.example` and generate a local-only `JWT_SECRET`; never commit secrets or print raw secrets in the final report.\n- After setup, run the smallest meaningful validation for the chosen active surfaces and report local URLs, commands run, and anything the user still needs to authorize manually.\n\n## What's Inside\n\n- `backend` - Bun + Hono + Prisma + PostgreSQL, custom JWT auth, Zod validation, and OpenAPI output.\n- `webapp` - React + Vite + TanStack Query\u002FForm\u002FRouter CSR browser client with the baseline auth flow.\n- `website` - a separate Astro project for public SSG\u002FSSR pages (landing, content sites, marketplace).\n- `mobile\u002FREADME.md` - pointer to the runnable Expo mobile template on the `mobile` branch.\n- `packages\u002Fcontracts` - shared Zod schemas and TypeScript API types.\n- `.do` - committed DigitalOcean App Platform spec templates; generate concrete specs into `.scratch\u002Fdeploy` with `bun run deploy:do:specs`.\n- `docker-compose.yml` - local PostgreSQL 18 through the official `postgres:18-alpine` image on port `54329`; test runners use a repository-derived port by default, or `POSTGRES_TEST_PORT` when set. PostgreSQL 18 is intentional because the backend schema uses strict database-generated UUIDv7 IDs.\n- `docs\u002FTESTING.md` - the backend and Playwright testing contract. Mobile Maestro guidance lives on the `mobile` branch.\n- `docs\u002FLOCAL_DATABASE.md` - cross-platform local PostgreSQL setup for Windows, macOS, and Linux.\n- `docs\u002FSTORAGE.md` - DigitalOcean Spaces, CDN, uploads, and image\u002Fmedia storage rules.\n- `docs\u002FYANDEX_CLOUD.md` - optional Yandex Cloud deployment path when the user explicitly chooses it.\n\n## Choosing `webapp` vs `website`\n\nThis template ships two browser surfaces. Putting a feature in the wrong one is the most common early mistake, so the installing agent must pick deliberately and explain the choice in product terms the user understands.\n\n- Build it in **`website`** (Astro, static by default, SSR per route) when the pages must be **public and found by search engines or shared with rich link previews**: marketing\u002Flanding pages, content sites, blogs, docs, and the public storefront of a **marketplace** (home, category, search, and product\u002Flisting pages that Google must index). This is the SEO surface. Pages are static SSG by default; switch a single dynamic route to server-rendering with `export const prerender = false` when its data changes often or is request-specific (search results, live inventory\u002Fprices).\n- Build it in **`webapp`** (React, client-side rendered) when the screens live **behind sign-in and do not need SEO**: dashboards, account settings, authenticated tools, the seller\u002Fadmin panel of a marketplace. No crawler needs these, so CSR is the simpler, cheaper choice.\n\nRule of thumb for the agent: *if a page must rank in search or preview nicely when shared, it belongs in `website`; if it is only reachable after login, it belongs in `webapp`.* Real products often use **both** — for a marketplace, the public catalog lives in `website` and the authenticated app lives in `webapp`, and both reuse the same `@web-app-demo\u002Fcontracts` schemas. Do not rebuild SEO pages inside `webapp` to \"keep everything in one app\"; that loses the SEO the product needs.\n\n## Quick Start\n\nInstall dependencies first:\n\n```bash\nbun install\n```\n\nIf backend\u002FAPI, full-stack, or other database-backed work is active, check Docker first. Docker is the local app that runs PostgreSQL for this template:\n\n```bash\ndocker compose version\ndocker info\n```\n\nIf either command fails, install and start Docker before continuing:\n\n- Windows: install Docker Desktop, enable the WSL 2 backend, start Docker Desktop, then rerun `docker compose version` and `docker info`.\n- macOS: install and start Docker Desktop, or another Docker Engine with Compose v2, then rerun `docker compose version` and `docker info`.\n- Linux: install Docker Engine and the Docker Compose plugin, start the Docker service, then rerun `docker compose version` and `docker info`.\n\nDo not switch new users to native PostgreSQL during local setup. The repository's documented local path is Docker Compose for backend\u002FAPI work.\n\n### Backend\u002FAPI Or Full-Stack\n\nOnly run this block when backend\u002FAPI, full-stack, or DB-backed validation is active.\n\n```bash\ndocker compose pull postgres\ndocker compose up -d postgres\n```\n\nCreate the backend env file:\n\n```bash\n# macOS, Linux, or Git Bash on Windows\ncp backend\u002F.env.example backend\u002F.env\n```\n\n```powershell\n# Windows PowerShell\nCopy-Item backend\u002F.env.example backend\u002F.env\n```\n\nThen apply migrations:\n\n```bash\nbun run --cwd backend prisma:migrate\n```\n\n### Run The Active Surfaces\n\nStart only the app surfaces you need in separate terminals:\n\n```bash\nbun run dev:backend\nbun run dev:webapp\nbun run dev:website\n```\n\nWebapp-only or website-only setups can skip the backend\u002FPostgreSQL block until backend\u002FAPI becomes active.\n\nCreate `webapp\u002F.env` when the browser client should use a non-default API URL:\n\n```bash\nVITE_API_URL=http:\u002F\u002Flocalhost:3000\n```\n\nTest runners use the separate Docker Compose `postgres_test` service and the `TEST_DATABASE_URL` shape from `.env.example`\u002F`backend\u002F.env.example`. Webapp Playwright E2E starts `postgres_test`, applies migrations to `web_app_demo_test`, runs the browser flow, and tears down its test database volume by default.\n\n## Workspace Commands\n\n- `bun run dev` - start all workspace projects in parallel dev mode.\n- `bun run dev:backend` - start the backend API.\n- `bun run dev:webapp` - start the Vite CSR webapp.\n- `bun run dev:website` - start the Astro website project.\n- `bun run typecheck` - run TypeScript checks across workspaces.\n- `bun run build` - run production build\u002Ftypecheck\u002Fexport scripts for workspaces that define them.\n- `bun run test` - run contract, backend, and webapp unit\u002Fintegration tests.\n- `bun run test:contracts` - run shared Zod contract tests.\n- `bun run test:backend` - run backend unit and integration tests.\n- `bun run test:backend:integration` - run DB-backed auth tests through `postgres_test`.\n- `bun run test:webapp` - run webapp client tests.\n- `bun run deploy:do:specs` - safely generate concrete DigitalOcean specs under `.scratch\u002Fdeploy`.\n- `bun run e2e:webapp` - run the Playwright auth smoke test through backend + Vite.\n- `bun run --cwd backend prisma:migrate` - create\u002Fapply a Prisma migration in development.\n- `bun run --cwd backend prisma:deploy` - apply existing Prisma migrations on a server.\n\n## Project READMEs\n\n- [backend\u002FREADME.md](backend\u002FREADME.md) - API, auth, Prisma, and backend validation.\n- [docs\u002FLOCAL_DATABASE.md](docs\u002FLOCAL_DATABASE.md) - Docker Compose PostgreSQL setup and reset workflow.\n- [docs\u002FSTORAGE.md](docs\u002FSTORAGE.md) - DigitalOcean Spaces, CDN, uploads, and image\u002Fmedia storage rules.\n- [docs\u002FYANDEX_CLOUD.md](docs\u002FYANDEX_CLOUD.md) - optional Yandex Cloud deployment path when explicitly selected.\n- [webapp\u002FREADME.md](webapp\u002FREADME.md) - CSR browser client setup, env, and Playwright smoke.\n- [mobile\u002FREADME.md](mobile\u002FREADME.md) - pointer to the full mobile template branch.\n- [website\u002FREADME.md](website\u002FREADME.md) - Astro website commands, hybrid rendering, and publishing model.\n- [packages\u002Fcontracts\u002FREADME.md](packages\u002Fcontracts\u002FREADME.md) - shared schema and DTO rules.\n\n## Architecture Notes\n\nAPI contracts live in `packages\u002Fcontracts` and are imported by every active layer. The backend validates input with those Zod schemas, and the webapp client reuses the same schemas in TanStack Form and API calls. The `mobile` branch extends the same contract model for Expo.\n\nThe backend API flow is `route -> validation -> auth\u002Fsession guard -> service -> Prisma -> DTO`. Routes stay thin, auth business logic lives in the feature service, and API, worker, and cron entrypoints share `src\u002Fruntime.ts` for env and Prisma setup.\n\nKeep the default architecture monolithic. For DigitalOcean production, the backend\u002FAPI default is one `apps-s-1vcpu-1gb` App Platform container so a new project starts inside the expected low-cost budget with Managed PostgreSQL while retaining a clear scale-up path. Add backend worker or scheduled-job components from the same Docker image only when a concrete background or periodic task exists; the deployment generator refuses to deploy the empty worker placeholder. For real-time features, a single backend instance can own its local WebSocket connections. If the backend is horizontally scaled and users connected to different instances must receive the same chat, presence, or live events, add a managed Redis-compatible Pub\u002FSub broker between instances, using DigitalOcean Managed Valkey on the default path or Yandex Managed Service for Valkey when Yandex Cloud is explicitly selected.\n\nOngoing engineering guidance lives in [AGENTS.md](AGENTS.md), [CLAUDE.md](CLAUDE.md), [docs\u002FARCHITECTURE.md](docs\u002FARCHITECTURE.md), [docs\u002FTESTING.md](docs\u002FTESTING.md), and [docs\u002FDEPLOYMENT.md](docs\u002FDEPLOYMENT.md). First-run download and product setup instructions live in this README.\n\n## Current Upstream Documentation\n\nFor framework, API, deployment, or testing questions, consult the current upstream documentation linked here first. The repository docs describe this template's conventions; the linked docs are the authoritative source for tool behavior and provider-specific changes.\n\n- Runtime and package manager: [Bun docs](https:\u002F\u002Fbun.sh\u002Fdocs)\n- Backend framework: [Hono docs](https:\u002F\u002Fhono.dev\u002Fdocs)\n- Database ORM: [Prisma docs](https:\u002F\u002Fwww.prisma.io\u002Fdocs) and [PostgreSQL docs](https:\u002F\u002Fwww.postgresql.org\u002Fdocs\u002F)\n- Validation and contracts: [Zod docs](https:\u002F\u002Fzod.dev\u002F)\n- JWT library: [jose documentation](https:\u002F\u002Fgithub.com\u002Fpanva\u002Fjose)\n- Web stack: [React docs](https:\u002F\u002Freact.dev\u002Freference\u002Freact), [Vite guide](https:\u002F\u002Fvite.dev\u002Fguide\u002F), [TanStack Query](https:\u002F\u002Ftanstack.com\u002Fquery\u002Flatest\u002Fdocs\u002Fframework\u002Freact\u002Foverview), [TanStack Form](https:\u002F\u002Ftanstack.com\u002Fform\u002Flatest\u002Fdocs\u002Fframework\u002Freact\u002Fquick-start), and [TanStack Router](https:\u002F\u002Ftanstack.com\u002Frouter\u002Flatest\u002Fdocs\u002Foverview)\n- Testing: [Playwright docs](https:\u002F\u002Fplaywright.dev\u002Fdocs\u002Fintro)\n- Website: [Astro docs](https:\u002F\u002Fdocs.astro.build\u002Fen\u002Fgetting-started\u002F)\n- Local infrastructure: [Docker Compose docs](https:\u002F\u002Fdocs.docker.com\u002Fcompose\u002F) and [PostgreSQL Docker Official Image](https:\u002F\u002Fhub.docker.com\u002F_\u002Fpostgres)\n- Deployment and storage: [DigitalOcean App Platform](https:\u002F\u002Fdocs.digitalocean.com\u002Fproducts\u002Fapp-platform\u002F), [DigitalOcean App specs](https:\u002F\u002Fdocs.digitalocean.com\u002Fproducts\u002Fapp-platform\u002Freference\u002Fapp-spec\u002F), [DigitalOcean Static Sites](https:\u002F\u002Fdocs.digitalocean.com\u002Fproducts\u002Fapp-platform\u002Fhow-to\u002Fmanage-static-sites\u002F), [DigitalOcean Managed Databases in App Platform](https:\u002F\u002Fdocs.digitalocean.com\u002Fproducts\u002Fapp-platform\u002Fhow-to\u002Fmanage-databases\u002F), [DigitalOcean Valkey](https:\u002F\u002Fdocs.digitalocean.com\u002Fproducts\u002Fdatabases\u002Fvalkey\u002F), [DigitalOcean Dockerfile builds](https:\u002F\u002Fdocs.digitalocean.com\u002Fproducts\u002Fapp-platform\u002Freference\u002Fdockerfile\u002F), [DigitalOcean Bun buildpack](https:\u002F\u002Fdocs.digitalocean.com\u002Fproducts\u002Fapp-platform\u002Freference\u002Fbuildpacks\u002Fbun\u002F), [doctl](https:\u002F\u002Fdocs.digitalocean.com\u002Freference\u002Fdoctl\u002F), [doctl apps spec validate](https:\u002F\u002Fdocs.digitalocean.com\u002Freference\u002Fdoctl\u002Freference\u002Fapps\u002Fspec\u002Fvalidate\u002F), [DigitalOcean Container Registry](https:\u002F\u002Fdocs.digitalocean.com\u002Fproducts\u002Fcontainer-registry\u002F), [DigitalOcean Spaces](https:\u002F\u002Fdocs.digitalocean.com\u002Fproducts\u002Fspaces\u002F), [DigitalOcean Spaces CDN](https:\u002F\u002Fdocs.digitalocean.com\u002Fproducts\u002Fspaces\u002Fhow-to\u002Fenable-cdn\u002F), and [external CDN in front of App Platform](https:\u002F\u002Fdocs.digitalocean.com\u002Fproducts\u002Fapp-platform\u002Fhow-to\u002Fconfigure-external-cdn\u002F)\n- Optional Yandex Cloud path: [Yandex Cloud CLI](https:\u002F\u002Fyandex.cloud\u002Fen\u002Fdocs\u002Fcli\u002Fquickstart), [Yandex Serverless Containers](https:\u002F\u002Fyandex.cloud\u002Fen\u002Fdocs\u002Fserverless-containers\u002F), [Yandex Container Registry](https:\u002F\u002Fyandex.cloud\u002Fen\u002Fdocs\u002Fcontainer-registry\u002Fquickstart), [Yandex Managed PostgreSQL](https:\u002F\u002Fyandex.cloud\u002Fen\u002Fdocs\u002Fmanaged-postgresql\u002F), [Yandex Managed Service for Valkey](https:\u002F\u002Fyandex.cloud\u002Fen\u002Fdocs\u002Fmanaged-redis\u002F), [Yandex Object Storage static hosting](https:\u002F\u002Fyandex.cloud\u002Fen\u002Fdocs\u002Fstorage\u002Foperations\u002Fhosting\u002Fsetup), [Yandex Object Storage AWS CLI](https:\u002F\u002Fyandex.cloud\u002Fen\u002Fdocs\u002Fstorage\u002Ftools\u002Faws-cli), [Yandex Cloud CDN](https:\u002F\u002Fyandex.cloud\u002Fen\u002Fdocs\u002Fcdn\u002Fconcepts\u002F), and [Yandex Cloud Marketplace Image Resizer](https:\u002F\u002Fyandex.cloud\u002Fen\u002Fmarketplace\u002Fproducts\u002Fyc\u002Fimage-resizer)\n","Vibe Coding Template 是一个全栈开发模板，适用于Web和后端产品的快速启动。该项目采用TypeScript编写，集成了Bun\u002FHono后端、React CSR浏览器客户端、Astro SSG\u002FSSR站点以及共享API契约，并且在`mobile`分支中提供了一个可运行的Expo移动应用模板。其核心功能包括支持多平台（Web、移动、后端）同步开发，通过清晰界定不同页面类型来优化SEO效果，同时提供了详尽的初始化指南帮助开发者根据具体需求配置项目。此模板特别适合需要快速搭建具有前后端交互能力及移动端适配需求的新项目或产品原型。","2026-06-11 03:59:49","CREATED_QUERY"]