Runtime compatibility is package-specific. A package's README describing the overall ecosystem as runtime-agnostic does not mean every exported symbol can be imported into every runtime.
| Package/area | Observed considerations |
|---|---|
@veap/kernel | Some contracts and abstractions are lightweight; the server config/provider entry point is explicitly server-oriented. |
@veap/database | Uses node:async_hooks, filesystem/path APIs and Knex drivers. Treat as Node/Bun server-side code, not generic Edge code. |
@veap/auth | Uses database repositories, crypto adapters and server actions; keep service/crypto modules on the server. |
@veap/mail | Nodemailer and environment-based transport configuration are server concerns. |
@veap/storage | Local provider uses Node filesystem APIs; it requires a writable, persistent filesystem if uploads must persist. |
@veap/intl | Client hooks require React context; server helpers may read request headers/cookies through kernel contracts. |
@veap/plugins | Contains server registry/router code and React client widgets; use the appropriate subpath. |
@veap/settings | Uses database persistence and cache; it is server-side application infrastructure. |
Deployment checklist#
- Separate server and client imports.
- Verify native module support for
better-sqlite3on your platform. - Use a persistent database and object storage where serverless filesystems are ephemeral.
- Test route/request context behavior in your chosen Next.js adapter.
- Run builds with the exact production Node/Bun and Next.js versions.
- Do not rely on implicit global state across isolated workers or serverless instances.
