Drop a folder

This page covers publishing a site without an account: dropping a folder on stasho.xyz/drop or posting a zip from a shell, what the 4-hour claim window means, what you get if you claim, and how an agent updates the site afterwards.

Prerequisite: none. This is the one flow that needs no wallet, no email, and no repo.

Prompt for your agent

Copy this into Claude Code, Cursor or any agent that can run shell commands. It needs no key, and the claim stays yours.

Read https://docs.stasho.xyz/guides/drop.md and publish the built site in ./dist with no
account: zip the folder's contents into a new zip file with index.html at its root, then POST it to
https://api.stasho.xyz/api/drop as the page shows. You need no key, so never ask me for a wallet
key, a seed phrase or a password. What you upload is public and cannot be taken back: upload
built files only, and stop and ask me if the folder holds anything secret. Fetch the url to
confirm it serves my site, then give me the url and the claimUrl verbatim. Tell me the claim
link expires four hours after publishing, and that I open it myself to keep the site.

What Drop is

Drop publishes a static site from a folder or a .zip. Drag it onto the page and it is live on a shareable URL in seconds, with no account and no build step.

Every drop is content-addressed: your files get a permanent fingerprint (a CID) and are served from IPFS. The same CID can be re-hosted by any IPFS-compatible host, including not ours. That is the part you keep regardless of what you do next.

Publish it

Open stasho.xyz/drop and either:

• drag a folder or a .zip file onto the drop zone, or
• click Choose a folder and pick one.

A folder is zipped in your browser before upload. Whatever you drop, index.html must sit at the top level of the folder, or at the root of the zip or inside its one top-level folder. That file is what the URL serves.

When the upload finishes you get a card with:

What a finished drop looks like. The URL is already live; the countdown is the claim window, not the site's lifetime.

The live URL	your site, already serving over HTTPS through the IPFS gateway. Share it, open it, embed it.
A countdown	how long the drop stays claimable.
Your CID	copyable, right there. This is the portable fingerprint of your files.
Claim this site	turns the drop into a project you own.

Dropping something new replaces the claim link for the previous drop in that browser, so claim one before you publish the next.

From a shell

The drop zone wraps one anonymous HTTP request, and the endpoint is public:

rm -f site.zip; (cd dist && zip -qr ../site.zip .)
curl -F artifact=@site.zip -F source=my-agent https://api.stasho.xyz/api/drop

cd dist first puts index.html at the zip root. zip adds to an existing archive, so remove the old one first: a leftover site.zip publishes files you have since deleted. The answer carries url, cid, expiresAt and claimUrl, the same live URL and claim link the card gives. Publish via API has every field, status and limit. Call it server-side: the endpoint has no browser (CORS) access.

The stasho CLI has no anonymous form. stasho create needs an agent key, and makes a site in that key's account with no claim step: see Your first deployment.

Claim it to keep it

Publishing is anonymous. Claiming is what attaches the site to you. The window is four hours.

Click Claim this site, or open the claimUrl the API gave you. If you aren't signed in, the sign-in choice appears on that same page: pick email or a wallet, then you land back on the claim form with your drop still attached.

The form asks for a project name (prefilled from the folder you dropped; a link from the API starts at my-drop) and then asks you to sign. You'll see one signature, or two the first time: one authorizes Stasho's delegate key to write on your behalf, one creates the project itself. Neither is a transaction and neither costs gas. If you signed in with email, the embedded wallet signs for you and you may not see a prompt at all.

When it completes you land on your new project's page. Claiming is free.

Whoever holds the claim link can claim the site. Its token rides the URL fragment, which isn't sent to Stasho's servers until you claim. Once you're signed in, the claim page moves the token into that browser's storage and clears it from the address bar. Until then the address bar still holds it, so don't share or screenshot that page. Google, GitHub and Apple sign-in also pass the full URL to our sign-in provider. The original link works in any browser, while a URL copied from the address bar after the move carries no token: opened in another browser, it reads "This drop isn't claimable from this browser."

If the window closes

An unclaimed drop is claimable for 4 hours, not guaranteed to disappear at 4 hours. After the window, a sweeper removes Stasho's storage record for it. The URL may keep working for a while before that happens, so treat it as gone, not as free hosting.

Two consequences worth stating plainly:

• Don't rely on an unclaimed drop. If the site matters, claim it.
• Don't drop anything secret. Dropped files are public from the moment they're published, and content that other IPFS nodes have already fetched can outlive our record of it. Removal is not deletion from the network.

If your window closed, just drop the folder again: you get a fresh URL and a fresh 4 hours.

After you claim

A claimed drop becomes a normal Stasho project with no repo behind it. From its page you can:

