Agent Doorman

Overview

Agent Doorman stands in front of web projects that are real enough to show a customer and not ready for the world. It resolves the site from the Host header, decides whether this visitor may in, and only then proxies to a container that has no public hostname of its own.

The project behind it stays a plain web app. No PIN page, no noindex policy, no "preview" banner, no allow-list of reviewer emails — none of that belongs in the product you are building for the customer, and with doorman none of it is there.

visitor ──▶ your reverse proxy (TLS, wildcard host)
                 ▼
            doorman        resolve site → crawler policy → gate → proxy → inject
                 ▼
            customer container    http://<network-alias>:<port>   (no FQDN)

What it does

• Four ways in. A shared PIN on an unambiguous alphabet, an email magic link against a per-site allow-list, Keycloak staff SSO for your own people, and a signed share link you paste into an email. Each one mints the same host-scoped cookie; each one is written to the site's audit log.
• Keeps crawlers out. X-Robots-Tag: noindex, nofollow, noarchive on every response including the gate page, a robots.txt doorman serves itself, an injected <meta name="robots">, and an optional user-agent block.
• Says who reviewed. Every unlock appends to an append-only audit log per site — method, subject, time, address. "Someone had the code" becomes "Anna opened it Tuesday at 09:12".
• Preview chrome without touching the project. An optional banner and arbitrary head/body HTML are injected into text/html responses only. JSON, assets, streams and WebSockets pass through untouched.
• Counts the audience without a script tag. Optional per site: page views, sessions and daily unique visitors from the gateway itself, cookieless by default. Returning visitors and retention cohorts are the one thing behind a consent signal, because they are the one thing that needs a memory.
• No admin UI, on purpose. Everything is driven by a REST API so the platform that already knows your customers — arvo.works, agentics.dk, your own tool — owns that surface. Doorman renders only the visitor-facing gate.
• Reviews that turn into changes. The optional Agent-01 widget puts a feedback bubble in the corner of any gated site, and hands the page the reviewer is looking at to Claude or ChatGPT over MCP — live edits in their own tab, then a ticket with the before and after attached.

When to use it

• A customer needs to review a site that must not be found, indexed or shared on.
• Several projects need the same review gate and you refuse to build it four times.
• An engagement has an end date and access should stop with it (expiresAt).
• You want a record of who actually looked, not a shared password nobody tracks.

Get started

• Quickstart — run it locally and put a site behind the gate in about five minutes.
• Self-hosting — the real deployment: wildcard host, certificate, the shared docker network, and per-customer onboarding.
• Admin API — the whole control surface, and how a platform integrates against it.
• CLI — doorman, a command-line client over that API: contexts, four commands to gate a site, and a doctor for the whole path.
• Agent-01 — the review widget and the MCP bridge that lets an assistant edit the page the reviewer is looking at.
• Analytics — audience measurement from the gateway: the three identity rungs, what each figure means, and what it cannot tell you.
• Consent — the cookie contract your own banner writes against, the standard it borrows, and the sources behind every rule.

Status: beta. A single instance is assumed — PIN and share-link use counters are guarded in-process, so two replicas over one volume would make "single-use" mean "rarely reused".