DEV Community: Bravi

The missing UI for the things you run.

Bravi — Sun, 19 Jul 2026 21:14:43 +0000

Hello world, again.

Last time I wrote about confish, it was a config tool. You'd define a typed schema, your scripts would fetch values from it, and you could nudge a threshold from the sofa without a redeploy. That post ended with "my scripts and bots haven't stopped asking for more" - and what they asked for surprised me. They didn't want more values coming down. They had things to send back up.

Because here's the other half of the automation problem. Every script eventually produces something worth looking at. The scraper finds things. The backup job finishes (or doesn't). The Pi in the loft measures a temperature. Where does all that output go?

If you're anything like me: a Telegram DM to yourself. A JSON file on the box. A spreadsheet with an importer that broke in March. Or another email getting lost in space. Yet another pain point where I saw a pattern forming.

Config was data flowing down to your things. This one's about the data flowing back up.

Push it

Feeds are typed collections of living state you push into confish - crawl results, job runs, incidents, sensor readings. Same philosophy as config: define the fields once (string, number, boolean, date), and your code pushes items that fit them.

from confish import Confish

client = Confish(env_id="a1b2c3d4e5f6", api_key="confish_sk_...")

feed = client.feed("backup-runs")
feed.set("2026-07-14", {
    "host": "homelab",
    "duration_s": 214,
    "status": "ok",
}, ttl=7 * 86400)

set is an upsert on a key you choose, so pushing the same item twice updates it in place - retries are harmless, and a "running" item can become a "done" item without growing a list. The ttl means the item cleans itself up a week later even if the script that pushed it crashes and never gets another word in. Finished runs and resolved incidents just quietly age out.

And like config, a feed's definition belongs to the application while each environment holds its own items - the same code pushes to staging and production with only the API key swapped.

Show it

Here's the part that finally killed that spreadsheet export for me. For each feed you pick a layout - cards, table, compact list, or hero - and assign fields to roles: this one's the title, this one's the badge, sort by that one. The dashboard renders whatever you push. Live, streamed in as items arrive, no refresh.

Hero deserves a special mention: it renders items big and centred, which turns out to be exactly right for singleton state, or a collection with just a handful of items. Here is my "Luckster" euromillions bot using it.

So the loop becomes: your script pushes typed items, and there's a live, decent-looking view of them on your phone. No frontend built, no charting library evaluated at midnight, nothing deployed.

Share it

Then it got out of hand, in a good way.

Any feed can be published at a read-only public link: unguessable URL, noindex, live updates, and it shows the items and nothing else - no app, no environment, no config details. Anyone with the link can install it on a phone or desktop as its own little app (each share is a proper installable PWA).

And when one feed isn't enough, a board composes several - feeds from any of your applications, each section pinned to whichever environment you choose, stacked in the order you set, each rendering with its own layout. Boards start as private drafts; you flip the public link on when it's ready.

Mine is a homelab board: uptime checks in a hero up top, last night's backup runs in a table, open incidents in a list. It's installed on my phone and the tablet, and it keeps itself current while I do nothing whatsoever. A zero-build status page for things that run on a shelf.

