Deliverd compared with static hosting
A static host will serve the file.
Everything else is yours to build.
Dropping generated HTML on a bucket or a static host is the obvious first move, and for something genuinely public it is the right one. The work starts when the report should be readable by four named people, replaceable next week without changing the link, and explicable to an auditor a year later.
Private by default · Unlimited viewers · No card required
Credit where it is due
What static hosting does well
Cheap and fast
Storage and bandwidth cost very little, the file is served from an edge close to the reader, and you already know how it works.
No opinions
Any HTML you can write, it will serve. Nothing inspects it, rewrites it or has a view about how it should be structured.
Yours entirely
Your account, your domain, your bill. Nothing sits between the file and the reader.
The boundary
Where it stops
The link is the permission
An unguessable URL is a shared secret. It survives forwarding, screenshots and someone leaving, and nothing tells you it has spread. Adding real access control means putting an authenticating proxy in front, which is a service to run rather than a setting to turn on.
Basic auth is not identity
A shared password is not a person. It cannot be revoked for one reader, it does not say who opened the report, and it will not satisfy anyone asking how access is granted and removed.
Publishing again destroys the last one
An overwrite is not a version. Rolling back means having kept a copy yourself, and there is nothing to point at when someone asks what changed between last month's numbers and this month's.
Nobody knows who read it
Request logs, if you keep them, record IP addresses and user agents. That is not the same as knowing that the CFO opened it on Tuesday, and it is not an audit trail.
Expiry, review and revocation are all projects
Time-limited access, comments a reviewer can leave on the report, and a way to withdraw access from one person are each a small system, and together they are the thing you did not set out to build.
Where Deliverd fits
What you get instead
Access decided per request
Every open is evaluated against the report's audience and your organisation's sharing policy. Forwarding the link forwards nothing.
The identity you already run
SAML single sign-on covering the major directories, with verified one-time codes for reviewers who are not in it. No new password anywhere.
Versions, kept and reversible
Publishing again updates the same address and keeps what was there. Compare, restore, or pin the report to one version.
A record, without instrumenting anything
Views, versions, access changes and share links are written to an audit trail you can export, retained to your policy.
Still your domain
Verify a hostname with a DNS record and reports are served from it, with the certificate handled for you.
Questions.
Can I keep using my own domain?
Yes, on Team and above. You verify it with a DNS TXT record and reports are served from your hostname.
Is this just a proxy in front of a bucket?
No. The content origin is separate from the control plane, every version is scanned before it is visible, and access is evaluated on each request against the same rules the database enforces.
What about a genuinely public report?
That works too, if your organisation allows public links. The difference is that it is a decision recorded against the report rather than a property of where the file happens to sit.
Can my CI publish it?
Yes. A REST call or the CLI from any pipeline, with a scoped token. There is also an MCP server if you would rather the agent did it.
Everything after “generate the report”.
Free to start. No credit card.