Publish on your Lovable website
Install the Blogged receiver in a compatible Lovable app, connect it securely, and publish approved articles on your own website.
Blogged manages your article workflow. A small receiver installed in your Lovable app stores the approved copy, copies its images, and serves the article on your website. After that initial installation, publishing articles updates content; you do not need another Lovable prompt or an app rebuild for every article.
Check compatibility
The first release requires server-rendered blog pages and a backend with durable storage. Current TanStack Start apps can use the native receiver route. Older Vite-only apps need a separate compatibility review: their normal HTTP response may contain only an app shell, which cannot pass Blogged's publication check. The installation instructions stop instead of migrating an existing app.
Your Lovable app's backend must have enough capacity for the copied content. Hosting, database storage, backups and Lovable usage remain your responsibility. The starter stores image bytes in its own PostgreSQL tables; it supports up to 20 raster images per article, each up to 5 MiB.
Install and connect
- In Integrations, choose Connect a destination → Lovable. Copy the setup instructions into your existing Lovable project. The instructions link to the versioned source attachment. You can also download the receiver ZIP.
- Have Lovable install the package while preserving existing routes, data, authentication, forms and styling. If a blog already exists at the chosen path, stop and decide how the two should coexist before installing.
- In the Blogged form, choose Generate setup secret, then Copy secret.
Add the same value as
BLOGGED_SIGNING_SECRETthrough Lovable's backend secrets form. Never paste it into chat or frontend code. Keep a secure copy; closing the unsaved form loses this locally generated value. - Configure the Project ID shown in Blogged as
BLOGGED_PROJECT_ID, your public blog URL asBLOGGED_PUBLIC_BLOG_URL, and the actual deployed receiver URL asBLOGGED_RECEIVER_URL. The backend service-role key stays server-only. - Use the hostname shown in Lovable’s Publish panel for both URL settings;
do not assume a project-ID hostname. Publish the app, then fill in the connection name, public blog URL and
receiver URL in Blogged. Keep the same signing secret and choose Verify
connection. A native endpoint normally ends in
/api/public/blogged-receiver; use the actual URL reported by the installation. - When the connection is ready, explicitly select it as the full-article destination and save routing for new articles. Keep the default Blogged summary and link if desired. Older articles keep their existing ownership.
Lovable setup uses the existing Signed webhook transport, which is how the saved connection is identified. Give it a clear name such as “Lovable website.” You do not need to register a Lovable OAuth app or grant Blogged access to your whole Lovable account.
How publishing and updates work
The receiver saves incoming work durably before acknowledging it. It copies and checks image bytes, publishes one approved revision, then sends a signed receipt. Blogged independently checks the real public article before reporting it live. A successful connection check is not a promise that every future delivery will succeed if hosting, credentials or routes change.
Autosaving an edit in Blogged does not silently update Lovable. Use the existing saved-version review and publish-update action. The supplied receiver has no separate CMS editor. Direct edits to its managed database rows require revision tracking; use the supported Blogged workflow instead.
Unpublish removes the article and its sitemap entry, and stops serving images that are no longer referenced by a published article. Previously downloaded copies cannot be recalled. Preserve delivery records and withdrawal tombstones so old requests cannot bring content back.
Troubleshooting
| Problem | What to check |
|---|---|
| Connection refused | Same Project ID and signing secret on both sides; actual deployed receiver URL; complete backend settings. |
| App shell or page not ready | Server-rendered blog routes are installed and published. Do not weaken verification or silently migrate a Vite app. |
| Native background hook unavailable | The deployed server must provide the real request waitUntil. Do not replace it with untracked asynchronous work. |
| Image or delivery retry | Backend capacity, execution logs and network availability. Completed copies are reused; repeated failure needs operator attention. |
| Page loads but verification fails | The configured public path must render the full approved content, title and durable images. Check custom templates and caches. |
| Project or public URL changed | The receiver binds its installation to both. Plan a migration or separate installation; reconnecting must not silently repoint it. |
New TanStack Cloud projects use native server routes and do not allow creating new Edge Functions. The package also contains an optional entry point for separately supported Supabase Edge deployments; it is not a workaround for that restriction. See the package README for runtime limits, retention and installation details.
For credential rotation, update the backend secret and use Reconnect in Blogged with the same new value. Resolve or withdraw managed deliveries before disconnecting. Removing the receiver or deleting customer content is a separate, deliberate operation after backup.
Return to publishing and updates or troubleshooting.