Plan
Make plans easier to follow
Publish project plans, launch checklists, dashboards, and research summaries as clear websites instead of another attachment.
Ship in minutes
Describe what you want, let your coding agent build it, and get a link you can share with teammates who can open, use, and build it with you.
Your first site
Do one step at a time. Install once, describe what you want, paste the prompt into your coding agent, and come back for the link.
Give this request to the ChatGPT desktop app on Mac or Windows, Claude Code, Cursor, or another coding assistant. It will explain what it plans to install and ask you to approve before changing anything.
Paste it into your coding agent and approve what it asks for. When it says the skills are installed, come back here.
Paste this to your coding agent. It answers yes or no.
Do I have the Simple Host skills installed? Look in the folders you load skills from for simple-host, simple-host-builder, and fix-paths-for-subpath-hosting. Answer yes or no in one line. If yes, tell me the version. Do not install or change anything.
You do not need to read this. The prompt checks the released version and trust boundary before approval; existing installations use their verified updater.
Install the three Simple Host skills from {{SIMPLE_HOST_ORIGIN}}
Browser platform is unknown. Detect and verify the actual operating system and shell before continuing.
First check whether you can actually read and write files on my computer. If you cannot — an ordinary ChatGPT chat window cannot — then stop, do not guess, and do not work around it. Tell me plainly that this has to run in the ChatGPT desktop app's coding agent, the part that can open a folder and edit files, and that I can ask my platform team if I cannot find it.
Work out my home folder using the shell you are actually in: $HOME on macOS or in PowerShell, %USERPROFILE% only in cmd. Install into exactly one folder:
Claude Code <home>/.claude/skills
ChatGPT or Cursor <home>/.agents/skills
1. Read {{SIMPLE_HOST_ORIGIN}}/skills/version as JSON. Download the /skills.zip it names, then check the file's size and SHA-256 against that manifest.
2. Copy the three folders (simple-host, simple-host-builder, fix-paths-for-subpath-hosting) straight into the skills folder, with no extra folder wrapped around them. Do not run anything out of the archive. Confirm all three SKILL.md files exist and none still says {{VERSION}}.
3. From the exact skills root you selected, directly read <selected-root>/simple-host/references/account-recovery.md completely. Do not rely on the newly copied skill being discoverable yet. Follow that file to get me signed in and holding an API key, including its existing-config check, exact-destination preflight, and save-and-verify steps.
4. Tell me my username, and that I may need a new chat or an app restart before the skills show up.
Before changing anything, tell me conversationally in one or two sentences that Simple Host will install its tools in the selected skills root and save publishing access in the resolved config path, then wait for one yes covering both. Still show and honor every approval required by the host, tool, sandbox, or operating system. If anything fails, say what happened without exposing credentials and tell me to ask my platform team.
Write it like you would to a colleague. Simple Host turns that one sentence into a detailed brief your coding agent can build from — you never write the technical prompt yourself.
Your agent will ask a few questions, then build the site. Which one are you using?
That's everything on your side. Go do something else for a bit — it takes a while.
When your agent finishes, it gives you a link. Every site you publish
is listed on your own address, where your-name is your username:
https://your-name.<this server>/
Your sites and your teams' sites are on your dashboard. A new site opens only for you (or your team) until you choose who else can see it.
Share it to build together. Publish under a team and everyone in it works on the same site — one link, one version history, and you can roll back any change. That is the point of publishing here rather than sending a file around.
See everything you can doWhat you can make
Simple Host is useful for the work between a document and a full product: quick to share, polished enough to use, and easy to update.
Plan
Publish project plans, launch checklists, dashboards, and research summaries as clear websites instead of another attachment.
Prototype
Share prototypes, workflow demos, and lightweight tools at a real link, then improve them as the conversation moves forward.
Coordinate
Make an interactive Gantt chart where teammates can update dates, owners, dependencies, and progress from the published page.
Use the simple-host-builder skill to turn my project plan into an interactive shared Gantt chart. Let teammates update task dates, owners, dependencies, and status. Save only that project state with Simple Host's versioned shared state. Never store passwords, secrets, API keys, or personal data.
Anyone who can open the site can read and change its shared state. Never save passwords, secrets, API keys, or personal data in it.
Made for shared work
Publish under a team and every member works on the same site, while you choose who can open it: only the team, named people, or the whole company.
Good to know
Simple Host stays out of the way, but these details help before your first publish.
Ask the platform team that runs Simple Host. If your coding agent gets stuck installing or publishing, paste what it told you — that is usually enough to sort it out.
No. A new site opens only for you (or your team). You then choose who can open it: named people or teams, anyone in your company with the link, or also the Showcase and search. Opening a site to people without a company sign-in needs an admin's approval.
Only information your company allows to be shared internally, plus anything that is already public. Do not host confidential material, personal data, or customer data. A site starts visible only to you, but treat anything you publish as something your whole company could see.
No. Accounts come from your company sign-in, and only you, or the members of the team that owns it, can change a site. Every deploy is backed up to S3 with the last five versions retained by default, so any change is one revert away, and access logs are available to security on request.
Each site gets a JSON store — that is what makes shared demos and trackers work. Everyone who can open the site can read and change it, so treat it as collaborative rather than protected, and never store passwords, secrets, or personal data in it. The last 20 versions are kept, so a bad change can be undone.
Prototypes, demos, internal tools, dashboards, and trackers — and as a canvas for AI-generated pages. It is static-only, so it is fast by construction and nothing runs server-side; up to 100 MiB per upload. Support and takedowns go through your platform team.
No. Accounts come from your company sign-in. The first time your agent needs access, it asks you to sign in: through the Simple Host connector, or with a link where you create an API key.
Yes. Each site gets its own shareable URL, and your assistant can list, update, inspect, or roll back the sites you own and your teams' sites.
Each site is served at the root of its own address, but may be served from a subpath of your address while that address is being set up. The deploy skill uses relative paths, which work at both, handles the right base-path build for supported frameworks, and can fix plain HTML paths when needed.
The install request falls back to the first-party ZIP, verifies its exact byte size and SHA-256, checks the archive, and installs all three skills into the one directory your assistant actually uses. The Install page also has manual steps.