Help users discover what you ship

Ding puts product updates inside the app people already use. Your team writes and publishes an announcement in a private dashboard; your users read it in a bell, a banner, or both.

Choose your starting point

How the parts fit together

1. Your Ding instance serves a private publishing dashboard, the public widget script and its API. You operate it on a server/container host with persistent SQLite storage.
2. Your app loads /widget.js from that instance. The script fetches published updates and displays them to visitors; visitors do not install Ding or need an account.
3. Your team publishes, edits or unpublishes updates in the dashboard. Existing pages refresh their feed while visible.

You host one service for your product, not one service per visitor. A static marketing website can link to Ding, but it cannot run the backend. If you use a temporary host to test an installation, you can remove it after the rehearsal; your actual product instance needs to keep running to deliver announcements.

What is available

Drafts, tags, Markdown previews, published updates, search/filtering, aggregate analytics and the bell/banner widget are implemented. The widget works with HTML, Next.js, React, Svelte, Vue, Angular and other browser apps through a script include.

Announcements and aggregate analytics stay on your infrastructure. Read/unread state stays in the visitor’s browser. The widget does not send analytics to an external service; the private admin dashboard uses a session cookie.

Ding currently has one shared admin login and an embedded SQLite database. Public changelog pages, scheduling, RSS, API tokens and a managed Ding Cloud service are not available yet. For release availability, check GitHub Releases; the installation guide includes a source-build path when no release is published.

After installation

Back up the database before an upgrade and verify a restore separately. Use configuration for environment variables and the API reference for exact response shapes.