Skip to main content
Reactive Resume ships as a Docker image and as a Vercel project. The Vercel Compatibility workflow (.github/workflows/vercel.yml) catches problems that only show up in a deployed build. It has two jobs: an offline artifact build that runs on every pull request, and a live smoke test you start by hand. You can run the same smoke test against your own installation.

​
Artifact build

The artifact job runs on every pull request, every push to main, and every manual run. It needs no Vercel account and no secrets, so pull requests from forks run it safely. The job:
  1. Starts an isolated PostgreSQL service.
  2. Writes a local .vercel/project.json with the services framework, then runs vercel build --prod --standalone offline with placeholder Blob credentials. Vercel packages dependencies into the Function output; the build applies migrations to the isolated database.
  3. Checks the backend service Function:
    • its runtime is nodejs24.x, maxDuration is 300, and its handler is apps/server/vercel.mjs;
    • a copy of the Function outside the checkout loads with --no-experimental-require-module, like the Vercel runtime does, so a dependency the build left out fails the job;
    • the copy rejects an unauthenticated upload-staging request with 401 and serves the prerendered homepage with its JSON-LD metadata.

​
When the loading check fails

If a new server dependency breaks the loading check, add it and its own dependencies to bundledInteropPackages in apps/server/tsdown.config.ts. CommonJS dependencies need this, because Vercel’s service builder leaves out the pnpm links they load through.

​
Live smoke test

The live-smoke job runs only when you start the workflow manually (workflow_dispatch). It uses the vercel-smoke GitHub environment and runs tooling/deployment/smoke.mjs against the installation at VERCEL_SMOKE_URL.
Point the smoke test only at a dedicated test installation. It signs up a new account, publishes a resume, and uploads files, then deletes the account and everything in it.
The script checks, in order:
  1. /api/health reports healthy, and /, /auth/login, /robots.txt, /sitemap.xml, and /.well-known/oauth-protected-resource respond. A missing asset returns 404.
  2. An email sign-up creates a session.
  3. A resume created from sample data can be read back and made public, and its public page and server-rendered public PDF load.
  4. A 10 MiB file uploads, downloads intact, and is deleted. On Vercel the upload goes through a staged request, and the script checks that a staged request can’t be replayed.
  5. Optionally, a 25 MiB assistant attachment uploads and is deleted (see below).
  6. The account is deleted, even if an earlier check failed.
The installation must allow sign-ups and email sign-in, so FLAG_DISABLE_SIGNUPS and FLAG_DISABLE_EMAIL_AUTH must not be true.

​
Attachment check

To include the 25 MiB attachment check, configure an OpenAI-compatible test provider that answers a connection test for the model smoke-model. No paid AI model is needed; a deterministic stub works. The installation needs ENCRYPTION_SECRET set to save the provider. A provider on a private or http:// address also needs FLAG_ALLOW_UNSAFE_AI_BASE_URL=true, which is only safe on an isolated test installation.

​
Run the smoke test yourself

The script needs only Node.js 24 and a checkout. Set SMOKE_URL to the installation’s origin:
Add SMOKE_AI_BASE_URL and SMOKE_AI_API_KEY to include the attachment check. The script detects the platform on its own: on Docker, the staging endpoint returns 404 and uploads go directly to the server.