Publish a static site in a day.

A public URL should be the easy part. This guide takes a folder of HTML, CSS and assets through the last mile: a local preview, sensible relative paths, a clean upload and a quick check from the outside.

What you need before you start

A static site is a set of files that the browser can read without a server-side language. You do not need a build step, a database or a framework. You do need the files in the shape the browser expects:

• An index.html at the top level. This becomes the page served at your public URL.
• Any CSS, JavaScript, fonts or images referenced by that page.
• A folder structure that matches the links between the files.
• A local copy you can keep after the hosted box expires.

If you use a site generator or a front-end build tool, run its build command first. Upload the built output, not the source folder with templates, dependencies and a node_modules directory.

Start with a boring folder structure

A small site is easiest to publish when it looks like this:

my-site/
├── index.html
├── style.css
├── script.js
└── assets/
    ├── portrait.jpg
    └── logo.svg

There is no rule forcing this layout, but it keeps the mental model simple. When you reference a file, the path in your HTML must resolve relative to the page doing the referencing.

Prefer paths like assets/portrait.jpg or ./assets/portrait.jpg inside a top-level page. Avoid C:\Users\you\Desktop\..., /Users/you/... or any absolute local path. The public host cannot see your desktop. Absolute paths beginning with a single slash are also a problem if the site is mounted under a subfolder such as /s/my-site/.

Preview it locally before uploading

Opening index.html directly from the filesystem works for a very simple page, but some browser behaviour changes when a file is loaded over HTTP. JavaScript modules, fetch requests and some font loading can fail with a file:// URL. A tiny local web server is a better preview.

If Python is installed, run this from the folder that contains index.html:

python -m http.server 8000

Then open http://localhost:8000 in a browser. If you are using Node, any small static server works; the point is to serve the folder over HTTP, not to add a new build system.

While previewing, click every internal link and open every image. Check the browser console for missing files. It is much easier to fix a broken path on your own machine than to hunt for it after the box is public.

Decide what the page is for

A public URL does not make an empty page useful. Before uploading, make sure the page answers a few basic questions: what is this, who made it, what should a visitor do next and how can they get in touch if they need to?

For a portfolio, that may mean a short introduction, two or three project links and a contact method. For an event page, it may mean a date, location, schedule and a clear note about whether registration is still open. For a demo, it might be a single interactive screen plus a short explanation of the idea.

Remove placeholder text, unfinished menu items and links that go nowhere. A small page that is complete is much better than a large page that looks broken. This is especially true when the site has a 24-hour lifespan: visitors should be able to understand it on the first try.

Create the box and upload

After your account is approved, create a static box in the dashboard. Give it a short, recognisable name. The box receives a slug, and the public address looks like /s/your-slug/.

Open the box, use the files tab and upload index.html and the rest of the folder contents. Keep the same relative structure you tested locally. If you upload a nested folder, the paths inside your HTML need to match that nested structure.

Static boxes are served directly. There is no process, no port and no tunnel to wait for. Once the files are in place, the public link should load the page immediately.

Check the public page like a stranger

Open the public URL in a private browser window, not the one where you are signed in. That catches a surprising number of issues:

• Do the CSS and images load from the public URL, not from a cached local preview?
• Do internal links point to files that exist inside the box?
• Does the page work at a narrow phone width?
• Is there any private information in the HTML, comments, filenames or image metadata?
• Can a visitor tell what the page is and how to reach you?

Static HTML on Mayfly is served with a sandboxed content security policy and an opaque origin. That protects the control panel, but it also means the page cannot read cookies from this site or assume it shares an origin with another Mayfly page. Keep each box self-contained.

Plan for the deadline

The 24-hour timer starts when the box is created, not when you finish uploading. Do the content work before you create the box if you need the full window for sharing.

Keep the source files in your own folder or repository. The hosted copy is not a backup. When the box expires, the files are erased; restarting the box does not reset the clock. If you need to show the same site again later, you will create a new box and upload the source again.

If the page needs to survive beyond the day, this is the point to move it to a conventional host. Ephemeral hosting is a good test drive, not a long-term archive.

A deadline is a useful design constraint as long as you do not mistake the hosted copy for the source of truth.