|
Some checks failed
DB migration compat / Check if migrations changed (push) Has been cancelled
DB migration compat / Back-compat — Current branch migrations with ${{ needs.check-migrations-changed.outputs.base_branch }} branch code (push) Has been cancelled
DB migration compat / Forward-compat — Current branch code with ${{ needs.check-migrations-changed.outputs.base_branch }} branch migrations (push) Has been cancelled
DB migration compat / No migration changes (skipped) (push) Has been cancelled
## Summary - use Vercel's native Elysia framework support with `src/index.ts` as the deployment entrypoint - remove the manual `api/` entrypoints and all `vercel.json` rewrites - continue loading the prebuilt `dist/vercel.mjs` bundle so the backend's existing tsdown bundling remains unchanged - keep API-version migration paths internal instead of exposing them through `x-middleware-rewrite` - add integration coverage for the migration branch's global Elysia error boundary and sanitized 500 response - inherit the Vercel project's 800-second maximum duration for every backend route ## Why The staging deployment timed out every request at the configured 60-second function limit. The serverless entrypoint returned a Web `Response` from a default-exported function, but Vercel interpreted that export shape as the legacy Node `(request, response)` handler contract and waited for the unused response object to be ended. The Elysia migration also exposed the internal API-version migration destination through `x-middleware-rewrite`. That header was internal Next.js routing state and was not exposed by the previous production transport. Consolidating the backend into one function initially hardcoded a 60-second duration. That was especially significant for the external DB sync poller and sequencer, whose normal work loops allow up to 180 seconds. The Vercel project is already configured with an 800-second maximum, so the backend now inherits that setting directly instead of maintaining route-specific wrapper files. Vercel's native Elysia builder recognizes `src/index.ts` when it contains a direct `elysia` import, and automatically routes requests to that application. This makes the manual catch-all rewrite and root `api/` directory unnecessary. ## Production behavior - Vercel requests are routed directly to the Elysia application through the native Elysia builder. - API migration routes retain their public URL without revealing internal migration paths. - Uncaught middleware or dispatch errors are captured by the global boundary and return a generic `500 Internal Server Error` with the global security headers. - All external DB sync endpoints—`fusebox`, `poller`, `sequencer`, `status`, and `sync-engine`—inherit the project's 800-second function duration. - GitHub config `apply`, `commit`, and `cancel` also inherit 800 seconds. This raises the previous 120-second `commit` and 60-second `cancel` maximums; normal successful behavior is unchanged, but a stuck invocation can run and be billed for longer before Vercel terminates it. ## Tradeoffs The function-duration policy is now controlled in one place—the Vercel project—rather than split between dashboard configuration and route wrappers. This is simpler and ensures long-running backend routes have enough time, but changing the project setting affects every endpoint. The native entrypoint remains a thin wrapper around the tsdown-generated bundle rather than asking Vercel to bundle the backend source graph. This preserves the existing alias and dependency bundling behavior while still using Vercel's native Elysia routing. The remaining lower-priority Elysia migration compatibility items are intentionally deferred to follow-up PRs. ## Validation - `pnpm test run apps/backend/src/server/app.ts` — 2 tests passed - focused TypeScript check for the native entrypoint and bundle declaration - the installed Vercel Elysia builder identifies `src/index.ts` as the application entrypoint - `pnpm test run apps/e2e/tests/backend/endpoints/api/migration-tests.test.ts` against the running local backend — 13 tests passed - live browser and raw HTTP checks confirmed a migrated route returns 200 and does not expose `x-middleware-rewrite` - backend build not run locally, per repository policy |
||
|---|---|---|
| .agents/skills | ||
| .changeset | ||
| .claude | ||
| .cursor | ||
| .devcontainer | ||
| .github | ||
| .vscode | ||
| apps | ||
| configs | ||
| docker | ||
| docs | ||
| docs-mintlify | ||
| examples | ||
| packages | ||
| patches | ||
| scripts | ||
| sdks | ||
| skills/hexclave | ||
| .dockerignore | ||
| .gitignore | ||
| .gitmodules | ||
| AGENTS.md | ||
| CHANGELOG.md | ||
| CLAUDE.md | ||
| CONTRIBUTING.md | ||
| LICENSE | ||
| package.json | ||
| pnpm-lock.yaml | ||
| pnpm-workspace.yaml | ||
| README.md | ||
| skills-lock.json | ||
| turbo.json | ||
| vitest.shared.ts | ||
| vitest.workspace.ts | ||
Hexclave
The user infrastructure platform.
Hexclave handles everything around your users: authentication, teams, payments, emails, analytics, and much more. Start in minutes on the hosted cloud. Your data is always yours to export and self-host.
Get started
Setting up Hexclave is one prompt. Paste this into your coding agent of choice:
Read skill.hexclave.com and help me setup hexclave in this project
For AI agents
If you're an AI coding agent, use your web fetch tool or curl the skill documentation for up-to-date integration instructions:
curl -sSL "https://skill.hexclave.com?question=<your-question>&context=<your-context>"
What's included
Hexclave ships as a catalog of apps you switch on as your product needs them. Each one is built on the same user model, and new apps land regularly.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Contributing
Hexclave is open source, and contributions are welcome. Read
CONTRIBUTING.md to get started, and say hello in
Discord before picking up anything large.
Found a security issue? Email security@hexclave.com.










