Simple Host for companies

Give every employee a place to build.

Simple Host is an open-source server. An employee describes a page to their AI agent, the agent publishes it, and anyone with the link can open it.

A page is plain HTML with a small data store attached. That is what my manager's project board is, and it is enough for the sign-up forms, polls and short guides I see colleagues make. Nobody has to stand up a backend first.

Source on GitHub Try it on simple-host.app

01.

Where this came from

In spring 2026 I ran a two-hour AI workshop at work. It was remote, at eight on a Monday morning, and I wanted people to have somewhere to keep going after the call ended. So I put up an internal copy of this: a place where you could describe a page to an AI agent, see it live, change it, and send the link to a colleague.

By September 2026 that instance had passed a hundred accounts, most of them people who do not write code for a living. My manager runs his project board on it. The page he built pulls tickets from Jira, draws the timeline, and is the screen we look at in the daily standup. A programme manager tracks a cross-team project on it so he can see who is waiting on whom.

The server that runs all of it is a 1 CPU, 1 GB box and costs $5 a month.

I think everyone carries an idea that only they can see. Give them a canvas and a patient collaborator and most of them will build it. The agent is the collaborator. This is the canvas.

02.

Why it is this simple

Agents already write HTML, and they can read and write a JSON document without a schema. Simple Host serves the first and stores the second.

Each site gets a folder of files, one JSON document of up to 1 MB, and append-only collections whose items are up to 64 KB each. A page reads and writes that data from the browser. Every deploy is versioned, so an earlier version of the files is one rollback away. Saved data is not versioned.

Cloudflare, Firebase and Supabase all do pieces of this. They still need a developer to connect the pieces. Here an agent with the Website Deploy skill does it from "make a page where the team can vote on lunch".

Per person

One account, one API key, sign-in by emailed code or Google. A site can be hidden from the person's profile listing; the link still works for anyone who has it. Up to 100 sites per account.

The agent

Claude Code, Codex, Cursor and Copilot install the Website Deploy skill once. After that the person says "put this online".

The server

One Go binary, one Postgres, one folder of files, behind nginx. MIT licence.

Traffic

Each owner sees views and unique visitors per site, split into people, bots and monitoring, with countries. It comes from the web server's log; the analytics add no script to any page.

03.

Running it inside your company

One script on a fresh Ubuntu server installs everything: the binary, Postgres and a web server that obtains its own HTTPS certificates. It has been run end to end, from an empty machine to a working instance. Re-running it after a failure is safe. The container image is published for both Intel and ARM, so nothing is ever compiled on your server.

Sign-in. An emailed code through Resend, or Google OAuth. Restrict Google to your Workspace domain on the OAuth client. Emailed codes go to whatever address someone types; the server has no domain allowlist, so keep the instance inside your network or accept open sign-up.
Admin view. The person running the instance sees every account and every site in one list. There is no way to remove an account from that page.
Where data goes. Site files and site data live on your disk and in your Postgres. Sign-in talks to Resend or Google. People's agents see whatever they paste into them.
No model on the server. AI create and voice transcription are off unless you configure them. People keep using the agent they already pay for.
Installing and upgrading. Installing is one script, and re-running it after a failure is safe. Moving an already-running instance to a newer version is a manual job today: the schema is applied on first boot, and the server does not report its own version.
Who can write. Anyone who can load a page can read it. On the shared hostname anyone can also change a site's saved data; the files themselves change only with the owner's API key. Per-person saves, gated by visitor sign-in, exist only on a site that has its own domain.

04.

How it is scoped

Knowing the shape of it up front is what makes it safe to point people at.

Every page is public	Anyone who has the link can read a site. If the instance is on the public internet, treat everything published on it as public.
State, not a database	A site keeps one 1 MB JSON document plus append-only collections. No queries, no schema, no server-side code. Anything past that shape belongs on a different host.
One owner per site	A site belongs to one account. On a site with its own domain, any signed-in visitor can save; there are no roles beyond that.
Google, or an emailed code	Those are the two ways in. Restrict Google to your Workspace domain on the OAuth client. There is no SAML or OIDC beyond Google.
Upgrades are manual	Installing is one script, safe to re-run after a failure. Moving a running instance to a newer version has no tooling yet: the schema applies on first boot only, and the server does not report its own version.
Docker Compose	That is the supported shape, on both Intel and ARM. Running it under Kubernetes is your own exercise; there is no Helm chart.

05.

Try it

simple-host.app runs the same code. Sign in, install the skill, and ask your agent for a page. For an instance of your own, the install script and the published image are in the repository, and an instance serves its own documentation so your people's agents publish to it rather than here.

Source on GitHub Install the skill For hackathons

I am Vineet Sriram. The account count and the $5 a month describe the instance I run at work, as of September 2026.