(Public links and boards are on the paid plan - pushing and viewing your own feeds isn't.)

Name it

Somewhere in all this, I looked at the product and realised the category had quietly changed underneath it.

Configuration is state flowing down to your things. Actions are commands flowing down. Logs are events flowing up. And feeds - the corner that was missing - are state flowing up. Four pillars, two directions, and none of them is "the feature" with the others as extras. The grid filled itself in, one complaint at a time.

So confish isn't a config tool with add-ons anymore. It's the dashboard your bots, scripts, and cron jobs never had - the missing UI for the things you run. Change a value, dispatch a command, watch the logs land, and see the state your things push back. One place, from anywhere, including the sofa.

Try it

If something you run keeps DMing you JSON - or worse, keeps its results entirely to itself - give feeds a spin at confi.sh. All five SDKs (Go, JavaScript, Python, PHP, Rust) speak feeds, and it's a couple of REST calls if your language isn't on the list.

Thanks for reading.

P.S. There's another way to talk to confish that keeps nagging at me. I'll come back to you on that.

I kept rebuilding the same config panel for my bots, so I built one tool for all of them

Bravi — Thu, 11 Jun 2026 20:28:55 +0000

Hello world.

I love automating things. And if you do too, you probably know how this goes: a Telegram bot here, a price watcher there, a scraper on a Raspberry Pi that sits on a shelf blinking its LED, a handful of cron jobs on a cheap VPS. Dozens of small things quietly doing useful work in the background while you get on with your day.

Here's the thing though - almost every one of them eventually wants tweaking while it's running. A threshold. A toggle. A retry count. Some tiny number you should be able to change in a second, ideally from your phone, on the sofa, whilst watching that intense episode of [insert your favourite TV show here], without opening a terminal.

How it actually goes: you edit a hardcoded value or a .env, push, redeploy, wait for the pipeline to succeed. For a one-character change.

I did that. A lot. And then I built a little control panel for that price watcher. A few inputs, a save button, an endpoint the script could read from.

Then I built a second one for another project. Then a third. Somewhere around the third hand-rolled dashboard doing the same job slightly differently, I admitted this was a pattern and built the thing I actually wanted: one place to manage config for all of my running things.

That's confish.

Shape it

You define a typed schema once per application - whatever fields your thing needs, each with a type (string, number, boolean, date, array). Then you spin up as many environments as you like: staging, prod, one per client, one per Raspberry Pi. Same fields, different values. Your code hits one endpoint and gets typed config back.

Here's a script reading its config:

from confish import Confish

client = Confish(env_id="a1b2c3d4e5f6", api_key="confish_sk_...")

config = client.fetch()
print(config)

And what comes back is already cast to the types you defined - numbers as numbers, booleans as booleans, and so on:

{
  "site_name": "My Application",
  "max_upload_mb": 25,
  "maintenance_mode": false,
  "allowed_origins": ["https://example.com", "https://app.example.com"]
}

Change max_upload_mb in the dashboard and the next fetch sees 50. No redeploy, no rebuild. Suddenly your scraper's politeness delay, your bot's cooldown, your job's batch size - they're all just values you can nudge from anywhere, including that sofa.

Grow it

The schema-and-fetch core was the plan. Everything else got added because my own scripts kept asking for it.

Logs. My scripts were already talking to confish, so I wanted them to tell me how they were doing without me SSHing in to tail a file. Now the 3am cron job can simply report in:

client.logger.info("Scrape finished", {"pages": 14, "new_items": 3})

Entries land in the dashboard, per environment, with levels and context - so when something looks off, the first clue is one tab away instead of one SSH session away.

Webhooks. When config changes, confish can POST to a URL you set per environment, so a service can react instead of polling. The payload includes a changes array of exactly which fields moved, deliveries retry with exponential backoff on 5xx, and every SDK ships a one-liner signature verifier.

Command it

I saved my favourite part for last.

Sometimes I don't want to change a value - I want a running thing to do something. Flush a cache. Rebuild an index. Restart a worker. The usual answer is to expose an endpoint on the app, secure it, open it to the internet, and then quietly worry about it forever. For a personal scraper sitting behind NAT on a home server, that's a lot of ceremony - port forwarding, a reverse proxy, maybe a tunnel, maybe that "temporary" ngrok URL you forget about - all so you can say "please flush your cache."

Actions flip the direction. Your app never listens for anything. It polls. You dispatch a command from the dashboard, it sits in a queue on the environment, and your app picks it up on its next poll - acknowledges it, runs your handler, reports progress, and marks it done or failed. Nothing inbound. No open port, no public URL, no ingress rules. Works the same on a VPS, a Pi, or your old laptop in a drawer.

The raw flow is just a handful of REST calls (poll, ack, update, complete/fail), but each SDK wraps it in a consume() loop with adaptive backoff when idle:

def handler(action, ctx):
    if action.type == "flush-cache":
        ctx.update("Clearing cache", {"keys": 1402})
        return {"cleared": 1402, "took_ms": 84}

client.actions.consume(handler=handler)

So from my phone I can hit "flush-cache" on a box that has no inbound access at all, and watch the result come back in the timeline a second later.

Wire it

There are official SDKs for Go, JavaScript, Python, PHP, and Rust (github.com/confishhq) - each wraps the same REST API, so if your language isn't on the list, plain HTTP works fine.

Try it

If you've got bots, scrapers, or cron jobs that deserve better than a redeploy per tweak, give it a spin at confi.sh - I'd genuinely love to hear what you end up wiring it to. And if you've solved this differently, or you look at the Actions model and think "hmm, not convinced" - tell me in the comments. Half the features above exist because someone (usually me) complained about something, and my scripts and bots haven't stopped asking for more - so watch this space.

Thanks for reading.

P.S. I just shipped dark mode - so when that 3am cron job has something to say, checking on it won't flashbang you.