Self-hosting your help desk: when it’s worth it

Self-host a help desk when policy or regulation requires that support data never leaves infrastructure you control, or when your sub-processor list has to be as short as possible. The trade-off is concrete: you swap a subscription for operational ownership of deploys, backups, upgrades, and email deliverability. For most teams, a regional cloud deployment gives the same compliance story without that burden — self-hosting earns its keep when the requirement is absolute.

Why teams self-host

Control and compliance, mostly. Running support on your own infrastructure — Node, MongoDB and your own AWS SES account — keeps data in your VPC and satisfies the strictest data-residency requirements. The recurring reasons:

• Regulatory mandate. A contract or law requires data stay in a specific environment or jurisdiction you operate.
• Shortest sub-processor chain. Self-hosting collapses the vendor list to infrastructure you already run — useful when answering the questions in the data residency checklist.
• Network isolation. Support runs inside a VPC with no inbound public dependency you don't control.
• Data ownership. Backups, retention, and deletion are governed entirely by your own policies.

What you actually run

The deployment is a standard Node service plus a datastore and an email path. Concretely:

• App tier. The Node application, typically behind a reverse proxy for TLS termination, run as multiple processes or containers for availability.
• MongoDB. Your primary store for tickets, contacts, and messages — either self-managed or a managed Mongo in your own account.
• Object storage. A bucket for attachments, in the region you choose.
• AWS SES. Outbound email through your own SES account, signed as your domain with BYODKIM.
• Inbound mail. A route from your MX or an IMAP mailbox into the app so replies thread correctly.

None of this is exotic, but it is yours to keep running. Plan for it like any other production service.

The cost trade-off

You trade a subscription for operational ownership: deploys, backups, upgrades. For many teams that’s worth it; for others, managed data residency in US or EU regions is the better balance. The cost that surprises people is rarely the servers — it's the engineering time. Budget for the on-call rotation that now owns support uptime, the upgrade cadence to stay current on security patches, and the deliverability tuning that a SaaS would otherwise handle for you. Note that Cherryrise pricing is per agent, with no per-resolution or deflection fees, so the cloud comparison is predictable rather than usage-metered.

Email is the hard part

Hosting the app is straightforward. Making mail land in the inbox is where self-hosting teams spend the most time. The fundamentals don't change just because you run the box:

• Authentication. SPF, DKIM, and DMARC all have to align — see the breakdown in SPF vs DKIM vs DMARC.
• Domain reputation. A new SES account starts in a sandbox and needs warming; reputation is earned over time, not configured.
• Bounces and complaints. You have to consume SES feedback for bounces and complaints and suppress bad addresses, or your reputation erodes.
• Why replies go to spam. Most deliverability failures trace back to auth or reputation — the patterns are in why support replies go to spam and the broader deliverability guide.

This is exactly the work BYODKIM is meant to keep clean: you send signed as your own domain through your own SES, so the authentication story is yours end to end.

The ongoing operational work

Self-hosting is a commitment, not a one-time install. The recurring tasks:

• Backups of MongoDB and object storage, tested by actually restoring them.
• Security patching and version upgrades on a regular cadence.
• Monitoring and alerting so a stuck queue or full disk pages someone before customers notice.
• Scaling the app tier as ticket volume grows.
• Rotating secrets and managing TLS certificate renewal.

If your team already runs production services this is familiar ground. If it doesn't, that's a strong signal to use a managed deployment instead.

When it’s worth it

Self-host when regulation or policy requires data never leave your control. Otherwise, regional residency usually gives you the compliance story without the ops burden. A quick way to decide:

• Self-host if a mandate requires it, you need the shortest possible sub-processor list, and you have the operational capacity to own it.
• Use regional cloud if your real requirement is data location and isolation, and you'd rather spend engineering time on your product than on email reputation.

Either way, insist it’s isolated, fails closed, and enforces RBAC server-side.

A middle path: regional cloud

For most teams the honest answer is a regional cloud deployment. You pick a US or EU region, get per-workspace isolation, and let the vendor own deliverability, patching, and uptime. You still get a multi-tenant platform with strict isolation and your data in a known jurisdiction — without becoming an email administrator. Reserve self-hosting for the cases where "in our environment" is a hard line, not a preference. If requirements tighten later, the path from regional cloud to self-hosted is a deployment change, not a product switch — review the options on the security page.

Frequently asked questions

What infrastructure does self-hosting require?

A Node application tier, a MongoDB datastore, object storage for attachments, and your own AWS SES account for outbound email. Inbound mail routes from your MX or an IMAP mailbox into the app. It runs like any standard production service in your own environment.

Is self-hosting cheaper than cloud?

Not usually, once you account for engineering time. The servers are the small cost; the real expense is the on-call rotation, upgrade cadence, and deliverability tuning you now own. Self-hosting is chosen for control and compliance, not to save money.

What's the hardest part of running it yourself?

Email deliverability. Hosting the app is routine, but getting mail to land in the inbox means warming a new SES account, keeping SPF, DKIM, and DMARC aligned, and consuming bounce and complaint feedback. BYODKIM keeps the authentication story under your own domain.

Can I start on cloud and move to self-hosted later?

Yes. Because it's the same platform, moving from a regional cloud deployment to self-hosted is a deployment change rather than a migration to a different product. Many teams start managed and switch only if their compliance requirements harden.