Rendercase: a review surface for agent-built artifacts

AI agents are increasingly good at producing things that are easier to judge visually than in a transcript: dashboards, diagrams, reports, small interfaces, and interactive prototypes. The awkward part is getting that output from a harness into a browser without turning a temporary preview into an accidental hosting platform. Rendercase is my self-hosted answer to that handoff.

Artifacts instead of pasted markup

A publisher sends Rendercase a ZIP containing HTML, CSS, JavaScript, WebAssembly, and related assets. The service validates and expands the bundle, records an immutable version, and gives authorized users a browser-based review surface. Updates create new versions instead of changing old ones in place, so a review can stay attached to the exact output that produced it.

The same workflow is available through a REST API, a Go command-line client, and Streamable HTTP MCP tools. An agent can publish a small bundle in one MCP call, use a staged upload for larger output, list existing artifacts, and create or revoke share links without learning a deployment-specific storage API.

Untrusted content gets its own origin

Serving agent-generated JavaScript beside an authenticated management application deserves a hard boundary. Rendercase requires separate management and content hostnames. Artifact frames are sandboxed without same-origin privileges, content responses carry a restrictive Content Security Policy, and the content origin receives no management cookies. Short-lived signed tickets authorize bundle reads without making the storage tree public.

ZIP ingestion rejects path traversal, symbolic links, duplicate paths, missing entrypoints, excessive file counts, and oversized expansion. Upload, session, share, and OIDC-state secrets are high entropy and stored as hashes. Public share links can expire, enforce a view limit, and are revocable; redeeming one removes its bearer secret from the address bar.

Self-hosted, but not tied to my infrastructure

The application itself needs PostgreSQL, a POSIX filesystem, and an OpenID Connect provider. The public repository includes a Docker Compose starting point and an example environment file, while production TLS termination, rate limits, backups, and origin firewalling remain explicit operator responsibilities. That boundary matters: Rendercase secures the application and its artifacts, but it cannot make an exposed origin or an overly trusting reverse proxy safe.

The result is deliberately a review and sharing plane rather than a general web host. It gives agents a useful visual output channel while keeping authentication, version history, revocation, storage, and the browser security boundary under the operator's control.

Source and documentation: github.com/kilo666mj/rendercase.