Instant web hosting for agents

oi is web hosting an agent can drive on its own. You give it a file or a folder; it gives back a URL that is already live. There is no build step, no server to keep running, and no dashboard you have to visit first.

It exists because the last step of agent work — show me the thing you made — used to need a human. Now the agent finishes the job.

All of them, in the sense that matters: if it can run a shell command or make an HTTP request, it can publish to oi. There is no plugin to wait for, and no vendor has to ship an integration first.

Install the hosted skill with npx skills add oimrdk/skill --skill oi -g and the agent learns the whole surface, or just point it at /llms.txt and let it read.

No. Anonymous publishing needs no sign-up at all: create, upload, finalize, and the URL is live.

Twenty-four hours later that site is deleted — the files, not just the listing — by a sweeper that runs every minute against the deadline. The URL then answers 410 Gone rather than pretending it never existed, so an agent can tell an expired link from a wrong one.

The create response includes a one-time claim link. Follow it with an account and the expiry never arrives — the same site, same URL, now permanent.

Yes, and it is the only account tier here — nothing on this deployment is sold. An account makes Sites permanent and adds version history, rollback, password and invite-only access, and up to 50 API keys.

The wider oi API contract describes paid tiers, and gates Site Data and Drives behind them. Here both are included and nothing can be charged for at all. What this deployment does not implement — custom domains, analytics, public profiles, team workspaces — is listed on the pricing page and, operation by operation, in the docs.

On oi's own infrastructure and nowhere else. Uploads go to the oi storage origin over signed, single-use URLs; the bytes land in content-addressed blob storage, identical files stored once; and a request to {slug}.oi.mrdk.io is answered by oi reading those same blobs back. No third-party content delivery network sits in front of your Sites, no external object store holds a copy, and no other provider is in the path.

The trade-off, since you will notice it eventually: one origin rather than edge locations everywhere, so how far you are from it is how fast the first byte arrives — and if it is down, Sites are down. That is what the status page is for, and it reports what the running process can actually verify rather than what someone remembered to update.

You choose, per Site. The default is a public link with an unguessable slug. You can add a password, or restrict a Site to specific verified email addresses and email domains.

Access is enforced by the server before a single byte of a gated Site is read, so a private Site cannot be reached by guessing a path or skipping the front page.

Not on this deployment. Every Site is served at its {slug} subdomain and nothing else.

The reason is specific rather than a shrug: a custom domain needs a TLS certificate issued for that exact hostname, and the proxy in front of this deployment can only answer HTTP-01 challenges for names it already knows. Connecting one would silently serve a certificate error, so the four domain endpoints answer 404 instead of pretending.

Not as shared accounts — workspaces are part of the oi API contract and are not implemented on this deployment. Every API key acts on exactly one personal account.

What does work for a team: share a Site with named people using invite-only access, which verifies each address by email before serving a single byte, and issue a separate API key per agent or tool so any one of them can be revoked alone.

Site Data gives a static page validated, access-controlled record storage it can call straight from its own JavaScript — enough for forms, polls, feedback, and shared lists — declared in a .oi/data.json manifest.

What this deployment does not have is proxy routes, the contract feature that forwards a Site path to an upstream API with the credential held server-side. A .oi/proxy.json file publishes as an ordinary static file and is never interpreted, so do not ship a key in one expecting it to be hidden.

Because nothing is built. A publish is a manifest, direct uploads, and a pointer flip — the version goes live the moment finalize returns.

Republishing is faster still: send a hash per file and oi skips everything it already has, copying those server-side instead of re-uploading. A byte-identical republish does no work at all and tells you so.

Anything static, within the file-size limit: a generated site or app, a report, a slide deck, a data visualization, a PDF, an image gallery, a prototype, a game, a single document you want a link for.

What you cannot do is run code on the server — a backend, a long-running process, a general-purpose database. Sites are files, plus Site Data for records a page needs to keep.

What you may not publish is set out in the acceptable use section: no malware, phishing, spam networks, harassment, or material that exploits minors. Reports go to the abuse page.

Read /llms.txt for the short version or /llms-full.txt for the whole context, then create a Site with POST /api/v1/publish. The OpenAPI spec describes every endpoint and /skill.md is the operating manual.

If you prefer structured discovery, start at /.well-known/agent.json or the RFC 9727 catalog.