TL;DR: Non-tech teammates can already build useful internal dashboards — often as a single HTML file with AI help. The real problems are sharing, secrets, and control. We solved that with a small publish app, two repositories, and a clear rule: code goes through review; passwords never go into Git.
The Problem
More teams can create internal tools than ever before. Someone in support, ops, or finance asks an AI assistant for “a dashboard that shows X,” downloads one HTML file, and it works on their laptop.
Then reality hits:
- How do we share it? Emailing files and “open this on your machine” does not scale.
- Where do API keys go? Those keys unlock company systems. Pasting them into a file that gets copied around is a security incident waiting to happen.
- Who checked it? One edit can break the dashboard — or worse, leak data. Someone should review changes before the whole company uses them.
- Who can open the link? It should be company people only, not anyone on the internet who finds the URL.
So the issue is not “can we build dashboards?” It’s can we publish them like a product: safely, repeatedly, without forcing every creator to learn Git.
What We Were Aiming For
Think of it as internal websites for ops dashboards, not a full developer platform.
| Goal | In plain terms |
|---|---|
| Easy publish | Drag a file into a simple UI — no terminal |
| Safe secrets | Keys live in a locked vault (database), not in the file people share |
| Review before live | Changes go through a pull request (a proposed change someone can approve) |
| Company-only access | Sign in with work Google account |
| Room to grow | Same design can later support bots, coding agents, and stricter permissions |
The Overall Idea
Creator + AI Publish app Two stores
───────────── ──────────── ──────────
One HTML file ──upload──► Company login ┌─ Git: redacted HTML (via PR)
Save settings └─ Database: config + secrets
Strip secrets
│
▼
After review + merge
│
▼
Shareable company link
│
▼
Server calls APIs with secrets
(keys never shown in the page)
In one sentence: people upload a dashboard; the app saves safe settings in a database, sends a cleaned-up copy of the HTML for review in Git, and only after approval serves a company login–protected link — while secrets stay on the server.
Why Two Repositories? (The Original Thinking)
This was the biggest structural choice. Early on it was tempting to keep everything in one place: the publish website and all the dashboard HTML together.
Here’s why we didn’t.
What each repo is for
| Repository | What’s inside | Who cares |
|---|---|---|
| Platform repo | The publish website, login, “serve this dashboard” logic, secret proxy | Engineers who ship the product |
| Dashboards repo | Only the HTML (and a tiny list of setting names, not values) | Reviewers, automated checks, and later AI agents that edit dashboards |
Why split them
1. Different jobs, different risk
Platform code is “how publishing works.” Dashboard HTML is “what the business sees.” Mixing them means a dashboard tweak and a security fix compete in the same history. Splitting them makes reviews clearer: Is this a product change or a dashboard change?
2. Secrets and HTML must not travel together
If HTML and the app live in one pile, it’s too easy for keys to end up next to the files people download and copy. A dedicated dashboards repo has a hard rule: only cleaned-up HTML. Real keys never belong there.
3. Review that non-engineers can still understand
A pull request on a dashboards-only repo looks like: “here’s the new support board page.” Reviewers aren’t wading through unrelated website code. That matches how the team actually works — ops owns the dashboard content; engineering owns the platform.
4. Safer automation later
We knew we might want Slack bots or coding agents to open dashboard updates. Giving an automation access to only the dashboards repo is much safer than giving it keys to the whole platform.
5. Cleaner automated checks
Checks on dashboards can be simple: “is there one HTML file?”, “does this look like a leftover API key?”, “is the file too big?” Those checks don’t need to understand the full website.
Tradeoff we accepted
| Two repos | One repo |
|---|---|
| Slightly more setup | Simpler at first |
| Clear ownership and safer automation | Faster to start, messier later |
| Platform releases don’t churn when dashboards change | Every dashboard edit looks like a product change |
Original thinking in short: treat dashboards like content and the publish app like product. Content gets a content repo. Product gets a product repo. Secrets get neither — they get the database.
How Publishing Works (For Humans)
- Sign in with your work Google account.
- Upload one HTML file (title, optional team label).
- The app reads any preview settings used for local testing, saves them for that dashboard, and strips secrets out of the copy that goes to Git.
- It opens a pull request — a proposed change — on the dashboards repo.
- Someone reviews and merges.
- The owner marks it live.
- Teammates open a share link, sign in, and use the dashboard.
Updates follow the same path: new upload → update the open pull request (or open a new one) → merge → live.
Security — What Can Go Wrong, and How This Helps
| Risk | What it looks like in real life | How the design responds |
|---|---|---|
| Keys in the file | HTML emailed around with an API key inside | Keys saved encrypted in the database; Git only gets placeholders |
| Keys in the browser | Anyone can “View Source” and steal a key | Page only gets non-secret config; the server calls external APIs on your behalf |
| Open link on the internet | Company data on a URL with no login | Company Google sign-in before viewing |
| Silent go-live | Broken or unsafe change hits everyone at once | Pull request + merge before live |
| One mega-repo blast radius | A bot or leak touches the platform and every dashboard | Two repos; automation can be limited to dashboards only |
The simple rule we tell creators:
Config (folder IDs, public URLs) can appear on the page. Secrets (API keys, tokens) never do — the server holds them.
The same HTML can still work on a laptop for preview: it uses a local preview block when it’s not on the platform, and platform-provided config when it is. Creators aren’t maintaining two different apps.
Architecture at a Glance
┌─────────────────────────────────────┐
│ Platform app │
Creator ───────► │ Upload · Settings · Google login │
│ Serve link · Secret proxy │
└───────────┬─────────────┬───────────┘
│ │
save config │ │ redacted HTML
+ secrets │ │ as a pull request
▼ ▼
┌──────────┐ ┌──────────────┐
│ Database │ │ Dashboards │
│ (locked) │ │ Git repo │
└────┬─────┘ └──────┬───────┘
│ │
│ after merge │
└───────┬────────┘
▼
Teammate opens
share link (+ login)
Three ideas to remember:
- Git holds the dashboard pages (after review).
- The database holds settings and secrets (encrypted).
- The platform app is the only door: login, upload, serve, and proxy.
Tradeoffs (Honest Ones)
| Choice | Upside | Downside |
|---|---|---|
| Pull request before live | Safer, reviewable history | Not “instant publish” |
| Secrets in the database + server proxy | Keys stay off pages and out of Git | Slightly more setup for API connections |
| Two repositories | Clear ownership, safer bots later | Two places to understand |
| Company sign-in only | Fits internal tools | Not for public / customer-facing sites |
| Single HTML dashboards first | Matches how people actually create with AI today | Multi-file apps come later |
We deliberately deferred finer team permissions, Slack bots, and heavy hosting complexity. The skeleton — two repos, secrets out of Git, company login, review before live — is what has to be right first.
Infrastructure (Small Picture)
You don’t need a huge cloud setup for this.
| Need | Typical choice |
|---|---|
| Run the publish website | A small hosted web service (for example on Google Cloud or AWS) |
| Database for settings and secrets | Managed Postgres |
| Keep the platform’s own production secrets safe | The cloud provider’s secret store |
Traffic is light for an internal pilot — tens of dashboards, a handful of people using any one at a time. Cost is usually dominated by the database staying on, not by the website. Google Cloud and AWS both work; pick wherever your company already lives.
Takeaways
- The bottleneck isn’t building dashboards — it’s sharing them without leaking keys or skipping review.
- Treat dashboard HTML as content and the publish website as product: that’s why two repositories beat one pile of everything.
- Security for humans: keys in the vault, pages for viewers, review before live, company login on the link.
- Start simple on infrastructure; invest first in the rules of the road — where HTML lives, where secrets live, who can open the URL.
If your non-tech teams are already creating internal dashboards, you don’t need to stop them — you need a front door that makes the safe path the easy path.
Top comments (0)