Self-Hosting Your Trust Layer: A Status Page and a Feedback Board

I run a couple of small products. The thing that quietly costs me users has almost never been a missing feature. It's something fuzzier and harder to put on a roadmap: whether people believe the lights are on.

You can ship the best feature in your niche and still lose someone who decided, with no evidence either way, that you're a ghost town. That decision is the default. People assume abandonment unless you give them a reason not to.

Underneath it are two questions running in the back of every user's head:

1. Is this thing actually working?
2. Does anyone here listen, and do they ship?

Most of us answer neither in public. The infra is fine — but only I can see the dashboard. I read every piece of feedback — but from the outside it looks like it falls into a void. The information that would answer both questions already exists. It's just private.

I think of the fix as a trust layer: a small set of public-facing surfaces whose only job is to answer those two questions before anyone has to ask. And because I'd rather own my stack than rent it, I run that layer self-hosted. This post is how I wire it up.

Why self-hosted, specifically

There's a particular irony in renting your trust layer.

A status page hosted on someone else's SaaS can go down when they go down — and now your "is it up?" page is part of the outage. A feedback board on a third-party platform means your users' words, your roadmap, and your changelog live in someone else's database, behind someone else's export button, priced per seat.

For the surfaces whose entire point is trust, I want the opposite properties: I own the data, I control what's public, and the thing runs on infrastructure I can see. That's not ideology for its own sake — it's just matching the tool to the job. A trust layer you don't control isn't fully a trust layer.

Both halves below are self-hosted, open-source, and ship as a single binary or a Docker image. I build most of my stack in Rust for exactly the reasons you'd guess: small footprint, boring reliability, runs happily on a cheap VM.

Surface 1: a status page you own

When something feels slow or broken, a user has two options. Email you and wait. Or assume you're down and walk.

A public status page gives them a third: check for themselves. It answers "is it just me?" at 3am on a Sunday without a support ticket, and it answers it the same whether you're awake or not.

For a small product this doesn't need to be a wall of green checkmarks maintained by an SRE team. It's one public page showing what's actually running: uptime, recent incidents, the services you depend on, maybe a couple of live metrics.

The one I run is infra.page — a self-hosted, open-source infrastructure dashboard. Think Linktree for your project's infrastructure: it pulls the things you already operate (uptime monitors, GitHub, Sentry, analytics, and more) into drag-and-drop widgets on a single page. It has owner-vs-visitor visibility, so you decide exactly what the outside world sees versus what stays internal, you can point it at your own domain, and since it's self-hosted the page isn't coupled to a vendor that can fail alongside you.

A quick rule of thumb for what to expose:

• Public: uptime, current incidents, a short note after something breaks.
• Public if you can: a response-time or request-volume trend — a visible heartbeat is reassuring.
• Keep internal: anything that's a security signal (exact topology, raw error detail, cost data).

The honesty test for an incident note: would you be comfortable if a user read it during the outage? If yes, publish. Owning a 20-minute blip in public buys more trust than pretending it never happened — they already noticed.

Surface 2: a feedback board you own

The second question is the one I care about most, because feedback tools usually get it backwards.

You can collect feedback flawlessly and still look dead. If every request lands in a private inbox, the person who sent it has no idea whether it arrived, whether anyone agreed, or whether anything happened. From their seat it's indistinguishable from piping to /dev/null.

The fix is to move the loop into the open. Three pieces that reinforce each other:

• A public feature-request board. Users post ideas, vote on each other's, and watch status move from "under review" to "planned" to "shipped." A vote count is a public promise that demand is real and that you can see it.
• A roadmap that's just the board, sorted. You don't need a second tool. "Here's what's planned, here's what's in progress" is the same board filtered by status. The point isn't precision — nobody holds you to dates — it's signal that someone's steering.
• A public changelog. The closing half of every loop: someone asked, you built it, you say so. A steady "what's new" stream is the most underrated trust signal a small product has, because it can't be faked — you either ship or you don't.

The feedback half I run is SeggWat, which is also self-hosted-friendly and gives you the board, the roadmap, and the changelog out of one widget. Its changelog can pull straight from GitHub releases and completed requests, so keeping it current isn't another chore competing with actual work.

The magic is the handoff between the three: a request comes in → collects votes → moves to "planned" → ships → shows up in the changelog → the person who asked sees their idea become a line item. That visible arc is what turns a passive user into someone who recommends you.

The two surfaces are one promise

Here's why I bundle them instead of treating them as unrelated tools.

A status page says: the machine is running.
A feedback board and changelog say: the people are running it.

Users need both. A product that's always up but never changes feels abandoned. A product that ships constantly but keeps falling over feels reckless. Show both, in public, and you've answered the only two trust questions that matter — before anyone had to email to ask.

And neither asks you to manufacture anything. The infra is already up; the status page just points at it. You already read feedback and ship; the board and changelog just turn that outward. The trust layer isn't extra work. It's the work you already do, made visible.

A small starting point

You don't need all of this on day one. The minimum viable trust layer is two links in your footer, both pointed at things already true about your product:

• Status → a self-hosted dashboard like infra.page wired to your uptime monitor.
• Roadmap / Changelog → a feedback board like SeggWat so users can ask, vote, and see what shipped.

Two links. Owned, not rented. You're not promising transparency in a blog post nobody reads — you're just no longer hiding the parts that build trust.

Show people the machine is running. Show them someone's home. Then get back to building.