Jelia.nyc

Jelia.nyc / What I do / Own your stack

WHAT I DO ยท SOVEREIGNTY

Own the stack your business runs on

Mail, files, analytics, chat and monitoring on infrastructure you control, with mail authentication that actually passes. Fewer subscriptions, and no vendor reading your data.

What it is

Most small and mid-sized organisations rent every piece of their working day. Mail from one vendor, files from another, chat, video, analytics and monitoring from four more. Each made sense when it was bought. Together they add up to a large monthly bill, data spread across companies you have never audited, and very little control over any of it.

Owning your stack means running some or all of those services on infrastructure you control: your own server or a cloud account in your name, open-source software, and one login across all of it.

Why it matters

  • Subscriptions creep. Per-seat pricing grows with headcount, and features you need move up a tier.
  • Your data lives on someone else's terms. Those terms can change, and leaving is made deliberately awkward.
  • Mail is often quietly broken. SPF, DKIM and DMARC are missing or wrong, so legitimate messages land in spam and anyone can send mail that claims to be from you.
  • Nobody has the whole picture. When everything is a separate account, nobody knows what the organisation actually depends on.

When SaaS is the right call

Often. If you have no one to look after a server, a hosted service is safer than a neglected one. If you need a vendor's support contract for compliance, buy it. If a SaaS product is good, fairly priced and easy to leave, keep it.

The point is not to self-host everything. It is to decide deliberately, service by service, and to know what it would take to leave. Sometimes my recommendation is to stay where you are and just fix the mail records. That is a perfectly good outcome.

How I do it

  1. List what you pay for and what you use. Each service, its cost, its data and how hard it is to leave.
  2. Decide per service. Keep, replace with self-hosted, or drop. With reasons written down.
  3. Build on one edge and one identity. A single front door for every service, and one login for all of them.
  4. Fix mail authentication first. SPF, DKIM and DMARC on every domain that sends mail, verified at the major providers, whether or not the mail itself moves.
  5. Monitor, back up, document. Before anything goes live: content checks, alerts that reach a person, backups stored off the server, and a runbook.
  6. Move, then cancel. Data migrated and checked before the old subscription is switched off.

In my own estate

Everything on this site runs this way. One Linux server, one nginx edge in front of every site and app, each service in its own container. Mail is self-hosted Postfix and Dovecot with Roundcube webmail and Mailman 3 lists, with SPF, DKIM and DMARC on every sending domain and verified passing at Gmail. Files, calendars and contacts are on Nextcloud. Video is Jitsi Meet with its own media relay. Chat is The Lounge over a self-hosted IRC server. Analytics is Umami, with no cookies and no fingerprinting. Uptime Kuma checks every site every five minutes for real page content. Database dumps go off the server nightly, with weekly full-disk snapshots.

244Mailboxes, self-hosted
39Domains under management
1Edge in front of every service
NightlyBackups pulled off the server

Questions people ask

Is running our own mail a bad idea?

It is work, not a bad idea. Deliverability depends on correct records, a clean sending reputation and someone watching it. If you have nobody to do that, stay on hosted mail and let me fix the authentication records. Either way, the records get fixed.

Who looks after it once it is built?

Your team, from the runbook I leave, or me if you prefer. It is designed so that it does not depend on any one person, including me.

Is it actually cheaper?

It depends on headcount, on what you replace, and on what your time is worth. The audit puts real figures against your own estate before you decide anything.