Deleting & restoring pages

Deleting a page in tela does not destroy it. The page is moved to its space's Trash, where it stays until someone puts it back.

[!NOTE] Deleting a page also deletes its sub-pages — they are part of the page, not neighbours of it. They go to the Trash together and come back together.

Find the Trash

Open a space (click its name in the sidebar) and pick the Trash tab, next to Overview and Health. The tab shows a count when the space has anything in it.

Each row is a page someone deleted, newest first:

• when it was deleted
• how many sub-pages went with it — these are what a restore brings back alongside it
• where it used to live, so two pages with the same name are still tellable apart

Only the page the delete was aimed at gets a row. Its sub-pages are not listed separately, because restoring the parent already brings them.

Restore a page

Click Restore on its row. The page and everything that went down with it return to exactly where they were — same parent, same body, same attachments, and its links to other pages are rebuilt.

[!TIP] A sub-page you deleted on its own, before its parent went, is a separate delete — restoring the parent will not quietly undo it. It gets its own row in the Trash, and you can restore it from there.

Who sees what

In a shared space the Trash is yours, not a public record of everything the team has removed:

• You see the pages you deleted, and you can restore them. Restoring needs editor or owner, like any other change.
• A space owner sees the whole bin, with each row attributed — "deleted 2 hours ago by ayşe" — and can restore any of it.
• Someone else's delete is not yours to reverse. It isn't listed for you, and asking for it by id reads as not-there.

A row also says when a delete did not come from someone clicking Delete: via sync means a vault sync removed the file, via agent means an AI agent did it over MCP. That is usually the first clue that something automated went wrong rather than someone changing their mind.

[!NOTE] Pages deleted before tela started recording who deleted them show to space owners only — there is no way to prove whose they were.

Delete a page for good

The Trash keeps pages indefinitely — nothing ages out on its own. When you want something gone rather than recoverable, the row has an ✕ next to Restore:

• ✕ on a row destroys that page, its sub-pages, its history and its attachments.
• Empty trash, on the "Deleted pages" heading, does the same for everything you can see in the bin — your own deletes, or all of them if you own the space.

Both ask you to confirm first, because this is the one delete in tela that really is final.

[!CAUTION] There is no second bin. A purged page cannot be restored and cannot be found in page history.

Purging is scoped exactly like restoring: your own deletes, or anything in the space if you own it.

[!NOTE] Self-hosting? A deploy can age the trash out automatically by setting TELA_TRASH_RETENTION_DAYS. It is unset by default — a bin that empties itself on a timer is how you lose the page you meant to come back for.

Deleting from a synced vault

If you sync a space to files (see [[Sync with rclone]]), deleting <page>.md deletes that page — and its sub-pages, which live in the <page>/ folder beside it. They land in the Trash like any other delete, so the way back is the same.

What this is not

Restoring a page is not the same as restoring its content. If the page is still there but you want an earlier version of what it said, that is [[Page history & revision restore]] — a per-save history of the body, independent of the Trash.