Auth at the boundary
Clerk provides session state in Proxy and authorizes the user again where private data is read.
Production starterYour release deck,
Your release deck,
ready for launch.
Start with authentication, a server safe D1 connection, tested UI foundations, and automatic Vercel previews already wired together.
Your accounts, your data, and a clear path to swap any provider.
Designed for the first real commit
Database secrets stay server side
A typed D1 adapter validates credentials, parameterizes values, and checks every Cloudflare response.
Every push gets proof
GitHub runs lint, types, and tests while Vercel creates a preview for each branch.
Setup sequence
From clone to production in three deliberate moves.
- 1
Create the accounts
Claim the Clerk app, create a D1 database, and import this repository in Vercel.
- 2
Add the keys
Copy the documented variables into Vercel for preview and production environments.
- 3
Push to main
GitHub verifies the code and Vercel promotes a clean build to production.
Field notes
Questions before launch
Why does D1 use the REST API?+
D1 bindings only exist inside Cloudflare runtimes. Shipdeck runs on Vercel, so server code calls the official authenticated query endpoint.
Is the D1 token sent to the browser?+
No. The adapter is marked server only, and the token does not use a public environment variable prefix.
Are dashboard routes protected?+
Yes. The dashboard checks the authenticated Clerk user at the same boundary where it reads private state.
What happens on a feature branch?+
Vercel creates a preview deployment when the repository is connected through its Git integration.
How are schema changes applied?+
Wrangler tracks the SQL files in the migrations directory and applies pending changes to local or remote D1 databases.
Can the database move behind a Worker later?+
Yes. The D1 adapter is one boundary, so a Worker API can replace the direct REST call without rewriting the pages.
Ready on your command