What is ephemeral hosting?

Ephemeral hosting gives a project a public address for a fixed, short period and then deletes it. It is not a compromise version of permanent hosting. It is a different tool for a different kind of work.

Most web hosting is designed around continuity. A site is created, linked to a domain and expected to stay up indefinitely. Even small projects tend to inherit that assumption: a recurring bill, an account with a provider, an SSL certificate to renew and an owner who feels vaguely guilty when the project goes stale.

Ephemeral hosting starts from a different assumption. The site is meant to exist for a specific window: a day, an evening, a review period. At the end of that window, the files and the process are removed automatically. The deadline is part of the service, not a billing restriction.

What makes hosting “ephemeral”?

There is no single standard definition, but most ephemeral services share three properties:

1. A fixed lifetime. The project is created with an expiry timestamp. There is no indefinite renewal, or at least no expectation that the same instance will survive.
2. Automatic cleanup. Files, logs, processes and public routes are deleted when the lifetime ends. A human does not have to remember to clean up.
3. A disposable public identity. The URL may be stable within the window, but it is not meant to be a permanent canonical address for a brand or archive.

That last point matters. Ephemeral hosting is often a poor fit for a business homepage because search results, inbound links and customer bookmarks accumulate around a permanent address. It is a much better fit for a proof of concept, an internal demo or a page that is intentionally temporary.

Why would you want a site to expire?

The obvious argument is cost: a short-lived host can be tiny because it never promises to run hundreds of abandoned projects forever. But cost is only part of the appeal.

It sets a natural finish line

Side projects often die slowly. A demo lives on a VPS for three years because the owner already paid for the year, even though nobody visits it and the code no longer runs. An expiry date makes the end explicit. You can make something, share it and move on without a maintenance appendix.

It reduces the stakes

When a project is not expected to be permanent, it is easier to publish the imperfect version. That is useful for portfolio drafts, design reviews and experiments where the point is to have a conversation, not to ship a final product.

It forces a backup habit

A good ephemeral host makes it very clear that the hosted copy is not the source of truth. Your repository, notes or local folder are. That is a healthier arrangement than using a live server as the only place a project exists.

It keeps the public surface small

Every abandoned test app is still a potential security surface, a forgotten credential and a page that may eventually contradict the current version of the project. Automatic deletion keeps the internet from accumulating your old experiments.

What you give up

Being honest about the tradeoffs is more useful than a list of benefits. A service like Mayfly is not a general-purpose replacement for a real host.

• Durability. There are no backups. If the laptop fails, the work is gone before the deadline.
• Availability. One small host can sleep or reboot. There is no SLA and no promise of uptime.
• Permanence. Search engines, bookmarks and URLs do not stay useful after the box is erased.
• Privacy. Published pages are public by default. Runtime code is sandboxed to its own folder, but that is a lightweight mitigation rather than a full virtual machine, and the operator can inspect box contents.
• Scale. A 512 MB memory cap and a shared CPU are not appropriate for serious traffic or long-running jobs.

Those are not bugs to work around. They are the terms of the tool. The right question is not “can I make this last?” but “does this project actually need to last?”

Good use cases

Short-lived hosting works best when the value is concentrated in a short window:

• A portfolio or case study you are sending to a specific person this week.
• A public demo for a hackathon, workshop or classroom session.
• A small API or webhook receiver that only needs to exist during an integration test.
• A prototype you want to show on a real URL before deciding whether it deserves a permanent home.
• A temporary landing page for an event that has already ended.

If the URL needs to be printed on a business card, indexed by search engines for years or used by customers every day, use a conventional host.

How Mayfly implements the idea

Mayfly gives each project a “box” with a 24-hour hard time-to-live. A sweeper runs every 30 seconds. When the expiry passes, it stops the process tree, closes any tunnel, erases the folder and removes the record. Restarting a box does not reset its timer.

Static boxes are served through a stable Cloudflare Pages address. Runtime Python and Node boxes get a temporary public tunnel to one of their allocated localhost ports. The memory watchdog enforces a 512 MB ceiling per runtime box, and the host refuses new runtime work when free memory is low.

The result is not “free cloud hosting”. It is a constrained, personal service with a deadline. If that sounds like the right constraint for your next small idea, the static-site guide is a good next step. If you need a server process, read the runtime guide.

Use the deadline as a reason to finish, not as a reason to skip the backup.