• Publish updates with Re-drop. Where a repo-connected project shows Redeploy, yours shows Re-drop: drag a new folder into the dialog and it publishes and becomes the new live deployment.
• Attach a custom domain. Add it in the project's Domains tab, create the DNS records it lists, and your domain serves the site over HTTPS and follows every future re-drop automatically.
• Roll back instantly. Once you've re-dropped at least once, any earlier build can be made live again by re-pointing at its CID, with no rebuild.
• Verify it on-chain. The project and its deployments are on-chain messages written under your address, readable and recoverable without us.

What a claimed drop does not get is anything that needs a repo: GitHub push-to-deploy, build settings, and environment variables all belong to a repo-connected project. You can have both; they're separate projects.

Update it from a shell

Another unkeyed POST /api/drop makes a separate site with a new URL and a new claim window. To update the claimed one, create an agent key with the publish scope on the project's Settings page, under Agent access (or under Settings → Authorizations, for all your sites), and set it as STASHO_AGENT_KEY. The site id is the part after /projects/ in the project page's URL.

npx @stasho/cli publish ./dist --site $PROJECT_ID

Or with curl:

rm -f site.zip; (cd dist && zip -qr ../site.zip .)
curl -H "Authorization: Bearer $STASHO_AGENT_KEY" -F artifact=@site.zip \
     https://api.stasho.xyz/api/agent/sites/$PROJECT_ID/publish

Each prints the new version's url, which changes with every version, and the custom domains that follow it. The CLI reference and the publish call have the rest.

Prompt for your agent

Copy this when the site is claimed and the key is set.

Read https://docs.stasho.xyz/guides/drop.md and publish the built site in ./dist as a new version
of my Stasho site <projectId>. Run stasho with npx @stasho/cli. My agent key (stasho_ak_…) is in
the STASHO_AGENT_KEY environment variable: never ask me to paste it in chat, and never write it
into a file, code or a commit. Do not POST to /api/drop: that makes a separate site. Fetch the
new url to confirm it serves the new version, then tell me the url, that it changes per
version, and which domains follow it. Read me every error, and stop on exit code 3 if the
message names something I must do.

Limits

These are operational values, not contract: they can change. They apply to an anonymous drop; a publish with a key has its own limits.

limit	value
zip size (compressed)	10 MB
extracted size	40 MB, max 1,000 files
claim window	4 hours
drops per IP	10 per hour, 20 per day
concurrent uploads per IP	1

IPv6 addresses count per /64. All IPv4 clients share one allowance for both IP limits, so a 429 over IPv4 can come from someone else's drops.

Anonymous publishing also runs against a platform-wide daily budget. If drops are paused because that budget is spent, the page says so: try again later, or sign in and import a repo instead.

What doesn't work

Static files only. HTML, CSS, JavaScript, images, fonts. Anything needing a server at request time (API routes, SSR, a database) won't run. Static output from any generator is fine: a Next.js or Astro export, a Hugo or Vite build, or a hand-written page in a folder.

Extension-less URLs and SPA deep links behave differently on an IPFS gateway than on a conventional host: /about 404s even when about.html exists, and a client-routed deep link 404s when loaded directly. This is the most common "my site is broken" report and it is not a broken deploy. See IPFS hosting quirks for the fix.

.env files. A drop is public and cannot be taken back, so a .env or .env.* file anywhere in the upload refuses the whole drop, and the error names the file. Remove it and drop again.

.git folders are left out of what gets published, at any depth. Every other dotfile, .well-known included, is published, so drop the built site rather than the project root.

Not signing up?

That's a real option, not a punishment. Copy the CID from the success card before you close the tab, or from the API's answer: any IPFS-compatible host or pinning service can serve those exact files from it. The deploy is yours either way, because content addressing is what makes that true.

Working with an agent

An agent can publish a drop on its own: no key, no account, one request. It can also update a claimed site with a publish key. If you already hold a key with create, it does better to create a site: the site lands in your account with no claim window.

An agent cannot claim for you. A claim ends in your sign-in and, on a wallet, your signature, in your browser, and no API takes its place.

What the agent hands you, in these words:

Open this link in your browser within four hours: <claimUrl>. Sign in with email or a wallet
when the page asks. Check the project name, click Claim this site, and approve the signature
if your wallet asks (one, or two the first time; neither costs gas). Anyone holding this link
can claim the site, so do not post it publicly. When your project page opens, paste me its URL.

How the agent verifies it afterwards. Before the claim, the gateway URL is the proof:

curl -s -o /dev/null -w '%{http_code}\n' "$URL"

After the claim, the project URL you paste carries the site id. With a publish key, stasho site $PROJECT_ID prints the site's url and its latest version's status. With no key, the public audit endpoint counts your projects, using the address under Settings → Account, and the count rises by one. It is cached for 30 seconds, and the endpoint takes one request a second, so a miss right after the claim is not a failure:

curl -s https://api.stasho.xyz/api/audit/$ADDRESS | jq .backendView.cachedProjects