A scheduled self-destruct retires a shared link on a date you set at upload — no reminder, no manual deletion. Here's why scheduling beats deleting by hand, how to pick the date, and what the viewer sees when the link retires.
A scheduled self-destruct is the difference between a link you have to remember and a link that remembers for you. You set a date the moment you create it. On that day, the URL stops resolving and the file behind it is removed — no action from you, no calendar nudge six weeks later asking whether that client preview is still live. The decision and its execution are separated in time: you make the call now, while the context is fresh, and the schedule carries it out later, when you've long since moved on.
That separation is the whole feature. Deleting a link manually requires two things to line up — that you remember it exists, and that you remember why it should go. By the time both are true, usually neither is. A scheduled date collapses the problem: you encode the "why" as a date at the only moment you reliably hold it, the moment of upload. Everything after that is the clock's job.
Think of it like a parking meter, not a sticky note. A sticky note says "take this down eventually" and waits for you. A meter counts down on its own and acts when it hits zero, whether you're paying attention or not. A scheduled self-destruct is the meter. When the clock passes the date you set, three things happen at once: the URL stops serving the content, the visitor sees an ended page instead of your work, and the underlying file is cleared from storage. Nothing waits in a dashboard for you to notice it.
This matters because the failure mode of sharing isn't usually a leak — it's drift. The pricing you sent in March is still live in June at the same URL, and someone forwards it. The "final" deck is one of four live links and the recipient opens the wrong one. The lead magnet from a campaign that ended is still collecting traffic with copy you'd no longer stand behind. Each of those is a link that should have retired on a date nobody scheduled. The fix isn't more diligence later; it's a date set earlier.
The reason to schedule — rather than plan to delete by hand — is that the right moment to decide is the moment you create the link, and it never comes back. Right then, you know exactly what the link is for and roughly when that purpose ends. A few patterns make the date obvious:
A single-pass review. You're sending a draft, prototype, or proof for one round of feedback. The reply comes, the link's job is done, and a scheduled fuse means the old version can't be re-opened next week after you've shipped a newer one. This is the everyday case for sending a vibe-coded app as a private link mid-iteration — schedule each version to retire as the next one goes out.
A number with a validity window. Quotes, proposals, rate cards, quarterly figures. The number is true as of a date, so schedule the link to retire when that date plus a small grace period passes — and you've set it before an old quote becomes an awkward conversation.
An event or season. An RSVP page, a launch microsite, a webinar registration. The thing it's about will happen and then be over; schedule the link to retire roughly when the event does, generous enough for stragglers.
Something you don't want re-surfacing. A scheduled date is a privacy control as much as a housekeeping one — it bounds how long the unguessable URL exists, not just who you sent it to. Set it at upload and the clock enforces it for you.
If you can name the day the link stops being useful, you already know the date to schedule — see how the right window matches the engagement for tuning the exact length.
A scheduled fuse on the wrong content is its own mistake. Some links are standing references, and those want the opposite setting:
On miinideck, permanence is a paid choice on purpose. Anonymous and Free links self-destruct after 7 days, and a Free account also keeps one always-on slot for the single thing that should last. Solo and Studio drop the forced expiry, so any link can be scheduled to "never" or to a custom date you choose. You're not paying to make a link private — privacy is free on every tier. You're paying to own how long it lasts.
The flow is one decision at upload time. You drop your self-contained HTML or ZIP, and before you copy the link you pick the window: a duration (7 days, 30 days) or a specific calendar date. From then on, the rule lives with the link.
When the date arrives, a visitor doesn't get a broken browser error. They get an ended page that says the link is no longer available. On Studio, that page can wear your brand instead of a generic notice — a redirect to your product page after a launch, or a short note after a client engagement closes. The last impression of a retired link is still an impression; white-label expiry makes it yours.
One honest boundary worth naming: a scheduled self-destruct governs a static page — your HTML and assets, frozen at upload. It is not a kill-switch on a running backend. If your link points to something with a live server or database — a logged-in app, a form that writes to a table — that lifecycle lives wherever the backend lives (a Vercel or Netlify deploy), and you'd retire it there. miinideck owns the static slice cleanly: a self-contained file, served until a date you scheduled, then gone. For the everyday case — a draft, a proof, a proposal, a microsite — that static slice is the whole job.
Schedule the self-destruct at upload, while you still know why the link exists. If you can name the day it stops being useful, that's the date. For standing references, schedule "never" instead — the point isn't to delete everything, it's to let the calendar execute the decision you'd otherwise forget.
Most expiry windows get set by guess — 7 days because that's the default, 'never' because that's reversible. The actual fit comes from matching the window to what the content references.
Every lever a private link gives you — expiry, password, searchable opt-in, custom domain, white-label, analytics — what each one is for, and which are free versus paid.
Every free tier has a wall somewhere. On a private-link host the wall is not storage — it is time, and how many links you are allowed to keep. Here is exactly where each limit sits, what happens on day 8, and the three situations where free genuinely never runs out.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.