Puls: one dashboard for every site we look after

A website isn't finished when it launches. We wrote that in our post about the PHP vulnerability, and it's the reason for this project. Puls is a dashboard we built for ourselves. It puts every WordPress site, server and Vercel deploy we look after on one screen. Everything in the video and the screenshots is made-up demo data.

The challenge

Looking after sites means knowing a lot of small things at once. Which sites have updates waiting? Did last night's backup run? Is anything down? Did the last deploy go through? Each answer lives somewhere else: a WordPress admin, a server you log in to over SSH, the Vercel dashboard, the Sanity dashboard. Checking them all takes time, so in practice some of them don't get checked.

There are good tools for managing WordPress sites, and good tools for watching deploys. We didn't find one that covers both, plus the servers underneath, in one place.

Our approach

What needs you first

The overview answers one question: what needs attention right now? A site that is down, a build that failed and a server with updates piling up sit at the top, each with a button that takes you to the fix. Below that is every site in one table, whether it runs on WordPress or on Vercel, with its status and the updates it is waiting for.

The heading counts for you. "52 sites, 3 need you" is a better start to the morning than opening twelve tabs.

WordPress, without logging in to each site

Puls talks to our servers over SSH and uses WP-CLI, the command-line tool for WordPress. Nothing has to be installed inside the sites themselves. For each site it shows:

• The updates that are waiting for WordPress, plugins and themes, with a button to run one or all of them
• Every installed plugin, its version and whether it is active
• Backups, with a button to take one now or restore an old one
• Uptime for the last 30 days, and what caused each incident
• The latest lines from the debug log

Staging in one click

Our routine for risky updates is to back up the live site, copy it to staging, test there, then roll out. Puls now does the copying. "Create staging" makes a copy of a site, from how it is right now or from an earlier backup. Two details matter to us here:

• The copy gets an address on our own domain, never the client's.
• The copy can't send email, and it asks search engines not to index it. A test order on staging should never end up in a real customer's inbox.

Servers, Vercel and Sanity

Not everything we build is WordPress, so Puls covers the rest as well.

• Servers. CPU, memory, disk and load for each server, and the sites that run on it.
• Vercel. Every deploy for every project. When a build fails, the error is on the page, and production keeps serving the last good version.
• Sanity. Datasets, usage, webhooks and API tokens, shown next to the site that uses them. A token that expires in nine days is the kind of thing nobody remembers until the site stops updating.

There's also a list of the sites on our own computer, a page for alerts and past incidents, and a search box that opens with ⌘K and jumps to any site or server.

It runs on our own machine

Puls isn't a service we log in to. It runs locally on the computer we work on and can't be reached from anywhere else. The database is local too, and the access tokens and SSH keys it needs are stored encrypted.

That was a deliberate choice. A tool that can update, back up and move client sites holds a lot of access. We'd rather keep that access on a machine we control than put a login page in front of it on the internet.

For the technically curious: it's built with Next.js, Postgres and TypeScript, with a background worker that syncs the sites and runs the jobs.

The result

Puls doesn't do the maintenance for us. It makes it harder to forget, and quicker to do. And because we built it ourselves, when something in our routine is slow, we can make a button for it.