Where your content lives, how to get it out, and what we commit to if Duggie ever shuts down.
Effective August 18, 2026
If you build a site for a client and put its content here, you are asking that client to depend on a service you do not run. It is a fair question to ask what happens to their site if we stop, and you should not have to take our word for the answer. Most of this page describes things you can check for yourself today.
Every published asset in a project is retrievable right now, as JSON, from the same public API that serves your live site. It is the endpoint your site already calls on every page load, and the key you already hold is the one that reads it. There is no separate export to request and nothing to wait for.
That means the content behind a site you have handed off is never locked inside an interface. It is a normal HTTP request returning a normal JSON document, and anything that can read JSON can read it. Our API reference shows the exact call.
That includes the files. Image and document assets come back as URLs in that same response, and for an image that includes the file at the resolution it was uploaded, under original, alongside the resized variants. A script that walks the API can save every file, not just the text. The Secret key reaches unpublished drafts the same way.
A project can be transferred to the person who owns the site. They accept it from their own account, which needs a verified email address and has to already be a member of the project. The site keeps serving throughout: no downtime, no key rotation, nothing to reconnect. You can stay on as an admin so you can still help, or leave entirely.
Once the recipient accepts, the transfer is final. We never move projects between accounts ourselves, so if you both change your minds, the new owner transfers it back the same way. An offer that has not been accepted can be withdrawn, and lapses on its own after 7 days, so an offer sent by mistake is not a transfer. Section 12 of our Terms of Service is the binding version.
Billing does not travel with the project, so it is worth settling before you start. A project on a paid slot needs an open paid slot on the new owner's account to move into, and from then on that slot is theirs to pay for. The slot it leaves behind stays on your account, free for another project, until you give it back. A project on free limits needs only room in the new owner's free allowance. Either way, the app checks before the offer is sent and tells you what is missing.
This matters for continuity as much as for billing. A client whose project is in their own account is not depending on your relationship with us, or on you still being reachable in three years. It also keeps them clear of anything that happens to your account: if an account is ever suspended, the projects it owns stop serving until that is resolved, while projects owned by other accounts carry on untouched. Section 10 of our Terms of Service says exactly what a suspension does. A project we have blocked cannot be transferred until the block is lifted.
When a paid project slot ends, whether it was canceled, a payment could not be collected, or a complimentary slot ran out, the project it was holding moves back to free limits rather than being switched off. It keeps serving content, on the smaller allowances. If the project already holds more than the free limits allow, everything in it keeps serving and stays editable; only adding new assets is blocked until it is back under the limit or on a paid slot again. A project is only archived when there is no free place left for it to occupy. An archived project does stop serving, and unarchiving it restores the same API keys, so nothing needs reconnecting.
The account owner is emailed first, with the name of the project and what will happen to it. For a canceled or complimentary slot the email gives the date. For a failed payment it cannot, because the retry schedule is Stripe's rather than ours, so it says what is at risk and that updating the card is enough. A second email says what happened once it has.
We will email every account owner at least 90 days before the Service stops. For the whole of that period everything keeps working as it does today: your projects stay published, your API keys stay valid, and your content stays retrievable through the public API.
This is a term of the agreement rather than a statement of intent. It is written into section 6 of our Terms of Service, which is the binding version of it.
We would rather be exact than reassuring, so it is worth being clear about the edges of this. We do not commit to a guaranteed uptime level, and we do not currently publish a self-hostable version of the delivery API. If Duggie ended, your content would be yours and retrievable, but you would need somewhere else to serve it from.
The export is the current content of each asset, published or draft. Version history lives in the app, is capped per asset, and is not part of it. If a past version matters, restore it or copy it out while it is still there.
If that changes we will say so here. If you are weighing this up for a particular client and want to talk it through, get in touch.