A practical checklist before you self-host your helpdesk

Self-hosting your support tooling is a real commitment — your customer conversations live there, so it’s worth getting the basics right before you migrate. Here’s the checklist we’d actually run through.

Infrastructure

• A server that can run a Laravel app. PHP, a relational database, and a queue worker running in the background — none of this is exotic, but it does need to actually be running, not just installed once.
• A domain with HTTPS. Mail credentials and customer conversations should never travel over plain HTTP.
• Enough headroom for growth. A small team can run comfortably on a modest VPS; plan to scale the queue worker and database separately from the web process once volume grows.

Backups, actually tested

A backup you’ve never restored isn’t a backup, it’s a hope. Before you move real customer conversations onto any self-hosted tool:

• Confirm your database backup includes everything you’d need to reconstruct a thread — not just message bodies, but the ticket numbering, assignment history, and audit log.
• Actually run a restore, on a throwaway environment, before you need it for real.
• Decide your backup frequency based on how much conversation history you’re comfortable losing in the worst case — hourly is safer than daily if your team is high-volume.

Access and credentials

• Rotate your workspace API key if it’s ever been shared somewhere it shouldn’t have been — it’s a gate for the desktop app to even attempt a login, not a secret that grants access on its own, but it’s still worth treating carefully.
• Review who has organization.manage and users.manage before go-live, not after. These are the permissions that can invite new users and change organization-wide settings.
• Decide your Google OAuth setup early if you’re connecting Gmail accounts — it requires a Google Cloud project and a one-time consent screen configuration before real mailboxes can connect.

The questions worth asking before you commit

• Who’s actually responsible for keeping the server updated? A specific person, not “whoever notices.”
• What’s your plan if the server goes down during business hours — how long can your team tolerate not having access to the shared inbox?
• Do you need every department’s mail on one install, or does it make sense to separate teams with very different compliance needs?

None of this is meant to talk you out of self-hosting — it’s genuinely the right call for a lot of teams, especially ones who don’t want customer conversations routed through a third party’s servers. It’s just worth going in with eyes open. If you’d rather skip the infrastructure work entirely, we can host it for you instead.