display.dev - Publish agent-generated HTML behind company auth
by•
display.dev is the easiest way to publish agent-generated artifacts behind company authentication. One command gives your HTML and Markdown files a permanent URL. Your colleagues sign in securely via OTP or Google/Microsoft SSO, and drive iteration with in-line comments.
Replies
Hey everyone!
I'm Ott, co-founder of display.dev.
A month ago @carlrannaberg came to me with a problem. In his constant use of Claude Code, his agents were building him beautiful HTML artifacts – spec sheets, interactive plans, reviews, etc. Sharing them with colleagues, however, was a mess – screenshots or PDFs to Slack, having others open HTMLs and run them on localhost – nothing good really.
The problem clicked immediately. Anyone building with agents long enough hits this wall.
So we built display.dev – one command publishes any HTML or Markdown artifact behind your company's auth. Your team signs in with Google, Microsoft or a one-time password. They see the artifact exactly as the agent built it. No static and inconvenient screenshots, no GitHub accounts, no $320/month Vercel add-ons.
Here’s what makes it actually useful day to day:
> One command, one click or your agent does it for you – CLI, web app or MCP. Publishing happens wherever you already are – your terminal, your browser or inside Claude Code/Cursor/etc. You get back a permanent URL.
> Gated by default, public when you want – Google + Microsoft SSO or OTP. Everyone at your company gets in, nobody outside does. And if you want to share something with the public, simply change the visibility setting.
> Comments your agent can read – Teammates drop inline comments. You and your agent can read them, update the artifact and resolve the thread. The thing stays alive instead of dying as a one-shot output.
> Your published artifacts are natively agent-readable – agents can pull the content as markdown from any published link, so there's no manual back-and-forth copy-pasting or importing-exporting.
> Stats and audit logs – View counts per artifact, plus audit logs of exactly who accessed what. Useful when you actually need to know if your exec opened the doc.
> Publish without an account – agents can publish unauthenticated using “curl”. The response is a public preview URL anyone can open and a single-use claim URL. Later, you can claim the URL for the organization, if you sign up or in.
> Unlimited viewers, flat price – No per-seat cliff when you share with your PM, exec and legal team on the same day. (Also, a free and a solo tier exist!).
We've been using display.dev daily ourselves – privately sharing analysis docs and ideas that Claude has built, collaborating on things fast. It's made a real difference to how we work.
Happy to answer questions – on the product, the problem and alternative solutions!
Outfunnel
Awesome that someone finally built this!
@andruspurde Appreciate the support!
This is a perfect utility for the current 'coding agent' era. Being able to instantly host agent-generated artifacts behind SSO is much cleaner than passing around raw HTML files. Does display.dev support custom domains for these permanent URLs, and is there an option to expire links automatically for temporary artifacts?
@rivra_dev Thanks, Rivra!
I agree that it's a much cleaner flow – so much easier to share a simple URL and collaborate within the artifact.
On your questions:
> Custom domains – we're introducing them shortly, they're planned to come out in the next few weeks. Keep an eye out on our channels or page.
> Automatic expiry – not at the moment, but currently it's as simple as telling your agent to delete it and it's done.
I like how this is both secure AND lightweight, a rare combination! Cool stuff!
@double_u_d thanks, Kirill!
The screenshot-or-PDF-to-Slack pain point is the right thing to fix — agent-generated artifacts only feel like artifacts when they have a stable URL someone can come back to. The SSO/OTP gate is doing two jobs at once: keep strangers out, and (more subtly) tell the agent which audience it's writing for, which I think is underrated.
I hit a related shape building PolyMind, a small alert tool that watches Polymarket and pings me when a position shifts in a market I care about. The artifact problem there is the same: an alert is only useful if it lives somewhere it can be revisited and annotated by the trader after the fact — a one-shot Slack ping is essentially fire-and-forget. Curious whether display.dev's comment layer is intended to drive iteration on the artifact itself, or whether it's more of an asynchronous review channel for humans to triangulate around what the agent produced.
@samir_asadov Thanks for the thoughtful comment – the alert tool sounds very useful.
The comment layer can be used for both purposes, and internally we use them for both, depending on the use-case. Certain docs have specific human-agent feedback loops (e.g. "fix this") that the agent can resolve; others have a discussion in them (e.g. "what do you think works best here, Carl?"). Both are possible and useful.
What got me was the MCP part, it means the agent handles the publish step itself from inside the chat, so there's no jumping between tools or touching a hosting config. The fact that users just sign in with their existing Google or Microsoft account without creating anything new is a genuinely so impressive. I also loved the fact that the url is not like public url which is what happens when you publish through claude code, so that security and authentication is maintained through and through. Curious how the comment-to-agent feedback loop works in practice, does the agent pick up all comments automatically or do you have to trigger it manually?
@radx_ishan Great points!
The comment-to-agent loop depends on your agent instructions – our service works provides the comment listing tools for the agent. You can instruct your agent to pick up and resolve comments as they come automatically, or you can trigger it manually to review the comments and resolve them.
@ottilves That actually makes a lot of sense. I think the part I really like is that it’s not pretending to be “AI magic”, you’re exposing the tooling and letting people decide how autonomous they want the workflow to be. The automatic comment pickup and resolution flow sounds especially cool for async collaboration because that’s usually where context gets lost between people and tools.
The idea is cool, but I’m pretty sure that in upcoming releases Claude Code and Codex will solve this problem and create similar built-in tools for team collaboration.
@natalia_iankovych Thanks for the comment! Sure I accept there's a likelihood of that happening in part. That said, there are a few small but important details that might make someone want to choose us anyway:
authentication via Claude/OpenAI will require everyone in the org to have a license, something that we don't mandate – one monthly fee covers every user.
cross-platform use – the authentication works on the company level, which means that it doesn't care which agent created the artifact; if someone's using different agents/AI platforms in their daily work, others will still have access.
Anyway, there's a lot that's in the works and will get shipped soon, and hopefully we'll keep making it more and more useful for organisations.
the MCP integration is a game changer. being able to tell claude 'hey, publish this so the team can see it' without leaving the chat interface is exactly how 2026 should feel. clean ui and very clear mission. congrats @ottilves @carlrannaberg
software is finally catching up to how we actually build with ai. display.dev feels like the 'missing manual' for claude code and cursor users. see you at the top of the leaderboard @carlrannaberg
Once the user is logged on, can their identity be passed so that when we fetch the data, we can customize it?
PS: Please add a "Contact us" page :)
@jay_janarthanan1 Can you explain in a little more detail what you mean about passing on the identity for customization?
We'll make sure to add a contact us page - a very good point!
@ottilves When a user is authenticated, I assume the app will receive a JWT token. Let's say I have a REST fetch command in my HTML. If the token can be dynamically passed to the REST body, I can return the correct data. Basically, I want to know who is authenticated.
@ottilves @jay_janarthanan1 Can you explain what would be the use case of knowing who is authenticated? Because we have audit logs, which show all the actions the users took on the artifact, including views. Would these cover your needs?
@ottilves @carlrannaberg Assume they are requesting data from Salesforce using the Rest end point . We only want to return data belonging to them.