A Bolt server function receives every article — set up by one prompt.
Bolt.new has no blog API, but Bolt Cloud runs its backend on Supabase, where server functions can take incoming requests. DraftSEO’s prompt has Bolt deploy one that verifies each delivery and writes it to Bolt Database, while routes inside your app display the posts. Delivery is hands-off; the pages, though, are client-rendered, so search engines have to run JavaScript to read them.
| Connection | One prompt in your Bolt project chat — secrets go under the database icon → Secrets, not into the chat |
|---|---|
| Receiver | Server function on supabase.co — must be deployed with JWT verification off, or Supabase answers 401 first |
| Posts and images | Bolt Database + a public storage bucket — images are downloaded and re-hosted on receipt |
| Secret changes | No redeploy required — server functions pick up Secrets without redeploying |
| SEO | Client-rendered /blog pages — crawlers must run JavaScript; SEO Boost prerendering helps where your plan offers it |
Who does what
Paste the prompt into Bolt, publish the site, add DRAFTSEO_WEBHOOK_SECRET and SITE_URL under Secrets, and pass the test delivery. Articles then arrive without per-post work — switch on SEO Boost too if your plan includes it.
Bolt deploys the function once; DraftSEO does the writing.
Setup
Copy the prompt written for Bolt Cloud’s server functions.
~30 seconds
Bolt deploys a draftseo-webhook server function with JWT verification off, a posts table in Bolt Database and /blog routes in your app. Publish, and use Update after every later change.
~a few minutes
Paste the function’s supabase.co address into DraftSEO and pick your site in the Site field, then add DRAFTSEO_WEBHOOK_SECRET and SITE_URL under the database icon → Secrets.
~2 minutes
Fire the test from DraftSEO; a green delivery shows the function accepted the signature — no redeploy needed after saving Secrets.
~1 minute
Each new article is saved to Bolt Database and listed on your app’s /blog.
Ongoing · zero clicks
FAQ
Bolt Cloud’s backend is Supabase, which runs server functions. The prompt has Bolt build one that checks DraftSEO’s signature and writes each article into Bolt Database; the /blog routes in your app then read the published posts from there.
Bolt serves your app as a client-rendered site, so a search engine has to run JavaScript before it sees an article’s text. Turn on Bolt’s SEO Boost, which prerenders HTML, if your plan offers it. Each page still takes its title and meta description from the post, but a server function cannot return HTML pages, so the blog is not server-rendered.
Bolt’s server functions run on your project’s supabase.co address, not on bolt.host or your custom domain — that is expected. Paste the function URL, choose your site in the Site field, and set SITE_URL so the function can reply with each post’s public address, which DraftSEO needs for internal linking, the per-article Search Console panel and the Backlink Exchange.
With verification on, Supabase rejects any call that lacks a Supabase JWT — DraftSEO’s included — with a 401 before your code runs, and Bolt’s own troubleshooting guidance says the same about webhooks. The function’s HMAC check, with its five-minute replay window, protects the endpoint instead.
No card required. Bolt runs the receiver; DraftSEO supplies every post.