Everyone in the company gets a place to build.
Give everyone in the company a place to build.
Someone signs in with your company account, describes a page to the AI agent they already use, and it is live at their own address a minute later. No ticket, no repository, no one to ask.
You run it. One service on your own Kubernetes cluster, against your own database, your own storage and your own identity provider, on whichever cloud you are already on. You decide how it is exposed (AI apps can connect only if they can reach it), and every change and every visit is written down.
Try it in your organization → Set up How to install it What it costs Source on GitHub
What a person gets
An address of their own, and somewhere for a page to keep what it collects.
Every person gets their own name under your base domain, and every page they publish sits at the root of its own address under it: <site>.<person>.<your domain>. Each page is its own browser origin, so it shares no cookies, storage or scripts with a colleague's pages or with the person's other pages.
A folder of files, a JSON document the page reads and writes without a schema, and an asset store for the things that are too big to sit in a document. Enough for a sign-up form, a poll, a project board that draws its own timeline.
Claude Code, Codex, Cursor, ChatGPT, Claude. They install one skill, or connect to the instance's MCP endpoint by signing in, and reach the everyday operations as tools: publish, roll back, share, manage a team.
Signing in is your normal company sign-in. There is no second password, no API key to keep somewhere, and no account for anyone to create or approve.
Who can see what
A new page opens only for the person who made it. They choose who else can: named people or teams, anyone signed in with the link, the company showcase, or, with an admin's approval, anyone who can reach the server.
Name the people who may read it and everyone else gets the same “doesn't exist or isn't shared with you” page as for an address nothing holds (a signed-out browser is asked to sign in first either way). Somebody who should not know it exists cannot tell that it does.
A team is named team-<name> and has its own address, and every member can publish and manage its sites: that is how people work on a site together. Share with a team once rather than maintaining the same list on eleven pages.
A deleted site can be restored for 30 days by default. A new version can be previewed through a one-hour private link before it goes live. A site can be renamed or moved into a team its owner is in (never handed to a person), and old links keep working for people who can open it. Sites nobody uses can be cleaned up after a warning, if you turn that on.
Your identity provider is asked only at sign-in, so disable a leaver there and here. Disabling here (on the admin page, or from HR automation with an offboarding key) ends their sessions, API keys and connected AI apps at once. Sign-ins last 8 hours, or 30 minutes idle, by default. An admin then moves their sites to a team or a colleague, or deletes them, exports everything held about them as one zip, or erases them; an erased person cannot sign back in until an admin allows it.
What it writes down
Every change and every visit, kept where you can read them back.
The action log records who published, who rolled back, who was given access to what, and who took it away. Its rows are hash-chained, so an edit or a deletion shows up, and every event also streams as a JSON line for your SIEM. The access log records what was visited: an owner sees how many people visited, an admin sees who, reads all of it and can export it.
Both are partitioned and pruned after retention periods you set, by a job that runs under the database's owning credential rather than the application's own, so the service that writes the audit trail is not the service that can delete it.
What it runs on
Your cluster, your Postgres, your object storage, your identity provider. The package is the manifests to do it.
Kustomize manifests: a base, and overlays for bringing your own managed services or running everything in-cluster to evaluate it. Any conformant cluster: managed or your own. Ingress and certificates are the cluster's normal ones; cert-manager issues each person's certificate automatically, ideally from your internal CA.
Any managed Postgres, and any S3-compatible object storage. The service refuses to start unless the database connection verifies the server's certificate in full and the storage endpoint is HTTPS, unless you deliberately opt out to evaluate it locally.
Anything that speaks OIDC. Which claim marks an administrator, and which email domains may sign in at all, are yours to set. There is no master key anywhere in the system: an admin is a real person who signed in.
The service connects to the database as a role that cannot alter the schema. Migrations run as the owner, separately, as their own step.
API keys are scoped, publishing only by default, and expire within a year. Each person and team has upload quotas, and uploads can be scanned with ClamAV before they are stored. Every time and limit (retention, link lifetimes, quotas, rate limits) is a setting with a checked range.
Nothing that identifies an installation has a default. If a required setting is missing the process will not start, and it tells you which ones.
What it costs
On a Kubernetes cluster you already run, Simple Host adds a share of one node, a small managed Postgres, some bucket storage and its traffic.
About $70–100 a month on AWS, Azure or Google Cloud, internal only (served over your private network link): about 3.5–5 cents a person.
About $25–45 a month.
List prices, excluding tax, for light to typical use (5 to 20 pages a person a working day), three sites a person, the cluster's existing ingress, and traffic that stays on a private link such as Direct Connect, ExpressRoute or Cloud Interconnect. Serving the internet, a new cluster, high availability or heavy traffic cost more; the calculator shows each, line by line.
Upgrading, backing up, getting it back
The schema is a numbered chain, applied by an init container before the new version serves. Rolling forward is deploying the new image; the migration runs itself.
Sites live in your bucket, and its versioning is their backup; your database's point-in-time recovery covers the rest. Every object is written with server-side encryption, and you can add a key of your own so objects are encrypted before they leave the pod. A command re-encrypts everything under a new key when you rotate it.
A command that brings back any stored version of a site, live or deleted. It is part of the binary, not a runbook someone has to write.
A smoke test ships with it: publishes, updates and rolls back a site, reads and writes its saved data and files, restricts it, and ends with a browser check of the session hand-off between hosts. Run it after every rollout.
Install it
A local cluster first, on your own machine, in about five minutes.
Docker Desktop with Kubernetes turned on, or minikube. One command brings up ingress, certificates, Postgres, storage and a test identity provider alongside the app, and prints two accounts to sign in with. When you have seen it work, the same manifests point at your real database, storage and provider.
The package documents every setting and what happens when it is wrong, gives a checklist per cloud for the pieces a real install needs, and ships its security review: the threat model, what closes each finding, the author's own scripted security tests and their results, and the limitations that are accepted rather than solved. The setup helper prepares Helm values or Kubernetes YAML for your existing cluster, with your company’s sign-in and bucket. Connect an existing Postgres database or install one in the cluster. It gives you the files and commands, with secrets left for you to fill in locally. No independent penetration test has been done yet: it is a side project built by one person, so review it before you depend on it.
Source on GitHub Try it in your organization → Set up Try the hosted one For hackathons