Architecture, Routes, Security, and Support
Understand the starter's boundaries, public routes, security responsibilities, license, and support policy.
VibeAny uses a gradual Clean Architecture SaaS kernel. The goal is to keep framework and provider details replaceable without turning the starter into a black box.
Layer map
| Directory | Responsibility |
|---|---|
src/app | Next.js pages, route handlers, layouts, and transport assembly |
src/interfaces | HTTP, MCP, CLI, cron, and webhook protocol adapters |
src/features | UI, hooks, presentation-facing APIs, and product composition |
src/application | Use cases, ports, actor context, policies, and business orchestration |
src/entities | Pure domain types, models, and algorithms |
src/infrastructure | PostgreSQL repositories and provider adapters implementing application ports |
src/shared | Reusable UI, auth helpers, hooks, state, and utilities |
src/lib | Low-level configuration and integrations that are progressively moving behind ports |
Core dependency rules:
- Application code does not import Next.js routes, UI, Drizzle, or infrastructure implementations.
- Entities remain framework-, database-, provider-, and environment-free.
- Infrastructure implements application ports and owns external effects.
- Route handlers stay thin and translate HTTP concerns into feature or application calls.
- Provider registries are typed by capability; they are not global service locators.
Architecture tests enforce these boundaries. Add abstractions where variation, reuse, external effects, or security/accounting risk justifies them—not for every function.
Browser routes
The root route redirects to the default locale, currently English. The starter defines en, zh, and es locales.
| Route | Purpose |
|---|---|
/[locale] | Marketing home |
/[locale]/about, /features, /pricing, /contact | Marketing and conversion pages |
/[locale]/blog, /blog/[slug] | MDX blog |
/[locale]/privacy, /terms | Legal pages |
/[locale]/login, /signup | Better Auth entry pages |
/[locale]/forgot-password, /reset-password, /verify-email | Credential recovery and verification |
/[locale]/dashboard | Protected dashboard |
/[locale]/dashboard/billing, /credits, /integrations, /settings | Protected product areas |
/[locale]/dashboard/admin | Administrator surface |
/[locale]/account | Protected account settings |
/[locale]/demo/image-generator | Optional authenticated image-generation demo |
/oauth/authorize | Stable, non-localized OAuth authorization entry; internally rendered with a locale |
Authentication pages are flat locale routes. Do not link to removed /auth/login or /auth/register paths.
API routes
Next.js route groups such as (billing), (public), and (internal) organize source files but never appear in URLs.
| Route | Method and access |
|---|---|
/api/auth/[...all] | Better Auth handler |
/api/payments/checkout | POST, authenticated one-time checkout |
/api/payments/subscription/checkout | POST, authenticated subscription checkout |
/api/payments/subscription | GET, authenticated current subscription |
/api/payments/subscription/cancel | POST, authenticated period-end cancellation |
/api/payments/portal | POST, authenticated stored-provider portal |
/api/payments/confirm | POST, authenticated checkout-return confirmation |
/api/payments/webhook | POST, provider-signed system delivery |
/api/credits/balance, /history, /stats | GET, authenticated credit views |
/api/credit-packages | GET, public active catalog |
/api/storage/upload, /confirm, /delete | Authenticated storage lifecycle |
/api/generate-image | POST, authenticated and feature-gated image generation |
/api/contact | POST, public contact submission |
/api/user/profile, /password, /delete | Authenticated account operations |
/api/admin/users/*, /api/admin/credits/adjust | Administrator operations |
/api/mcp, /api/mcp/api-keys/* | MCP transport and authenticated key management |
/api/oauth/authorize, /consent, /register, /token, /revoke | OAuth authorization-server endpoints |
/api/cron/subscription-credits | GET, CRON_SECRET-authenticated system job |
The application also publishes OAuth authorization-server and protected-resource metadata under /.well-known/.
Payment provider boundary
PAYMENTS_PROVIDER=stripe|creem selects one active provider for new checkout and webhook traffic. Provider-neutral application use cases sit behind Stripe and Creem adapters. A stored subscription keeps its original provider for cancellation and portal behavior.
This makes ordinary application flows provider-transparent, but it does not make live subscription migration automatic. Customer, payment-method, subscription, and webhook ownership migration remains an external operational project.
Security baseline
The production application configures CSP, HSTS, strict-origin referrer policy, SAMEORIGIN framing, MIME sniffing protection, and a restrictive permissions policy. Better Auth uses secure cookies in production; email/password auth requires verification and hashes passwords with bcrypt cost 12. Optional Turnstile verification requires both a browser site key and a server secret.
These defaults do not replace application-specific security work. In particular, the included API rate limiter stores counters in one process and explicitly is not suitable as a distributed production control on Vercel, horizontally scaled services, or load balancers. Replace it with a shared serverless-compatible limiter before relying on it for abuse prevention.
Application owners remain responsible for:
- secret rotation and least-privilege provider credentials;
- database backups, restore testing, and migration review;
- authorization for newly added pages and APIs;
- dependency and security-update review;
- logs that avoid credentials and personal data;
- privacy, tax, payment, refund, and other legal obligations for the end product.
To report a vulnerability in the unmodified starter, email support@vibeany.io with subject [SECURITY] Vibeany Starter. Include the affected version, impact, reproducible steps, and a minimal proof of concept with credentials and unrelated customer data removed. Do not publish an unresolved vulnerability or test systems you do not own or have permission to assess.
No response or remediation SLA is promised by the repository. Security maintenance targets the latest released patch in the supported 1.0.x line; modified or older deployments may need to port a fix.
Commercial license summary
The authoritative commercial license is included with the purchased source and is qualified by the order confirmation. In summary, it grants the named licensee a non-exclusive, non-transferable, perpetual right to use and modify the acquired version and build commercial hosted end products within the purchased scope.
It does not permit publishing the starter source, placing it in a public repository, redistributing or sublicensing it as source, reselling it, using it to create a competing starter or template, removing proprietary notices, or sharing it beyond authorized users. Client work, contractors, and source delivery are allowed only when the order expressly includes that scope.
The acquired version does not require a seller activation service or phone-home mechanism. Updates, future major versions, and support are included only when the order or written offer says so. This summary is explanatory and does not replace the license or order terms.
Support boundary
Support is available only when the order confirmation or purchase-time written offer includes it. Included support covers reasonable questions about installing the unmodified starter, reproducing starter defects, and understanding documented configuration.
Unless separately agreed, support does not include custom feature development, application-specific debugging, data recovery, infrastructure operation, provider outages, third-party account configuration, or legal and compliance advice. The repository promises no response time, resolution time, update frequency, or continuing access to future releases.
Use the contact method stated in the order for an included support request. Provide the starter version, redacted logs, reproduction steps, and expected behavior. Use the private security-reporting path above for vulnerabilities rather than a general support request.
For operational diagnosis, continue with Deployment Troubleshooting.