I recently added subscriptions to this blog.
Not in the “build a platform” sense. Just email updates when I publish, optional push notifications, a welcome message, and unsubscribe links. No accounts. No backend. No database. No admin UI.
The goal was simple: let people follow along without turning this into a side project of its own.
This post is about how I did that, and why I deliberately kept it boring.
What I actually needed
Readers should be able to subscribe via email or push. They should receive a welcome message. They should get notified when a new article goes live. Drafts should not notify. Scheduled posts should notify when they become public.
On my side, I didn’t want to run servers, manage users, or build tooling around this. This is a personal blog, not a SaaS product.
So the constraint was clear: solve subscriptions with as little infrastructure as possible.
Why OneSignal
I ended up using OneSignal because it gives me both email and push in one place, handles consent and unsubscribe flows, and doesn’t require me to store subscriber data myself.
The frontend integration is lightweight. Two buttons trigger OneSignal’s built-in slidedown prompts. That’s it. No forms, no accounts, no custom auth.
For publishing, I don’t log into dashboards either. Everything happens from CI.
When I deploy, a small Node script scans my blog posts, reads their frontmatter, skips anything scheduled for the future, and sends notifications for anything new. It also keeps a tiny state file so articles are only announced once.
That’s the entire pipeline.
Welcome emails and publish templates
Initially I was rendering email HTML myself inside the script.
That worked, but OneSignal already has templates and Liquid variables, so I moved both the welcome message and the “new article” email into OneSignal directly. Now the script just sends custom data like title, short description, and URL.
OneSignal handles the rest.
This turned out much cleaner. The logic lives in one place. The styling lives in one place. And I don’t have to redeploy just to tweak copy.
Push notifications are sent separately with a small second call, since templates currently apply to email only. Slightly annoying, but still simpler than building my own system.
Drafts, scheduling, and publishing rhythm
Instead of explicit draft flags, I use the existing date field in frontmatter.
If an article’s date is in the future, it’s treated as unpublished. The notify script skips it. When that date arrives and I deploy, the article goes live and subscribers are notified automatically.
This gives me scheduling for free.
I publish weekly, so my site deploys weekly too (or manually if I need it). That keeps CI noise low and matches my writing rhythm. No need for daily pipelines.
Why this matters
The interesting part here isn’t OneSignal. It’s restraint.
It’s very easy to overengineer something like subscriptions. You can spend weeks building infrastructure around a problem that already has decent off-the-shelf solutions.
For a personal blog, the optimal system is the one you stop thinking about.
Now I can write, deploy, and people get notified. That’s it.
No dashboards. No queues. No maintenance burden.
And honestly, that’s exactly the level of sophistication I want for this.
